[Slackbuilds-users] Redis, one fork, two forks, and a spoon.

[Arnaud via SlackBuilds-users]

Hi fellow Slackers,

some of you may know that the Redis database took a turn out of free
software.
Since it is widely used, there are already two forks about it.
One is named redict, and also forks hiredis to hiredict, and uses its own binary
names : redict-server, redict-cli, etc.
The other one named valkey with less names changes, probably aiming at being a
drop-in replacement.

As maintainer of Redis, I've decided to allow us to try them, hence I've just
submitted three new packages : redict, hiredict and valkey.

I made the valkey build so that it uses valkey names, for data, logs, and
binaries.
So you would actually be able to have all of the three running at the same time.
Beware of the default port of 6379 for all three of them, I've added a build
option to change this default port inside the packages.

All of them comes with their own {redis,redict,valkey}-cli binary, which can
connect to any of the databases, providing the right port number (always at the
default of 6379 though), compatibility being - for now - at 100%.

Here, I've tried my best to allow for having all three of them alongside one
another on a single box, mainly for testing and validation purposes.

Redis is a nice project, and its build is fairly clean, so the job wasn't very
difficult and everything works pretty fine here, at home.

Let the future tell us what will happen to them all!

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] tracking down SBo "dependencies"

[Arnaud via SlackBuilds-users]

> > However, tracking potential breakages could be done using hoorex.
> 
> Not in this case...
> 
> > # hoorex -i dav1d This'll list all installed packages requiring directly
> > dav1d.
> 
> And there's the problem... Neither vlc nor libheif (nor maybe others I
> haven't found yet) *directly* require dav1d, so hoorex doesn't list them.

So I've looked again, and sbbdep is quite useful.
So my libheif is built with dav1d, but not my VLC.
And then :
$ hoorex -i dav1d
dav1d libheif
$ sbbdep --whoneeds /var/log/packages/dav1d-1.4.0-x86_64-1yth
dav1d-1.4.0-x86_64-1yth
libheif-1.17.6-x86_64-1yth

Which returns what is relevant.
Then I rebuilt VLC, which might probably have been built without dav1d.
And then :
$ sbbdep --whoneeds /var/log/packages/dav1d-1.4.0-x86_64-1yth
dav1d-1.4.0-x86_64-1yth
libheif-1.17.6-x86_64-1yth
vlc-3.0.20-x86_64-1yth

So it does work, for binary dependencies.
I know that either libheif or vlc could require rebuilding after an update of
dav1d.

To be noted :
I haven't tested building vlc with libdav1d.so.6, then updating dav1d to
libdav1d.so.7, and asking sbbdep.
It might fail, because the link is broken, vlc wouldn't show a link to dav1d
since it doesn't link to libdav1d.so.7

But, you could update sbbdep database before an update, and ask without updating
the sbbdep database.

Let's say, it might not be perfect, and may require something on top of it, to
detect, through comparison of dependencies before and after an update, what
links may have been severed.
As I said, I didn't test such a situation.


For perl and python (and haskell, and... maybe other), it's less problematic,
since most dependencies are SBo-related, hence we have a dependency tree
available. That would be more True on stable 15.0 where python/perl and system
modules aren't very updated, but could be pretty wrong on -current.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] tracking down SBo "dependencies"

[Arnaud via SlackBuilds-users]

Well, you've still got sbbdep then, in reverse mode it could help you.
It does calculate a full dependency tree, binary only, so for like python 
packages it won't work, but in your case it should.
I never used it like that though, so it's kind of a guess.

 - Yth

Le 29 février 2024 19:22:49 UTC, Jim  a écrit :
>Hi Arnaud,
>
>On Thu, Feb 29, 2024 at 16:53 (+), Arnaud via SlackBuilds-users wrote:
>
>> Tracking the breakage might require launching the app,
>
>Trying *every* program after upgrading a library seems like a bit of a
>non-starter.
>
>> or checking with ldd.
>
>After seeing a complaint appear in my terminal window I ran ldd on a lot of
>things (such as the vlc binary and the libraries of libheif) and it didn't
>show up.  However, what I didn't look at immediately, which I now know was
>the place to look, is /usr/X11/lib64/vlc/plugins/codec/libdav1d_plugin.so,
>which is (presumably) the thing that whined after I upgrades dav1d.
>
>Similarly /usr/X11/lib64/libheif/libheif-dav1d.so has a reference to
>libdav1d.so.7.
>
>> However, tracking potential breakages could be done using hoorex.
>
>Not in this case...
>
>> # hoorex -i dav1d This'll list all installed packages requiring directly
>> dav1d.
>
>And there's the problem... Neither vlc nor libheif (nor maybe others I
>haven't found yet) *directly* require dav1d, so hoorex doesn't list them.
>
>Cheers.
>Jim
>
>> Le 29 février 2024 16:12:14 UTC, Jim  a écrit :
>>>I recently upgraded the SBo dav1d, which upgraded the library from
>>>libdav1d.so.6 to libdav1d.so.7.
>
>>>Unfortunately, a couple of other SBo packages (libheif and vlc) had
>>>references to (specifically) libdav1d.so.6, which caused them to whine a
>>>bit.
>
>>>It was easy enough to recompile libheif and vlc after I found the problem,
>>>but this got me wondering...
>
>>>Does anyone have an easy way of tracking down this sort of "breakage" which
>>>might happen when upgrading an SBo package?
>
>>>Thanks.
>>> Jim
>>>___
>>>SlackBuilds-users mailing list
>>>SlackBuilds-users@slackbuilds.org
>>>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>>>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>>>FAQ - https://slackbuilds.org/faq/
>
>
>> -- 
>
>> ___
>> SlackBuilds-users mailing list
>> SlackBuilds-users@slackbuilds.org
>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - https://slackbuilds.org/faq/
>
>
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] tracking down SBo "dependencies"

[Arnaud via SlackBuilds-users]

Tracking the breakage might require launching the app, or checking with ldd.
However, tracking potential breakages could be done using hoorex.
# hoorex -i dav1d
This'll list all installed packages requiring directly dav1d.

 - Yth.

Le 29 février 2024 16:12:14 UTC, Jim  a écrit :
>I recently upgraded the SBo dav1d, which upgraded the library from
>libdav1d.so.6 to libdav1d.so.7.
>
>Unfortunately, a couple of other SBo packages (libheif and vlc) had
>references to (specifically) libdav1d.so.6, which caused them to whine a
>bit.
>
>It was easy enough to recompile libheif and vlc after I found the problem,
>but this got me wondering...
>
>Does anyone have an easy way of tracking down this sort of "breakage" which
>might happen when upgrading an SBo package?
>
>Thanks.
>Jim
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] hw-probe should be arch independent

[Arnaud via SlackBuilds-users]

Hi fellow slackers.

I'd guess that x86_64=UNSUPPORTED means it is unsupported.
Which is not the case, it works.
It should be left empty.

Most builds have a unique source for all arch, noarch is the same, with only 
DOWNLOAD and MD5SUM.

Best regards,

 - Yth.

Le 27 février 2024 09:40:39 UTC, Dimitar Nikov via SlackBuilds-users 
 a écrit :
>Hi Erich,
>I hope you are doing well.
>
>Thank you for your feedback, it is much appreciated.
>
>On 2024-02-26 21:38, Erich Ritz wrote:
>> Hello Dimitar,
>> 
>> hw-probe looked interesting so I tried building it.  The build failed as 
>> x86_64 is "UNSUPPORTED".  But the Debian package is arch independent, so I 
>> don't know why you have this restriction.
>> 
>
>Slackware package is arch independent too, hence x86_64 download is marked as 
>unsupported. I do believe this is correct for acrh independent packages.
>There should be no issues building the package using SlackBiulds script.
>Would you mind providing me more details about the errors you are getting when 
>trying to build it please?
>Thank you.
>
>> More than that though, I don't think you need to repackage the Debian 
>> binary.  The project supplies a Makefile. The software is just a perl script 
>> that gets installed to /usr/bin/hw-probe.
>> 
>
>Makefile provided by upstream does not make any difference as it does a simple 
>mkdir -p / copy (when installing) and rm -f (when uninstalling). The idea to 
>repackage Debian package have a man page and I am little bit lazy (as any 
>other programmer) :D
>
>> Upstream doesn't provide a man page, but it looks like Debian just uses 
>> help2man, which Slackware has.
>> 
>
>Nice shout, will move to help2man in next version update.
>
>> Here is the contents of the Debian package (I just exploded the Debian 
>> package tarball):
>> 
>> $ tree usr
>> usr
>> ├── bin
>> │   └── hw-probe
>> └── share
>> ├── doc
>> │   └── hw-probe
>> │   ├── README.md.gz
>> │   ├── changelog.Debian.gz
>> │   └── copyright
>> └── man
>> └── man1
>> └── hw-probe.1.gz
>> 
>> 6 directories, 6 files
>> 
>> So it shouldn't be too difficult to just grab the upstream source to 
>> generate the package.
>> 
>
>Yes, you are absolutely right. I will move to upstream source in the upcoming 
>update.
>
>> Erich
>
>Best regards,
>Dimitar
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] unattended package python3 3.7.2

[Arnaud via SlackBuilds-users]

Can't it be some leftovers from a previous rsync ?
Because there's no python3 package since 15.0, as it has been a part of 
Slackware stable since the release of 15.0.
 - Yth

Le 11 février 2024 11:35:22 UTC, "viel.los...@gmail.com" 
 a écrit :
>Hi,
>I think i found an unattended package. python3 3.7.2
>
>from last update with rsync, the python3.tar.gz seems that is old. I found it 
>because don't have an extracted dir with the SlackBuild file and others ... 
>and that make me curious.
>
>[root@arcadia t1]# grep python3 
>/var/lib/srpm/repositories/sbo/15.0/CHECKSUMS.md5 | tail -20
>c2124db45079c4a5da5b3bcef405ecf5  ./python/python3-zxcvbn/README
>53fea0b9500c79fdce7bd062a0ed4c1d 
>./python/python3-zxcvbn/python3-zxcvbn.SlackBuild
>a33997f0ddb2f53a45ecbafaa937192e ./python/python3-zxcvbn/python3-zxcvbn.info
>5a57d63831a7525b534550277e4a07ec ./python/python3-zxcvbn/slack-desc
>a22977ecb64571bec6ad412ffa807102  ./python/python3.tar.gz
>ab6fb66d89dd19f037d24c6bdee81608  ./python/python3.tar.gz.asc
>0d1931eeacdf713b2ba148b2fc77ad43 ./system/python3-docker-compose.tar.gz
>288689b99fdeec238f258a58c263f09e ./system/python3-docker-compose.tar.gz.asc
>f75c198eff9a1380fd7fd36a6d58fce8 ./system/python3-docker-compose/README
>1022470b1dba49604f7bab796001098c 
>./system/python3-docker-compose/python3-docker-compose.SlackBuild
>1b4a5d97267ea0cbfec736e0dc4a1f33 
>./system/python3-docker-compose/python3-docker-compose.info
>ba06334d025d892dcf9f9390a6057240 ./system/python3-docker-compose/slack-desc
>47327a75b6b992f233db9889919d6148 ./system/python3-nvidia-ml-py.tar.gz
>a571f1b03c02a3a35fafc1b27bff7e1e ./system/python3-nvidia-ml-py.tar.gz.asc
>da2082d1f5880f5150f220996b6ac3d2 ./system/python3-nvidia-ml-py/README
>3d460b5e71059f7e761f329a9789b2ad 
>./system/python3-nvidia-ml-py/python3-nvidia-ml-py.SlackBuild
>2bdc12478783998e3c05ea34dbfed411 
>./system/python3-nvidia-ml-py/python3-nvidia-ml-py.info
>f4020b4564a1fd325dad9a5a6fae5c45 ./system/python3-nvidia-ml-py/slack-desc
>4bd0be69e441b4131997982b9a0861c7  ./system/python3-urwid.tar.gz
>2372411b8895787ae82c8c86890114d5 ./system/python3-urwid.tar.gz.asc
>[root@arcadia t1]#
>
>Happy to help,
>
>regards.
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Larry Hajali's SlackBuilds

[Arnaud via SlackBuilds-users]

> Are Larry Hajali's SlackBuilds up for grabs? There has only been one update
> from him since April 2021 and that was in May of 2022[1]. I found this
> because another python3 package I'm working on required lxml and it pulled
> in several python2 packages as dependencies, so I'd like to split lxml into
> python2 and python3 packages. It seems many of his other python packages
> could use naming changes and/or splits.
> 
> If they are available, I can take the following as they're dependencies for
> some of the SlackBuilds I maintain:
> 
> libraries/libcec/
> libraries/libnfs/
> libraries/platform/
> libraries/tinyxml/
> libraries/tinyxml2/
> python/lxml/
> 
> The remaining SlackBuilds are:
> [...a lot...]
> 
> Thanks,
> Jeremy
> 
> [1]
> https://git.slackbuilds.org/slackbuilds/log/?h=15.0=author=Larry+Hajali

If that is the case, my own Slackbuilds have dnspython and tinyxml2 as
requirements.
I'd be ok to maintain dnspython until it dies, as I'm already maintainer of
python3-dnspython.

If really those slackbuilds are abandoned I could take care of those ones :
office/grisbi because I use it
system/dosemu, so I'll maintain almost anything DOS-related ^^
network/nginx to cuddle along my darkhttpd and thttpd
office/texmaker, office/texstudio and office/sigil, because they ought to be
maintained.
And also those games because I like games : games/megaglest, games/alienarena,
games/chromium-bsu, games/assaultcube, ggames/lestae, games/opensonic,
games/dustrac.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Hi all, first question about package naming

[Arnaud via SlackBuilds-users]

On Mon, 15 Jan 2024 17:37:33 +0700
Willy Sudiarto Raharjo  wrote:

> > Ok, I see.. So in this case I think the name should be 
> > "python3-gbinder-python", perhaps a bit complex but clearly identifies 
> > python release and real name of the project.
> 
> python3-gbinder is enough, no need to have another python at the back
> 
> -- 
> Willy Sudiarto Raharjo

It would only become a problem if a python project called only « gbinder » 
appears.
Looking at the choices made by other distributions, people don't think it's 
very likely.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Hi all, first question about package naming

[Arnaud via SlackBuilds-users]

