Core Solus Plumbing, package management, dev tools, etc
Sun, Jul 26
After discussing this with @silke in #Solus-dev, I'm assigning this to Josh with tentative Priority and Project Tags as he's the one who handles OpenSSL.
Mar 19 2020
@serebit No need to draw this out.
Mar 18 2020
I wrote a large post of a reply but I've deleted it. Instead I'm just going to say this.
Let me be perfectly clear. This is a very low priority issue that you are making sound far worse than it actually is. That rule is working exactly as Josh intended when it was implemented. If something truly needs to be patched with regard to having the word eopkg in it, I can 99% guarantee that it's a patch that should probably be applied to an upstream repository and not one hosted on Phab.
Chiefly package repository priorities need to work correctly in mixed and layered repositories through a well designed system, something that eopkg currently lacks.
Given the amount of engineering effort required to make this nice in solbuild, and the obvious limitations in eopkg it would work around, the ROI is practically nil compared
to integrating directly with the Makefile system (which could do with overhauling)
OK, but its not working as intended at all. Mentioning eopkg in a package patch does and has happened (I literally am the voice of experience here.)
The rule is clearly too crude. As for solbuild having the functionality I don't directly object, but the entire process needs review tbqh.
The rule is working exactly as intended. It doesn't allow upload of any eopkg files, or files containing the word eopkg, as this should never be a requisite for a package-related patch.
Mar 13 2020
Mar 1 2020
eopkg fetch dash; lseopkg dash*; rm dash*
Oct 10 2019
Jun 28 2019
Should be filed at https://github.com/getsolus/solbuild
May 5 2019
Apr 30 2019
Ok, I'll do this
Nevermind. let's get rid of gnutls and replace it with libgnutls-utils then rename the package itself as libgnutls and make like 100 times easier.
Misread. What if we just rename the packages from libgnutls to gnutls and move the executables in gnutls to gnutls-utils?
I never used yconvert.py. The attached package.yml was done manually.
Can we just manually convert? I don't really want to spend time fixing yconvert.py when it will be going away.
Apr 24 2019
Apr 21 2019
Why was a new issue created for this.
Mar 29 2019
Is it safe to delete the older entries? Or is there possibly a better way to clear them? Thanks!
Mar 28 2019
Feb 9 2019
Closing as invalid. Tooling in ypkg 3 will resolve this.
Jan 15 2019
Yea I don't know. It's not a firefox update issue. Something is corrupting the language selection. Posting eopkg history
Jan 13 2019
The issue did not seem to appear this time. I am going to close the issue, and keep a watchful eye.
Jan 11 2019
This is a recent issue Kyrios. I maybe first noticed it within the last 2 or 3 Firefox updates. I am using Solus GNOME. I haven't done anything special with my locales. I did mark my timezone as CST however when I installed the OS. What are the env variables for locale? I will watch for the 64.0.2 update when that happens and see if it changes.
Jan 6 2019
Hello, is this a recent issue or have you always had this issue ?
Which DE do you use and more important, how are your locales defined ?
Jan 5 2019
Nov 1 2018
We are no longer adding new functionality to eopkg, I will however take this under advisement for the next package manager.
There are tons of utilities that can do this
Oct 16 2018
Oct 8 2018
Aug 7 2018
Seems fine now:
$ echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/snap/bin
Aug 2 2018
Resolved, we're now forcing HTTPS (and thus http URL is removed) by setting security.require-https to true
Aug 1 2018
Not valid, that isn't how you set options.