[SOLVED] Since I realise that I'm in the minority on this issue, let me point out that the (at the time) vice president of the FSF has written about this same problem, and I also knew a former Nokia developer who felt similarly-- about the Python part, not OpenBSD. OpenBSD is my favourite operating system. It's new to me, I've spent time with NetBSD and FreeBSD, and 6.8 may mean I'm increasing the time I spend with NetBSD. The main thing I need an operating system for is running PyPy. Python2 will do in a pinch, but I realise the Python Foundation (while getting paid by Microsoft) has abandoned Python2. No problem, right? PyPy2 fulfils my needs. Only in FreeBSD and in OpenBSD, and probably in NetBSD if this keeps up, PyPy is deprecated because Python 2 is-- and Python 2 is used to build PyPy. Essentially, PyPy2 is a well-maintained Python2. All the projects that need Python2 may find it easier to port to PyPy than Python3. I've already got a Python3 port of my favourite software, but it is certainly inferior-- I tested it for about half a year (I'm also the author.) I am not interested in the Python Foundation's hegemony. Python 2 is needed to build PyPy, but FreeBSD and NetBSD have Linux compatibility layers, and there is a pre-built (portable) PyPy2 for GNU/Linux. Today, I installed BSD over my last GNU/Linux installation. Good riddance. But I wish I'd installed 6.7 instead of 6.8, because 6.8 is the first version of OpenBSD that lacks Python2. That wouldn't bother me if it had PyPy2 instead. Again, PyPy2 is actively maintained. So not building it because it needs Python 2 to build is silly, but that's how things are working in BSD. It's a big catch 22. I've talked to FreeBSD maintainers about this-- that was the first BSD I isntalled. I've talked to the person who did the port for Python2 or PyPy in OpenBSD, and I've talked to the PyPY maintainers. This seems unresolved. I really won't enjoy computing until I can use PyPy again. I may eventually ditch my own favourite language and create a new one, based on something else-- but right now, this is very depressing. I've been waiting for years to ditch Linux now. It's a pretty hollow victory with this taking place. But it was my choice to use OpenBSD 6.8 as the reason to stop using my last GNU/Linux install. If I'd just installed 6.7, I would be a lot happier right now. I was excited about 6.8, but I knew this was a possibility. NetBSD is a possible fix, until they do this too. I almost wish there was binary compatibility and I could just copy Python from NetBSD to OpenBSD-- but there are pretty good reasons that binaries are not compatible. I might try copying Python from 6.7 to 6.8, but I know there are reasons that might not work (and it's certainly no good for production if it works, but that's a minor concern.) I won't miss GNU/Linux. I DO miss Python. And I have no interest in Python 3. I'd rather use a different language-- but I watch those closely, and I don't love most of them. For example, I started working on a somewhat different version of my Python software in JavaScript. It's a bit apples and oranges, but it shows the amount of trouble I'm willing to go to sometimes. Anyway, first impressions of OpenBSD 6.8: It's my favourite operating system in the world. I hate it. I'm not saying this won't improve. I bet it takes years to get fixed though. The Python Foundation is incredibly arrogant; it's one thing to ditch software people want and need. That's how it goes, it's not their job to do work that doesn't suit them. The way they've campaigned against anybody working on compatibility is the incredibly selfish part. Projects like Trinity (KDE 3.5 fork) and MATE (GNOME 2 fork) and all projects that work hard to maintain things that were abandoned by devs but not fans-- they deserve more respect. PyPy deserves better, so do its users. I hope the PyPy devs will make a portable PyPy for OpenBSD-- they did one for FreeBSD, but not in a while. I've known about Python 3 for years-- there are computer science majors who aren't convinced it's better, I'm thoroughly convinced it's not. Python 3 is pushed on people who don't want it. "You'll like it if you just" "It's really not that hard to" NO. It's not even true. It's only true for some, and by waving away the many people it's most certainly not true for, it becomes a circular argument. Long live PyPy. And hooray for the Linux compatibility layer (we really shouldn't need it, but sometimes it's nice.) It's not in OpenBSD anymore, NetBSD still has it.

