Which ports do you implemented as soon as possible?

[John Marino]

As the Ravenports project is young and required many things to be implemented, the amount of ports available is relatively small and is lacking a great number of ports of popular and well used software.

Listing which ports you'd like to see introduced next will likely help that port jump in priority, so feel free to add your vote on this topic!

[Sean Long]

John,

I really like what I'm seeing while experimentation with ravenports, my hope is to use it at work to install my common set of *nix tools between Linux distros (CentOS7 and Ubuntu 16.04) all while having the familiar FreeBSD pkg interface that I use at home. Below are some of my wants (and the path in the FreeBSD ports tree):

• zim - deskutils/zim
• tmux - sysutils/tmux
• taskwarrior - deskutils/taskwarrior
• sqlitebrowser - databases/sqlitebrowser
• meld - textproc/meld
• patchelf - sysutils/patchelf
• deadbeef - audio/deadbeef
• rubygem-fpm - archivers/rubygem-fpm
  

Thanks for this awesome tool.

[John Marino]

Thanks for the list, Sean.

The only thing that stands out at first glance is the rubygem one.

The python and perl ports are all generated (there's no maintainer, but I've written scripts that create the ports).

Rubygems will be in the same vein.  Once the scripts are written, adding a rubygem port will be trivial.  However, as you might imagine, the initial scripts can be quite involved.  Don't get me wrong, I know I have to support rubygems; i just haven't gotten there yet.

[Михаил Кръстев]

Hi John,

събота, 2 септември 2017 г., 0:01:51 UTC+3, John Marino написа:

As the Ravenports project is young and required many things to be implemented, the amount of ports available is relatively small and is lacking a great number of ports of popular and well used software.

Listing which ports you'd like to see introduced next will likely help that port jump in priority, so feel free to add your vote on this topic!

Currently my fav list is:
 - zsh

 - tmux

 - vim-lite

 - golang

 - nodejs 

Also, I see xorg related packages in http://ravenports.ironwolf.systems/catalog/ . If possible, the X related apps that I mostly use are:

 - openbox

 - tint2

 - gmrun

 - pcmanfm
 - tilda

 - mpv

[John Marino]

Hi Mikhail,

Zsh is already in the catalog.