> Hi all.
> 
> I've created a slackbuild for gbinder-python ( 
> https://github.com/waydroid/gbinder-python ) but I''ve doubts about how 
> shall be the package named: python3-gbinder as usual with python modules 
> or gbinder-python as the real name of the project?
> 
> Thx in advance,
> 
> -- 
> === In soft we trust ===

You can look on repology here :
https://repology.org/projects/?search=gbinder
Clicking on the * next to gbinder-python shows that :
https://repology.org/project/gbinder-python/related
Where you can see that this package has different names, and that's fine.
So python3-gbinder or even python3-gbinder-python both looks OK.
gbinder-python doesn't specify which python, and the decision has been to
prefix python packages with python2/3.

I say that because sometime it's not that easy, for exemple for
python3-python-editor, I need that name, because python-editor
and editor are two different projects, so we could have a
python3-editor and a python3-python-editor.

And, well, repology is not a reference, but it's useful, or at least
practical, to be properly referenced there.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Qt6 and QTWEBENGINE_RESOURCES_PATH

[Arnaud via SlackBuilds-users]

> > I think this actually happens because one of the cmake options in the
> > qt6.SlackBuild is missing
> > 
> > -DINSTALL_DATADIR=./share/qt6
> > 
> > if I add that between the others then the qtdiag6 output show the correct
> > DataPath.
> > 
> > I'll put the maintainer in cc.
> > 
> > Matteo
> 
> I'll try rebuilding qt6 on my end.
> Dreadfully waiting for this bloatingly huge monster to stuff my whole RAM
> without any hope...
> See you... later !
> 
>  - Yth...

And 7 hours later, my new and shiny qt6 works perfectly, and rssguqrd doesn't
need a hack anymore !
That's a good catch Matteo, thanks.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Updates - 20240106.1

[Arnaud via SlackBuilds-users]

For examples, I've just sent a bunch of PRs, which can be seen here :
https://github.com/SlackBuildsOrg/slackbuilds/pulls
Most are just one package update.
Some are batches, like for the new PyPy version, there are 4 packages (pypy,
pypy3, PyPy and PyPy3), therefore 4 commits, one for each package.
I could have sent 4 PRs, but I want them to be either all updated at the same
time, or none of them.

As a side note about batch updates : if one package in the batch has a problem,
it's not very easy to just update that one inside the batch, and admins will
block the whole batch.
You need either to push new commits, but there'll be unuseful ones inside the
batch, or you have to do some medium-advanced git-jutsu to change one commit in
the lot, or even restart your commit/push from the beginning.
With separate PRs, everything that works is put out of the way, and there
remains only the problems to be handled.

Of course, usually there are no problems, but they happen from time to time...

I am taking a chance with my buildbot update : 5 packages, 3 for buildbot 
itself,
that should all be at the same version, and two from REQUIRES.
But I could have (and maybe should have) separated the requirements from the
buildbot ones : if, let's say, python3-klein has a problem, I won't have my
buildbot update, even though it would have worked fine with the actual
non-updated python3-klein.

 - Yth.