I think it was a big mistake of the Python foundation to maintain both versions for 10+ years. Complete nonsense. A very special tree has inspired a poem to me today, which seems appropriate. I'll try and translate it to English: "Oh! What a magnificent tree! Its scarlet foliage shines like a bonfire in the grayness of the day! What a startling beauty! I have to come back to take a picture." Yes, I have to come back. But tomorrow, leaves will wear a different color. Tomorrow, light will be different. Tomorrow, grayness me be darker. Fall is uncatchable. As uncatchable as life.

flfederation If OpenBSD 6.7 is the last version to support Python 2, how much work is it to keep a partition or machine with that around and build a PyPy3 on it for OpenBSD 6.8? Can this be done easily? At least, until the PyPy folks fix their code to drop the dependency on Python2.

20-100 I think it was a big mistake of the Python foundation to maintain both versions for 10+ years. Complete nonsense. I agree with that part. But you've taken a very one-sided fallacy and dressed it up with a poem. The mistake (or long series of mistakes) was breaking Python and then deciding everybody should live with it. All they had to do to get rid of Python 2 was this: from __past__ import strings or: import legacy_strings But they were full of hubris . Daddy PF knows best, entire computer industry , get with the program! This was political. It was a power move. The only reason they were forced to support Python 2 for so long was their power move failed, it cost more than it saved, and they had to keep legacy Python around for years and years to save face and keep from losing people. The evidence is everywhere. The arrogant mistake caused the stupid mistake as a workaround. Think about how much it cost them to break compatibility for so many years, then sit around for a decade tapping their foot, telling users to conform. Complete foolishness. I want nothing to do with them, though I'll settle for what PyPy offers. If I can get that. In my opinion they're (Python Foundation) corrupt (or at least dubious) as a 501c3 as well, but that's a different topic.