Full vim is quite involved (which is why lite vim hasn't been ported yet), but at least Neovim is already in the catalog.

I'll have to study "go".  It's unclear if FreeBSD has the best approach with Go and I'm not educated enough yet about it.

Thanks for the list.

[Justin Sherrill]

On Thursday, September 7, 2017 at 11:37:13 AM UTC-4, John Marino wrote:

I'll have to study "go".  It's unclear if FreeBSD has the best approach with Go and I'm not educated enough yet about it.

For what it's worth, Tim Darby <t+d...@timdarby.net> took over building the Go builder snapshots for DragonFly for me. I was somewhat hapless, so he may have insight into the build process if needed.

As for what packages to build: I don't see a log on avalon.dragonflybsd.org of what gets pulled down the most, but I think Francois Tigeot had stats from his ports mirror that showed more popular items.  If any of the FreeBSD ports or NetBSD pkgsrc download sites publish stats, that could also work as a starting point.

[Dan Partelly]

On Saturday, September 2, 2017 at 12:01:51 AM UTC+3, John Marino wrote:

As the Ravenports project is young and required many things to be implemented, the amount of ports available is relatively small and is lacking a great number of ports of popular and well used software.

Listing which ports you'd like to see introduced next will likely help that port jump in priority, so feel free to add your vote on this topic!

Hi John,

I like Ravenports, it brings multi platform consistency , and I am a big fan of consistent things on all my computers.  Work such as yours was long overdue.  As for ports:

1. Valgrind

2. Lisp stack  starting with SBCL and CMUCL

3. Erlang

4. Complete Xorg  drivers ? init stack ? , minimal utility suite

5. vim-lite

6. emacs

Also, something to manage symlinks of tools like GCC / CLANG/LLVM tools to binary directories,  in infrastructure ,since those appear to land in nonstandard places. Sure its easily fixable with path changes, but I prefer links in standard places, rather than modifications in PATH like I have to do in Windows.

As for policy: I know that the ports policy is to be updated for open source, but for C/C++ compilers (CLANG/GCC) which are used to build OSs, maybe you could make an exception and allow older versions to exist in tree for a long time, frozen.

And about the scripts you use to manage Perl Python. Do you plan to make those open source as well, or they already somewhere on github ?

[John Marino]

On Monday, September 11, 2017 at 2:16:19 AM UTC-5, Dan Partelly wrote:

Also, something to manage symlinks of tools like GCC / CLANG/LLVM tools to binary directories,  in infrastructure ,since those appear to land in nonstandard places. Sure its easily fixable with path changes, but I prefer links in standard places, rather than modifications in PATH like I have to do in Windows.

I'm not sure I'm clear on this.  LLVM/CLANG is in a "standard" path, it's just "${LOCALBASE}/" where LOCALBASE=raven

The GCC stuff is special because ravenports has a single ports compiler (the host machine base compiler is not used), and the location isn't too strange: ${LOCALBASE}/toolchain/gccX

However, trying to change this via symlink will not work.  Ravenports does not leverage ldconfig or equivalents on non-BSD platforms.  It embeds DT_RPATH and DT_RUNPATH tags in the ELF binaries to tell the real-time linker where to find libraries.  This especially includes GCC libraries.  So all produced binaries are going to search ${LOCALBASE}/toolchain/gccX anyway.  Plus it's important to remove any potential ambiguity with the system's base compiler.

I'd recommend adding ${LOCALBASE}/bin and ${LOCALBASE}/toolchain/gcc7/bin to the PATH env variable which should solve most issues.  I don't see how to change it in a way you suggest.

 

As for policy: I know that the ports policy is to be updated for open source, but for C/C++ compilers (CLANG/GCC) which are used to build OSs, maybe you could make an exception and allow older versions to exist in tree for a long time, frozen.

Ravenports features a "custom" ports directory so someone interested in a frozen version can just maintain that themselves (usually only requiring a snapshot of the port which is available via git). 

 

And about the scripts you use to manage Perl Python. Do you plan to make those open source as well, or they already somewhere on github ?

Yes, they are in the Scripts subdirectory of the "ravensource" repository.

 

[dan_pa...@rdsor.ro]

>
> I'd recommend adding ${LOCALBASE}/bin and
> ${LOCALBASE}/toolchain/gcc7/bin to the PATH env variable which should
> solve most issues. I don't see how to change it in a way you suggest.
>
>

Which I did, sure. I udnerstand now the GCC situation. About LLVM/CLANG
the binaries where installed to ${LOCALBASE}/LLVM40/BIN . I would have
eexpected the binaries of LLVM4 to go in ${LOCALBASE}/bin which was
already in my path. But if this is the intended behaviour, sure no
problem , changing the path every x months wont be a problem.

Besides, I cought a bug in the sytem already. Im sorry I can't give you
a perfect sequence of operations since it corrupted any pkg databse,
but I beleive raven needs a mutual exclusion mehcanism for ports.
Meaning, prevent a certain set of ports (n..n+1 ) to be installed is x
is already present.

install Clang:

llvm40-clang-standard-4.0.1_1 LLVM 4.0 and Clang (clang)

then you realize it doesnt contain LLVM binaries, because you didnt
payed attention to port name

do not remove llvm40-clang


llvm40-complete-standard-4.0.1_1 LLVM 4.0 and Clang (complete)

All Ok.

remove llvm40-clang-standard-4.0.1_1

Now this allows me to remove clang, but in effect also corrupts the
instalation of llvm40-complete-standard-4.0.1_1 LLVM 4.0 and Clang
(complete) (they sahre files in the same location)
Then llvm40-complete. In my case it resulted to pkg databse corruption,
which didnt really suprised me. No worries, Im *perfectly* happy to
early adopt ravenports and play with it. Its on BTRFS subvolumes on
Linuxso I can get rid of it and reinstall in giffie till I get the hang
of it,

Now, I say that the port system must be foolproof to such problems. Yes,
I could have removed cland girst, then install llvm+clang. But if a user
doesnt do this from lack of attention to detail, or simply because it
expected a different result, the system must be bullet-proof. Coruption
of database should never ensure.

I beleive that an exclusion mechanism would protect against such issues.
I also beleive that the llvm situation will be far from unique. I hope
raveports will be the success it deserves, and there will be many
packages which will present such issues, especially because the system
supports flavors. Potentially every flavor of port needs a lock against
its other variants.

I tested it on Arch Linux on my desktop. I also have FreeBSD machines at
work, and OSx laptop, but I beleive it wont make any difference in what
I describe.

Dan

[dan_pa...@rdsor.ro]

For the life of it, I cant reproduce the corruption once again. Now the
databse is ok, whatever I do. I dont know what went worng first time.
If I get any clue Ill update.
Meanwhile ....

[John Marino]

On Tuesday, September 12, 2017 at 11:54:05 AM UTC-5, Dan Partelly wrote:

For the life of it, I cant reproduce the corruption once again. Now the
databse is ok, whatever I do.  I dont know what went worng first time.
If I get any clue Ill update.
Meanwhile ....

okay, but use a new thread to report any suspected bugs.

 > ${LOCALBASE}/LLVM40/BIN .

right, LLVM is like gcc in that each release gets their own subdirectory (sorry, I forgot).

I'll probably only keep the latest release + the 2 next most recent.  We'll see.  LLVM gets released so often that it's easy to get a ton of old llvm compilers just hanging around.

also just be aware that pkg(8) on linux has the least amount of testing on it.  As far as I know, ravenports is the first fulltime user of pkg(8) on linux so maybe extra use will flush out some linux-only issues.  so far its solid for me though.

[John Marino]

Hi Mihail, 

I've gotten all of these into Ravenports.  You might want to test them more thoroughly than I could.  Note that nodejs is freezing on DragonFly but seems to work on Linux.  I'm going to check these on FreeBSD soon.

Sean,

I've gotten everything on your list except for sqlitebrowser (qt5 requirement) and rubygem-fpm (requires rubygem infrastructure).  The missing two are still in the queue though.

[kraileth]

Hi John,

thanks for your efforts with Ravenports! I tried it out on FreeBSD and (Debian) Linux. I'd like to do a little project with it next for which I had planned to use Pkgsrc but I'm very much in favor of Ravenport's more modern approach. (Eventually I hope to introduce it at work, too, but I need to get familiar with it before I can make a decision if I should attempt to convince management)

Here's a quick list of things that I'm currently missing for my test project:

sysutils/py-salt
devel/py-pygit2
devel/gitolite
sysutils/iocell
security/sudo
www/uwsgi
www/py-flask
dns/bind911

This should suffice to put up a jailhost system and create as well as configure both a web jail and a DNS jail automatically using SaltStack.

I've read the Github wiki (a lot of the rules for the specfiles are really pedantic - love it!) and tried to create a port myself. I managed to compile a buildsheet just to get an idea of how everything is working. It doesn't compile, yet, and I run out of time yesterday. But the whole process looks nice. And while you asked which ports are needed by people, in the long run I'll most likely dig deeper into creating some more ports myself.

[John Marino]

On Saturday, September 23, 2017 at 4:29:24 AM UTC-5, kraileth wrote:

I've read the Github wiki (a lot of the rules for the specfiles are really pedantic - love it!) and tried to create a port myself. I managed to compile a buildsheet just to get an idea of how everything is working. It doesn't compile, yet, and I run out of time yesterday. But the whole process looks nice. And while you asked which ports are needed by people, in the long run I'll most likely dig deeper into creating some more ports myself.

Thanks Kraileth,

I have an "to-do" item to add an example of how to create a port from scratch and add it to the ravenporter's guide.

There's probably a lot of tricks you don't know about (and wouldn't), such as the dev subcommands ("dev template save", "dev distinfo", "dev buildsheet . save", etc).

Actually I'd be really impressed if somebody figures out how to write a working port without such documentation. :)

But yes, it won't take garbage.  It's caught hundreds of typos for me so far, mistakes that maybe wouldn't have been been caught under pkgsrc/freebsd ports, at least not quickly.

[kraileth]

On Saturday, September 23, 2017 at 11:09:08 PM UTC+2, John Marino wrote:

Thanks Kraileth,

I have an "to-do" item to add an example of how to create a port from scratch and add it to the ravenporter's guide.

There's probably a lot of tricks you don't know about (and wouldn't), such as the dev subcommands ("dev template save", "dev distinfo", "dev buildsheet . save", etc).

Actually I'd be really impressed if somebody figures out how to write a working port without such documentation. :)

But yes, it won't take garbage.  It's caught hundreds of typos for me so far, mistakes that maybe wouldn't have been been caught under pkgsrc/freebsd ports, at least not quickly.

Hi John,

good documentation is an essential thing for any serious project and I'm very much looking forward to your porting example. In fact I've used "dev distinfo" and "dev buildsheet save" which placed a valid sheet in a bucket (after I removed the custom license info that I didn't get right on my first attempt and couldn't figure out how to fix quickly). Only the test command failed after building all the dependencies - but that's because I put wrong build instructions in the specfile.

On BSDNow Allan Jude keeps mentioning that writing good documentation is not that easy for two reasons: a) if you don't know a program well enough, you'll probably hesitate to help with documentation b) if you know a program inside-out, you likely have a hard time guessing which problems complete newcomers might actually run into.

For reason b) I'd like to give you some feedback in the hope that it might be useful. Thanks to Synth I had a good idea of what building packages would look like, there wasn't much of a surprise there (except for good ones like being able to choose Perl, Python, etc. versions to build ports against!). What felt strange at first was that the "install" command that I'm used to from Synth is missing. But that's not a big thing; I figured out how to build packages, create the repo info and everything is fine.

