yep, feel free to close it

Good observation. It seems that --disable-schemas-install is no longer needed.

@joebonrichie I kept

replaces   :
    - nautilus : nautilus-actions

in order to assure safe upgrade path, because for users who are already using nautilus-actions it won't be enough to install just filemanager-actions, but they need filemanager-actions-nautilus package (which depends on filemanager-actions).

Replaced by D2661

Use git for source, which fixes radeontop --version reporting version.

remove devel pattern, change sed command

clean pattern, change sed command

:D

I believe it's already included automatically. Since xz-devel provides pkgconfig(liblzma) and it is part of system.devel and I see liblzma.so.5 at abi_used_libs (also xz is marked as dependency of the package).

• added bzip2-devel builddep for bzip2 support (xz-devel is already in system.devel component)
• used --with-gconf configure option in order to actually use gconf similar to arch,fedora,opensuse packages (it wasn't enabled automatically)
• @hashhsah I don't see the packages of other distributions have the _LARGEFILE64_SOURCE macro, but maybe we can add it in the future if you find any problems.

• update to 1.28.1
• changed license to GPL-2.0-or-later
• update config using make oldconfig
• comment out CONFIG_DPKG, CONFIG_DPKG_DEB, CONFIG_RPM, CONFIG_RPM2CPIO options

Commited by mistake, this better wait until next vala-panel-appmenu since I see some changes which I'm not sure how they affect the current release.

change component from programming to office.scientific

Move /usr/include headers and /usr/lib64/*.a files into iverilog package since it's built that way in both Fedora and Ubuntu (https://packages.ubuntu.com/artful/amd64/iverilog/filelist).
Also in fedora (https://src.fedoraproject.org/rpms/iverilog/blob/master/f/iverilog.spec) which normally has a strick rule for separate devel patterns, has a comment which states that headers are meant to be used by the user.

@sunnyflunk aaa the other diff didn't mention the task, so I didn't see it. If you want close this and accept the other one, it's fine by me.

use %make_install -j1

Additional notes:

• I've set version at 10.2 instead of the upstream 10_2 because it seemed better, so tell me if I need to change it
• For some weird reason, %make_install gives error while make install DESTDIR=%installroot% works properly.

@kyrios123 if you can take a look at this. Before many packages needed some configure options, setting variables or even sed commands in order to successfully find private headers. Now, they seem to work out of the box. This is how the package is built in arch too (using make install-private-headers), in contrast with Ubuntu and Fedora (manually installing private headers).

I used make install-private-headers instead of manually installing private headers and now both otcl and expect can be built out of the box (without any configure options) while either the one or the either were failing before no matter what I did.

done

@DataDrake sorry for mentioning you again but if you can take a look at it (I believe that something similar should be done for tk package too).
I'm also thinking that maybe /usr/lib64/tclConfig.sh and /usr/lib64/tclooConfig.sh should be owned by devel pattern but I'm not sure about it.

@DataDrake Yeah when they go into path /usr/include/tcl8.6/tcl-private the headers are recognized. However, there is also another problem. Header tclInt.h includes tclPort.h which has the line: include "tclUnixPort.h". However, this file is at folder ../unix (relative path from generic folder). So, we should either add a patch similar to this https://src.fedoraproject.org/rpms/tcl/blob/master/f/tcl-8.6.7-hidden.patch or add the unix header files into the generic folder as well (I don't know if are needed to be at a separate unix folder for any other software)

@kyrios123 @DataDrake Why do private headers go under %libdir/tcl8.6 and not /usr/include/tcl8.6 ? In Fedora (https://src.fedoraproject.org/rpms/tcl/blob/master/f/tcl.spec) they are added under /usr/incude/tcl8.6/tcl-private/ and /usr/include/tcl8.6 headers get linked under /usr/include/tcl8.6/tcl-private/generic/ folder too. I am trying to build otcl (which I need to build ns2, which I really need!) and I cannot make it to find tclInt.h header (which is in private/generic folder). I don't know if that's the problem, but I had successfully built it in Fedora in the past.

It seems fixed now, I don't know what changed.

I'd like to add some extra panel layouts for mate tweak (I will do a patch submition when I'm done with testing). Some of them are base on ubuntu-mate-settings layouts (e.g. Mutiny) and mate tweak checks /usr/lib path for finding vala appmenu mate applet. This fixes that. The official ubuntu package vala-panel-appmenu package is built with the same cmake option.

reset release number to 1 since this package has a new name

Replaced by D2227 as a changed name should be achieved with a newly created repository.

filemanager-actions-nautilus replaces nautilus-actions in order to keep a smooth update path for users who are using it currently. Repository nautilus-actions should be removed if this is accepted.

already done by ikey.

added python-secretstorage rundep as it is listed as requirement in the official site (https://pypi.python.org/pypi/keyring)

@JoshStrobl I could be wrong but I believed I double checked it. According to this https://pycairo.readthedocs.io/en/latest/changelog.html latest version is stable version (since 11.0). Also according to this: https://pycairo.readthedocs.io/en/latest/ it says it requires cairo >= 1.13.1 without demanding any specific cairo version. I did a simple tutorial and seems to work fine with the latest versions. Can you verify and confirm it once again please (it's not important but mostly because I want to know if I missed something that important).

Just leaving this comment here. What I understand from the official site (https://pypi.python.org/pypi/jupyter_client), is that the option extra=='test' means if you want to run the tests on the module (my knowledge in python is minimal so I could be completely wrong). So, if I'm right, then python-pytest, python-mock, python-ipython and python-ipykernel could be added as builddeps in order to add tests to the package, but not as rundeps.

fix mistake

The old config file didn't work. So I did make defconfig, then I manually changed the lines:

CONFIG_FEATURE_HAVE_RPC=y
CONFIG_STATIC=y
CONFIG_FEATURE_FAST_TOP=y

which I thought they were important and copied the file to config.

I am trying to learn good packaging practices in order to be able to achieve high quality packages, so I would love some guidance. I have these questions:

It needs python-pytest version 3.4 otherwise the tests fail

revert to version 9.3.1 and leave update to 11.0.0 for some other time so that we don't mix python rebuilds and version updates.

added test

fix summary

Josh it's not a budgie issue. The desktop launcher link has wrong path. If you see the file here: https://github.com/solus-project/3rd-party/blob/master/office/mendeleydesktop/actions.py I think that the line

pisitools.dosym("../../opt/mendeley/share/applications/mendeleydesktop.desktop", "/usr/share/applications/mendeleydesktop.desktop")

should be changed to

pisitools.dosym("../../../opt/mendeley/share/applications/mendeleydesktop.desktop", "/usr/share/applications/mendeleydesktop.desktop")

(with an extra "../") but I'm not familiar with how pisitools work, so I don't do any Pull Request because I cannot test it, better try it yourself to see if that's the problem.

That isn't our responsibility. Consult winehq.org

Well fixing steam isn't Solus responsibility either, but LSI is one of the most brilliant piece of software in modern linux distributions. I consider wine more important than steam since it also has software that people use for work and not just games.