rvp rvp If OpenBSD 6.7 is the last version to support Python 2, how much work is it to keep a partition or machine with that around and build a PyPy3 on it for OpenBSD 6.8? That would remove one of the giant benefits of PyPy, which is that is compatible with both 2 and 3. Again, not every person cares about the Python Foundation's wishes for people to stop writing Python 2 code. Suppose Google and Microsoft get together and fund the people who maintain C and C++ until they merge into a single project, and they decide it's time for everybody to stop writing C code and "get with the program" and write C++ from now on? It's a ridiculous example, but if someone else went to the trouble of maintaining a C compiler, you wouldn't encourage them to stop and break compatibility just to be like everybody else. That's what you're asking/expecting (at least proposing) PyPy should do. You may not have any serious expectations in that regard, but that's the expectation everybody is encouraged to have. I mean if I'm supposed to care about what's good for the mainstream or Big Tech, why don't I just use Windows? (Indeed, there are reasons). And I feel like that's what's going on-- they're conflating cooperation with pretending their needs and other needs are the same. That's not just useless, it's insulting. It's incredibly manipulative. That's exactly why I don't like (or care about) PF. PyPy is happy to support PyPy2 . It's a separate offering, it's not developed OR hosted by the Python Foundation. It's all PyPy. But you do need Python2 to build it. Yeah, that's a tricky bit. But after you build it, you have a project that is NOT deprecated nor unmaintained. Let's be clear about this: IF you use GNU/Linux, they build it for you . If you use BSD though... that's where PyPy is having trouble. I honestly don't know why, I presume it's because there aren't enough people using BSD who also use Python. I mean it's not even included by default. (Unlike most mainstream GNU/Linux distros). Can this be done easily? No, it would 1. break PyPy's functionality, and 2. require the entire project to be reworked. At least, until the PyPy folks fix their code to drop the dependency on Python2. That's not a goal of PyPy, only a goal of Python Foundation. There is another option: If I could build Python 2 AND PyPy for OpenBSD myself, that would fix this. I doubt I can afford to host both of them, and if PF finally removes the downloads for Python 2, I presume that PyPy will host them as they're needed. Or perhaps at some point they will work the PyPy tree into being able to build PyPy without building a "separate" project first. That would be lovely. I hope at some point they will address this. I may even move towards NetBSD if it continues to support Python 2 and OpenBSD doesn't. Python is the primary software I use on a computer. Even my text editor uses it. As long as the much larger number of PyPy users are on GNU/Linux, they may not have the resources to support more than one BSD (And sadly, FreeBSD seems to have the most users.) But even if they fully supported FreeBSD (They don't) That would likely have a tree that could be used by someone (even me) to build it for OpenBSD or NetBSD. That would be lovely as well. I started using GNU/Linux 20 years ago. I'm done with it, I have no more use for it. I'm not going back to it for this. But OpenBSD without Python 2 isn't an OS that will ever make me happy. It may fix most of the other problems (that's why I moved to it) and until a few days ago, it solved this as well. I just wrote an article about leaving GNU/Linux this week. Not to brag (I honestly don't know how much this is in relative terms) but based on the other stuff I've done, it will probably get tens of thousands of views. It's probably too colourful to link to from here. I wrote it before the migration was complete. This matter is a concern for the day after migration. I'm only running BSD on my machines. As long as a group of people (like the PyPy authors) are willing to maintain a program that users find valuable, the idea that they should not do that just for the good of the Python Foundation's (commercially-tainted) ambitions makes no sense. I'm not against commercialisation-- it's okay. I am against the corruption of non-profit orgs into cheap, often unpaid labour for powerful multinationals. ( This isn't about copyleft vs. permissive , I would be alright with copyright being abolished and de Raadt makes an interesting argument for permissive based on contracts being more complicated.) It's about work being done without pay, which is alright (by me) if it benefits all humanity-- including corporations-- so long as it isn't manipulated into benefiting for-profits much to the exclusion of all others. (OpenBSD doesn't generally have this problem. I'm arguing Python does and has for quite some time.) Just like the DOJ barely goes after monopolies, we hold 501c3 orgs that take money from for-profit corporations to very low standards. I think they sometimes represent those corporations more than their own mission-- and they're really not supposed to. The mission statement isn't really optional. But we are talking about things that vary from country to country as well. But like I said, that's its own topic. And I'll keep sidestepping that one, not because I don't talk about it all the time elsewhere-- but because I'm pretty sure it would be an uncomfortable topic here. I'll try to avoid mentioning it here in the future. The circular argument being used against the public (and I do think it's dishonest and misleading-- though it's sort of innocent when it comes from people who don't do it on purpose, but because it "seems legit") is this: This is deprecated, it's not our job to maintain it, please stop using this. It's NOT the Python Foundation's job to maintain it. (Nor do I put the onus on the BSD developers, though I do think it's a shame.) The circle in the argument is that people should stop using it because it's unsupported and everybody has moved on to Python 3. No matter how large (or well-maintained) the project is that depends on Python 2, they're going to keep telling people that the thing to do is move to Python 3 because nobody uses it and its not maintained, even when it is. The Python Foundation gave $10,000 to PyPy devs, but now they want people to just abandon one of its (PyPy's) best features, just because it would be a help to someone at PyPy's expense. It's up to Python Foundation what Python Foundation does. Okay. But then it's not up to PyPy what PyPy does-- they should do what PF says. It's not up to me what I do, I should do what PF says and do things their way. It's just not honest. What it really is, is lying to the public for the convenience of one party over another. But it's not for my convenience. That part is simply a lie. Not only is it dishonest, but it ultimately rests on something that applies only to PF, but doesn't apply to anybody else. Special pleading, begging the question, appeal to novelty or argumentum ad populum? No matter how you approach it, it's dubious-- but totally popular! If it were just dishonest and insulting, that's one thing-- what's a little corporate propaganda between friends? In this instance however, it's dishonest tactics that break the software of others. I started using GNU/Linux (and then BSD) to get away from that sort of stuff. But I don't hold the BSD developers/maintainers responsible for this. It's not really their fault, and I haven't said it is.

flfederation Can't you just bootstrap pkgsrc on OpenBSD and build python2? EDIT: just an example, http://www.h-i-r.net/2018/09/running-pkgsrc-on-openbsd.html?m=1

pin It's WAY outside of my comfort level and my experience. But that's not a no, it's a maybe. If I can build PyPy2, I'm happy. Right now I'm already settling with Python 2 in 6.7, so it's not a step back from there if I'm just building Python 2. Maybe it's that simple. However, I expect it will be a while. It's not like they're going to remove the 6.7 downloads immediately. I made a point of trying 5.9 (it was the last OpenBSD with the compatibility layer) just to try to the Linux compatibility layer. It wasn't great (the one in FreeBSD is better, I haven't used the NetBSD one yet-- but they're all clearly very similar and likely of the same origin) but that wasn't a real solution, I think the only 5.9 mirror I could find wasn't even https. The OpenBSD website still hosts some things that are older than 6.7, so I'm not saying I'm in a hurry to get PyPy compiled. It's an option I'm willing to evaluate. Meanwhile, I am looking at all the options. I do prefer OpenBSD to NetBSD, but NetBSD supports more archs and packages-- that's a plus. I strongly prefer both to FreeBSD. (It's nice software, but that's not the only criteria I go by.) So I'm leaning OpenBSD/NetBSD in general. I don't have to upgrade everything to 6.8 right now. I may even get Python copied from 6.7 to 6.8, meaning I can at least upgrade everything to 6.8 immediately, but still have Python. But being able to build it would probably be the most sustainable option. That and maybe the PyPy devs will figure out their next move.

At least in the NetBSD case (pkgsrc), we intend to keep Python 2.7 in the foreseeable future, but the support in libraries and applications will be successively reduced (as we are down to follow upstream), possibly to the point that almost nothing left supports Python 2.7. Same like it happened with Qt3 and some other legacy software. At some point nobody left relied on it and it was dropped.

kamil At least in the NetBSD case (pkgsrc), we intend to keep Python 2.7 in the foreseeable future, but the support in libraries and applications will be successively reduced (as we are down to follow upstream), possibly to the point that almost nothing left supports Python 2.7. That's really good! Huge props to NetBSD for this. For more than a year (well before the original 2020 deadline, which used to be the 2015 deadline) I've promoted PyPy as a supported alternative to Python2. This was in the GNU/Linux world and I wasn't using BSD (though for the record, I was also promoting BSD as an alternative to a lot problems going on there. I was talking to rms about whether a "fully-free" (per his standards) BSD existed, and neither of us knew of one (per his standards). This prompted me to look up LibertyBSD (OpenBSD-based). Fast forward a year or two, and FSF-approved Hyperbola is creating the first FSF-approved BSD-- based on LibertyBSD. What they don't tell you is that OpenBSD is already that free, except for firmware. And I'm familiar with what de Raadt says about those. De Raadt makes the more reasonable argument about firmware. I can argue for the other side as well-- but it's beside the point. BSD is becoming a solution that fixes some long-term issues that the Linux kernel is actually creating and adding to. It's almost funny, because people demonstrably cannot fork the Linux kernel. I've asked around. I've pestered the linux-libre author for years. Linux doesn't seem like it will be forked. And yet, in BSD land you have entire operating systems (kernel and applications) forked in one swoop. Sometimes by relatively small teams. I will try to get PyPy enough support that it makes its way back to OpenBSD. I have talked to ports maintainers about this, though ideally PyPy will eventually help also. (They probably figure they have their bases covered). I know it may come down to the number of people interested in PyPy on BSD. But, I expect an increase in both of those groups, especially in BSD. I've been predicting that for years, and it's happening (I also predicted that Microsoft would try to buy Red Hat after GitHub. It was on the table, but they were worried about antitrust.) Again, PyPy used to be available, but its build requirements are deprecated. I can appreciate the possibility of it simply getting abandoned. But there's really no reason it couldn't be brought back, instead. It will come down to whether people understand what it is, why it's not what PF is sort of implying (intentionally or otherwise) and whether somebody can make it available. As it happens, the only libraries I'm using with PyPy are the standard ones, and Tkinter. Tkinter is also what's used to create the standard Python IDE, IDLE. I have actually received some very useful tips in this thread, almost enough to get started on fixing this right now (fixing it eventually is the goal). I'm very grateful. My favourite BSD is still OpenBSD. With that said, installing 6.8 (maybe not 6.9, maybe not 7.0) has earned points for NetBSD. I can tell this is predominantly a NetBSD community here. It's nice of you all to be open to the others. NetBSD got huge points with me today. I'm not going to stop supporting OpenBSD, but due to this issue which is very important to me, I (really) might donate to NetBSD this year instead of OpenBSD as was more likely. I haven't donated money to free software in at least a year, but it wasn't that long ago. NetBSD was already becoming my second favourite, and second favourite isn't bad. But because it's not presently planning to drop Python 2, and the other BSDs are-- that's worth actual money to me. So is OpenBSD, but this is a priority and NetBSD is tending to it. I've checked the particulars of the Foundation and the donation options, and while I can assure you it won't be today (money IS tight, lots of things going on right now) I wouldn't be talking about this unless it was far more likely to happen than not. I won't mention it until long after the fact, but NetBSD probably made money on this. I can't do a Gold Sponsorship, but I can definitely do better than buying NetBSD a coffee. But more than that, I really want to encourage projects to consider that different users have different needs. If I expected BSD to be everything to everyone, I would probably not have chosen OpenBSD in the first place. That's not what OpenBSD is about. But this isn't about adding features-- it's about keeping options. Within reason, of course. As a hint, I'll tell you the two biggest things that tend to make me favour OpenBSD: Pledge, and the simple installer. I'm sure NetBSD is not going to go all out on Pledge (Firefox with Pledge can't even load things from directories other than ~/Downloads, it seems. Though that's a feature-- definitely not for everybody) and it may need all those installer options. But without Python (I've written a small Logo interpreter in Bash and I use ksh a lot in BSD) for my needs at least, it's half a system without it. NetBSD got big points today. If anybody bad-talks it anytime soon I'll be sure to tell them "Hey now, NetBSD has some pretty good things going for it". Some of this may sound silly, but all of it is sincere. (Including the money part. NetBSD just made it to the top line of my donation list. I'll be telling other people that as well.)

flfederation That's not a goal of PyPy, only a goal of Python Foundation. 😆I ask a question and get completely firehosed. Relax, mate, it was just a technical question. What I meant was that since PyPy is written in rpython does it matter what flavour of Python is used to build PyPy (either 2 or 3)? PyPy itself can of course keep compatibility with Python 2 & 3. My next suggestion (I wring my clothes dry while writing this) would've paralled @pin 's: build Python2 itself from source on 6.8. Python is not, I think, like Go where they use their own runtime and direct syscalls , so any changes to the source would not be extreme. In fact, I can try to meet you half-way on this. The last free space on my disk is now being used by FreeBSD-12.2-RC3 (for another user here). When that is gone, I can install OpenBSD and try to build Python2 from scratch (it's been a while since I've done this and that was on Linux ages ago). Then you can use my instructions and build PyPy itself. (Of course, if you can use pkgsrc on OpenBSD then use that in preference.)

I ask a question and get completely firehosed. Relax, mate, it was just a technical question. It's alright-- I know it was lengthy but I didn't expect you to read it all. It's strictly on a volunteer basis. I apologise for anything that was stressful or felt unpleasant, it was my feeling about the situation, not your post. What I meant was that since PyPy is written in rpython does it matter what flavour of Python is used to build PyPy (either 2 or 3)? Apparently. This isn't sarcasm, far from it-- I made exactly the same assumption myself. It's understandable that the devs want to compile PyPy from source. Sadly for BSD this is a catch 22 where to build rpython from source you need to build Python 2 from source. The PyPy devs don't have that problem (they already have rpython.) But understandably, BSD ports devs don't simply trust an rpython binary. If they do that, they might as well mirror PyPy binaries (if they existed for BSD) instead of compiling. Of course they wouldn't. It makes sense, though the implications and result are that PyPy isn't deprecated (but building it is.) PyPy itself can of course keep compatibility with Python 2 & 3. Yeah, I wish I'd gotten that from what you were saying. Not your fault. My next suggestion (I wring my clothes dry while writing this) would've paralled @pin 's: build Python2 itself from source on 6.8. Python is not, I think, like Go where they use their own runtime and direct syscalls, so any changes to the source would not be extreme. If I can figure out how to do that (right Now I'm happy to send money to NetBSD isntead-- not in hopes they'll do more, just for supporting what they already do now) that will work. But I have always leaned towards binary distributions, albeit ones with source available. In fact, I can try to meet you half-way on this. The last free space on my disk is now being used by FreeBSD-12.2-RC3 (for another user here). When that is gone, I can install OpenBSD and try to build Python2 from scratch (it's been a while since I've done this and that was on Linux ages ago). Then you can use my instructions and build PyPy itself. That's exactly what would make this so much easier for me, though it's far above and beyond my expectations here. It would be incredible to have instructions for that. Incidently, I am focused on i386 (or 686, whatever comes before amd64.) Of course, if you compile amd64 I assume the instructions will be similar, but if you're just doing this for me I'd recommend compiling for i386 (you can do this on a 64-bit x86 machine.) But I'm either way I'm grateful. (Of course, if you can use pkgsrc on OpenBSD then use that in preference.) I haven't yet. So far I've only used pkg_add and pkg_info. The instructions you're talking about writing may help more; I believe pkgsrc only works for "recipes" (whatever they're called locally) that are already available, so if Python 2 is "dropped" it may come down to another mirror hunt. I don't claim to know how pkgsrc works, these are guesses. Thanks very much. And please don't take anything I said personally. I wrote some things that could easily be interpreted as such, but despite challenging something you said, I took no offense to your post. All critique is aimed at PF (for their words, less for dropping support.) You've been ridiculously patient and it truly is appreciated. I got that you were trying to help, so let me clarify that here.

A sad day for BSD and Python

rvp

Looking into this, it appears most of the hard work has already been done:
https://openports.se/lang/pypy
https://openports.se/lang/python/2.7

Instructions:
https://www.openbsd.org/faq/ports/index.html

flfederation

rvp Thanks, I'll try to do that soon and let you know if it works.

flfederation

rvp This is not working, by the way. I'm getting stuff that the instructions don't cover, which I would probably get if I were more experienced with BSD. For a very relevant example:

$ make install 
Fatal: /usr/local/lib/X11/app-defaults should exist and be a symlink

Doing as root doesn't seem to help. I know what a symlink is, and how to make one, but it doesn't really help here.

On a slightly nicer note, I'm running Python 2.7 on OpenBSD 6.8.

I copied /usr/local/bin/python2.7, /usr/local/lib/libpython2.7.so.0.0, libintl.so.6.0 (6.8 uses 7.0, now it's got both) and tar -xvzf /usr/local/lib/python2.7 which I then copied to the 6.8 installation. And it's running-- haven't tried copying tkinter yet, I assume that will be a little trickier.

rvp

flfederation This is not working

I'll look into it... but, if it's this broken, you should contact the port maintainer (these being actively maintained ports).

flfederation I copied /usr/local/bin/python2.7, /usr/local/lib/libpython2.7.so.0.0, libintl.so.6.0 (6.8 uses 7.0, now it's got both) and tar -xvzf /usr/local/lib/python2.7 which I then copied to the 6.8 installation.

Hmm... dependency hell coming soon?
I guess you know what you're doing.

As you know, I don't use OpenBSD but, did you come across this, http://openbsd-archive.7691.n7.nabble.com/usr-local-lib-X11-app-defaults-td230392.html ?

As @rvp suggested, official ports should just work. Otherwise, the package should be marked as BROKEN.

flfederation

but, if it's this broken, you should contact the port maintainer (these being actively maintained ports).

This can't be blamed on the Python maintainer or Python-- it's what happened when I followed the instructions on using ports. I was trying to compile the example port.

However, trying to compile the Python port afterwards gives me the same problem. I use make clean because I think that's what you do, but the reason I'm not thrilled about compiling is I've never had a lot of luck with it. Some, yes-- very little. I mean I've written a (simple) compiler, it's not like "compiling" in and of itself is a complicated thing. But we are talking about make files, and they hate me for some reason-- this isn't specific to BSD.

But the mechanism is the same, and like I said, not a lot of luck yet. I try the instructions as-is first, try to understand what I'm doing and compensate for problems when they come up, but this is simply an aspect of Unix-like operating systems where I've always had this sort of thing happen.

Not enough practice, I'm sure doesn't help. Though this is catch-22 territory. I've only got so much motivation for doing the same things and getting the same results, when I don't know what else to do. Not that I intend to give up yet, it's just backstory. This isn't urgently needed, so if a solution comes up eventually that's cool too.

flfederation

I guess you know what you're doing.

So far a quick fix, not a good fix. Step 2 is to hopefully fix it properly.

official ports should just work. Otherwise, the package should be marked as BROKEN.

I've tried to compile two ports, without experience, previous success or the knowledge that I set it up properly or didn't accidentally skip a step. When I was already tired. I think assuming those ports are broken is hasty. I'd like better data, but I'd also like to have a better idea what I'm doing.

Please don't assume it's broken. Author of datapoint doesn't trust the datapoint.

I believe the same thing will happen no matter which port I try to compile-- so if you're going to mark those broken, mark the entire ports tree broken, please.

flfederation if you're going to mark those broken, mark the entire ports tree broken, please.

That's not possible 😆
I don't even use OpenBSD.

Try building something simple and see if it works, if not, something is probably wrong.

flfederation

That's not possible

Right, you may have missed the point there, which is that it's got nothing to do with those two particular packages.

Try building something simple and see if it works, if not, something is probably wrong.

That's exactly what I did in the first place. That's even what the instructions recommend. After that, I tried doing the same with Python.
Neither worked. I do not know how to compile ports packages.
Even with instructions.
There is the real problem.
I have a truly uncanny ability to miss the shot when I throw things in the bin. If there was a basketball scholarship where entry was based on how terrible you are, I'd get it. Somehow, this extends to using make. I don't know how I do it. I can do lots of other things, but when I try to compile packages (this applies cross platform) it's like letting Jacques Clouseau loose in the reactor room of Dr. No.
It's a fine recipe for an excuse I know, but trying harder and trying again tends to yield the same results. I was hoping that this would change with the switch to BSD. Fortunately, that wasn't a real factor in migrating.

rvp

OpenBSD installed. Python2.7 installation was also surprisingly easy. Next up: PyPy.
(Instructions: weekend--if not too busy.)

flfederation

@rvp Thank you for this. I'm not too surprised you find it easy-- when I started really learning GNU/Linux stuff 13 years ago (before that not as much) there were times like this when I thought "these guys can only do this because they're wizards."

These days I know better, but somehow I never got the hang of this. When I have your instructions (take your time) I can try them and let you know if/what goes wrong with then. If it doesn't simply work, it will probably be small simple things. But that's how it is.

rvp

flfederation OpenBSD 6.8 PyPy install:

# uname -a
OpenBSD x202e.localdomain 6.8 GENERIC.MP#1 amd64
# id -nu
root
# pkg_info -a -Q pypy
pypy-7.3.1
# pkg_add pypy
quirks-3.439 signed on 2020-10-31T12:23:49Z
pypy-7.3.1:tcl-8.5.19p4: ok
pypy-7.3.1:tk-8.5.19p1: ok
pypy-7.3.1:gdbm-1.18.1p0: ok
pypy-7.3.1:python-2.7.18p0: ok
pypy-7.3.1: ok
New and changed readme(s):
        /usr/local/share/doc/pkg-readmes/tcl-8.5
--- +tcl-8.5.19p4 -------------------
You may wish to add /usr/local/lib/tcl/tcl8.5/man to /etc/man.conf
--- +tk-8.5.19p1 -------------------
You may wish to add /usr/local/lib/tcl/tk8.5/man to /etc/man.conf
# pypy
Python 2.7.13 (?, Sep 30 2020, 23:12:46)
[PyPy 7.3.1 with GCC OpenBSD Clang 10.0.1 ] on openbsd6
Type "help", "copyright", "credits" or "license" for more information.
>>>> print 'O frabjous day! Callooh! Callay!'
O frabjous day! Callooh! Callay!
>>>> 
#

Standard OpenBSD install + handful of additional packages: bash, lynx, mc, firefox, xearth. No other system changes.

flfederation

rvp

# pkg_add pypy
Can't find pypy

# pkg_info -a -Q pypy
#

You said:

OpenBSD x202e.localdomain 6.8 GENERIC.MP#1 amd64

That could be the difference. I'm using i386 here. If I say "pkg_add leafpad" it installs, but if I say "pkg_add pypy" it doesn't have it. It only has pypy3.

Note I still run some i386-only hardware. Could I ditch it at this point? Probably. Would I like to be able to compile the package? Yes. This will probably come up again, and the only working solution right now is to copy from 6.7 or to switch the arch support.

I don't know why I can't compile things that require make. I mean in general? I'm sure I've managed to do so once or twice, in many many tries (not including the latest).

rvp

flfederation I'm using i386 here

What's the output of:

# pkg_info -a -Q python | fgrep 2.

flfederation

I must have been using pkg_info wrong, and tried installing Python2 without "p0".

Still no pypy, but Python2 as well as tkinter are now installed (after I found them). Same as 6.7. I normally use -Q with pkg_info, the -a part I didn't know about.

When I don't use -a it doesn't give any Python2 results, so that seems to be the culprit here. Until now, pkg_info -Q has worked well enough on its own.

Here is the output of pkg_info -a -Q python | fgrep 2. Thank you, I'm marking this solved. I don't hate pkg_info, it's actually quite useful, but it sure did make an ass of me today. I tried the simple things first, but they did not behave as expected. This is the problem with being a noob to a platform, even if you have plenty of experience elsewhere. Thanks again, and apologies for the inconvenience. That certainly doesn't sum up my feelings about this, but it's a start.

hamlib-python-1.2.15.3p1
postgresql-plpython-12.4
py-GitPython-2.1.9p0
py-ipython_genutils-0.2.0p2
py-wxPython-3.0.2.0p0
py3-GitPython-2.1.9p0
py3-ipython_genutils-0.2.0p2
python-2.7.18p0 (installed)
python-bsddb-2.7.18
python-gdbm-2.7.18
python-idle-2.7.18p0
python-tests-2.7.18
python-tkinter-2.7.18 (installed)
python-tools-2.7.18
weechat-python-2.9

rvp

Cool.

flfederation Still no pypy

pypy you can try building yourself (my machine has only 4GB RAM which, according to the PyPy website, won't do). If you can't, ask back here.

flfederation

(my machine has only 4GB RAM which, according to the PyPy website, won't do)

Same here. I honestly doubt that is required (swap ought to suffice, it would be ugly) though I will probably wait for a little more experience before I try to build PyPy again. If somehow I manage it though, I'll post the instructions.

« Previous Page