Porteus-AUR: Building Porteus modules w/ Arch build scripts!
-
- Samurai
- Posts: 112
- Joined: 06 Aug 2013, 15:32
- Distribution: Porteus 2.1 Gnome
- Location: Netherlands
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
Thanks,
I will try that.
The python error can be ignored because it python3 and I need python2.
Roelof
I will try that.
The python error can be ignored because it python3 and I need python2.
Roelof
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
Under porteus kde 2.1, building nano was sweet.
In the process of building gnumerics, it was not so easy as it required more recent version of certain packages or libraries<; gtk+3-3.4.4 and libgsf--1.14.28-1, goffice-0.10, gobject-introspection-1.32.1... that could be fetch from porteus, slackware, slacky and pkgs.org. Additional, libraries had to be built from Arch: libgsf-1.14.28.
I am not done yet, but the process of building packages from arch structure is rather pleasant.
Thanks.
In the process of building gnumerics, it was not so easy as it required more recent version of certain packages or libraries<; gtk+3-3.4.4 and libgsf--1.14.28-1, goffice-0.10, gobject-introspection-1.32.1... that could be fetch from porteus, slackware, slacky and pkgs.org. Additional, libraries had to be built from Arch: libgsf-1.14.28.
I am not done yet, but the process of building packages from arch structure is rather pleasant.
Thanks.
Prendre son temps, profiter de celui qui passe.
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
multilib is downloading now.
Prendre son temps, profiter de celui qui passe.
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
We will have to see if AUR packages could be seemlessly incorporated to usm package manager. 8)
Prendre son temps, profiter de celui qui passe.
- ViktorNova
- Contributor
- Posts: 33
- Joined: 19 Jun 2013, 19:38
- Distribution: Porteus 3.0rc1 64-bit
- Location: Portland, Oregon, USA
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
@francois
Glad you dig it! It's neato, huh? 8) In my experience, even having to manually track down all the dependencies and install many of them from Arch, it's been much easier for me to get the latest version of lots of weird software running issue-free on Porteus this way than going for the pure source or Slackbuilds (although every once in awhile the Slackbuild will succeed where this will fail, always because of a certain patch and/or install script)
@phhpro
The reason this only works with -d right now using this particular method, is that the only way Arch's makepkg would knows if a dependency exists is to check if that dependency has been installed by Pacman, Arch's package manager. So basically, it instantly fails and says you're missing dependencies, even if you actually do have all the dependencies satisfied already. Hopefully, this will change in the future =D
@brokenman
Thank you, this totally helps me on this mission. I have a few questions - by database, do specifically mean sql? And would this db also need to include runtime/build dependencies? This may well exist already, I'm just not a hardcore enough Arch user to know off the top of my head, but if this is what you'd need for USM I will totally do some digging. The commandline ABS/AUR search tools I have used and am currently looking at tweaking are returning results in json (package names, versions, and descriptions) and then when a package is selected, the PKGBUILD bash script is downloaded and parsed for dependencies.
I actually have not looked at USM, do you have a way to deal with dependencies of Slackbuilds at the moment, or are you not going for Slackbuild compatibility? Does USM track dependencies with ldd alone, or are there other things it checks too?
@roleof
With something as deep in the core of the OS as systemd, you can expect to have some difficulty any way you approach it, you are ambitious! Arch's way of installing it for Arch is likely to have some non-slackware/porteus compatible things there.. maybe not though. I happened to notice this on Github today and thought I'd pass it on, might be less problematic?
https://github.com/PhantomX/slackbuilds ... er/systemd
Glad you dig it! It's neato, huh? 8) In my experience, even having to manually track down all the dependencies and install many of them from Arch, it's been much easier for me to get the latest version of lots of weird software running issue-free on Porteus this way than going for the pure source or Slackbuilds (although every once in awhile the Slackbuild will succeed where this will fail, always because of a certain patch and/or install script)
@phhpro
The reason this only works with -d right now using this particular method, is that the only way Arch's makepkg would knows if a dependency exists is to check if that dependency has been installed by Pacman, Arch's package manager. So basically, it instantly fails and says you're missing dependencies, even if you actually do have all the dependencies satisfied already. Hopefully, this will change in the future =D
@brokenman
Thank you, this totally helps me on this mission. I have a few questions - by database, do specifically mean sql? And would this db also need to include runtime/build dependencies? This may well exist already, I'm just not a hardcore enough Arch user to know off the top of my head, but if this is what you'd need for USM I will totally do some digging. The commandline ABS/AUR search tools I have used and am currently looking at tweaking are returning results in json (package names, versions, and descriptions) and then when a package is selected, the PKGBUILD bash script is downloaded and parsed for dependencies.
I actually have not looked at USM, do you have a way to deal with dependencies of Slackbuilds at the moment, or are you not going for Slackbuild compatibility? Does USM track dependencies with ldd alone, or are there other things it checks too?
@roleof
With something as deep in the core of the OS as systemd, you can expect to have some difficulty any way you approach it, you are ambitious! Arch's way of installing it for Arch is likely to have some non-slackware/porteus compatible things there.. maybe not though. I happened to notice this on Github today and thought I'd pass it on, might be less problematic?
https://github.com/PhantomX/slackbuilds ... er/systemd
- ViktorNova
- Contributor
- Posts: 33
- Joined: 19 Jun 2013, 19:38
- Distribution: Porteus 3.0rc1 64-bit
- Location: Portland, Oregon, USA
How to fix when some existing libs aren't found
I thought I'd mention this in case it helps someone: sometimes when building packages from Arch, a lib that exists on your system might occasionally not get picked up during the compile process. I've done a few things to help this situation:
-running ldconfig as root.
Don't know why, but every once in awhile this picks up a bunch of new things
-Adding this to your users ~/.bashrc
PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig
-adding /usr/lib to /etc/ld.so.conf
(if it's not already there) and then running ldconfig as root
-running ldconfig as root.
Don't know why, but every once in awhile this picks up a bunch of new things
-Adding this to your users ~/.bashrc
PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig
-adding /usr/lib to /etc/ld.so.conf
(if it's not already there) and then running ldconfig as root
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
by database, do specifically mean sql?
No. Whatever file holds the information about the AUR packages. In slackware repositories this is plain text.
The commandline ABS/AUR search tools I have used and am currently looking at tweaking are returning results in json
Whatever the CLI search tools are parsing for information will be the database file. That handles the package information, great. Then if all is needed is the PKGBUILD to get the dependencies (and they are accurate) then you have what you need to make it work.
do you have a way to deal with dependencies of Slackbuilds at the moment
In slackware it is not really required because a full slackware install contains everything you need to build your packages (same with dependencies). Nothing should fail. Porteus is minimal so many packages are missing (QT in some desktops for example) and if a SlackBuild requires QT in this situation it will fail. I am slowly working towards a system for discovering and automating the slackbuilds process for Porteus but as I said above it is not easy to do this for package building. Think of all the times you compiled something and it failed. The current release of USM does not handle dependency resolution for SBo. I don't a tool exists yet for this.
Does USM track dependencies with ldd alone, or are there other things it checks too?
There are two files that USM requires to handle dep resolution. One contains a list of all files a package contains (MANIFEST) and the other contains a list of all libraries a package requires to run (LIBS.TXT). USM itself doesn't run ldd except in one situation, when a user wants to resolve dependencies for a package they downloaded manually. I have built in a file so that if a dependency is required but missed by USM (for whatever reason) then it can be manually added. This was the case for clucene and audacious.
Hope that helps. Good luck.
No. Whatever file holds the information about the AUR packages. In slackware repositories this is plain text.
The commandline ABS/AUR search tools I have used and am currently looking at tweaking are returning results in json
Whatever the CLI search tools are parsing for information will be the database file. That handles the package information, great. Then if all is needed is the PKGBUILD to get the dependencies (and they are accurate) then you have what you need to make it work.
do you have a way to deal with dependencies of Slackbuilds at the moment
In slackware it is not really required because a full slackware install contains everything you need to build your packages (same with dependencies). Nothing should fail. Porteus is minimal so many packages are missing (QT in some desktops for example) and if a SlackBuild requires QT in this situation it will fail. I am slowly working towards a system for discovering and automating the slackbuilds process for Porteus but as I said above it is not easy to do this for package building. Think of all the times you compiled something and it failed. The current release of USM does not handle dependency resolution for SBo. I don't a tool exists yet for this.
Does USM track dependencies with ldd alone, or are there other things it checks too?
There are two files that USM requires to handle dep resolution. One contains a list of all files a package contains (MANIFEST) and the other contains a list of all libraries a package requires to run (LIBS.TXT). USM itself doesn't run ldd except in one situation, when a user wants to resolve dependencies for a package they downloaded manually. I have built in a file so that if a dependency is required but missed by USM (for whatever reason) then it can be manually added. This was the case for clucene and audacious.
Hope that helps. Good luck.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
@ViktorNova:
Do you mean that you would fool pacman or abs and feed them with a list of all the packages and libraries of porteus stock?@phhpro
The reason this only works with -d right now using this particular method, is that the only way Arch's makepkg would knows if a dependency exists is to check if that dependency has been installed by Pacman, Arch's package manager. So basically, it instantly fails and says you're missing dependencies, even if you actually do have all the dependencies satisfied already. Hopefully, this will change in the future =D
Prendre son temps, profiter de celui qui passe.
-
- Contributor
- Posts: 678
- Joined: 26 Jun 2013, 14:03
- Distribution: x64 Openbox
- Location: Russia is causing the immense damage to humanity
- Contact:
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
Some trick is to create a list with all directories in /var/abs, convert to proper text file and after invoke extract pkgver= from /var/abs/.../PKGBUILDAre there any database files that would allow a program to search for and report available packages from within the program? It would be nice to do all searching and downloading without having to switch to a browser.
You have mind and feelings. Be wise and clever.
- ViktorNova
- Contributor
- Posts: 33
- Joined: 19 Jun 2013, 19:38
- Distribution: Porteus 3.0rc1 64-bit
- Location: Portland, Oregon, USA
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
@tome
Good idea! I'll do that. I've found a thing (not on github yet) that downloads the entire list of all Arch & AUR package name, versions, and descriptions, and outputs to stdout, so that will be easy
@phhpro
Thats the idea! More realistically, it will probably be a hack that uses Porteus/Slack tools to check if listed dependencies are installed, optionally install them, and then continue
@brokenman
Thanks for all this info, I got some work to do! I will report back when I've made some headway
@roelof
Just this week I compiled a ton of Python stuff and learned a few things-Arch used Python 3 by default, and on Arch "python" means Python 3, and "python2" is the Python we're more used to. In order to get stuff to work on Porteus, I first had to do a few things:
First, I installed python3 from SBo (as I compiled some audio tools that use Python 3)
http://slackbuilds.org/repository/14.1/python/python3/
For most Python packages, the PKGBUILD has 2 (or 3) sections - one for python2, one for python3, and sometimes one for common shared stuff between the two
After that, most python-related PKGBUILDs needed the following changes:
1: Replace all references to /usr/lib/ with /usr/lib64/
2: Replace all commands that start with "python" with "python3"
After that, python stuff should work better!
Good idea! I'll do that. I've found a thing (not on github yet) that downloads the entire list of all Arch & AUR package name, versions, and descriptions, and outputs to stdout, so that will be easy
@phhpro
Thats the idea! More realistically, it will probably be a hack that uses Porteus/Slack tools to check if listed dependencies are installed, optionally install them, and then continue
@brokenman
Thanks for all this info, I got some work to do! I will report back when I've made some headway
@roelof
Just this week I compiled a ton of Python stuff and learned a few things-Arch used Python 3 by default, and on Arch "python" means Python 3, and "python2" is the Python we're more used to. In order to get stuff to work on Porteus, I first had to do a few things:
First, I installed python3 from SBo (as I compiled some audio tools that use Python 3)
http://slackbuilds.org/repository/14.1/python/python3/
For most Python packages, the PKGBUILD has 2 (or 3) sections - one for python2, one for python3, and sometimes one for common shared stuff between the two
After that, most python-related PKGBUILDs needed the following changes:
1: Replace all references to /usr/lib/ with /usr/lib64/
2: Replace all commands that start with "python" with "python3"
After that, python stuff should work better!
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
Just to have some water flow in the threadmill. Hoping that the following comments will not be too much out of track.
I have done some research on the following theme to found interesting tools (for you to judge):
I don't (think) a tool exists yet for dependency resolution.
spbuilder for slackware: generates a new, completely separate, minimal Slackware environment in which the package's build script is executed.
http://www.vislab.uq.edu.au/howto/spbui ... ilder.html
scripts to collect and visualize dependency graphs from SlackBuilds.org
http://slackalaxy.wordpress.com/tag/sbo/
sbopkg and sbotoos coexistance:
https://slackalaxy.wordpress.com/2012/1 ... s-coexist/
http://dawnrazor.net/sbotools/
@brokenman:do you have a way to deal with dependencies of Slackbuilds at the moment
In slackware it is not really required because a full slackware install contains everything you need to build your packages (same with dependencies). Nothing should fail. Porteus is minimal so many packages are missing (QT in some desktops for example) and if a SlackBuild requires QT in this situation it will fail. I am slowly working towards a system for discovering and automating the slackbuilds process for Porteus but as I said above it is not easy to do this for package building. Think of all the times you compiled something and it failed. The current release of USM does not handle dependency resolution for SBo. I don't a tool exists yet for this.
I have done some research on the following theme to found interesting tools (for you to judge):
I don't (think) a tool exists yet for dependency resolution.
spbuilder for slackware: generates a new, completely separate, minimal Slackware environment in which the package's build script is executed.
http://www.vislab.uq.edu.au/howto/spbui ... ilder.html
scripts to collect and visualize dependency graphs from SlackBuilds.org
http://slackalaxy.wordpress.com/tag/sbo/
sbopkg and sbotoos coexistance:
https://slackalaxy.wordpress.com/2012/1 ... s-coexist/
sbotools, a recent project:sbopkg ... ... combined with a collection of queue files (sbotools), the dependency resolution becomes semi-automatic.
http://dawnrazor.net/sbotools/
Prendre son temps, profiter de celui qui passe.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
The trouble with all the sbo deps info is that they assume a complete installation as the base. So even the info they provide is partial and helps not one bit when trying to cut down to less than a complete installation. AUR PKGBUILD scripts also are not ideal as they contain arbitrary depends info which must be manually generated.
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
Hello, amigo. You have all my respect. However, according to spbuilder, they would have find some way to cirumvent the problem. Have you been working with spbuilder? If its the case forgive my intervention.
spbuilder for slackware: generates a new, completely separate, minimal Slackware environment in which the package's build script is executed.
http://www.vislab.uq.edu.au/howto/spbui ... ilder.html
Prendre son temps, profiter de celui qui passe.
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
A quote from their page:
The basic problem is that people don't follow a standard. If every SBo had a correctly written .info file then this would work but the fact is that they don't. Because of this any reliable dependency resolution is almost impossible. I would love (probably more than most people) for SBo to be fail proof and build everything but I don't think this is realistic at the moment.
The quite minor changes they speak of requires editing every .info file in the repository that is not written correctly. In short, they are saying that it is an automated build system, but it won't resolve build time dependencies.Issues
The very basic ability to work with standard Slackware® or SBo build scripts is of limited value at the moment since they have no (or not enough) fields to fully describe prerequisite packages for building. However quite minor changes to SBo packages can allow them to fully utilize spbuilder's capabilities.
The basic problem is that people don't follow a standard. If every SBo had a correctly written .info file then this would work but the fact is that they don't. Because of this any reliable dependency resolution is almost impossible. I would love (probably more than most people) for SBo to be fail proof and build everything but I don't think this is realistic at the moment.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- francois
- Contributor
- Posts: 6445
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: Porteus-AUR: Building Porteus modules w/ Arch build scri
Is it possible to adapt porteus-aur to porteus 3.0? usm is really more efficient than ppm was.
Prendre son temps, profiter de celui qui passe.