Working with the "dev" commands, I found it a bit strange that you need to create a subdir for a port and while "distinfo" had to be run while you're inside that dir, "buildsheet" wants the directory as an argument and not the actual specfile. But that's probably my fault as I was a bit overwhelmed (and short on time) when I finished reading the Github wiki and admittedly only skimmed through the ravenadm manpage afterwards. I definitely need to invest a bit more time!

[John Marino]

Reason C) is that it takes a lot of time to write documentation like you want -- a lot more time than you estimate.  I've sat down thinking I'd be there for 45 minutes and found it took 3+ hours.

When I'm done with the rubygem port generator script, I'll carve out some time to write a decent illustration on how to create a port from scratch.

FYI, on the install commands, this ended up being a real source of confusion (for some people) on Synth so I basically regretted adding these convenience commands.  Combine that with the main use case for ravenports is targetted at one-repo-many-clients (and normally avoiding building altogether), the install commands didn't add much.  So that's the reason for leaving them off.

[Михаил Кръстев]

Hey JMarino, 

Really impressed by the results. All currently working / I am a webdev, so nginx,php-fpm,mysql + their rc scripts/

I've red in docs that its not a good idea to prefix in /, eg when install smth I want it to be in /usr/rpkg /or smth like that/ not in /raven/bin/ ...