> Great explanation. Thank you.
> 
> Maybe is should be in the site FAQ :-)
> 
> 
> On 09/01/24 17:24, Jeremy Hansen wrote:
> >
> >
> > On Tue, Jan 9, 2024, 9:26 AM Petar Petrov  wrote:
> >
> > >And then on github I simply make a pull request
> > how do you "simply make a pull request"?
> >
> > -p
> >
> >
> > I'm a relative git and GitHub newb, but here's what I did to start 
> > working with GitHub. (For those who are far more knowledgeable than 
> > me, if there are improvements to be made, please let me know.) I'm 
> > sure GitLab is similar, but they have slight variations in terminology.
> >
> > This is aimed at other git/GitHub newbs... if you aren't one, I apologize.
> >
> > To get started, do the following:
> >
> > 1. Fork SBo's GitHub repo through the GitHub interface (you need to 
> > have a GitHub account and be logged into it to fork).
> > 2. Clone your newly forked repo onto your computer.
> >   git clone $your_new_repo_address
> > 3. Set SBo's GitHub as upstream to make getting public updates easier.
> >   git remote add upstream 
> > git://github.com/SlackBuildsOrg/slackbuilds.git 
> > 
> >
> > If you've never used git on your computer to make commits before, 
> > you'll need to tell git who you are so it can know who to attribute 
> > your commits to:
> >
> >   git config --global user.email "y...@example.com"
> >   git config --global user.name  "Your Name"
> >
> > Now you're ready to start updating on your local computer.
> >
> > 1. Create a new branch for the package you're updating and switch to 
> > that branch. Typically this will be the package name that you're 
> > updating, but naming schemes are more for you than anything. The name 
> > of the branch won't affect the SBo admins reviewing your pull request.
> >   git checkout -B $branch_name
> > 2. Make the changes to the files and verify everything works. This may 
> > require moving those files to a clean VM to verify they build properly 
> > in a clean environment.
> > 3. Commit those changes to that branch on your local repo:
> >   git commit -m "network/discord: Update version to 1.2.3" 
> > location/to/changes
> > (If there are multiple package changes due to dependency bumps or 
> > similar, do an individual commit for each package.)
> > 4. Once all commits are complete that apply to your update, push those 
> > commits to your GitHub repo, forcing GitHub to create a new remote 
> > branch (since it only exists locally):
> >   git push -f origin $branch_name
> > 5. Git will provide a link in the output you can visit to submit the 
> > pull request (PR) or you can just browse to your GitHub repo and you 
> > can submit the PR yourself (if the push was recent, it'll list the 
> > option at the top of the nation page, otherwise you can go into the 
> > branches area and can submit it that way.
> > 6. Explain your changes, if necessary, when submitting the PR back to 
> > SBo's repo.
> >
> > Then it's just a matter of waiting for SBo admins to review your 
> > submission. If changes are needed, they'll suggest them. Once the 
> > changes are accepted, you can delete the branch on your repo online 
> > and on your local repo:
> >   git checkout master  # first make sure you're on your master branch
> >   git branch -D $branch_name
> >
> > Once a public update is released, you can then update your local copy 
> > on the master branch using:
> >   git checkout master
> >   git pull upstream master
> >
> > From here, you can then create a new branch again to make more 
> > 

Re: [Slackbuilds-users] Qt6 and QTWEBENGINE_RESOURCES_PATH

[Arnaud via SlackBuilds-users]

> Il giorno mar 9 gen 2024 alle ore 12:11 Arnaud via SlackBuilds-users <
> slackbuilds-users@slackbuilds.org> ha scritto:
> 
> > > Qt should be able to find that directory by itself using
> > > |QLibraryInfo::DataPath.|
> > > Can you try to run this command and see what it returns?
> > >
> > > qtdiag6 --no-vulkan --no-rhi --no-gl | grep DataPath
> > >
> > > In my case it returns
> > >
> > > ArchDataPath: /usr/lib64/qt6
> > > DataPath: /usr/share/qt6
> > >
> > > So the chromium resource pack path should be discovered automatically.
> >
> > Well :
> > $ qtdiag6 --no-vulkan --no-rhi --no-gl | grep DataPath
> >   ArchDataPath: /usr/lib64
> >   DataPath: /usr
> >
> > Even though I do have :
> > Environment:
> >   QT5DIR="/usr/lib64/qt5"
> >   QT6DIR="/usr/lib64/qt6"
> >
> > So I guess something is wrong on my box.
> >
> 
> I think this actually happens because one of the cmake options in the
> qt6.SlackBuild is missing
> 
> -DINSTALL_DATADIR=./share/qt6
> 
> if I add that between the others then the qtdiag6 output show the correct
> DataPath.
> 
> I'll put the maintainer in cc.
> 
> Matteo

I'll try rebuilding qt6 on my end.
Dreadfully waiting for this bloatingly huge monster to stuff my whole RAM
without any hope...
See you... later !

 - Yth...
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Updates - 20240106.1

[Arnaud via SlackBuilds-users]

> On Sat, 6 Jan 2024, at 9:47 AM, Willy Sudiarto Raharjo wrote:
> > Please note that all new submission MUST be submitted via normal 
> > submisison form in order to get it populated in the database during 
> > public update. Updates to existing scripts can be done in both ways (via 
> > Github PR or Gitlab MR or normal submission form).
> 
> Thanks Willy. So does this mean that for regular version updates (not new
> scripts) we can submit using git? Are there any docs outlining the basic
> workflow for GitLab and/or GitHub with the SBo repo specifically?

I have forked the https://github.com/SlackBuildsOrg/slackbuilds on my own
github account. And I update my master branch when there is an update on the
upstream repository.
Also I have sbo-maintainer-tools installed

My workflow is, when I want to update, say rss-guard package :
 * I am on master branch
 * sbolint desktop/rss-guard/
 * sbopkglint /path/to/rss-guard-x.y.z.txz  # Doesn't validate for other ARCH
 * git checkout -b rss-guard
 * git add desktop/rss-guard/*
 * git commit -m "desktop/rss-guard: updated for version x.y.z"
 * git push --set-upstream origin rss-guard
And then on github I simply make a pull request, usually without comments, if it
is a straightforward update.

If I want to group some updates, for example if I have an update on libjodycode
and jdupes at the same time :
 * commit for jdupes only
 * commit for libjodycode only
 * push both commit on a jdupes branch
 * PR from jdupes branch with message stating that it is an update of jdupes and
its library libjodycode.


Corner cases :
 * Renaming a package is adding a new package using the submit web form, then a
github PR deleting the old package, with a message stating that it is a
renaming, with the new name, so that admins knows to wait for the new package
before merging.
 * If I change the name of a dependency (that has happened a lot with python
package renaming), I still make one commit per package updated, stating that it
is a REQUIRES update, and one commit to remove the old package.

I never group PR for unrelated packages.
A single commit should only be on one package, not multiple packages.

That's mostly my way of doing things.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Qt6 and QTWEBENGINE_RESOURCES_PATH

[Arnaud via SlackBuilds-users]

> Qt should be able to find that directory by itself using 
> |QLibraryInfo::DataPath.|
> Can you try to run this command and see what it returns?
> 
> qtdiag6 --no-vulkan --no-rhi --no-gl | grep DataPath
> 
> In my case it returns
> 
> ArchDataPath: /usr/lib64/qt6
> DataPath: /usr/share/qt6
> 
> So the chromium resource pack path should be discovered automatically.

Well :
$ qtdiag6 --no-vulkan --no-rhi --no-gl | grep DataPath
  ArchDataPath: /usr/lib64
  DataPath: /usr

Even though I do have :
Environment:
  QT5DIR="/usr/lib64/qt5"
  QT6DIR="/usr/lib64/qt6"

So I guess something is wrong on my box.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Qt6 and QTWEBENGINE_RESOURCES_PATH

[Arnaud via SlackBuilds-users]

Hi fellow Slackers, and wishing you all a happy and healthy new year.

I'm having some questions with a Qt6 build :
rss-guard recently bumped to Qt6, still allowing to build with Qt5, and I'm
willing to allow people to build with either one.

Everything goes fine except when launching the Qt6 version, I have the following
error :

time=" 0.432" type="fatal" -> The following paths were searched for Qt
WebEngine resources: /usr/resources
  /usr
  /usr/bin
  $HOME/.RSS Guard
but could not find any.
You may override the default search paths by using QTWEBENGINE_RESOURCES_PATH
environment variable.

The file for Qt6 is there :
/usr/share/qt6/resources/qtwebengine_resources.pak
So if I `export QTWEBENGINE_RESOURCES_PATH=/usr/share/qt6/resources/` rssguard
starts and works fine.

The /etc/profile.d/qt6.sh only sets up QT6DIR=/usr/lib64/qt6

Solutions :
1 - asking nicely for people to setup their QTWEBENGINE_RESOURCES_PATH. That'll
lead to people being unhappy because rssguard won't work, because nobody reads
anything: I wouldn't.
2 - create a wrapper around /usr/bin/rssguard to setup this variable, which
seems a bit overcomplicated.
3 - ask the qt6 maintainer to update the /etc/profile.d/qt6.sh, but is that
really why the problem happens ?
4 - update the /etc/profile.d/qt6.sh in rssguard's doinst.sh, which is nice and
hacky, but very ugly, and nightmarish after a Qt6 update.
5 - Ask people on SBo, because brain-loop.

Hence I'm asking...

To be noted : we do have a QT6DIR environment setup to /usr/lib64/qt6, but
knowing that, there is no way of finding that some Qt6 stuffs are located
at /usr/share/qt6/, so maybe there is another more generic export for
QT6's /usr/share location ?

 - Yth.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] maintainer status report

[Arnaud via SlackBuilds-users]

Here it is :
https://repology.org/projects/?search==volkerdi%40slackware.com=slackbuilds
I didn't know Patrick had a Slackbuild.

 - Yth.

Le 30 décembre 2023 10:15:44 UTC, Franzen via SlackBuilds-users 
 a écrit :
>Patrick Volkerding is listed with 114 scripts, but in fact has one script in 
>SBo.
-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] start SlackBuilds-current-users / news:gmane.linux.slackware.slackbuilds.current.user ?

[Arnaud via SlackBuilds-users]

‌Le 2023-12-11 06:07, dchme...@gmail.com a écrit :
> If SlackBuilds.org (SBo) staff not only don't 'support'
> Slackware-current (I forgot) (some SBo maintainers including myself
> support Slackware-current) but don't want people discussing
> Slackware-current, then  shouldn't there be SlackBuilds-current-users
> / news:gmane.linux.slackware.slackbuilds.current.user?
>     I tried to make habit of writing '[Slackware-current]' in subject
> lines.  After over five years from Slackware 14.2 to 15, many/most
> people I know who do much with Slackware used Slackware-current
> several years, and so did I, which seemed stable enough 99+% the time,
> so I never switched back to Slackware-stable except spare PCs and
> chroots (SlackBuilding/testing, fallback). Slackware-current seems so
> stable that for years I often forgot I'm using it (more stable than
> Devuan/Debian/Ubuntu/Mint/KDE_Neon 'stable' versions I administer for
> users).
>     Things I post here recent years normally aren't problems/questions
> rather than what I repeatedly see from queues stopping early in sbopkg
> & sbotools, and wondering if anyone else saw (usually not stuff I use
> much/anytime yet, just testing). I didn't mean to waste anyone's
> time.  However, I don't want to have to use a web-forum rather than
> listserv/mailing-list/NNTP/Gmane.
>
> Sincerely,
> David Chmelik (abridged Melik)
> mirror.davidchmelik.com / mirror.davidchmelik.com/math/slackbuilds (most 
> uptime)
> davidchmelik.com / slackbuilds.davidchmelik.com (updates first)
>

The issue with SBo and -current is that current is a moving target.
We, at SBo, cannot make sure everything works on -current.
That would be each week on public updates, and each time -current has an update.
Who can do that ? There are truly as many -current versions of Slackware as 
there are public updates by Patrick Volkerdig and his team, and that is a lot 
of -current versions, because they doesn't tire easily !

Instead, we make sure scripts on SBo are working on stable Slackware, because 
that is doable : base is stable, only inter-dependance between updated 
slackbuilds needs to be checked, and that can be done on a script's update 
basis.
That is actually doable.
And yet, we are still not sure all scripts results in a working package.
That is the work of SBo maintainers.

That being said, I often also make sure my scripts are working on -current, 
even making some hacks for supporting both, sometimes.
I also often tries them on ARM or AARCH64, because I own such machines, and put 
Slackware on them.
As long as it works on stable x86, I can do more if I want to.

This means that sometime I cannot push an update, because 15.0 is too old.
We've had workarounds on Python's packages, with setuptools-opt for example.


That is what is meant by SBo doesn't support -current.
And that does absolutely not mean that this can't be a basis for a -current set 
of slackbuilds, which is a job handled by Ponce.
And his method of communication is through LQ.
Which means that LQ is the place for discussing -current problems.
This mailing list serves the purpose of making sure SBo on stable works, which 
is the foundation of Ponce's repository.
I'd go as far as saying that Ponce rely on the work we do here, for doing his 
own work : he can't handle all the updates and testing we do here, and besides 
most of them are working nicely on whatever Slackware version you're on.
As much as we throughly rely on Patrick's job to provide us with a stable fully 
functional, and properly patched, Slackware stable release.

You don't mean to bother Patrick with broken slackbuilds on -current ?
Then here is not the place for it either.

I'm sorry that LQ doesn't suit you, you'd have to talk with Ponce about that, 
maybe he'd be open for other ways of communication, I certainly would not go 
about that behind his back!

All that being said, if you need help with your own slackbuilds, for making 
them work as well on -stable and -current, you could ask questions here about 
the right way for your script to handle both.
Just not about how to make a script work on -current, that's not the place for 
an answer about that.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] [RFC] Adding features to .info format.

[Arnaud via SlackBuilds-users]

>> My first thought was DOWNLOAD_X86 is not needed because the same end result 
>> can be
>> achieved with DOWNLOAD, DOWNLOAD_X86_64, and DOWNLOAD_AARCH64. But now I 
>> think I
>> agree with you because it has a different meaning: DOWNLOAD is a (mostly)
>> arch-independent download, where 1 or more of DOWNLOAD_* may be needed to 
>> override
>> it. However, the absence of DOWNLOAD and the use of DOWNLOAD_* communicates 
>> that
>> there are no arch-agnostic downloads; every download tarball is 
>> arch-specific.
>>
>
>Sorry, _almost_ like this, but not quite. To maintain current behaviour,
>the absence of arch-agnostic downloads is indicated by
>DOWNLOAD="UNSUPPORTED".

That line currently means that the package does not build on ix86.
The DOWNLOAD_X86 line would effectively break backward compatibility.
But adding optional DOWNLOAD_{ARCH} for ARCH in ARM and AARCH64, and maybe 
later RISCV who knows, alongside the existing X86_64, looks like a fully 
backward-compatible evolution.
And not very hard to use in existing tools, and easy to understand for 
maintainers, and users also.

So I am fully in favor of that evolution : allowing DOWNLOAD_{ARCH} for other 
values, with the corresponding MD5SUM_{ARCH}. I already use it at home for 
syncthing on arm and aarch64.
As for names, I'm unsure, but yeah, there are some problems with downloaded 
files, depending on tool, content-disposition, source also, etc.
-- 
Yth.___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Microsoft Edge is up for grabs

[Arnaud via SlackBuilds-users]

Hmm, looks like a damn good way to track your activity, making sure all 
browsing happens from the same machine...
Looks like a file needing to be regenerated on a daily basis, or each time you 
start edge.

Ugly...

 - Yth.

Le 27 novembre 2023 17:53:59 UTC, Petar Petrov  a écrit :
>hi,
>
>i was reading about a possible solution...
>
>newest Edge beta does not start either, but at least suggests running
>it with the  "--enable-chrome-browser-cloud-management" option. Doing
>this, it complains about missing machine-id in /etc. Generating it by
>"dbus-uuidgen --ensure=/etc/machine-id" seems to fix the problem and
>Edge starts. I have no idea what "machine-id" is, though
>
>hope this helps
>
>best,
>
>Petar
>
>On Thu, 16 Nov 2023 at 02:54,  wrote:
>>
>> I'm still not able to get recent versions of Edge to run. I have neither
>> the desire nor the expertise to fool with it any longer.
>>
>> The version on SBo is working but stale.
>>
>> -AP
>>
>> ___
>> SlackBuilds-users mailing list
>> SlackBuilds-users@slackbuilds.org
>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - https://slackbuilds.org/faq/
>>
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Conflicts and/or redundancies of slackbuilds of some python packages (constantly, incremental, hyperlink)

[Arnaud via SlackBuilds-users]

hyperlink, bleach, constantly and incremental are being renamed to 
python3-package.
In the last update, the new packages have been added, the old ones removed, and 
all relevant REQUIRES updated.
Only two of them were still building for python2, and packages requiring them 
are python3 only, which justifies dropping python2 support.

So everything should be good.

 - Yth.

Le 12 novembre 2023 10:40:43 UTC, "Giancarlo Dessì"  a écrit :
>Hi, recent update includes three new slackbuilds of python packages supported 
>by Python 3, but these are reduntant with other available slackbuilds or may 
>cause conflicts between different versions of the same module:
>
>1) redundancies
>
>python3-incremental: this builds and installs incremental for Python 3, but in 
>the repository there is also the slackbuild incremental that builds and 
>installs for both Python 2 and Python 3. Both slackbuilds build the same 
>source.
>
>Also python3-hyperlink (supporting Python 3) conflicts with hyperlink 
>(supporting both Python 2 and Python 3)
>
>These redundancies should cause issues in the package management because two 
>different packages share the same files in Python 3
>
>2) conflicts
>
>python3- constantly builds constantly-23.10.4 for Python 3, but there is also 
>the slackbuild constantly, that builds and installs constantly-15.1.0 for 
>Python 2 and Python 3. This should cause conflicts because in Python 3 could 
>exist two different versions of the same module
>
>How to solve?
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Updates - 20231014.1

[Arnaud via SlackBuilds-users]

> network/httpie: Update MD5SUM.

This new version changes the source path from httpie-$VERSION to cli-$VERSION.
Well, that doesn't seem to work here, when I download the sources, they extract
to a httpie-3.2.2/ directory.

I don't know what happened, probably something upstream, but it seems broken 
now.

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Brent Earl's slackbuilds

[Arnaud via SlackBuilds-users]

That one's been received Jay !

I'll take over textadept, as I use it regularly.

Cheers,

- Yth.

> Hello Brandon,
> 
> I'm not sure if this email will send (I'm having server issues sending 
> to the list directly, but maybe to a user it will) but I've taken ufw 
> and uploaded an update to sbo already for it, but I'm having 
> communication issues currently, so I couldn't post to the list in 
> advance, but notified them on irc.
> 
> Apologies in advance for the confusion,
> 
> - Jay Lanagan
> 
> On 2023-09-18 00:53, Brandon Pribula wrote:
> > On Sun, Sep 17, 2023, 6:59 PM fourtysixandtwo,
> >  wrote:
> > 
> >> Hi all,
> >> 
> >> As per Brent's attached email, if anyone would like to take over any
> >> of his slackbuilds, here's the list.
> >> 
> >> I'm claiming fio and passlib so have removed them from the list.
> >> 
> >> network/ufw
> > 
> > I'll take ufw.
> > 
> > I recenty abandoned my slackbuilds due to time contraints which may
> > have been premature. I can manage maintaing at least one right now and
> > probably more in the future.
> > 
> >> 
> > ___
> > SlackBuilds-users mailing list
> > SlackBuilds-users@slackbuilds.org
> > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> > FAQ - https://slackbuilds.org/faq/
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 


___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] using $DOWNLOAD for alt. purpose

[Arnaud via SlackBuilds-users]

> > So I've got a few scripts that are 64bit only and have different binary 
> > files to download for amd64 or aarch64. The scripts are setup to fail on 
> > 32bit and I'd like to know if it'd be possible for me to use the 
> > $DOWNLOAD for the aarch64 files, so I don't have to omit a otherwise 
> > working script for the platform I mostly use.
> > 
> > As-is this works with the tool "sboui" on my machines and automatically 
> > gets the $DOWNLOAD on aarch64 and the correct one on x86_64 as well.
> > 
> > Would it be acceptable to have the script itself fail on 32bit rather 
> > than marking $DOWNLOAD=unsupported so we can offer support for the 
> > aarch64 platform?
> > 
> > Side note: is there any future plans to add a $DOWNLOAD_AARCH64 to the 
> > .info?
> 
> As far as i can tell, no
> Not all admins have access to ARM machines to test the script, so the 
> best thing we can do is to offer parameter  flags for ARM architecture.
> 
> https://git.slackbuilds.org/templates/commit/?id=20ac57b04874a38a4a1b4aa8d0fa4ec95a5605a4
> 
> https://slackbuilds.org/faq/#ports
> 
> -- 
> Willy Sudiarto Raharjo
> 

My own 2¢ about that :
I, personally, only needs an ARM/AARCH64 source for syncthing.
On those boxes, I patch the .info to setup the ARM or AARCH64 source, it works
only for me and myself.

If we had optional DOWNLOAD_ARM/MD5SUM_ARM and DOWNLOAD_AARCH64/MD5SUM_AARCH64,
build tools could be updated to use them if present, or simply ignore them if
they wouldn't want to handle ARM in any way.
The download links would be there for any purpose.

This seems - to me - the least intrusive solution, with a clean design.
I truly dislike the idea of repurposing an UNSUPPORTED DOWNLOAD value for ARM
purposes, it would be very unclear.

Of course, the problem of having an ARM/AARCH64 DOWNLOAD link while not
supporting it is present. But that wouldn't be for all .info files, probably
very few of them, as the vast majority have a unified DOWNLOAD for sources that
works everywhere, even ARM or AARCH64.

That might be a simple step to allow some unsupported support of those
architectures.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Markdown overwrites Slackware's /usr/bin/markdown_py

[Arnaud via SlackBuilds-users]

Maybe the python2 Markdown package could drop the executable altogether and 
only install the python2 library ?
I don't know if there'd be a point in having a /usr/bin/markdown_py2...

Yth, kill python2, until it's thoroughly dead !

Le 15 août 2023 12:58:39 UTC, Erich Ritz via SlackBuilds-users 
 a écrit :
>Hello Markus,
>
>I noticed today that Markdown overwrites /usr/bin/markdown_py provided by 
>Slackware.
>
>Slackware's python-markdown package provides markdown_py for Python 3.9, 
>whereas SBo's Markdown package provides markdown_py for Python 2.7.
>
>Is there any way to cleanly separate the two different markdown_py scripts in 
>/usr/bin? For me I just reinstalled Slackware's package. I build SBo packages 
>in a chroot so I could probably just remove Markdown from my system (I'm 
>guessing it's a build-time dependency only for SBo packages to build docs?).
>
>Erich
-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Updates - 20230729.1

[Arnaud via SlackBuilds-users]

> > system/pv: Updated for version 1.7.18.
> 
> md5sum for pv does not match
> 
> Matt Egger

Ok, source for pv-1.7.18 did change between my update and now.
The differences are of no consequences, but md5sum did change.
I've pushed an md5sum update.

- Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Happy 30 years Slackware !

[Arnaud via SlackBuilds-users]

It was yesterday, 30 years ago :

http://www.slackware.com/announce/1.0.php

Cheers :)

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Scripts up for grabs

[Arnaud via SlackBuilds-users]

> Hi all,
> 
> Markus Reichelt has announced that he has no time maintaining his 
> scripts anymore, so scripts below are up for grabs:
> 
> Botan
> Markdown
> Nevow
> Parsley
> aespipe
> characteristic
> darcsver
> dietlibc
> extundelete
> foolscap
> i2pd
> libowfat
> nyx
> onioncat
> openzfs
> pycryptopp
> pyutil
> service_identity
> shutilwhich
> 
> stem
> tahoe-lafs
> tcc
> txi2p
> txsocksx
> txtorcon
> vanguards
> webassets
> zbase32
> zfec
> 
> 
> -- 
> Willy Sudiarto Raharjo

To be noted that some of those packages have been removed by last wekk's update,
for being obsolete, outdated, or replaced by a python3 version.
Those are : Nevow, Parsley, foolscap, service_identity, tahoe-lafs, txi2p,
txsocksx, and txtorcon.

I'm ok taking over tcc
Also I'll remove characteristic, which is the python2 version, now unneeded, and
replaced by python3-characteristic, it slipped through last weeks cleanup.
I think shutilwhich is pretty unneeded, being python2 only, and not required
anywhere.

Furthermore : zfec builds for python3, but it's requirements (pyutil, zbase32,
darcsver) all build for python2, meaning this cannot work properly.
Since none of them are required by anything else - zfec was a requirement of
tahoe-lafs, which wasn't working and has been removed - I suggest to simply
remove them.

Bottom line :
I'm ok taking over tcc, if nobody else wants it.
I'll simply remove characteristic, shutilwhich, zfec, pyutil, zbase32, darcsver.

Cheers,

 - Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Python2 packages in need of action

[Arnaud via SlackBuilds-users]

> > And nothing not on that list depends on something on that list.
> >
> > Cheers :)
> 
> Please add python/poster to the list.
> 
> Best regards,
> Alexander

Done, and that's 32 builds removed.

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Python2 packages in need of action

[Arnaud via SlackBuilds-users]

Follow-up on that message.

Nobody wishes to take over any of those outdated, obsolete, not working
as they are, python2, and unmaintained packages.

I'm removing them all, alongside gaphor, and stuff that are only required by
something on that list.
The full list is :

salt
tahoe-lafs
Scrapy
graphite-carbon
graphite-web
txtorcon
foolscap
python2-orbited
TaskCoach
Nevow
sslstrip
Parsley
txsocksx
txi2p
txrequests
Electrum-DASH
gaphor
etk.docking
simplegeneric
gaphas
python2-automat
python2-mistune
python2-pyhamcrest
python2-pyzmq
python2-twisted
python2-txaio
python-m2r
python2-autobahn
service_identity
python2-klein
python2-ldap

And nothing not on that list depends on something on that list.

Cheers :)

 - Yth / Arnaud.


> Hi everybody.
> Taking another look at my python2 packages, they are requirements of some 
> other
> stuff, most of which is unmaintained.
> 
> Amongst those there are packages very outdated, building for python2, no
> python3 version available on SBo, and the upstream newer versions are python3
> only. Most of them probable aren't working at all, probably build fine, but
> short of really using it, with python packages, you can't know if they work.
> Mosty of the one I've tested don't, they have broken dependencies, or rely on
> Great Old Stuff from Way Before Slackware 15.0.
> 
> 
> Hence those packages are in dire need of either :
>  - someone to step up as maintainer, pushing an update to later version, using
> python3 ;
>  - be removed as nobody seems to use them, because they'd have complained 
> about
> their situation.
> 
> Here is a short list of the ones I've found, which are related to the python2
> package I really want not to maintain anymore.
> 
> * To be updated or dropped
> |  |  version | date | newest |
> | salt | 2018.3.3 | 2018 |   3008 |
> | tahoe-lafs   |   1.12.1 | 2017 | 1.18.0 |
> | Scrapy   |1.7.3 | 2019 |  2.8.0 |
> | graphite-carbon  |   0.9.15 | 2015 | 1.1.10 |
> | graphite-web |   0.9.15 | 2015 | 1.1.10 |
> | txtorcon |   0.19.3 | 2017 | 23.0.0 |
> | foolscap |   0.13.1 | 2017 | 23.3.0 |
> 
> * To be removed because very obsolete, and often an old requirement of
> tahoe-lafs or Scrapy, and not required by newer version.
> Upstream has *not* been updated for years.
> |  |  version | date | newest |
> | python2-orbited  |   0.7.10 | 2009 |yes |
> | TaskCoach|1.4.3 | 2016 |  1.4.4 |
> | Nevow|   0.14.4 | 2018 | 0.14.5 |
> | sslstrip |  0.9 | 2013 |  0.9.2 |
> | Parsley  |  1.3 | 2015 |yes |
> | txsocksx | 1.15.0.2 | 2015 |yes |
> | txi2p|0.3.2 | 2017 |yes |
> | txrequests   |0.9.6 | 2018 |yes |
> | Electrum-DASH|2.4.1 | 2015 |  2.8.3 |
> 
> * Other packages for which there is already a python3 package :
>  - service_identity as a requirement of Scrapy and tahoe-lafs should be 
> removed
> after dealing with them, as a python3-service-identity already exists.
>  - python2-klein -> python3-klein exists and is uptodate.
>  - python2-ldap - > python3-ldap exists and is uptodate.
> 
> * Needing split :
>  - python-m2r, for which python2 support could be dropped.
> 
> 
> -> I will split python-m2r, taking python3-m2r, because it is an optional
> dependency of python3-automat, which I maintain already. The old python-m2r
> could then be removed, unneeded as I plan on removing python2-automat soon
> enough.
> I have absolutely no use of any of the packages I marked as needed to be
> updated or removed, I have no wish to take over them.
> They probably simply don't work at all, because some requirements are python3,
> and other are python2, just look at Scrapy requirement tree, I can't see how 
> it
> would work.
> Which means that nobody uses them.
> 
> My advice would be to remove them.
> That means removing : salt , tahoe-lafs, Scrapy, graphite-carbon,
> graphite-web, txtorcon , foolscap, python2-orbited, TaskCoach, Nevow,
> sslstrip, Parsley, txsocksx, txi2p, txrequests, Electrum-DASH,
> service_identity, python2-klein, python2-ldap.
> And replacing python-m2r with a python3-m2r (which I'm willing to do).
> 
> That would lead to the removal of my packages : python2-attrs, 
> python2-automat,
> python2-mistune, python2-pyhamcrest, python2-pyzmq, python2-twisted,
> python2-txaio. All available for python3.
> And probably some more, which I don't maintain, but we may see clearer after
> that big operation.
> 
> 
> Cheers, and sorry for the very long message :)
> 
>  - Yth / Arnaud.
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
> 


___
SlackBuilds-users mailing list

Re: [Slackbuilds-users] pytho2-config/python2-lz4

[Arnaud via SlackBuilds-users]

> Good Day,
> 
> I am in the process of trying to catch up with my builds this week.  I
> maintain both the python 2 and 3 versions of python-lz4, which requires
> python-pkgconfig.  I maintain these as dependancies of plaso.  Plaso has
> moved on to the python3 version only, and I see no other builds that
> depend on python2-lz4 or python2-pkgconfig.  Can these be removed, or
> does someone what to take them over?  
> 
> Thanks,
> Barry
> 
> bgru...@linuxleo.com

Delenda est Python2 !
Please, feel free to remove them, and embrace the joice of reducing python2 !

;)

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] [zope] Taking over the Zope...

[Arnaud via SlackBuilds-users]

Hi everybody,

I've taken over maintainance of mailman, but it is stuck on version 2.x,
as it is.
I'm trying to update it to version 3.x which requires a *lot* of python 
packages.

Amongst them are most of the existing zope.something packages.
All of them are unmaintained, except for zope.interface which I'm maintaining
already. Some are dating as far back as their addition on Slackware 13.0, except
for global maintainance, template updates and stuff like that.

So I'll take over all of them, put them on python3, and update them.
The list is as follow :
Needed for mailman 3 :
 * zope.component
 * zope.configuration
 * zope.event
 * zope.hookable
 * zope.i18nmessageid
 * zope.schema
Other zope packages :
 * zope.location
 * zope.proxy
 * zope.security
 * zope.sqlalchemy
 * zope.testing
New packages :
 * python3-transaction -> part of the zope project too, but without zope in the
name.
 * ZODB -> Replacing ZODB3 which is archived

For that, I'll check that locust, letsencrypt and gaphor are still working
properly, and are maintained, thay are the only packages requiring any of those
ones.

If someone got something to add, please do, I'm preparing the work :)
That won't be enough for mailman 3, but it's a start...
Other packages will have to be added, using proper channels...

I'm wondering about keeping a mailman2 package for mailman 2, which is far less
complex. Or maybe not, if nobody wants that.

Also, I think I'll keep their names as zope.something, instead of
python3-zope.something, feeling like the zope prefix might be enough, since
they'll all be python3-only after I'm done with them.

Feel free to give your opinion !

Cheers,

- Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] unmaintained SlackBuilds

[Arnaud via SlackBuilds-users]

I am very ok to take over dkimproxy, since I use it, mailman also.

Cheers,

- Yth.


> Then i'll take webalizer
> 
> Am 13. Juni 2023 08:19:24 MESZ schrieb "B. Watson" :
> >
> >
> >On Tue, 13 Jun 2023, Franzen via SlackBuilds-users wrote:
> >
> >> may I assume that Steven King is not maintaining his builds anymore, and
> >> that anybody may take these? Since over 6 years no commit. A few months ago
> >> a asked him via mail and got no response.
> >
> >Yes, feel free to take them over. This goes for anyone else who wants
> >any of them, too.
> >
> >The full list:
> >
> >libraries/iniparser
> >libraries/log4c
> >network/aiccu
> >network/csync
> >network/dkimproxy
> >network/httping
> >network/mailman
> >network/webalizer
> >python/python2-pydns
> >python/python2-pypolicyd-spf
> >python/python2-pyspf
> >system/newrelic-sysmond


___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] [python3-setuptools] A Question about a SlackBuild.

[Arnaud via SlackBuilds-users]

> Hi Yth,
> 
> I have a slackbuild for setuptools, using the same version (65.1.1) and
> patch from current source that I've been thinking of uploading.  I've
> tested it with a newer version as well, so I'm not set on using the one
> from current.
> 
> I've attached the slackbuild if you want to give it a try.  It could use
> another set of eyes and testing.  Let me know your thoughts.
> 
> Here's a snippet from the README on how to use it.
> 
> Installs to /opt/python3.9/site-packages.
> 
> Add the following before the python3 build commands in your
> Slackbuild to use this version over the stock one in 15.0:
> 
> export PYTHONPATH=/opt/python3.9/site-packages/
> 
> Cheers
> 
> P.S. It's currently 26C in my house and I can't sleep so you're getting
> this reply now instead of later

I like the idea of installing it in /opt
I would become a requirement of python3-dulwich, and the Slackbuild itself would
set the right PYTHONPATH, while not altering the stock slackware's packages.

That does work, I've just removed my own updated setuptools and replaced the
proper slackware one, checked dulwich build still doesn't work, then installed
your slackbuild, and confirmed it builds fine when adding the proper PYTHONPATH
in the SlackBuild script.

In the absence of your package, the dulwich build ignores the PYTHONPATH,
meaning that on a -current box the SlackBuild will also work fine, without 
python3-setuptools-opt

Please, do submit your slackbuild, it works for me :)

- Yth.

PS : Urk, where do you live to have such heat at night ? I'm almost suffering
with 26°C during the day already...
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] [python3-setuptools] A Question about a SlackBuild.

[Arnaud via SlackBuilds-users]

> have you tried just sed'ing the version in the toml line to the version 
> that ships with slackware 15.0  ?
> quite often that works, and the only reason the requirement changed was 
> that the system it was developed on had a newer setuptools, not that it 
> actually used any new features.
> regards, Tim

Well, this requirement is not enforced, the python3 setup.py command works
without complaining.
It just produces the wrong result with files in :
/usr/lib64/python3.9/site-packages/UNKNOWN-0.0.0-py3.9.egg-info/

This seems to mean that a newer setuptools is actually required.
As for the exact version, maybe it's something between 57.5.0 and 61.2, but that
doesn't matter much.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] [python3-setuptools] A Question about a SlackBuild.

[Arnaud via SlackBuilds-users]

Hi everybody !

I'm facing a slight problem.
I've updated python3-dulwich, apparently more than a month ago.
It is used by Kallithea and hg-git which I also maintain, I'm not using hg-git
often, but I have a working and updated Kallithea service around.
Well it seems I didn't test this update as throughly as I thought.
Or at all, for that matter.

The build is broken and produces those files :

/usr/lib64/python3.9/site-packages/UNKNOWN-0.0.0-py3.9.egg-info/
/usr/lib64/python3.9/site-packages/UNKNOWN-0.0.0-py3.9.egg-info/PKG-INFO
/usr/lib64/python3.9/site-packages/UNKNOWN-0.0.0-py3.9.egg-info/SOURCES.txt
/usr/lib64/python3.9/site-packages/UNKNOWN-0.0.0-py3.9.egg-info/dependency_links.txt
/usr/lib64/python3.9/site-packages/UNKNOWN-0.0.0-py3.9.egg-info/top_level.txt

That, obviously, doesn't work as expected.

The problem resides in the python-setuptools package of Slackware 15.0 which is
at version 57.5.0.
In dulwich/pyproject.toml lies the answer :
[build-system]
requires = ["setuptools>=61.2"]


Here I've got three solutions :

 * revert dulwich to earlier version, 0.21.3, and wait for Slackware 15.1.

 * create a python3-setuptools package which'll overwrite Slackware's stock
python-setuptools with a newer version. Could even name it python-setuptools for
obvious, and transparent, replacement. It'll probably be updated naturally when
Slackware releases 15.1 is out.
 -> I have it working with latest setuptools 67.8.0, and dulwich builds fine.

 * somehow prepare a local setuptools to use for building dulwich, adding the
source to dulwich's info file, and building both while installing only dulwich.


Does anyone have any advice on that ?
I mean, apart from the obvious « test your friggin' SlackBuilds before
submitting them », I've got it in a loop between my ears, and in French...

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Next week, I will no longer maintain and update SlackBuilds

[Arnaud via SlackBuilds-users]

Sorry to see you go Isaac, and thanks for all the work !
Good luck with Debian, we'll welcome you back here whenever ;)

Now for the plunder.

Requirements of things I maintain are the following :
* The ones I'll take :
zeromq
cairocffi
python2-pyasn1
python3-pyasn1
python3-asn1crypto
* The ones already taken by Jeremy :
iniconfig
typing-extensions
python3-pluggy
python3-py
python3-pytest
python3-pytest-runner


Furthemore I use those ones, and I'm ok maintaining them :
office/focuswriter
python/python3-black
system/winetricks

Cheers,

- Yth.

> Thanks for all your work, Isaac! Best of luck to your future.
> 
> I can take the following as they're all dependencies of other packages I'm
> maintaining:
> 
> cppy
> iniconfig
> ipython
> pickleshare
> python3-beniget
> python3-deprecation
> python3-executing
> python3-gast
> python3-iniconfig
> python3-jedi
> python3-joblib
> python3-kiwisolver
> python3-matplotlib-inline
> python3-pandas
> python3-pluggy
> python3-pure_eval
> python3-py
> python3-pytest
> python3-pytest-runner
> python3-scipy
> python3-stack_data
> python3-threadpoolctl
> python3-tornado
> scikit-learn
> traitlets
> typing-extensions
> xsimd
> 
> I can submit a pull request later this week to switch maintainership over.
> Jeremy
> 
> On Sun, Jun 4, 2023 at 4:34 PM isaac...@isaacyu1.com 
> wrote:
> 
> > Hi everyone,
> >
> > ​I now have 200+ SlackBuilds to maintain.
> > Given my part-time job and my coursework, I am going to have a harder time
> > maintaining it all.
> >
> > This is the last week in which I will maintain and update SlackBuilds.
> >
> > I will also switch my email address (on SlackBuilds) to
> > isaa...@protonmail.com:
> > https://github.com/SlackBuildsOrg/slackbuilds/pull/2898
> >
> > I need to pay a small yearly subscription fee (to Gandi, the company) for
> > the isaacyu1.com domain. However, the ProtonMail email service is free.
> > Hence the email address change.
> >
> > My SlackBuilds are available at the following link:
> > https://github.com/isaackwy/slackbuilds-15.0
> >
> > I plan on switching to Debian.
> > Debian 12 (Bookworm) will be released in a few days, on June 10.
> >
> > - Isaac ___
> > SlackBuilds-users mailing list
> > SlackBuilds-users@slackbuilds.org
> > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> > FAQ - https://slackbuilds.org/faq/
> >
> >


___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Building TeXLive 2023

[Arnaud via SlackBuilds-users]

Texlive was a SlackBuild on 14.2, maybe you could start from this build and 
upgrade it to 2023 ?
Or you can also look at slackware's current sources, get the SlackBuild here, 
it builds a 2023 package, could be that it builds on a 15.0 box without further 
ado.
https://slackware.uk/slackware/slackware-current/source/t/texlive/

Yth.

Le 23 mai 2023 16:47:32 UTC, Rich Shepard  a écrit :
>TeXLive 2021 is the current version for both Slackware64-14.2 and -15.0. I
>have a document that will not build (using pdflatex) on that version, but it
>does build on TeXLive 2023. Why this one document won't build is unknown;
>Herbert Voss found it built on the 2023 version so he cannot help.
>
>I did not find that version on AlienBOB's web site. I need suggestions on
>how I can upgrade TeXLive to the 2023 version so I can provide this document
>to my client.
>
>Thanks in advance,
>
>Rich
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] slackbuilds up for grabs

[Arnaud via SlackBuilds-users]

I didn't see that.
Well, I'm willing ti take over dbgl, dbgl-legacy and dosbox-x, since I also 
maintain dosbox/dev.

 - Yth.

Le 7 mai 2023 16:11:26 UTC, Franzen via SlackBuilds-users 
 a écrit :
>Hi,
>
>see the mails below, the scripts 
>https://slackbuilds.org/advsearch.php?q=leo+c=maint are up for grabs.
>I'll take Qogir-icon-theme.
>
>Johannes
>
>
>
> Originalnachricht 
>Betreff: Re: Qogir-icon-theme on SBo
>Datum: 2023-05-07 17:03
>Von: Leonardo Citrolo 
>An: Franzen 
>
>Hi there,
>I'm afraid not; actually, I stopped using Slackware Linux more that 2 years 
>ago, and I havent't got any Slackware installations left, not even VMs.
>If you'd like to take over maintenance of this or other SlackBuilds of mine, 
>please do so.
>Cheers
>Leo
>
>On Sun, 07 May 2023 13:37:47 +0200
>Franzen  wrote:
>
>> Hi,
>> 
>> the version of Qogir-icon-theme is almost 3 years old, do you plan to
>> submit an update?
>> 
>> Cheers,
>> 
>> Johannes
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Python2 packages in need of action

[Arnaud via SlackBuilds-users]

Hi everybody.
Taking another look at my python2 packages, they are requirements of some other
stuff, most of which is unmaintained.

Amongst those there are packages very outdated, building for python2, no python3
version available on SBo, and the upstream newer versions are python3 only.
Most of them probable aren't working at all, probably build fine, but short of
really using it, with python packages, you can't know if they work.
Mosty of the one I've tested don't, they have broken dependencies, or rely on
Great Old Stuff from Way Before Slackware 15.0.


Hence those packages are in dire need of either :
 - someone to step up as maintainer, pushing an update to later version, using
python3 ;
 - be removed as nobody seems to use them, because they'd have complained about
their situation.

Here is a short list of the ones I've found, which are related to the python2
package I really want not to maintain anymore.

* To be updated or dropped
|  |  version | date | newest |
| salt | 2018.3.3 | 2018 |   3008 |
| tahoe-lafs   |   1.12.1 | 2017 | 1.18.0 |
| Scrapy   |1.7.3 | 2019 |  2.8.0 |
| graphite-carbon  |   0.9.15 | 2015 | 1.1.10 |
| graphite-web |   0.9.15 | 2015 | 1.1.10 |
| txtorcon |   0.19.3 | 2017 | 23.0.0 |
| foolscap |   0.13.1 | 2017 | 23.3.0 |

* To be removed because very obsolete, and often an old requirement of
tahoe-lafs or Scrapy, and not required by newer version.
Upstream has *not* been updated for years.
|  |  version | date | newest |
| python2-orbited  |   0.7.10 | 2009 |yes |
| TaskCoach|1.4.3 | 2016 |  1.4.4 |
| Nevow|   0.14.4 | 2018 | 0.14.5 |
| sslstrip |  0.9 | 2013 |  0.9.2 |
| Parsley  |  1.3 | 2015 |yes |
| txsocksx | 1.15.0.2 | 2015 |yes |
| txi2p|0.3.2 | 2017 |yes |
| txrequests   |0.9.6 | 2018 |yes |
| Electrum-DASH|2.4.1 | 2015 |  2.8.3 |

* Other packages for which there is already a python3 package :
 - service_identity as a requirement of Scrapy and tahoe-lafs should be removed
after dealing with them, as a python3-service-identity already exists.
 - python2-klein -> python3-klein exists and is uptodate.
 - python2-ldap - > python3-ldap exists and is uptodate.

* Needing split :
 - python-m2r, for which python2 support could be dropped.


-> I will split python-m2r, taking python3-m2r, because it is an optional
dependency of python3-automat, which I maintain already. The old python-m2r
could then be removed, unneeded as I plan on removing python2-automat soon
enough.
I have absolutely no use of any of the packages I marked as needed to be updated
or removed, I have no wish to take over them.
They probably simply don't work at all, because some requirements are python3,
and other are python2, just look at Scrapy requirement tree, I can't see how it
would work.
Which means that nobody uses them.

My advice would be to remove them.
That means removing : salt , tahoe-lafs, Scrapy, graphite-carbon,
graphite-web, txtorcon , foolscap, python2-orbited, TaskCoach, Nevow,
sslstrip, Parsley, txsocksx, txi2p, txrequests, Electrum-DASH, service_identity,
python2-klein, python2-ldap.
And replacing python-m2r with a python3-m2r (which I'm willing to do).

That would lead to the removal of my packages : python2-attrs, python2-automat,
python2-mistune, python2-pyhamcrest, python2-pyzmq, python2-twisted,
python2-txaio. All available for python3.
And probably some more, which I don't maintain, but we may see clearer after
that big operation.


Cheers, and sorry for the very long message :)

 - Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] remove wheel slackbuild

[Arnaud via SlackBuilds-users]

> > With everything switched to python3-wheel, the wheel slackbuild can now be
> > removed.
> 
> i'll keep them for a week and remove them if no reports of scripts broken
> 
> -- 
> Willy Sudiarto Raharjo
> 

Well, there's no python2-wheel.
It looks fine because it seems it mostly is an shell executable, so whatever
Python version is used should be ok.

But...

python2-automat builds with python3-wheel with this message :

WARNING: The wheel package is not available.
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please
upgrade your Python as Python 2.7 is no longer maintained. A future version of
pip will drop support for Python 2.7. More details about Python 2 support in
pip, can be found at
https://pip.pypa.io/en/latest/development/release-process/#python-2-support

Which looks like its making a call to pip, but not installing wheel, and not
seeming to do much.
The package builds fine.
Keeping the old wheel package there removes the warning, and the
python2-Automat package builds... well exactly the same.
Removing all wheel packages, old and python3-wheel, well, doesn't change
anything, the warning is there, the package builds fine.

Anyway, this does not seem that big a problem, but I guess we could just drop
the python3-wheel requirement altogether, since it builds the same.

My whole not very useful point being that we might see some problems with the
removal of python2 version of wheel.

But...

I don't care, and all python2 packages should be removed, or presenting
themselves at the morgue soon ^^

But... (again, I know)

A package like python2-automat is used by python2-twisted, itself used by :
Nevow TaskCoach python2-txaio Parsley txi2p Scrapy python2-orbited sslstrip
python2-klein txrequests txsocksx graphite-carbon foolscap

Most of which are probable outdated, not really maintained, and might not work
at all, but will require some work to know what's what, ask for people to update
and step up as maintainers, or be removed (then I may at last kill
python2-twisted and be rid of that old stuff).

Cheers :)

- Yth / Arnaud.

PS : on a side note, problems might appear at a very late time, because the old
wheel package is not removed by the name change, therefore the python2 wheel
will stay in many slackware box used by real people, masking any problem that
might arise.
So things will break, but I think those things are either already broken, or
needs to be updated.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Gitlab download filename changed

[Arnaud via SlackBuilds-users]

>>> it seems that gitlab download filenames changed very recently.
>>> For example when downloading the new graphviz-8.0.1.tar.bz2 I get a file
>>> named :
>>> graphviz-8cd5300e2e31c80dbbfcdd65aad697187e5ac0b0.tar.bz2
>>
>> This is what I get clicking on the link in firefox.
>> However wget   works as usual.
>> Didier
> 
> No matter whether content disposition or not, the tar contains the following
> dir for 7.1.0: 'graphviz-e650d3ba65f6d672a1fe09505bb576d4fed320bc'. That's not
> the expect $VERSION naming. What the actual fuck...
> 

That was the main problem, true.
Fortunaltely, it turns out this was probably a mistake on gitlab part, and
things are now working as usual again !

So Graphviz will be updated this week...

Cheers !

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Gitlab download filename changed

[Arnaud via SlackBuilds-users]

Hi everybody,

it seems that gitlab download filenames changed very recently.
For example when downloading the new graphviz-8.0.1.tar.bz2 I get a file named :
graphviz-8cd5300e2e31c80dbbfcdd65aad697187e5ac0b0.tar.bz2

So I tried for another package, say for example slpkg, which I built fine 8 days
ago, the file was properly named slpkg-4.6.1.tar.gz
Now it is named slpkg-52a30faf2a1e3680ea60e08093181e05fc6828b0.tar.gz and my
build script fails.

Has anybody any news about that ? Some transient problem ? A big change that'll
make all maintainers of all distributions all around the world shout angrily ?

- Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Rust question for python3-bcrypt

[Arnaud via SlackBuilds-users]

Erich Ritz via SlackBuilds-users 
> See for example https://slackbuilds.org/repository/15.0/system/bat/
> The SlackBuild has an extra bit that forces cargo to look on the local
> filesystem instead of the net.
> Additionally, here are my scripts to create the the "DOWNLOAD" and "MD5SUM"
> parts of the info file.  Someone has a better script posted on LQ which I 
> can't
> find right now and never got around to integrating into my process.  It just
> creates pkg.info directly instead of having you copy and paste bits around.

Tonus 
> Hi,
> 
> When I asked, I've been given this script from K. Eugene Carlson  
> Tsukuba that is attached.
> 
> Regards,
> 
> Tonus

Thanks both !

I used bit of both answers, and managed to make it work.
That's... not very straightforward, hence many thanks for the scripts !

And here I was thinking maintaining Python stuff was kinda painful, welcome to
Rust inside Python ;)

Cheers !

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Rust question for python3-bcrypt

[Arnaud via SlackBuilds-users]

Hi fellow Slack(Build)ers,

I have a package (namely python3-bcrypt) that recently added some Rust
stuff.
If we simply bump the version to 4.0.1, and add python3-setuptools-rust as
requirement it builds fine.
See files included for anyone wanting to try it.

It builds fine, *but*...
It downloads a lot of crates.
And that is not SBo policy to download stuff during a build.
So I need to add those crates to the download URLs, and make the SlackBuild use
them.

And I am not Rust-proficient.

Hence I'm asking for some help here on how to do that, and how to maintain it
properly thereafter.

Thanks !

 - Yth.


python3-bcrypt.tar.xz
Description: Binary data
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Script that will not build on 32bit Slackware

[Arnaud via SlackBuilds-users]

Hi Andrew !

It is possible to have a slackbuild only for x86_64.
Simply put UNSUPPORTED on the DOWNLOAD value of the. info file, with empty 
MD5SUM, and add the source url on DOWNLOAD_x86_64, with proper MD5SUM_x86_64.

You can add a comment on the README stating that 32 bit build is in progress 
upstream and may become available in the future.

That's all 

Regards,

 — Yth 

Le 7 mars 2023 06:56:51 UTC, andrew  a écrit :
>Hi,
>
>I am preparing build scripts for the newish encoder and decoder for
>H.266 video: vvenc and vvdec. vvdec compiles and runs fine on 32bit
>but vvenc does not.
>
>See the bug report I filed here:
>
>https://github.com/fraunhoferhhi/vvenc/issues/242
>
>You will see that one of the developers has undertaken to correct the
>issue while also questioning the worth of running the encoder on 32bit
>Linux at all.
>
>So my plan was, in the interim, to submit both scripts to SBo as 64bit
>only but I am not sure if:
>
> 1. This is in line with SBo policy
> 2. Exactly how to make this clear in the SlackBuild
>
>Thanks for your throughts and advice,
>
>Andrew
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Explanation regarding reverting python3-mistune to build python-m2r

[Arnaud via SlackBuilds-users]

> 
> Hi Duncan,
> 
> I suggest simply removing python 3 support from python-m2r instead.
> In that case, we do not need to update python2-mistune.
> 
> If we really need python 3 support for python-m2r, I would suggest splitting
> python-m2r into 2 packages: python2-m2r (v0.2.1), which depends on
> python2-mistune (v0.8.4) python3-m2r (v0.3.1), which depends on
> python3-mistune1 (v0.8.4) ​​
> As I mentioned, python3-mistune1 is meant to be an older version of
> python3-mistune (at v2.0.4).
> 
> ​After all, it was Yth's original intention to split mistune into
> python2-mistune and python3-mistune.
> 
> - Isaac

I think it's the best thing to do.
m2r is only used by Automat, and has been removed as requirement, because it's
optional, and only used for generating better documentations.

It is very possible that Automat uses the /usr/bin/m2r command, and not any
Python import, so having the python2 version of m2r wouldn't prevent
python3-automat for using it.

Since m2r looks very unmaintained, and should still work while being python2
only, it looks safe to remove the python3 support for it.

As for mistune, the python2 version, stuck at 0.8.4, is only used by python-m2r,
so all this stays pretty legacy, and we have nice updated stuff on python3.

My advice is that we don't need a python3-m2r or a python3-mistune1.

Cheers,

- Yth.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Trouble building graphviz 7.0.6

[Arnaud via SlackBuilds-users]

> Hi,
> 
> Build originally failed when sed could not open /usr/lib64/libglib-2.0.la.
> 
> I tried messing around with Makefiles but I couldn't make it go away so
> patched graphviz.SlackBuild to temporarily inject libglib-2.0.la into the 
> build
> system.
> 
> You are welcome to the patch, just say
> 
> Cheers ... Duncan.

That's strange, it had been tested and not only by me.
I've reconstructed my build environment from scratch, and built graphviz.

It worked perfectly fine.

Could you tell me more about your setup, and the error itself ?
Are the requirements up-to-date ?

Cheers,

- Yth
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Updates - 20221105.1 - Failures on xmlsec and slackrepo

[Arnaud via SlackBuilds-users]

Hi folks !

xmlsec and slackrepo are failing to build since last update.

For xmlsec, the documentation files are wrong, it fails copying README, which is
really named README.md

For slackrepo, there's been a probable copy-paste, or sed, mistake since the
DOWNLOAD URL now states
20221105.com/aclemons/slackrepo/archive/v20221105/slackrepo-20221105.tar.gz
Where it should be on github.
sbolint caught that one.

Best Regards,

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] BuildScripts up for grabs

[Arnaud via SlackBuilds-users]

> pyasn1-modules

I'll take that one, as it's a dependency of python3-twisted.

- Yth/Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Sourceforge Slackbuildsdirectlinks access changed ?

[Arnaud via SlackBuilds-users]

> > It seems I can't upload files to the slackbuildsirectlinks account on
> > Sourceforge.
> > Did something change here ?
> > I may have missed some information...
> > I was connecting through sftp and uploading into :
> >   /home/frs/project/slackbuildsdirectlinks/dosbox/
> > But now that directory doesn't exist anymore, even /home/frs/project/ seems
> > unavailable...
> 
> I'm changing your role now
> please try and let me know if it works now
> i might add other active maintainers as well if it works
> 
> 
> -- 
> Willy Sudiarto Raharjo
> 


This is working fine now, thank you !

But Sourceforge seems to have changed a few things:
My downloaded file was named dosbox-dev-0.75_pre4481.tar.xz?viasf=1
Using "wget --content-disposition".

Could someone try building dosbox-dev (or any other package hosted on
slackbuildsdirectlinks) using any other automated tool, to see if it is handled
properly ?

- Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Sourceforge Slackbuildsdirectlinks access changed ?

[Arnaud via SlackBuilds-users]

Hi!

It seems I can't upload files to the slackbuildsirectlinks account on
Sourceforge.
Did something change here ?
I may have missed some information...
I was connecting through sftp and uploading into :
 /home/frs/project/slackbuildsdirectlinks/dosbox/
But now that directory doesn't exist anymore, even /home/frs/project/ seems
unavailable...

-- 
Arnaud 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] OT qmake not found

[Arnaud via SlackBuilds-users]

> Hello and have a nice weekend dear fellow Slack Builders,
> 
> the trouble qtmib complained qmake missing
> 
> "wich" finds "qmake" in "/usr/lib/qt5/bin".
> 
> In "/usr/bin" I see "qmake-qt5 -> ../lib/qt5/bin/qmake".
> 
> After
> 
> ln -s /usr/lib/qt5/bin/qmake /usr/bin/qmake
> 
> qtmib successfully built and I guess qtmib is not the only one.
> 
> Kind regards and sorry for the noise
> Peter Dambier, DL2FBA

/usr/lib64/qt5/bin should be added to $PATH by /etc/profile.d/qt5.sh
So either you're not in a full root shell (eg: use "su -", and not just "su"),
or something else is wrong on your end.

You should have :
$ which qmake
/usr/lib64/qt5/bin/qmake

Cheers,

- Yth.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Removal of tryton / trytond

[Arnaud via SlackBuilds-users]

Hi all,

the tryton and trytond packages are wy out-of-date :
They are 8 years old, as the latest release is 8 days old.
It probably doesn't work as it is, looking at the dependency tree which is a
proper python2/python3 mess.

It is obviously unmaintained, and nobody seems to care.

So I suggest we simply remove those packages instead of advertising we have a
Slackbuild for it.

This'll also allow me to remove the obsolete python2 psycopg2, which isn't used
anywhere else, and, as other python2 slackbuilds, should be allowed a proper
burial.


If nobody objects I'll send a PR to this effect.

 - Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] DevIL - Does not Compile when nvidia-texture-tools is installed

[Arnaud via SlackBuilds-users]

> On 22/05/22 14:46,
> Konrad J Hambrick  put forth the proposition:
> > All --
> > I emailed the maintainer on May 12 but have received no reply.
> > Below is the email I sent.
> > The Punchline is that the DevIL SBo will not compile on my Slackware64
> > 15.0 + Multilib System when the nvidia-texture-tools SBo is installed.
> > The simplest fix is to turn off nvidia-texture-tools via a cmake Config
> 
> > Is this the best place to post such info ?
> > Thanks everyone !
> > -- kjh
> 
> This is the right place, usually we accept patches as attachments,
> but if this only the one flag.  I can take a look this week.
> 
> We don't support multilib though, so do you know if it fails still on
> a non-multilib full 15.0 installation?
> 
> Link to blog post on sending patches:
> https://slackblogs.blogspot.com/2022/03/how-to-send-patches-to-sbo.html.

Well, I did reply, but my mail provider has been quite unprofessional lately.
I'll look into it, and push an update.

 - Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Updating Redis - and whats depends on it...

[Arnaud via SlackBuilds-users]

Hi everybody,

I'm in the process of taking over Redis and updating it (from 4.0.9 
released 4 years ago, to 6.2.6).
That works pretty nicely, but a few projects are depending on it, and are 
pretty outdated.

 - libraries/php-redis: May be bumped from 4.2.0 to 5.3.7, but seems to work 
fine anyway. Though its maintainer, Ebben Aries, hasn't been active in 2 years.
I will post an update for it, and if nobody maintains it by two weeks, I'll 
take over, as it is kinda linked to redis.

 - system/redis-py: Also very obsolete (2.10.5 is more than 6 years old !), 
builds for python2 (we ought to mercifully kill that beast), and its maintainer 
is very much active here.
So Dimitris, do you want me to handle that one for you ?

 - system/trmaid: builds on Python2 (again !?), but its dependencies are not 
all python2. Namely feedparser builds only Python3. Hence this will not work.
I don't very much want to take over that one, but I will update it if nobody 
does, just so that it works.

 - network/openvas-libraries: another outdated thingy. OpenVAS is still pretty 
much active, but it seems that openvas-libraries in itself doesn't exist 
anymore, the whole bunch of SlackBuilds relating to OpenVAS ought to be 
reworked, and I don't really want to do that. Its maintainer, Kent Fritz, seems 
inative for 1 year and a half. I won't do anything about it, and I don't know 
if updating Redis will break it, but since it doesn't build anyway (source 
isn't available anymore), that won't change much.
Maybe remove all (openvas-cli, openvas-scanner, openvas-libraries), if nobody 
wants to take over maintainership there ?

To summarize :
 - I will post updates for php-redis, redis-py and trmaid, if nobody steps up 
soon.
 - I will take over maitainership of php-redis in a few weeks if there is still 
no active maintainer.
 - I'm willing to take over redis-py from Dimitris Zlatanidis, because it seems 
pertinent since I will be maintainer of Redis itself.

 - I don't especially want to maintain trmaid, I'm just OK to make it work 
today.
 - I will not look into OpenVAS.


Cheers,

- Yth / Arnaud
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Please your support

[Arnaud via SlackBuilds-users]

Same here 

 — Yth.

Le 18 avril 2022 10:03:10 UTC, marav  a écrit :
>Le 17/04/2022 à 19:55, Dimitris Zlatanidis a écrit :
>> Greetings to all members,
>>
>> I would like to ask for your support.
>> I'm giving a job interview (Python Developer) and my Gitlab 
>> repository, will play an important role, so whoever wants to add an 
>> asterisk in my Projects and especially in slpkg, colored, sun, 
>> dropbox-filemanager, sbo-templates etc., I would appreciate it a lot!
>>
>> Thank you very much,
>> Dimitris
>>
>Done!

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Contacting Audrius Kažukauskas

[Arnaud via SlackBuilds-users]

> Hi!
> 
>   I've tried contacting Audrius Kažukauskas 3 weeks ago, about his
> SlackBuilds, but received no answers.
> His last contribution was more than a year ago.
> 
> Does anyone know if he's still active and well ?
> 
> Else I my need to upgrade some of his packages (redis and hg-git, probably 
> some
> containerd/runc related stuff too as I use them at work).
> 
> Thanks,
> 
>   - Yth.

Hello fellow Slackers,

seeing as I've still had answers neither from Audrius, nor from anybody
on the list with informations, I'll take over maintainance of some of his
SlackBuilds.
Namely :
 - dulwich: it is the python2 build, I already maintain python3-dulwich.
 - hg-git: doesn't work as it is, needs update to python3
 - pgbadger, pgsanity: if nobody wants them, I already maintain psycopg2.
 - redis: I use it, already updated at home, I'm ok with keeping it up-to-date.
 - graphviz: I use it too.
 - pypy, pypy3: python stuff, I already have so many, what's two or ten more ?
 - smem, iotop: why not ?
 - uwsgi: interesting, I'll look into it.


There are also a lot of container/docker related SlackBuilds there, some not 
very
up-to-date. If nobody wishes to care for them, I may step up in a few weeks, but
I'd be glad not to add too much stuff on my plate.
This concerns those SlackBuilds, at least :
 - python2-cached-property
 - python2-docker-pycreds
 - python2-docker
 - python2-dockerpty
 - python2-texttable
 - containerd
 - docker-cli
 - docker-compose
 - docker-machine-kvm
 - docker-machine
 - docker-proxy
 - docker
 - runc
 - tini
I have not checked whether the python2 packages exists in python3 version and
could be removed as requirements of docker related stuff, switching everything 
to
python3.


If all that's OK, I'll submit updates (for the first list only) this week.

Cheers :)

- Yth / Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] openjdk8 compile (either manually or via sbotools) failing at openjdk7

[Arnaud via SlackBuilds-users]

> Here is what I have found.  The checksum error comes from the new zlib
> 1.2.12, which may have fixed the problem in 1.2.11 but I suspect badly
> broke something else.  Adding --disable-system-zlib to the icedtea
> configure parameters takes care of that.
> As for the libstdc++ library linking issue on 32-bit, this looks like an
> issue with the interaction between gcc11 and gcc5 and not in openjdk(6,7).
> Installing an older -current in a test partition (actually 15.0-rc1), I'll
> let you know what I find.

Well, our messages crossed path, but they lead to the same conclusion.

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] openjdk8 compile (either manually or via sbotools) failing at openjdk7

[Arnaud via SlackBuilds-users]

> Hello Luc
> 
> Yes it does seem to work from a fresh install with no updates as I 
> mentioned earlier.
> 
> It will be interesting to know how it goes for you once the updates are 
> applied.
> 
> Might be a good idea to resinstall Slack again (clean machine) and then 
> apply the updates and then try the build - that would match what I 
> originally did when it failed.
> 
> Regards and thank you
> Habs

Well, my chroots (multilib or not) are not fully uptodate.

Here is the [patches applied] -> [patches not applied] list:
aaa_base-15.0-x86_64-4_slack15.0
at-3.2.3-x86_64-1_slack15.0
bind-9.18.1-x86_64-1_slack15.0 -> bind-9.16.27-x86_64-1_slack15.0
bluez-5.64-x86_64-1_slack15.0
boost-1.78.0-x86_64-2_slack15.0
ca-certificates-20220309-noarch-1_slack15.0 -> 
ca-certificates-20220403-noarch-1_slack15.0
cyrus-sasl-2.1.28-x86_64-1_slack15.0
expat-2.4.7-x86_64-1_slack15.0
flac-1.3.4-x86_64-1_slack15.0
httpd-2.4.53-x86_64-1_slack15.0
libxml2-2.9.13-x86_64-1_slack15.0
libxslt-1.1.35-x86_64-1_slack15.0
mariadb-10.5.15-x86_64-2_slack15.0
mozilla-firefox-91.7.1esr-x86_64-1_slack15.0
mozilla-thunderbird-91.7.0-x86_64-1_slack15.0
openssl-1.1.1n-x86_64-1_slack15.0
openssl-solibs-1.1.1n-x86_64-1_slack15.0
php-7.4.28-x86_64-1_slack15.0
polkit-0.120-x86_64-3_slack15.0
python3-3.9.11-x86_64-1_slack15.0 -> python3-3.9.12-x86_64-1_slack15.0
qt5-5.15.3_20220312_33a3f16f-x86_64-1_slack15.0 -> 
qt5-5.15.3_20220318_e507d3e5-x86_64-1_slack15.0
seamonkey-2.53.11-x86_64-1_slack15.0 -> seamonkey-2.53.11.1-x86_64-1_slack15.0
util-linux-2.37.4-x86_64-1_slack15.0
 -> glibc-zoneinfo-2022a-noarch-1_slack15.0
 -> vim-8.2.4649-x86_64-1_slack15.0
 -> vim-gvim-8.2.4649-x86_64-1_slack15.0
 -> whois-5.5.12-x86_64-1_slack15.0
 -> zlib-1.2.12-x86_64-1_slack15.0

I see two possible culprits :
 -> glibc-zoneinfo-2022a-noarch-1_slack15.0
 -> zlib-1.2.12-x86_64-1_slack15.0

I'd bet on zlib, but I've been known to be false ;)
Because the error is :
  > java.util.zip.ZipException: invalid entry CRC (expected 0x3943b2a7 but got
0xc7a06d31)
So I downgraded zlib to the stock Slackware 15.0 on my main box (which is not 
clean, bloated, but uptodate as a few days ago).
And I'm rebuilding it there.
...
[ 46 minutes later ]
...
It worked !
So I guess there is something different with the new zlib, and it might 
probably be worth mentioning to Pat and Ze SlackTeam on Linuxquestions.
I should test with updating zlib on the chroot and see it fail, but I'm going 
away for the week-end, so see you all on monday.

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] openjdk8 compile (either manually or via sbotools) failing at openjdk7

[Arnaud via SlackBuilds-users]

On Thu, 7 Apr 2022 22:17:56 +1000
Christoph Willing  wrote:
> 
> I don't normally have /tmp as tmpfs and the build has consistently
> worked OK.
> 
> I just tried with /tmp as tmpfs and had a few failures because of
> insufficient "disk" space. The reason is quite explicitly explained when
> it happens so I don't think that is OP's problem.
> 
> Eventually the build succeeded when I had 10G allocated (it used ~8.3G)
> and the build was quite a bit faster (23mins vs 36mins).
> 
> chris

Well, you're right, I just rebuilt it on a tmpfs place.
It is faster, and doesn't wear SDD drives, and my box has 32G of RAM,
hence I'm pretty OK with a 24G tmpfs for building stuff.

So eliminating process shows :
 - tmpfs or SSD are both OK.
 - JOBS=1, JOBS=5 or JOBS=9 doesn't change the outcome.
 - setting LANG=C, LANG=en_US.UTF-8 or LANG=fr_FR.UTF-8 is the same (we
never know when unicode might break something old !)
 - sourcing /etc/profile.d/gcc5.sh matters not.
 - multilib chroot or normal chroot are both working. Today. Because
yesterday's multilib chroot wasn't working (it had fontforge,
webcore-fonts, and some python packages for Kallithea and buildbot, I
removepkg'ed all non-slackware and non-multilib stuff).


So I think I figured it out finally, and we should have these sentences
added to the README :
«
  This build may consistently fail.
  In case it happens, please do unrelated stuff, sleep it off, and retry
  another day.
  It might pretty well consistently work by that time.
 »

- Yth...
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] openjdk8 compile (either manually or via sbotools) failing at openjdk7

[Arnaud via SlackBuilds-users]

On Wed, 6 Apr 2022 22:24:19 -0400
Lenard Spencer  wrote:

> Since openjdk6 and 7 can no longer be built at this time, I would have to
> say drop them for now.  openjdk8 can be built if you have zulu-openjdk7
> installed and adjust BOOT_JAVA to point to /usr/lib(64)/zulu-openjdk7 in
> the script.

Well, I wouldn't say it can no longer be built, because it can, but we still 
haven't figured out why it fails for some and not for others.

I *might* have a lead though.

I usually use a tmpfs for my builds.
I tried with a real drive, not tmpfs.
And, well, it worked, I've just build openjdk7.

May some other share if they are using tmpfs for TMP ?
And if so, does the build works if they don't just for this time ?

- Yth / Arnaud
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] openjdk8 compile (either manually or via sbotools) failing at openjdk7

[Arnaud via SlackBuilds-users]

> >> java.util.zip.ZipException: invalid entry CRC (expected 0x3943b2a7 but
> >> got 0xc7a06d31)
> >
> > This looks like you're inadvertently using the wrong set of source
> > files. Each new openjdk version has a new set of source files, many of
> > which have no version number (openjdk.tar.bz2, corba.tar.bz2, ...) so
> > your build system can easily pick up the wrong source file.
> >
> > chris
> 
> Good morning all
> 
> I do not doubt the comment above, but in this case, how could it be unless 
> the slackbuild source links are out of step/compromised/whatever.
> 
> As I mentioned, it is a clean physical machine freshly installed and then 
> updated - no other [java related or other slackbuild addons etc] downloads 
> prior - and simply the source files linked in the slackbuild info.  Each 
> slackbuild individually run using 'su -' (rather than using sbotools or 
> similar) as required.  I don't even get to try openjdk8 (or download 
> anything for it) as apache-ant, gcc5 and openjdk7 are listed as required 
> first.  It is openjdk7 that is failing in that chain as such.
> 
> That all said, I will go back and check the sources, though I think that 
> has been done by Matteo.
> 
> Regards
> Habs

My comment will not add much to the problem, but my several tries are all 
failing at the same place (ie: invalid entry CRC).
Be it on my master very unclean multilib box, a chroot, multilib or not, 
updated and clean, or some other cleaner boxes, VMs, not multilib, I can't make 
it build, and it always fails on the same place...

But unlike others here, I don't pretend doing it on perfectly clean 
installations (though always without any other java installed).
Although I am really sure my source packages are the right ones, MD5SUM checked 
and all.

-- 
Arnaud 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Contacting Audrius Kažukauskas

[Arnaud via SlackBuilds-users]

Hi!

I've tried contacting Audrius Kažukauskas 3 weeks ago, about his
SlackBuilds, but received no answers.
His last contribution was more than a year ago.

Does anyone know if he's still active and well ?

Else I my need to upgrade some of his packages (redis and hg-git, probably some
containerd/runc related stuff too as I use them at work).

Thanks,

- Yth.

___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Request to team members: File exists; a submission by the name 'molequeue' is already pending approval

[Arnaud via SlackBuilds-users]

> Hi,
> 
> I uploaded some slackbuilds for a new package, Avogadro 2, but the 
> slack-desc of two slackbuilds wasn't correctly formatted, then I removed 
> them: avogadroapp, avogadrolibs, and molequeue. Second step I uploaded 
> avogadroapp and avogadrolibs with the slack-desc fixed.
> 
> However I cannot upload "molequeue.tar.gz" (dependency needed by 
> "avogadrolibs") because it appears already uploaded:
> 
> *"*File exists; a submission by the name 'molequeue' is already pending 
> approval"
> 
> But the old tarball has been removed! It appears only in the database of 
> pending istances. Sorry, I surely made a mistake with the removal, but 
> Avogadro 2 cannot be built without molequeue and I can't send this 
> dependency. Please, would you solve the issue?
> 
> Thanks
> 
> gian

Hi!

Looks like I've got the same problem with python3-tubes, I need to
submit it, but I've made a mistake and I can't...

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Name clash

[Arnaud via SlackBuilds-users]

The submission queue is also for updates.
It is mandatory for new packages.

 - Yth.

Le 27 mars 2022 21:41:20 UTC, Christoph Willing  a 
écrit :
>After I submitted a new SlackBuild, I checked that it existed in the
>pending queue. Right after my own submission, I noticed another
>submission for a SlackBuild which already exists - dcmtk.tar.gz
>
>Assuming the new submission is for new _different_ software, the name
>will have to be changed.
>
>chris
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Please update your tqdm SlackBuild

[Arnaud via SlackBuilds-users]

> > Hi Dionysis,
> >
> > Many thanks for that: I sent a pull request with the minumum necessary 
> > changes.
> > On a freshly installed 15.0 system, python is python3, so your SB only 
> > makes the
> > 3.9 packages. You might want to change `python` to `python2`, but I leave 
> > that
> > up to you.
> 
> No, /usr/bin/python points to python2.7: [...]
> Looks like existing practice on SBo is split between "python setup.py" and 
> python2 setup.py", with the majority being "python setup.py":
> 
> $ git grep "python setup.py" | wc -l
> 662
> $ git grep "python2 setup.py" | wc -l
> 298
> $ git grep "python3 setup.py" | wc -l
> 671
> 
> 
> Erich

Looking at install scripts for slackware's python2 and python3, the symbolic 
link /usr/bin/python is for python2, whatever package you install first. And 
even if python2 is uninstalled, you won't have a /usr/bin/python executable.

So python is python2, and python3 is always explicit.

However, more and more slackbuilds are explicit for python2 also, which is a 
good thing, and should be the rule, at least whenever any given python2 package 
is updated for another good reason.

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] NodeJS version in Slackbuild causing issues

[Arnaud via SlackBuilds-users]

That will not change anything on slackbuilds.org, because node.js was added to 
-current.
We are at 15.0, so no node.js there, and we need to keep maintaining it.

It'll be dropped when 15.1 is out.
Yeah, yeah, one day... 

 - Yth.

Le 2 mars 2022 23:09:47 UTC, Duncan Roe  a écrit :
>On Wed, Mar 02, 2022 at 01:12:13PM -0300, Ricardo J. Barberis wrote:
>> FYI, SBo admins surely know already but nodejs LTS got added to Slackware
>> today:
>>
>> slackware64 current changes for Wed, 02 Mar 2022 01:54:23 GMT
>> a/lrzip-0.650-x86_64-1.txz:  Upgraded.
>> d/mercurial-6.1-x86_64-1.txz:  Upgraded.
>> l/nodejs-16.14.0-x86_64-1.txz:  Added.
>>   Thanks to Audrius Kažukauskas, Ryan P.C. McQuen, and Willy Sudiarto 
>> Raharjo
>>   for the slackbuilds.org version of the build script.
>>
>> El sabado, 26 de febrero de 2022 20:41:33 -03 nix escribio:
>> > > The last post in that thread indicates to try upgrading nodejs to 17.6.0.
>> > > Try that -- it's been updated in the SBo master branch already.
>> > >
>> > > -RW
>> >
>> > Ah, I forgot to pull the latest version in the repo. Thanks for for
>> > that. I will give it a try.
>> >
>> > Eric
>>
>I don't see this in 15.0 patches
>http://slackware.osuosl.org/slackware64-15.0/patches/packages/
>
>Cheers ... Duncan.
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] renaming python scripts

[Arnaud via SlackBuilds-users]

> Hi all,
> 
> Some of my python scripts, mostly inherited, tend to be a bit over the
> place. Some are named with a python?- prefix, some aren't, some are not in
> the python folder but in libraries (nltk and that one is my fault).
> 
> I know there has been a long discussion in the past on how to deal with
> python naming  but I am sure where we are at.
> 
> This was vaguely prompted by me tracking my packages in repology which in
> some cases doesn't add the python: prefix to some of the packages (xarray
> and nltk).
> 
> Should I rename/relocate these?
> 
> Greg

Hi !

I have a lot of work to do myself on that part.

I think the only thing that was mostly decided is that python2 only packages 
should be named python2-package

Hope that helps at least a little...

- Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Concerning 15.0 and 14.2

[Arnaud via SlackBuilds-users]

Today's message was : I will be finished tomorrow.
...
Can't wait... 

 - Yth

Le 2 février 2022 00:43:48 UTC, Rich Shepard  a écrit 
:
>On Tue, 1 Feb 2022, King Beowulf wrote:
>
>> After that message there was "Hey, my shiny brass lamp is almost out of
>> fuel!"
>>
>> Hopefully "real soon now!"
>
>Ed,
>
>I saw that the cave was closed (is that the home of the Clan of the Cave
>Bear?) and that his shiny brass lamp was low on fuel but they meant nothing
>to me as I haven't followed the developer's jargon.
>
>And chaning the output to pulse and killing the mics fixed the problem.
>
>Thanks,
>
>Rich
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Concerning 15.0 and 14.2

[Arnaud via SlackBuilds-users]

Well, Pat did write in this morning changelog « The cave is now closed ».
We are at 15.0 RC3.

We may have jumped ship a bit early last year, but it might not be long before
15.0 is out...

 - Yth.


> OK, thanks. No slur implied - it's just that I have a number of 14.2
> systems, and I needed this information to decide if and when I will upgrade
> them to 15.0 once it is available.
> 
> On Tue, Feb 1, 2022 at 1:51 PM B Watson  wrote:
> 
> > On 2/1/22, Luveh Keraph <1.41...@gmail.com> wrote:
> >
> > > What happens to 14.2? No Slackbuilds packages for 14.2 will be updated
> > any more?
> >
> > Correct. 14.2 slackbuilds.org branch is already considered frozen,
> > not getting updated. We just don't have the time/energy/resources to
> > keep updating builds for previous versions. The same thing happened
> > before 14.2 was released, at some point we stopped updating for 14.1
> > and started gearing up for 14.2 (at which time, the submission form
> > was closed, just like it is now).
> >
> > From a user's perspective, it might look like we jumped the gun and
> > started updating everything for -current a bit too early... but it's
> > been (and still is) a lot of work to get everything ready for 15.0.
> >
> > Remember we are a small team of unpaid volunteers...
> > ___
> > SlackBuilds-users mailing list
> > SlackBuilds-users@slackbuilds.org
> > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> > FAQ - https://slackbuilds.org/faq/
> >
> >


___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Slackbuilds

[Arnaud via SlackBuilds-users]

> I am no longer going to be maintaining my Slackbuilds. Please feel free to
> claim them.
>
> Best, Ben

Well, that's a shame, you were doing a great work.
Best of luck in the future, and thanks for all the time spent !

I could take over those slackbuilds :
development/psycopg2
libraries/Jinja2
python/Pygments
python/bleach
python/decorator
python/parso
python/mistune
python/click-plugins
python/pyzmq
python/python3-pyzmq
python/python3-wcwidth
python/python3-dateutil
python/python3-babel
python/python3-prompt_toolkit
python/python3-webencodings

Mostly requirements of stuff I already do.

Yth - Arnaud
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] [Slackware64-current] zfs-on-linux build broken

[Arnaud via SlackBuilds-users]

Apparently, installing latest update of Slackware-current should fix that 
problem.

Changelog says you need tu run autoreconf -vif for exactly that problem, with 
automake-1.16.5

 - Yth.

Le 11 octobre 2021 04:06:51 UTC, David Chmelik  a écrit :
>People were able to get zfs-on-linux (now actually openzfs) working on 
>Slackware64-current by just changing the SlackBuild version number.  
>People should be using 2.1.1 now and in SBo-git it should be updated to 
>reflect that.  However with the recent Slackware64-current python3 
>upgrade, zfs-on-linux will no longer build.  Its configure script is 
>broken and detects python 3.10.0 as 3.1 and says it's too old, so won't 
>continue.  What can be done about this meantime so people can continue 
>to use zfs-on-linux with newer kernels on Slackware64-current before 
>Slackware 15?
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] notice of change of maintainership

[Arnaud via SlackBuilds-users]

On Thu, 7 Oct 2021 21:49:28 +0200
Markus Reichelt  wrote:

> Yo. Many moons ago already maintainership was passed along for the
> following scripts: (CC: because of reasons :-)
> 
> buildbot-worker / -slave, python-twisted, attrs, Automat, constantly, 
> hyperlink, incremental
> 
> for the transitional period, this is done exactly how? :-)
> 
> just switch me for 'y...@ythogtha.org' in the sea of scripts, that'd
> work for me.
> 
> All the best. --jg71
> 
> 
> -- 

Hi Markus !

yes, I'll work on it again, maybe not waiting for 15.0 anymore, since 
we don't really know when it'll be there.
I'll update my draft-PR and submit it !

- Yth / Arnaud
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] anyone wants my SlackBuilds?

[Arnaud via SlackBuilds-users]

I'd be okay to take all vcmi related SlackBuilds along with heroes3 demo data.

 - Yth /Arnaud.

Le 19 septembre 2021 18:09:55 UTC, Franzen via SlackBuilds-users 
 a écrit :
>> I am not using Slackware anymore, so hereby I turn my SlackBuilds over
>> to whoever wants to adopt them.
>
>I'll take "digger".
>
>Johannes
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/
>

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Opensmtpd build error

[Arnaud via SlackBuilds-users]

> I'm sorry but I haven't look at it for an update: you should ask those
> informations to an eventual maintainer but, as I explained in the previous
> mail, at the moment there isn't one.
> 
> Matteo
> 
> Il giorno mar 24 ago 2021 alle ore 11:04 karthik krishna <
> karthikkri...@gmail.com> ha scritto:
> 
> > Thanks
> > If i need to use the latest version how do i build it ?
> > what changes would i need to make in the slackbuild script?
> > I updated the version info in the slackbuild script but that doesn't seem
> > to help

If you get the latest Slackbuild from the git repository's master branch, it is
on version 6.6.4p1.
A simple version bump to 6.8.0p2 works perfectly on -current :
VERSION=6.8.0p2 ./opensmtpd.SlackBuild

That's the easiest way to do it !

Slackbuild's git is there : git://git.slackbuilds.org/slackbuilds.git
Always uses this on -current, until 15.0 is out (or even after, but at least
until).

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Bad character in snappy.info

[Arnaud via SlackBuilds-users]

> If we use UTF-8 for names in Spanish, where does it end?
> 
> I cannot easily recognize UTF-8 names in Chinese or Thai or Russian or
> Japanese.
> 
> My keyboard does not easily support such languages.
> 
> If we allow UTF-8 names in SlackBuild scripts then how about UTF-8 in
> documentation and descriptions?
> 
> Where does it end?
> 
> I would hope that we keep the English language as a standard for
> software that I can, read and write and that matches my keyboard.
> 
> Richard Narron


Well,mostly, you do not need to write people's names, and you could
always easily cut and paste them.
So it could stop at them names.

To be noted that UTF-8 email addresses are valid, per the standard, so
we can't really forbid UTF-8 in EMAIL field, so .info files should be UTF-8
valid, hence MAINTAINER field could also have UTF-8.

That being said, as a rule, everything should always work with UTF-8.

 - Yth.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] (re)naming of Python software

[Arnaud via SlackBuilds-users]

I'm working on a lot of python stuff too.
And I do agree :
Python3 by default
Python3 MoDuLe is named python-module
Python2 MoDuLe is named python2-module
Python Software is named software (like mercurial for example)

It seems it is often pertinent de separate both because requirements differs, 
even if the version is the same fir Python 2 and 3.

That being said, I'd be glad to rename my different python MoDuLe called MoDuLe 
for consistency.

 - Arnaud.

Le May 4, 2021 11:39:10 AM UTC, Didier Spaier  a écrit :
>Hello,
>
>Now that Python 2 is end-of-life and its support ended how should we 
>handle the
>naming of Python packages? I'd be tempted to us python for python3 
>packages and
>packages still built against both 2 and 3 and python2 when built
>against
>python2 only.
>
>I ask as I am in the process of upgrading Python3 in Slint to 3.9.x (I
>won't
>wait until Slackware 15 be released because we ship 3.5.9, really too 
>old) and
>would like that the naming in Slint be consistent with the one in SBo
>to 
>help
>users check if a software "packaged" by SBo is included in Slint and
>avoid
>installing a software twice.
>
>Also, how to best handle the transition in case of a renaming?
>
>Cheers,
>Didier
>___
>SlackBuilds-users mailing list
>SlackBuilds-users@slackbuilds.org
>https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>FAQ - https://slackbuilds.org/faq/

-- 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] Warzone 2100 4.0.0 will have to wait.

[Arnaud via SlackBuilds-users]

> On 4/10/21 1:15 PM, Dave Woodfall wrote:
> > Slackbuilds Users  put forth the
> > proposition:
> >> Hi everybody,
> >>unfortunately 14.2 oldness striked again.
> >> This time it's SQLite that is too old for the brand new 4.0.0 version of
> >> Warzone
> >> 2100.
> > 
> > Have you looked at the possibility of using a bundled version of
> > sqlite?  A few slackbuilds download and use internal versions of libs
> > etc. when the stock ones are too old.
> > 
> 
> I considered this as well for some of mine but rejected it.  Since
> Current is "real soon now" it didn't seem worth the effort or risk.
> 
> -Ed

I'm there too : doesn't feel its worth the hassle since 15.0 is coming.
And also, I feel that people really wanting to have an up-to-date warzone2100
might already be on -current, at least since 15.0-beta is out.
And others may feel ok to wait a few months (hoping it won't be longer).

But that's also why I sent the original message :if there are people really
wanting it for 14.2, then it might be worth the effort. If nobody really asks
for this specifically, I won't do it.

-- 
Arnaud 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Warzone 2100 4.0.0 will have to wait.

[Arnaud via SlackBuilds-users]

Hi everybody,

unfortunately 14.2 oldness striked again.
This time it's SQLite that is too old for the brand new 4.0.0 version of Warzone
2100.

For people using -current at home, a simple version bump is enough to build the
package.
Others will have to either upgrade their sqlite at their own risk, or wait for
15.0...


Arnaud 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Allegro 5 and slackware-14.2

[Arnaud via SlackBuilds-users]

Hello everybody,

Allegro 5.2.7.0 does not build on slackware 14.2 because one of its
internal addons (native_dialog) uses gtk3, and 14.2 gtk3 version is too old.

There are two ways I can go with this :
 - conservatism, by sticking to 5.2.6.0 until slackware 15.0 is out.
 - I-don't-care-ism, by disabling this particular addon.
I have no idea what would be the impact of disabling this addon for 
other
slackbuilds, and I don't feel this question warrants more than a passing
thought.

The middleground I choose is to add a build option to allow for
disabling this addon. Then anybody can do a simple version bump to allegro
5.2.7.0. It's an easy enough workaround while waiting for slackware-15.0.

So if you don't care, don't change anything.
But if you want allegro 5.2.7.0, then build it that way for slackware-14.2 :
VERSION=2.5.7.0 ALLEGRO_NATIVE_DIALOG=off ./allegro.Slackbuild
And that way for slackware-current :
VERSION=2.5.7.0 ./allegro.Slackbuild

It's all written in the README, and will be available in the next update.

Best regards!

- Arnaud.
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

Re: [Slackbuilds-users] qemu feature freeze for 14.2

[Arnaud via SlackBuilds-users]

> * King Beowulf  wrote:
> 
> > I'm going to freeze to qemu-4.1.1 for 14.2 since the gtk3, glib (and
> > some other stuff) is too old to use newer versions. If PV bumps glib to
> > 2.48, we can update to qemu-4.2.1.
> 
> speaking of ancients, python-setuptools seems to be stuck in time as
> much as that monolith in the utah desert.
> 
> too many pythongs are stuck in the past because a newer
> pythong-setuptools version than stock slack 14.2 offers is required.
> 
> -- 
> Funky Tahoe-LAFS.

Couldn't it be possible for cases like this to offer a replacement
slackbuild ? With a proper disclaimer stating that it is altering the stock
stable slackware.

I'm also stuck with Kallithea, at almost the first version I uploaded,
because mercurial is too old.
Admitedly it gives me time to enhance the Slackbuild to make it easier to use in
the future, but anyway, it's stuck at 0.4.1 even though 0.6.2 is out.

For gtk3 and glib, it's probably too much core to be replaced without
side effects.
But for something like python-setuptools, I have to wonder why not having an SBo
updated version, it won't break any existing slackware package.

This is just a thought, not a request in any way.

-- 
Arnaud 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/

[Slackbuilds-users] Problem building latest OpenSMTPD

[Arnaud via SlackBuilds-users]

Hello,

I am having some problems building the latest OpenSMTPD.
I recreated a new chroot with an fully up-to-date slackware64 without multilib,
and it still doesn't build.
I'm pasting the end of the build at the end of the mail, if someone can help,
maybe there's a missing dependency (but then it might have worked on my regular
box which is pretty bloated with slackbuilds) ?

Thanks !

Arnaud 

--

gcc -DHAVE_CONFIG_H -I. -I../..  -I../../smtpd -I../../openbsd-compat
-I../../openbsd-compat/err_h -I../../openbsd-compat/paths_h -I. -I/usr/include
-DSMTPD_CONFDIR=\"/etc/opensmtpd\" -DPATH_CHROOT=\"/var/empty\" -DPATH_SMTPCTL=
\"/usr/sbin/smtpctl\" -DPATH_MAILLOCAL=\"/usr/libexec/opensmtpd/mail.local\"
-DPATH_LIBEXEC=\"/usr/libexec/opensmtpd\" -DHAVE_CONFIG_H -DIO_TLS -DCA_FILE=
\"/etc/ssl/certs/ca-certificates.crt\" -O2 -fPIC -fstack-protector
-D_DEFAULT_SOURCE  -fPIC -DPIC -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign
-Wno-unused-result -fno-strict-aliasing -fno-builtin-memset -D_BSD_SOURCE
-D_DEFAULT_SOURCE  -D_GNU_SOURCE -DNEED_EVENT_ASR_RUN -c
-o ../../smtpd/smtpd-envelope.o `test -f '../../smtpd/envelope.c' || echo
'./'`../../smtpd/envelope.c ../../smtpd/ca.c: In function
'rsae_pub_enc': ../../smtpd/ca.c:438:10: warning: implicit declaration of
function 'RSA_meth_get_pub_enc' [-Wimplicit-function-declaration] return
(RSA_meth_get_pub_enc(rsa_default)(flen, from, to, rsa, padding));
^ ../../smtpd/ca.c:438:10: error: called object is not a function or function
pointer ../../smtpd/ca.c: In function 'rsae_pub_dec': ../../smtpd/ca.c:446:10:
warning: implicit declaration of function
'RSA_meth_get_pub_dec' [-Wimplicit-function-declaration] return
(RSA_meth_get_pub_dec(rsa_default)(flen, from, to, rsa, padding));
^ ../../smtpd/ca.c:446:10: error: called object is not a function or function
pointer ../../smtpd/ca.c: In function 'rsae_priv_enc': ../../smtpd/ca.c:457:10:
warning: implicit declaration of function
'RSA_meth_get_priv_enc' [-Wimplicit-function-declaration] return
(RSA_meth_get_priv_enc(rsa_default)(flen, from, to, rsa, padding));
^ ../../smtpd/ca.c:457:10: error: called object is not a function or function
pointer ../../smtpd/ca.c: In function 'rsae_priv_dec': ../../smtpd/ca.c:469:10:
warning: implicit declaration of function
'RSA_meth_get_priv_dec' [-Wimplicit-function-declaration] return
(RSA_meth_get_priv_dec(rsa_default)(flen, from, to, rsa, padding));
^ ../../smtpd/ca.c:469:10: error: called object is not a function or function
pointer ../../smtpd/ca.c: In function 'rsae_mod_exp': ../../smtpd/ca.c:476:10:
warning: implicit declaration of function
'RSA_meth_get_mod_exp' [-Wimplicit-function-declaration] return
(RSA_meth_get_mod_exp(rsa_default)(r0, I, rsa, ctx)); ^ ../../smtpd/ca.c:476:10:
error: called object is not a function or function pointer ../../smtpd/ca.c: In
function 'rsae_bn_mod_exp': ../../smtpd/ca.c:484:10: warning: implicit
declaration of function
'RSA_meth_get_bn_mod_exp' [-Wimplicit-function-declaration] return
(RSA_meth_get_bn_mod_exp(rsa_default)(r, a, p, m, ctx, m_ctx));
^ ../../smtpd/ca.c:484:10: error: called object is not a function or function
pointer ../../smtpd/ca.c: In function 'rsae_init': ../../smtpd/ca.c:491:6:
warning: implicit declaration of function
'RSA_meth_get_init' [-Wimplicit-function-declaration] if (RSA_meth_get_init
(rsa_default) == NULL) ^ ../../smtpd/ca.c:491:37: warning: comparison between
pointer and integer if (RSA_meth_get_init(rsa_default) == NULL)
^ ../../smtpd/ca.c:493:10: error: called object is not a function or function
pointer return (RSA_meth_get_init(rsa_default)(rsa)); ^ ../../smtpd/ca.c: In
function 'rsae_finish': ../../smtpd/ca.c:500:6: warning: implicit declaration of
function 'RSA_meth_get_finish' [-Wimplicit-function-declaration] if
(RSA_meth_get_finish(rsa_default) == NULL) ^ ../../smtpd/ca.c:500:39: warning:
comparison between pointer and integer if (RSA_meth_get_finish(rsa_default) ==
NULL) ^ ../../smtpd/ca.c:502:10: error: called object is not a function or
function pointer return (RSA_meth_get_finish(rsa_default)(rsa));
^ ../../smtpd/ca.c: In function 'rsae_keygen': ../../smtpd/ca.c:509:10: warning:
implicit declaration of function
'RSA_meth_get_keygen' [-Wimplicit-function-declaration] return
(RSA_meth_get_keygen(rsa_default)(rsa, bits, e, cb)); ^ ../../smtpd/ca.c:509:10:
error: called object is not a function or function pointer ../../smtpd/ca.c: In
function 'ECDSA_METHOD_new_temporary': ../../smtpd/ca.c:530:33: error:
dereferencing pointer to incomplete type 'ECDSA_METHOD {aka struct
ecdsa_method}' if ((ecdsa = calloc(1, sizeof (*ecdsa))) == NULL)
^ ../../smtpd/ca.c: In function 'ecdsae_do_sign': ../../smtpd/ca.c:623:23:
error: dereferencing pointer to incomplete type 'ECDSA_METHOD {aka const struct
ecdsa_method}' return (ecdsa_default->ecdsa_do_sign(dgst, dgst_len, inv, rp,
eckey)); ^ ../../smtpd/ca.c: In function
'rsa_engine_init': 

Re: [Slackbuilds-users] Marcel Saegebarth's orphaned builds

[Arnaud via SlackBuilds-users]

> https://slackbuilds.org/advsearch.php?stype=maint=mos65
> 
> I took qjactctl already. Anyone interested in any of these?

I'd like to take lgogdownloader, sshuttle, x-tile, and htmlcxx (as a dependency
of lgogdownloader).

Thanks :)

-- 
Arnaud 
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/