Re: AMD64 packages - Reflecting dynamic linking
And who are you, and what you have you done to test and then prove your thesis? Absolutely nothing, I must assume. (BTW, your argument is weak and would be stronger if you tied it into the faked moonlandings). I may get a little off-topic here and object for this very important topic to be discussed in a separate thread some day, but come to think of it, the overhead induced with dynamic linking, symbol versioning and crazy workarounds to make the dynamic linker remotely safe nowadays completely destroy the once good reasons for dynamic libraries. Static linking eliminates all the issues involved with symbol versions, wrecking your system with a library update and I'd even go as far as saying that static binaries are more or less independent from distributions. Memory usage is also not a point any more, because we have shared tables nowadays and in many cases, statically linked programs need less RAM than dynamically linked ones. So, what are the remaining arguments against static linking? I agree there are programs which do not run well if statically linked (the X-server for instance), but that's more or less a matter of design and can be worked around in most cases. One specific point often raised is the argument, that if you have an update for a specific library (a security update for instance), you just need to recompile the library and all programs depending on the library will behave correctly. With static libraries on the other hand, you would have to recompile all binaries and superset-libraries depending on this library for the security fix to be effective. This point is increasingly losing significance due to the following reasons: 1) hot-swapping a library for a security-fix implies that the ABI doesn't change, i.e. that the binaries on your system using this library can access the functions the way they have been told where they can find them. In many cases nowadays, bugs are fixed concurrently with version bumps (major minor) which means that all binaries have to be manually updated and recompiled anyway. 2) compiling is not expensive any more (in most cases). On my Gentoo-based system, it just takes 2 hours to recompile the entire operating system including all user-space applications. Moore's law will decrease this time over the years significantly. Imagine if it just took 5 minutes, would there still be a reason to have a hand-crafted dynamic linker to carefully dissect libraries and binaries, imposing a run-time loss and lots of security-considerations? I'm not talking about beasts like libreoffice, chromium and others. There are better alternatives around and if not, there will be in the future. For huge packages, it should be simple enough to design the package-manager in a way serving static binaries, and in case there is a library-fix, tell all clients to redownload the current version again. So the only real worry here is to have a clean build- environment on the build-servers (designed by experts) and not wasting hundreds of man-hours designing systems to cope with the dll-hell almost all Un*xes have become on the client-side. Why is Linux/BSD not popular on the desktop? Because of fragmentation. And one reason for fragmentation is that you can't use Debian packages in Ubuntu, mostly because there are library incompatibilities. Other reasons are lack of good software, but that's just a matter of time. And if we can get more developers to work on useful stuff instead of having to worry about library-versioning, this goal could be reached in shorter time. It may be a little far-fetched, but I'm sure it would be possible to have one package-manager for all distributions if there would just be the motivation to distribute statically linked binaries and not fuck things up with distribution-specific folder-structures. 3) security Well, the issues with dynamic linking have been stated often enough[0] [1][2][3][4]. As far as I understand, the initial motivation of the OpenBSD-project was to favor security over speed. It just puzzles me that issues like dynamic linking have not yet been discussed broadly or dealt with in the last few years given these obvious negative implications. Please let me know what you think. Cheers FRIGN [0]: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ [1]: http://benpfaff.org/papers/asrandom.pdf [2]: http://web.archive.org/web/20120509105723/http://teddziuba.com/2008/09/a-web-os-are-you-dense.html [3]: https://www.nth-dimension.org.uk/pub/BTL.pdf [4]: http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols -- FRIGN d...@frign.de
Re: AMD64 packages - Reflecting dynamic linking
On Thu, 01 Jan 2015 09:37:24 -0700 Theo de Raadt dera...@cvs.openbsd.org wrote: And who are you, and what you have you done to test and then prove your thesis? Absolutely nothing, I must assume. Your assumption is wrong. I am working with my colleagues from 2f30 on the morpheus-project[0] (including package-manager) and we have a set of static binary-packages[1] already ready for use. (BTW, your argument is weak and would be stronger if you tied it into the faked moonlandings). I know you as a rude person and like your humour, but your response contains no argument against the points I have given. I'm not saying that in an arrogant way (maybe I'm getting this whole deal completely wrong) and wanted to give some food for thought for the future. The OpenBSD-security-focus paid off. It wasn't the fastest system 10 years ago and isn't today, but when it made a difference in the past, security is more important today than speed, given how rapidly hardware is developing. I see the same issue here: How long do we really want to waste our time on this cruft and develop libraries with the wrong concept in our heads when dynamic linking is apparently becoming more and more irrelevant? Cheers FRIGN [0]: http://morpheus.2f30.org/ [1]: http://morpheus.2f30.org/0.0/packages/x86_64/ -- FRIGN d...@frign.de
Re: AMD64 packages - Reflecting dynamic linking
And who are you, and what you have you done to test and then prove your thesis? Absolutely nothing, I must assume. Your assumption is wrong. I am working with my colleagues from 2f30 on the morpheus-project[0] (including package-manager) and we have a set of static binary-packages[1] already ready for use. Ah, another arrogance -- you came here to advertise. You will gain little security or safety by rewriting everything for a small and obscure userbase, without attacking the hard problems of coding and enabling all possible mitigations. Static binaries are not a valid mitigation. It sounds like you have no real word experience, because your userbase is nonexistant.
Re: AMD64 packages - Reflecting dynamic linking
At the risk of having Theo tell me to shut up and get back to work on things that matter, ... On Fri, Jan 2, 2015 at 1:33 AM, FRIGN d...@frign.de wrote: On Fri, 12 Dec 2014 20:02:33 +0100 Ingo Schwarze schwa...@usta.de wrote: There are dragons. If this scares anybody, i'm not surprised; updating libraries is not a playground for newbies. That, actually, is *terrible* advice and almost guarantees a fiasco. If you edit shlib_version manually, you build a library containing code *incompatible* with what it's supposed to contain, so the end result will be that programs using that library will, at run time, * crash, * produce obviously wrong results, * and/or silently produce results that are wrong in non-obvious ways. Some programs, by mere luck, may also work, if you are lucky, but it's hard to predict in advance which ones will and which ones wont. To update a library, update all related source code - ideally, the whole source tree unless you know precisely what you are doing - to one consistent state, than compile from that state *without* manually screwing with shlib_version. That's the whole point of library versioning! I may get a little off-topic here and object for this very important topic to be discussed in a separate thread some day, but come to think of it, the overhead induced with dynamic linking, symbol versioning and crazy workarounds to make the dynamic linker remotely safe nowadays completely destroy the once good reasons for dynamic libraries. Do I hear echos of the /usr argument? Speed and large drives solve this one problem, so we can throw sense and reason out the window? Static linking eliminates all the issues involved with symbol versions, If only we had perfect libraries to start with. wrecking your system with a library update and I'd even go as far as saying that static binaries are more or less independent from distributions. As long as you ignore the inherent implicit linkages of the context OSses and the tools being used at a certain point in time, sure, theoretically, distribution independence can happen. Probably in the same universe where openbsd is a Linux distribution. (But, then you must remember to never argue that Linux Is Not UniX!) Memory usage is also not a point any more, because we have shared tables nowadays and in many cases, statically linked programs need less RAM than dynamically linked ones. Even if your arguments were not random, would they be meaningful? You not only fail to prove your assertions, you fail to explain their relevance. Why? So, what are the remaining arguments against static linking? What is your underlying argument? Static vs. dynamic is a null argument, so you must be using it as noise cover to sell something really noxious. I agree there are programs which do not run well if statically linked (the X-server for instance), but that's more or less a matter of design and can be worked around in most cases. ??? One specific point often raised is the argument, that if you have an update for a specific library (a security update for instance), you just need to recompile the library and all programs depending on the library will behave correctly. With static libraries on the other hand, you would have to recompile all binaries and superset-libraries depending on this library for the security fix to be effective. This point is increasingly losing significance due to the following reasons: Riding your noise waves, to look for clues, let's see: 1) hot-swapping a library for a security-fix implies that the ABI doesn't change, i.e. that the binaries on your system using this library can access the functions the way they have been told where they can find them. So, you are saying that there are so many bugs in the APIs that it is useless to fix non-API bugs? Cool. We can all go home now. In many cases nowadays, bugs are fixed concurrently with version bumps (major minor) which means that all binaries have to be manually updated and recompiled anyway. What do you mean by manually, anyway? 2) compiling is not expensive any more (in most cases). On my Gentoo-based system, it just takes 2 hours to recompile the entire operating system including all user-space applications. Gee, I wish I had a 512 core 14GHz Intel Core 10 with 16 Terabytes of RAM ... ... and the requisite nuclear reactor to power it. Moore's law will decrease this time over the years significantly. Intel's going to start shrinking silicon atoms now? Imagine if it just took 5 minutes, as opposed to 5 seconds? Why not? We're in the imaginary world anyway. would there still be a reason to have a hand-crafted Hand crafted, now? What does that mean? dynamic linker to carefully dissect libraries and binaries, imposing a run-time loss and lots of security-considerations? Oh, I'm the boogie-woogie man! (The Nightmare before Christmas is actually a rather deep movie.) I'm not talking about beasts
Re: AMD64 packages - Reflecting dynamic linking
On 15-01-01 07:44 PM, Joel Rees wrote: At the risk of having Theo tell me to shut up and get back to work on things that matter, ... and I suppose it's inevitible that someone will want to control the world, but I really wish you and your friends would quit lying to yourselves about power. I disagree - to me, this smells like just another instance of jwz's CADT (http://www.jwz.org/doc/cadt.html) cycle repeating itself. To me, this means that the day approaches where systemd will have its very own invasive CADT movement to deal with - this thought gives me a rare example to use the word schadenfreude in regular conversation :). -- -Adam Thompson athom...@athompso.net
Re: AMD64 packages - Reflecting dynamic linking
On Fri, 12 Dec 2014 20:02:33 +0100 Ingo Schwarze schwa...@usta.de wrote: There are dragons. If this scares anybody, i'm not surprised; updating libraries is not a playground for newbies. That, actually, is *terrible* advice and almost guarantees a fiasco. If you edit shlib_version manually, you build a library containing code *incompatible* with what it's supposed to contain, so the end result will be that programs using that library will, at run time, * crash, * produce obviously wrong results, * and/or silently produce results that are wrong in non-obvious ways. Some programs, by mere luck, may also work, if you are lucky, but it's hard to predict in advance which ones will and which ones wont. To update a library, update all related source code - ideally, the whole source tree unless you know precisely what you are doing - to one consistent state, than compile from that state *without* manually screwing with shlib_version. That's the whole point of library versioning! I may get a little off-topic here and object for this very important topic to be discussed in a separate thread some day, but come to think of it, the overhead induced with dynamic linking, symbol versioning and crazy workarounds to make the dynamic linker remotely safe nowadays completely destroy the once good reasons for dynamic libraries. Static linking eliminates all the issues involved with symbol versions, wrecking your system with a library update and I'd even go as far as saying that static binaries are more or less independent from distributions. Memory usage is also not a point any more, because we have shared tables nowadays and in many cases, statically linked programs need less RAM than dynamically linked ones. So, what are the remaining arguments against static linking? I agree there are programs which do not run well if statically linked (the X-server for instance), but that's more or less a matter of design and can be worked around in most cases. One specific point often raised is the argument, that if you have an update for a specific library (a security update for instance), you just need to recompile the library and all programs depending on the library will behave correctly. With static libraries on the other hand, you would have to recompile all binaries and superset-libraries depending on this library for the security fix to be effective. This point is increasingly losing significance due to the following reasons: 1) hot-swapping a library for a security-fix implies that the ABI doesn't change, i.e. that the binaries on your system using this library can access the functions the way they have been told where they can find them. In many cases nowadays, bugs are fixed concurrently with version bumps (major minor) which means that all binaries have to be manually updated and recompiled anyway. 2) compiling is not expensive any more (in most cases). On my Gentoo-based system, it just takes 2 hours to recompile the entire operating system including all user-space applications. Moore's law will decrease this time over the years significantly. Imagine if it just took 5 minutes, would there still be a reason to have a hand-crafted dynamic linker to carefully dissect libraries and binaries, imposing a run-time loss and lots of security-considerations? I'm not talking about beasts like libreoffice, chromium and others. There are better alternatives around and if not, there will be in the future. For huge packages, it should be simple enough to design the package-manager in a way serving static binaries, and in case there is a library-fix, tell all clients to redownload the current version again. So the only real worry here is to have a clean build- environment on the build-servers (designed by experts) and not wasting hundreds of man-hours designing systems to cope with the dll-hell almost all Un*xes have become on the client-side. Why is Linux/BSD not popular on the desktop? Because of fragmentation. And one reason for fragmentation is that you can't use Debian packages in Ubuntu, mostly because there are library incompatibilities. Other reasons are lack of good software, but that's just a matter of time. And if we can get more developers to work on useful stuff instead of having to worry about library-versioning, this goal could be reached in shorter time. It may be a little far-fetched, but I'm sure it would be possible to have one package-manager for all distributions if there would just be the motivation to distribute statically linked binaries and not fuck things up with distribution-specific folder-structures. 3) security Well, the issues with dynamic linking have been stated often enough[0] [1][2][3][4]. As far as I understand, the initial motivation of the OpenBSD-project was to favor security over speed. It just puzzles me that issues like dynamic linking have not yet been discussed broadly or dealt with in the last few years given these obvious negative implications. Please let
Re: AMD64 packages - Reflecting dynamic linking
On Thu, 01 Jan 2015 10:04:26 -0700 Theo de Raadt dera...@cvs.openbsd.org wrote: Ah, another arrogance -- you came here to advertise. Nope, if you read my first mail again, you'd see that I did not mention our project once and only presented it to challenge your assumption that I'm just some warrior presenting crude ideas. You will gain little security or safety by rewriting everything for a small and obscure userbase, without attacking the hard problems of coding and enabling all possible mitigations. These words are very true. Even with arc4random() and given how long it has been around (and given how _obvious_ its benefits are), people still use PRNG's attempting to generate truly random data. Static binaries are not a valid mitigation. It sounds like you have no real word experience, because your userbase is nonexistant. Maybe you are right. I must confess that I am an optimist and idealist when it comes to software development and looking at most software, mostly what I've seen in the last few years, you can't learn enough that there are many ugly spots in this area. You don't need a large userbase to see the issues even with a long-term switch to static binaries (so I definitely know what you're talking about) and that it is not a trivial thing. However, as a long-term perspective, one might hope that software development will actually take hardware-advancements in regard not by crufting software with more complexity, but by actually optimizing the foundation. You don't need to rewrite a lot to achieve that, same as you didn't have to rewrite a lot to make srand() truly random in builds that were non-deterministic. But I see that this discussion is getting nowhere for good reasons on both sides. So let's get back to coding. Happy hacking! Cheers FRIGN -- FRIGN d...@frign.de
Re: AMD64 packages - Reflecting dynamic linking
Quoting FRIGN d...@frign.de: It may be a little far-fetched, but I'm sure it would be possible to have one package-manager for all distributions if there would just be the motivation to distribute statically linked binaries and not fuck things up with distribution-specific folder-structures. I'm not a hacker so I have no means to ponder your other arguments, but as a user you lost me with this. I'm running away from systemd so the concept of one package manager to rule them all does not appeal to me. http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html -- Best regards, Jorge Lopez. This message was sent using IMP, the Internet Messaging Program.
Re: AMD64 packages
On 2014-12-12, ian kremlin i...@kremlin.cc wrote: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects is grab a fresh source tree and compile them manually. for example, libc: cd /usr/src/lib/libc edit 'shlib_version' to have the appropriate major/minor versions This is bad advice. There is a reason why we bump library versions! What you could do if you can't wait for new packages and don't have the correct version of the library, is to identify the date/time when the library was updated and e.g. cvs up -D 2014/12/05 (i.e. before the update) to fetch a copy of the source code for the library at the version you need, and build that.
Re: AMD64 packages
Hi Ian, ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. is grab a fresh source tree and compile them manually. for example, libc: There are dragons. Sometimes, you need to do make includes in the right directory first. Then again, that tends to reinstall *many* headers, not just those you care about right now, so be sure you don't install some that hurt you. Also, make depend can sometimes be necessary, and you certainly should never forget about make obj. When there is a flag day, very special steps may be required before doing anything else or somewhere in the middle. If you screw up, chances are you can't even do a clean shutdown any longer and are in for fsck(8) and manually reinstalling working libraries in single user mode before you can fully boot again. If this scares anybody, i'm not surprised; updating libraries is not a playground for newbies. cd /usr/src/lib/libc edit 'shlib_version' to have the appropriate major/minor versions (pkg_add(1) will tell you which ones it wants. That, actually, is *terrible* advice and almost guarantees a fiasco. If you edit shlib_version manually, you build a library containing code *incompatible* with what it's supposed to contain, so the end result will be that programs using that library will, at run time, * crash, * produce obviously wrong results, * and/or silently produce results that are wrong in non-obvious ways. Some programs, by mere luck, may also work, if you are lucky, but it's hard to predict in advance which ones will and which ones wont. To update a library, update all related source code - ideally, the whole source tree unless you know precisely what you are doing - to one consistent state, than compile from that state *without* manually screwing with shlib_version. That's the whole point of library versioning! make make install The command make install in lib/libc is among the more dangerous commands you might type, and if something is wrong, recovery is often more difficult than recovery from less scary errors. the bsd.port.mk(5) build system is well thought out No objection here... and allows for straightforward, helpful maneuvers like this ... but i really wouldn't give it that twist. Nothing about what you said is straightforward or helpful. It sounds more like somewhere between foolhardy and suicidal. pkg_check(8) is also an invaluable tool in helping deal with package issues. also, use the right $PKG_PATH! That's good advice again, for sure. Yours, Ingo
Re: AMD64 packages
ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. is grab a fresh source tree and compile them manually. for example, libc: There are dragons. No, Ingo, stop right there. What he is trying to do is create a frankenstein. People who do this will run into problems. Then they'll submit a bug report. It ends badly.
Re: AMD64 packages
On Dec 12, 2014 1:06 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. is grab a fresh source tree and compile them manually. for example, libc: There are dragons. No, Ingo, stop right there. What he is trying to do is create a frankenstein. People who do this will run into problems. Then they'll submit a bug report. It ends badly. I never dreamed that asking a simple question of about how long it might be before I could fix what I screwed up would end causing all of this. Whenever new packages are available, I'll fix what I broke and try to not do it again. Stan
Re: AMD64 packages
On Fri, Dec 12, 2014 at 2:02 PM, Ingo Schwarze schwa...@usta.de wrote: There are dragons. ingo, theo: sorry to post toxic advice, and thanks for the knowledge. i did not realize how shlib_version worked. i must have gotten lucky with my build but i should go back and fix it properly now ian
Re: AMD64 packages
If you don't understand that snapshots get built, that libraries crank, that there are PEOPLE building this, that the data takes time to get to the mirrors, and that this is a non-static situation, that small catch-up syncronization errors are made, that they get fixed by real people, then PLEASE DON'T RUN SNAPSHOTS. [...] Oh, I wasn't accusing anybody, or pointing fingers, or anything like that. I was just saying it's currently broken, that's all. Sorry if it came accross any other way. It happens all the time. The conversation is very META.
Re: AMD64 packages
On 2014-12-11, Stan Gammons sg063...@gmail.com wrote: Ok. The way I normally update is by downloading the install5x.iso, make the cd and boot from it, do an upgrade, reboot, do a sysmerge, then do pkg_add -u. After all the failures because of the library mismatch, kde4 will no longer start due to an ssl library mismatch. Bummer... Looks like it's wait until new packages are built. That method is ok, you just need to allow for library changes. I'd suggest following source-changes so you can spot these and hold off on updating for a couple of days.
Re: AMD64 packages
The conversation is very META. What is META?
Re: AMD64 packages
That it is a discussion about a discussion, not about any topic of its own. 2014-12-11 12:37 GMT+01:00 Mihai Popescu mih...@gmail.com: The conversation is very META. What is META? -- May the most significant bit of your life be positive.
Re: AMD64 packages
On Wed, 10 Dec 2014 21:27:46 -0500 STeve Andre' and...@msu.edu wrote: You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Just reading the titles is not very helpful and I also don't feel like pulling the entire OpenBSD CVS-tree just to view the recent code-changes. I'm subscribed to numerous mailing lists, and all of them provide diff-data in the mail itself. I'm sure more people would subscribe to such a list if it actually encouraged to read and check the source. Cheers FRIGN -- FRIGN d...@frign.de
Re: AMD64 packages
On Thu, Dec 11, 2014 at 11:59:55AM +0100, FRIGN wrote: Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Not official and not instantly updated: http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ -- Oliver PETER oli...@gfuzz.de 0x456D688F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: AMD64 packages
you could try http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ On Thu, Dec 11, 2014 at 11:59 AM, FRIGN d...@frign.de wrote: On Wed, 10 Dec 2014 21:27:46 -0500 STeve Andre' and...@msu.edu wrote: You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Just reading the titles is not very helpful and I also don't feel like pulling the entire OpenBSD CVS-tree just to view the recent code-changes. I'm subscribed to numerous mailing lists, and all of them provide diff-data in the mail itself. I'm sure more people would subscribe to such a list if it actually encouraged to read and check the source. Cheers FRIGN -- FRIGN d...@frign.de -- Björn Ketelaars bjorn.ketela...@hydroxide.nl GPG key: 0x4F0E5F21
Re: AMD64 packages
On 2014-12-11, Oliver Peter li...@peter.de.com wrote: On Thu, Dec 11, 2014 at 11:59:55AM +0100, FRIGN wrote: Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Not official and not instantly updated: http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ Yes, this is what I use if I'm looking for contents of diffs that have been committed. Personally I also try to keep the main part of my commit logs in the first line (and where ports is concerned I include the name of the port for simple updates rather than just 'update to xx') so that the truncated commit message on this type of display is still usable :-)
Re: AMD64 packages
On 12/11/14 05:59, FRIGN wrote: On Wed, 10 Dec 2014 21:27:46 -0500 STeve Andre' and...@msu.edu wrote: You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Just reading the titles is not very helpful and I also don't feel like pulling the entire OpenBSD CVS-tree just to view the recent code-changes. I'm subscribed to numerous mailing lists, and all of them provide diff-data in the mail itself. I'm sure more people would subscribe to such a list if it actually encouraged to read and check the source. Cheers FRIGN Have you looked at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ ? You can get a diff of the change of any revision, which should help out. --STeve Andre'
Re: AMD64 packages
whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects is grab a fresh source tree and compile them manually. for example, libc: cd /usr/src/lib/libc edit 'shlib_version' to have the appropriate major/minor versions (pkg_add(1) will tell you which ones it wants. a good article on how these work here: http://www.tedunangst.com/flak/post/OpenBSD-version-numbers) make make install the bsd.port.mk(5) build system is well thought out and allows for straightforward, helpful maneuvers like this pkg_check(8) is also an invaluable tool in helping deal with package issues. also, use the right $PKG_PATH! On Thu, Dec 11, 2014 at 3:13 PM, STeve Andre' and...@msu.edu wrote: On 12/11/14 05:59, FRIGN wrote: On Wed, 10 Dec 2014 21:27:46 -0500 STeve Andre' and...@msu.edu wrote: You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Just reading the titles is not very helpful and I also don't feel like pulling the entire OpenBSD CVS-tree just to view the recent code-changes. I'm subscribed to numerous mailing lists, and all of them provide diff-data in the mail itself. I'm sure more people would subscribe to such a list if it actually encouraged to read and check the source. Cheers FRIGN Have you looked at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ ? You can get a diff of the change of any revision, which should help out. --STeve Andre'
Re: AMD64 packages
On 12/10/14 20:51, Stan Gammons wrote: When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. Stan They come out frequently, but not on a set schedule. Since the last set came out on the 6th, I would expect the next set in the next several days -- unless some change caused a cascade of non-compiles in which case the problem will be worked on before the next release. You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html
Re: AMD64 packages
On Dec 10, 2014 10:03 PM, STeve Andre' and...@msu.edu wrote: On 12/10/14 20:51, Stan Gammons wrote: When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. Stan They come out frequently, but not on a set schedule. Since the last set came out on the 6th, I would expect the next set in the next several days -- unless some change caused a cascade of non-compiles in which case the problem will be worked on before the next release. You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html Ok. The way I normally update is by downloading the install5x.iso, make the cd and boot from it, do an upgrade, reboot, do a sysmerge, then do pkg_add -u. After all the failures because of the library mismatch, kde4 will no longer start due to an ssl library mismatch. Bummer... Looks like it's wait until new packages are built. Stan
Re: AMD64 packages
On 10 December 2014, Stan Gammons sg063...@gmail.com wrote: When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. There are bigger problems with the latest snapshot: $ ldd /usr/sbin/unbound /usr/sbin/unbound: /usr/sbin/unbound: can't load library 'libssl.so.30.0' /usr/sbin/unbound: exit status 4 $ ls -l /usr/lib/libssl* -r--r--r-- 1 root bin 1518902 Oct 29 03:25 /usr/lib/libssl.so.27.2 -r--r--r-- 1 root bin 1512855 Nov 16 09:49 /usr/lib/libssl.so.28.0 -r--r--r-- 1 root bin 1518550 Dec 8 07:54 /usr/lib/libssl.so.29.0 $ dmesg | head -1 OpenBSD 5.6-current (GENERIC.MP) #668: Wed Dec 10 12:43:55 MST 2014 Regards, Liviu Daia
Re: AMD64 packages
Look, this is rather simple. If you don't understand that snapshots get built, that libraries crank, that there are PEOPLE building this, that the data takes time to get to the mirrors, and that this is a non-static situation, that small catch-up syncronization errors are made, that they get fixed by real people, then PLEASE DON'T RUN SNAPSHOTS. Hours later, another snapshot neaks out for each architecture, which has managed to pick up the shared library crank. Please learn what the snapshot processes are. It's in the FAQ! If you don't learn and understand the strong tech-innovation promise but much weaker delivery promise of snapshots, you are denegrating the effort by chattering into people's mailboxes. We do what we can, based on what we have. It is very nearly an auto-build platform with catchup corrections for these details. AND furthermore, snapshots sometimes contain surprise eggs for future coming test code; where it is easier to build it for all architectures and get it dogfooded in subsets of the test community, than wait and wait and wait for them to build it themselves. Those are our prorities showing through. Alternatively we could create a snapshots-failed-minute-...@openbsd.org mailing list, which I will not participate in. On 10 December 2014, Stan Gammons sg063...@gmail.com wrote: When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. There are bigger problems with the latest snapshot: $ ldd /usr/sbin/unbound /usr/sbin/unbound: /usr/sbin/unbound: can't load library 'libssl.so.30.0' /usr/sbin/unbound: exit status 4 $ ls -l /usr/lib/libssl* -r--r--r-- 1 root bin 1518902 Oct 29 03:25 /usr/lib/libssl.so.27.2 -r--r--r-- 1 root bin 1512855 Nov 16 09:49 /usr/lib/libssl.so.28.0 -r--r--r-- 1 root bin 1518550 Dec 8 07:54 /usr/lib/libssl.so.29.0 $ dmesg | head -1 OpenBSD 5.6-current (GENERIC.MP) #668: Wed Dec 10 12:43:55 MST 2014 Regards, Liviu Daia
Re: AMD64 packages
On 11 December 2014, Theo de Raadt dera...@cvs.openbsd.org wrote: On 10 December 2014, Stan Gammons sg063...@gmail.com wrote: When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. There are bigger problems with the latest snapshot: $ ldd /usr/sbin/unbound /usr/sbin/unbound: /usr/sbin/unbound: can't load library 'libssl.so.30.0' /usr/sbin/unbound: exit status 4 [...] Look, this is rather simple. If you don't understand that snapshots get built, that libraries crank, that there are PEOPLE building this, that the data takes time to get to the mirrors, and that this is a non-static situation, that small catch-up syncronization errors are made, that they get fixed by real people, then PLEASE DON'T RUN SNAPSHOTS. [...] Oh, I wasn't accusing anybody, or pointing fingers, or anything like that. I was just saying it's currently broken, that's all. Sorry if it came accross any other way. Regards, Liviu Daia