Also, an install /which will be prob a link to pkg add .../ will be good.

Regards, M.

--
You received this message because you are subscribed to a topic in the Google Groups "Ravenports" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravenports/iuMmWJF5L1Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ravenports+unsubscribe@googlegroups.com.
To post to this group, send email to raven...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ravenports/b9042418-07de-4629-bca9-caac4fd9e37a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- "meaning of life is the sense of living"

[megoback...@yahoo.com]

I would love to see Veracrypt. All my data is encrypted with this, or actually Truecrypt which is the father to this and which it supports. Thanks for writing Ravenports. It looks like a huge advance. Much applause and cheering.

https://www.veracrypt.fr/en/Downloads.html

https://www.freshports.org/security/veracrypt/

[John Marino]

On Monday, September 25, 2017 at 3:42:49 AM UTC-5, Михаил Кръстев wrote:

Hey JMarino, 

Really impressed by the results. All currently working / I am a webdev, so nginx,php-fpm,mysql + their rc scripts/

I've red in docs that its not a good idea to prefix in /, eg when install smth I want it to be in /usr/rpkg /or smth like that/ not in /raven/bin/ ...

These type of rules are system specific.  I created a new localbase because A) avoid several potential conflicts and B) because /opt has issues.

However, you cannot just rename /raven to /usr/rpkg or something like that.  many things include rpaths are hardcoded to the chosen localbase (/raven).

However, ravenports supports *any* localbase, but this requires creating a new ravensys-root and ravensys-toolchain package to use that new localbase, and then every package has to be built locally.  The prebuit packages are only available in the default localbase of /raven.  So basically, if there is a _hard_ requirement for a specific localbase, it can be accommodated.  All users that just want the default packages have to settle for /raven localbase though.

 

[John Marino]

hi megobackandforth,

According to freebsd site, "fuse" is required.

Do you know if this is a hard requirement?  And that's needed for core functionality (so disabling fuse isn't an option)?

[Sean Long]

On Tuesday, September 19, 2017 at 3:10:37 PM UTC-7, John Marino wrote:

Sean,

I've gotten everything on your list except for sqlitebrowser (qt5 requirement) and rubygem-fpm (requires rubygem infrastructure).  The missing two are still in the queue though.

Thanks John,

Sorry for the delay in responding, I've been checking in on the progress every couple of days and building/installing the latest. Looks like I waited long enough that fpm is now available, awesome!

[megobackandforth]

In short FUSE is a must have.
First I'm not of the caliber of people your used to dealing with, meaning lower, my humble apologies for this. I'm not an idiot but I do claim some ignorance in this instance. (I can learn). I've wanted to move to FreeBSD for a LONG time but the only thing stopping me was a truecrypt comparable interface. FUSE is vital for that. Filesystem in Userspace (FUSE) is useful for a hoard of add on file systems, encrypted, NTFS, truecrypt, veracrypt any file system you can think of and some that haven't been yet. My understanding is it is in 11.0 FreeBSD. (As a module??????). Here's an announcement where FUSE is integrated into the base system in Freebsd 10.0 (Search for "FUSE support in the base system"). Since it's part of the base system I'm not exactly sure...why it would be excluded???? Very likely I don't understand something.

https://wiki.freebsd.org/WhatsNew/FreeBSD10

As an example I found FUSE NTFS. FUSE is way handy. You can add any file system you have or can dream of if you interface it with the FUSE kernel program instead of having to have the driver for the file system in the kernel itself.

http://www.freshports.org/sysutils/fusefs-ntfs/

My apologies if I've inadvertently fomented a conundrum. I didn't mean to. Moving to FreeBSD is a big learning curve and there's no point in me installing if it doesn't have a file system I can use with all my data. I read a lot of the handbook but it doesn't stick if you don't actually use it. I know it's just a matter of time because Veracrypt is so useful. It's compatible for so many systems. Hopefully I've answered your question but...alas I may not have.

I heard about Ravenports from DragonFly BSD blog. The idea impresses me a great. Pulling this off will be a great coup. Veracrypt or not. Thank you very much for all the work you've done.

[megobackandforth]

Right after I wrote this I finally understood. Maybe. NetBSD and OpenBSD, I think, don't have the same FUSE interface. FUSE is a driver in the kernel. FreeBSD has it, macOS has it, Linux has it and Windows, I think has it. There not separate programs. Each of them have, I believe, something similar or are working on the same thing, as FUSE, but they're not a separate program that can be added in so it ruins the "compile for all the same" system you have. I didn't pick this up at first. Frankly I don't see how you're going to pull off such an ambitious program as Ravenports. For just such a reason. Each one of these systems have a lot of different quirks. Don't think I'm not rooting for you, it's just going to be difficult.

[John Marino]

On Wednesday, September 27, 2017 at 11:21:26 AM UTC-5, megobackandforth wrote:

Right after I wrote this I finally understood. Maybe. NetBSD and OpenBSD, I think, don't have the same FUSE interface. FUSE is a driver in the kernel. FreeBSD has it, macOS has it, Linux has it and Windows, I think has it. There not separate programs. Each of them have, I believe, something similar or are working on the same thing, as FUSE, but they're not a separate program that can be added in so it ruins the "compile for all the same" system you have. I didn't pick this up at first. Frankly I don't see how you're going to pull off such an ambitious program as Ravenports. For just such a reason. Each one of these systems have a lot of different quirks. Don't think I'm not rooting for you, it's just going to be difficult.

It's not really difficult.  

The ideal is that a port is "write once, build anywhere".  99.5% of the ports meet that ideal.  However, a port can be marked broken on specific platforms.

So for example veracrypt could be added as a port but marked broken on all platforms except FreeBSD.

Anyway, there are already over 2000 variant ports now, so I think I've already demonstrated that Ravenports fundamentally works. 

[John Marino]

On Wednesday, September 27, 2017 at 11:03:42 AM UTC-5, megobackandforth wrote:

As an example I found FUSE NTFS. FUSE is way handy. You can add any file system you have or can dream of if you interface it with the FUSE kernel program instead of having to have the driver for the file system in the kernel itself.

off topic, but personally I don't trust FUSE very much.

There's no single person responsible for it at the kernel level (it seems to be ignored until some commit breaks it) and there's really no maintainers for the ports at the userspace level.  Of the dozens of fuse filesystems, maybe 2 of them work "reasonably" well but all seem to have quirks one wouldn't accept on a native filesystem.

So the lack of consistent maintainership would bother me on an enterprise level, and lack of confidence in performance would as well.  I realize it's the only game in town on some systems (e.g. NTFS) but if I had a choice I'd take a maintained native FS over it.  

as I said, it's offtopic.  I'd just beware of putting too many eggs in the FUSE basket

 

[megobackandforth]

"...Anyway, there are already over 2000 variant ports now, so I think I've already demonstrated that Ravenports fundamentally works. ..."

Hard to tell sometimes what people are thinking with just text but just so you know I'm not in any way being dismissive at what you've accomplished nor do I doubt your ability.

FUSE I think is going to be really useful. Maybe not if you're just thinking about a normal server but big things are coming. FUSE is already being though of as an interface for all kinds of internet alternatives for HTTP like,

https://en.wikipedia.org/wiki/InterPlanetary_File_System

Lots of these type systems are being written as censorship is going up. People canceling web site addresses (how can they do that, don't they own the url???) Soon if it's not on TV you won't be able to hear about it.

[John Marino]

On Sunday, September 24, 2017 at 1:07:17 AM UTC-5, kraileth wrote:

On Saturday, September 23, 2017 at 11:09:08 PM UTC+2, John Marino wrote:

Thanks Kraileth,

I have an "to-do" item to add an example of how to create a port from scratch and add it to the ravenporter's guide.

There's probably a lot of tricks you don't know about (and wouldn't), such as the dev subcommands ("dev template save", "dev distinfo", "dev buildsheet . save", etc).

Actually I'd be really impressed if somebody figures out how to write a working port without such documentation. :)

But yes, it won't take garbage.  It's caught hundreds of typos for me so far, mistakes that maybe wouldn't have been been caught under pkgsrc/freebsd ports, at least not quickly.

Hi John,

good documentation is an essential thing for any serious project and I'm very much looking forward to your porting example. In fact I've used "dev distinfo" and "dev buildsheet save" which placed a valid sheet in a bucket (after I removed the custom license info that I didn't get right on my first attempt and couldn't figure out how to fix quickly). Only the test command failed after building all the dependencies - but that's because I put wrong build instructions in the specfile.

Hi Kraileth,

I wrote the howto and posted on it in the devel list: https://groups.google.com/forum/#!topic/ravenports-devel/RFs_Lj7USaU

It's section 14 of the Ravenporter's Guide wiki.

I think it should help illustrate the basic process.

[kraileth]

On Thursday, September 28, 2017 at 6:59:39 PM UTC+2, John Marino wrote:

Hi Kraileth,

I wrote the howto and posted on it in the devel list: https://groups.google.com/forum/#!topic/ravenports-devel/RFs_Lj7USaU

It's section 14 of the Ravenporter's Guide wiki.

I think it should help illustrate the basic process.

Thanks a lot, John! I'll definitely read that and give writing a port a try again on the weekend. I'll let you know if I have any comments.

[kraileth]

Hi John,

I've seen that SaltStack and nearly all of my requested ports are already available - great work! Just tried to build them but it looks like libiconv is currently broken (according to the logs applying one patch fails).

Another question: As long as zstd isn't used - do you see a problem with building a package repository with ravenadm and then pointing pkg on a fresh FreeBSD installation to it? If I disable the FreeBSD repo and put /raven/bin and so on into the PATH, this should work, right?

[John Marino]

On Saturday, September 30, 2017 at 6:22:42 AM UTC-5, kraileth wrote:

I've seen that SaltStack and nearly all of my requested ports are already available - great work! Just tried to build them but it looks like libiconv is currently broken (according to the logs applying one patch fails).

libiconv has a freebsd-specific patch.  I developed the port on DragonFly so I couldn't identify an out-of-date patch (maybe ravenadm needs a patch-check command where you can change OPSYS for cases like that).  I'll get it fixed.

 

Another question: As long as zstd isn't used - do you see a problem with building a package repository with ravenadm and then pointing pkg on a fresh FreeBSD installation to it? If I disable the FreeBSD repo and put /raven/bin and so on into the PATH, this should work, right?

It's unclear to me which case you mean.  A) use an existing pkg(8) and add a ravenports repository conf file or B) use the ravenports-built pkg(8) and add a conf file for an official freebsd pkg(8).

Regardless of which case you mean, I think you'll have problems doing it. In my experience, if you try to update one repository, pkg(8) may try to delete or update packages from the other repository.  It gets confused.   So my recommendation is to keep two pkg(8)'s on the system: One for freebsd repository and one for ravenports repository.  Refer to the pkg executable by the full path.  Then for sure you won't have any cross-repository confusion.

 

[John Marino]

Okay, I upgraded the FreeBSD repository, finding a few port errors (freebsd-specific) in the process.

Everything should build now although it's not required (since binary packages are available).

I also added iocell while i was there (it's a freebsd-only port).

[John Marino]

This thread is getting unwieldy.  I'm going to respond to each initial request in a separate thread.

For new responders, consider starting a new thread.  It's easier to follow rather than have several topics open at once.

For ports development, use the https://groups.google.com/forum/#!forum/ravenports-devel mail list instead.