Re: ispec - PSK - issues
On Thu, Aug 18, 2016 at 07:57:40PM +, Justin Mayes wrote: > Hello all - > > I was also recently trying to do a simple ipsec/l2tp vpn. I found that it > works fine for everything except my android 5.1.1 device. This problem and a workaround were already discussed here: http://marc.info/?l=openbsd-misc&m=145931891921713&w=2 Quote: [[[ This issue is caused by Android, it sends ESP packets with wrong padding size when SHA2-256 is selected for HMAC. It seems that Android is using an old ietf draft for SHA2-256, but OpenBSD is using RFC 4868. When the issue occurs, XXX packets with bad payload size or padding received counter in "netstat -sp esp" will be incremented. We can force using MD5 or SHA for HMAC to workaround this issue. To do this, put the text below to /etc/isakmpd/isakmpd.policy and remove "-K" from isakmpd_flags. Authorizer: "POLICY" Comment: This is test Licensees: "passphrase:PASSPHRASE" conditions: app_domain == "IPsec policy" && doi == "ipsec" && esp_present == "yes" \ && (esp_auth_alg == "hmac-md5" || esp_auth_alg == "hmac-sha") -> "true"; --yasuoka ]]]
Re: Security updates and packages
On 19 Aug 2016, thu...@yeuxdelibad.net wrote: > I was wondering if packages for -release would be fixed if a security > issue is found in one of these third party programs, which could be > updated with pkg_add -u. It's a good question. I was quite amused to notice the juxtaposition of: ] Our aspiration is to be NUMBER ONE in the industry for security (if we ] are not already there). ] The ports tree is meant for advanced users. Everyone is encouraged to ] use the pre-compiled binary packages. ] When serious bugs or security flaws are discovered in third party ] software, they are fixed in the -stable branch of the ports tree. Note ] that binary packages for -release and -stable are not updated. I am guessing that your fear is correct but it's a matter of resource availability given the effort it takes to keep the core system great. If we want security updates for binary packages then I'd hope that people agree it to be a good idea in the abstract but we probably need to volunteer actual work (or donate more!) if it is to actually happen. -- Mark
Re: Security updates and packages
You can pay someone to build them for you, where M:Tier springs to mind. Also, having a build host (or vm) somewhere running -stable and (re)building any updated -stable port for your particular platform isn't all that difficult and hard, especially if its just about a single or a specific small subset of ports. Building ports numbering upwards to 1 or whatever todays list is, and co-publishing it as any single on gets an update takes a certain amount of effort, for which snapshots right now only get that kind of attention, and the per-6month package builds. So the juxtaposition thing is a bit weird, since updates do get published, its just that you also need to chip in with a bit of effort if your particular port got a security update in -stable. So the project can still be about security if it does updates, even if you can't just lean back and open your mouth and get spoonfed precompiled binaries the same day. The project updates -stable and -current ports (and base) in terms of cvs commits. The prebuilt packages, if any, are a nice bonus on top of that. 2016-08-19 9:45 GMT+02:00 Mark Carroll : > On 19 Aug 2016, thu...@yeuxdelibad.net wrote: > > > I was wondering if packages for -release would be fixed if a security > > issue is found in one of these third party programs, which could be > > updated with pkg_add -u. > > It's a good question. I was quite amused to notice the juxtaposition of: > > ] Our aspiration is to be NUMBER ONE in the industry for security (if we > ] are not already there). > > ] The ports tree is meant for advanced users. Everyone is encouraged to > ] use the pre-compiled binary packages. > > ] When serious bugs or security flaws are discovered in third party > ] software, they are fixed in the -stable branch of the ports tree. Note > ] that binary packages for -release and -stable are not updated. > > I am guessing that your fear is correct but it's a matter of resource > availability given the effort it takes to keep the core system great. If > we want security updates for binary packages then I'd hope that people > agree it to be a good idea in the abstract but we probably need to > volunteer actual work (or donate more!) if it is to actually happen. > > -- Mark > > -- May the most significant bit of your life be positive.
Re: Security updates and packages
On Fri, Aug 19, 2016 at 8:58 AM, Thuban wrote: > Hello, > I was wondering if packages for -release would be fixed if a security > issue is found in one of these third party programs, which could be > updated with pkg_add -u. > Officially? No. But this seems to be a "industry standard" - https://stable.mtier.org/ -- chs
Re: Security updates and packages
Hi, haveva look at this: https://stable.mtier.org/ Regards Am 19.08.2016 08:59 schrieb "Thuban" : > Hello, > I was wondering if packages for -release would be fixed if a security > issue is found in one of these third party programs, which could be > updated with pkg_add -u. > > Or does someone has to stay up to date and usr ports to upgrade each > single package on his system to follow -stable? (with the risk to miss > the last new of a tiny library...). This is what the FAQ make me wonder, > but just to be sure. > > Regards. > > -- > /Thuban/ > > [demime 1.01d removed an attachment of type application/pgp-signature > which had a name of signature.asc]
Re: Security updates and packages
On 2016-08-19, Thuban wrote: > I was wondering if packages for -release would be fixed if a security > issue is found in one of these third party programs, which could be > updated with pkg_add -u. No, they're not, they're fixed for release and not further updated. It's the same for the base OS - releases are a fixed point, we don't rewrite history. > Or does someone has to stay up to date and usr ports to upgrade each > single package on his system to follow -stable? (with the risk to miss > the last new of a tiny library...). This is what the FAQ make me wonder, > but just to be sure. Options include: - use -current snapshots. this is likely to be the easiest way for most people. - build your own from -stable if the relevant commits have already been backported, dpb -R can help with this, but it's not really a beginner thing. - backport things yourself if the relevant commits have not already been backported. - use a third party service. - use a different OS, some of the Linux distributions are a lot better suited to people who don't want to update most of their software but still get some backported fixes ;)
Re: Upgrading from 5.8 to 5.9: Can't install patches
On 2016-08-19, trondd wrote: > On Thu, August 18, 2016 7:34 pm, Jay Hart wrote: >> >> Next I downloaded all 25 patches but patch 002 failed to install and I >> think its because I need to >> download and untar src.tar.gz and sys.tar.gz. My thinking is the source >> tree I installed under >> 5.8, is still 5.8, not 5.9. > > Correct. The installer does not install/update the source for you. You > have to get it yourself by downloading the tarballs or via CVS. Yes - and if it's by tarballs, remove the old files.
Re: Upgrading from 5.8 to 5.9: Can't install patches
According to the documentation I could find, I need to delete everything in /usr/src and /usr/obj, then untar the 5.9 tar files. Once this is done, I can start patching. I was just going to remove all files and directories under these two locations. Is this the correct procedure? TIA, Jay
Re: Security updates and packages
> > I was wondering if packages for -release would be fixed if a security > > issue is found in one of these third party programs, which could be > > updated with pkg_add -u. > > It's a good question. I was quite amused to notice the juxtaposition of: > > ] Our aspiration is to be NUMBER ONE in the industry for security (if we > ] are not already there). > > ] The ports tree is meant for advanced users. Everyone is encouraged to > ] use the pre-compiled binary packages. > > ] When serious bugs or security flaws are discovered in third party > ] software, they are fixed in the -stable branch of the ports tree. Note > ] that binary packages for -release and -stable are not updated. > > I am guessing that your fear is correct but it's a matter of resource > availability given the effort it takes to keep the core system great. If > we want security updates for binary packages then I'd hope that people > agree it to be a good idea in the abstract but we probably need to > volunteer actual work (or donate more!) if it is to actually happen. There is no juxtaposition. You are expecting a bunch of volunteers to do the massive job of upgrading last-month's software -- and do it better than Google with Android, or car manufacturers, or basically anything which contains software. You are labelling "security" as purely "dealing with yesterday's bugs" essentially for "customers" -- and we don't have customers. When we talk about security, we mean a development mindset for security-related innovation which get designed, proven, adopted, and reduce risk of software having bugs. Then slowly as a whole we try to drag everyone in the world forward - some of the things listed at http://www.openbsd.org/innovations.html are relevant to that. The juxtaposition I observe is someone I never heard of before in regards to investment & work in this community, arriving on a list to make a judgement. You even come to the conclusion that such work isn't going to happen for free, but leave the result dangling. Especially since OpenBSD isn't a PRODUCT. If product-servicing is a requirement, first of all choose something which is a PRODUCT, then choose a PRODUCT VENDOR who actually does SERVICING. It's doubly hard, without having to hold a non-product non-vendor responsible for a servicing requirement, which WE DO WELL WITH, but expecting more is ridiculous. AND WHERE IS THE PONY. Perhaps the distictions are too subtle for you, and doesn't roll off the keyboard well enough as a snipe. It's ok, my cats cannot read and interpret such complexities either.
Re: Security updates and packages
Theo de Raadt wrote: Especially since OpenBSD isn't a PRODUCT. If product-servicing is a requirement, first of all choose something which is a PRODUCT, then choose a PRODUCT VENDOR who actually does SERVICING. Nicely put. My open source Ublu (https://github.com/jwoehr/ublu) is currently attracting attention in the IBM record-based systems world (for precisely which Ublu was coded) and people keep referring to it as a "product" and I have to make similar corrections to their understanding ... AND WHERE IS THE PONY. Much easier question to answer: https://az616578.vo.msecnd.net/files/responsive/embedded/any/desktop/2015/12/18/6358600036517504461717781900_maxresdefault.jpg -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan
Re: Security updates and packages
> You even come to the conclusion that such work isn't going to happen > for free, but leave the result dangling. Especially since OpenBSD > isn't a PRODUCT. If product-servicing is a requirement, first of all > choose something which is a PRODUCT, then choose a PRODUCT VENDOR who > actually does SERVICING. It's doubly hard, without having to hold > a non-product non-vendor responsible for a servicing requirement, > which WE DO WELL WITH, but expecting more is ridiculous. AND WHERE > IS THE PONY. OK I have done a lot of cutting and I may have put your words out of context, this isn't intended of course, however I feel when you say "OpenBSD isn't a PRODUCT" that this just can't be. By that I mean, that I buy every CD that comes out, a) it has an ISBN number so it's a book (but not really) b) It has a booklet inside so perhaps it is a book. It has 3 awesomely decorated CD's inside too, that contain binary code to run on a set of computer architectures and the last CD has source code so the purchaser can study the inner workings of the binary, *) these are expected to be synced. When running the contents of your product it's able to compile itself from the provided source code with means of a GCC compiler. The fact that you don't want to promise service for your product is your decision, but it is a product. In fact it's a wise decision because you'd be facing a lot of work for which human resources are needed and human resources require money. The income of your product is not substantial to pay the human resources to deliver service. Perhaps for future customers who are looking around a book store and find your product it should say "AS IS. Promise no further service." so that they can spend their money wisely. Regards, -peter
Re: Security updates and packages
> > You even come to the conclusion that such work isn't going to happen > > for free, but leave the result dangling. Especially since OpenBSD > > isn't a PRODUCT. If product-servicing is a requirement, first of all > > choose something which is a PRODUCT, then choose a PRODUCT VENDOR who > > actually does SERVICING. It's doubly hard, without having to hold > > a non-product non-vendor responsible for a servicing requirement, > > which WE DO WELL WITH, but expecting more is ridiculous. AND WHERE > > IS THE PONY. > > OK I have done a lot of cutting and I may have put your words out of context, > this isn't intended of course, however I feel when you say "OpenBSD isn't a > PRODUCT" that this just can't be. By that I mean, that I buy every CD that > comes out, a) it has an ISBN number so it's a book (but not really) b) It > has a booklet inside so perhaps it is a book. It has 3 awesomely decorated > CD's inside too, that contain binary code to run on a set of computer > architectures and the last CD has source code so the purchaser can study the > inner workings of the binary, *) these are expected to be synced. When > running the contents of your product it's able to compile itself from the > provided source code with means of a GCC compiler. You bought some plastic. If we shipped blank plastic, half our user community would still purchase it in support of what we do. You never purchased an agreement for it to be serviced. Nowhere will you find promise that this is a product, nor a product with servicing, you are making shit up. Considering the CDs have been sold at close to a loss for years, your expections are way out of line. Then, you stand here and demand things? You sir, are just wastewater. > The fact that you don't want to promise service for your product is your > decision, but it is a product. In fact it's a wise decision because you'd > be facing a lot of work for which human resources are needed and human > resources require money. The income of your product is not substantial to > pay the human resources to deliver service. It is not a product. You cannot claim that something I largely give away is a product, if I say it isn't a product. Your words are just bile. > Perhaps for future customers who are looking around a book store and find > your product it should say "AS IS. Promise no further service." so that > they can spend their money wisely. Text like this occurs 40,000 times throughout just the base source tree: * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. You are way out of line with the software development community. Your interpretations are hostile.
Re: Security updates and packages
On 08/19/16 17:43, Theo de Raadt wrote: >>> You even come to the conclusion that such work isn't going to happen >>> for free, but leave the result dangling. Especially since OpenBSD >>> isn't a PRODUCT. If product-servicing is a requirement, first of all >>> choose something which is a PRODUCT, then choose a PRODUCT VENDOR who >>> actually does SERVICING. It's doubly hard, without having to hold >>> a non-product non-vendor responsible for a servicing requirement, >>> which WE DO WELL WITH, but expecting more is ridiculous. AND WHERE >>> IS THE PONY. >> OK I have done a lot of cutting and I may have put your words out of context, >> this isn't intended of course, however I feel when you say "OpenBSD isn't a >> PRODUCT" that this just can't be. By that I mean, that I buy every CD that >> comes out, a) it has an ISBN number so it's a book (but not really) b) It >> has a booklet inside so perhaps it is a book. It has 3 awesomely decorated >> CD's inside too, that contain binary code to run on a set of computer >> architectures and the last CD has source code so the purchaser can study the >> inner workings of the binary, *) these are expected to be synced. When >> running the contents of your product it's able to compile itself from the >> provided source code with means of a GCC compiler. > You bought some plastic. If we shipped blank plastic, half our user > community would still purchase it in support of what we do. > > You never purchased an agreement for it to be serviced. I'm not expecting that. But the "hint" that this will not be serviced should be there. > Nowhere will you find promise that this is a product, nor a product with > servicing, you are making shit up. > > Considering the CDs have been sold at close to a loss for years, your > expections are way out of line. > > Then, you stand here and demand things? You sir, are just wastewater. I simply suggested a line to be put on the front or back cover of the CD case. Thanks for the insult. >> The fact that you don't want to promise service for your product is your >> decision, but it is a product. In fact it's a wise decision because you'd >> be facing a lot of work for which human resources are needed and human >> resources require money. The income of your product is not substantial to >> pay the human resources to deliver service. > It is not a product. > > You cannot claim that something I largely give away is a product, if I say > it isn't a product. Your words are just bile. > >> Perhaps for future customers who are looking around a book store and find >> your product it should say "AS IS. Promise no further service." so that >> they can spend their money wisely. > Text like this occurs 40,000 times throughout just the base source tree: > > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > You are way out of line with the software development community. Your > interpretations are hostile. To whom? The person buying your plastic? For someone to read the source code license (which isn't even the book) they have to purchase the CD's and open them, or they write down the ISBN and go home and educate themselves on the product they consider buying. But in this fast-paced life who really does that? People see, and buy it. I've been buying your CD's since 2.6. I don't mean to be rude, in fact I'll continue to buy the CD. And regarding the software development community, I can't speak for it or against it. Regards, -peter
Re: Security updates and packages
On 19 Aug 2016, Theo de Raadt wrote: (snip) > There is no juxtaposition. I'm pretty sure that I managed to place the quotations side by side! > You are expecting a bunch of volunteers to do the massive job of > upgrading last-month's software -- and do it better than Google with > Android, or car manufacturers, or basically anything which contains > software. I don't expect anything of the sort. Please don't confuse what I actually said with your generic caricature of people. I'm sorry that you read my amusement as judging and sniping but that sneering's wholly in your head. I wouldn't be on this list at all were I not pretty impressed with the project. Though, I have a feeling that you might keep on seeing sniping in this response, so go ahead and have the last word after this: you need not fear my extending this subthread beyond it having plausible value in reducing confusion. > You are labelling "security" as purely "dealing with yesterday's bugs" > essentially for "customers" -- and we don't have customers. Not "purely" but in common parlance and practice I do regard prompt installation of fixes for "security flaws" as part of "security" in its usual sense, yes. That's why I was surprised by how "everyone is encouraged to use" packages that don't get such fixes and I assumed the lack of binary fixes to simply be a matter of having to allocate limited resources to other, more valuable, efforts, that the "everyone is encouraged" might just be worded too strongly. I now find that I may well be wrong, that it is a deeper philosophical issue: Thank you for your explanation of how the security discussed by one of the pages I quoted is specifically about a development mindset rather than being about some general concept of users' systems security: that explains why the quotes all make sense as a whole and it also fits with your laudable stance on W^X, etc. I already wrote elsewhere how I value how the project puts "solid engineering well ahead of adding features". You can understand why the average outsider reading through these public pages might be confused and read "security" more broadly though? Maybe it was just me. Indeed, I've not contributed much to OpenBSD. I do answer questions here where I can (which isn't often!) and I wrote up details of how I got OpenBSD running on my machines in the hope of helping other new users (and of course sent a dmesg) but, back to the optimal allocation of resources, mostly I use and contribute to FOSS according to my actual ability: with my being fairly new to running BSDs and having barely used C for years, I am sorry to agree that I don't offer OpenBSD much at present. But, on the other hand, just this week I contributed Java code to kryo-serializers and I've not even actually used that library myself yet: I figure it all balances out but of course you may reasonably think otherwise. I also occasionally contribute FOSS security fixes (e.g., one that got into this month's release of OMERO) and my thinking may be colored by the anxiety I sometimes feel in seeing people still running the vulnerable versions. Of course it helps that the OpenBSD release schedule has been fairly brisk so people certainly aren't encouraged to run /ancient/ packages. -- Mark
Re: Security updates and packages
> Not "purely" but in common parlance and practice I do regard prompt > installation of fixes for "security flaws" as part of "security" in its > usual sense, yes. Then hire some people to do it. Our crew who cares about a subset of that is at their limit. We aren't going to keep slaves, and garden fairies can't do the work. > You can understand why the average outsider reading through these public > pages might be confused and read "security" more broadly though? Maybe > it was just me. I don't care if you misread or misunderstood our web pages. Lots of other people understand them fine. > But, on the other hand, just this week I contributed Java code > to kryo-serializers and I've not even actually used that library myself > yet: I figure it all balances out but of course you may reasonably think > otherwise. So you submitted some small changes to someone. Somehow those small changes will pixie-dust turn into a driving factor which causes other people to give you "prompt installation of fixes for "security flaws" as binaries. > I figure it all balances out but of course you may reasonably think > otherwise. It does not balance out. About one thousand people write all the free software. Everyone benefits to a tremendous extent. Then some of those benefiting users come on lists and demand that a thousand volunteer do more for them. I expect more, damn it. And I want my flying car tomorrow.
Re: Security updates and packages
> > You never purchased an agreement for it to be serviced. > > I'm not expecting that. But the "hint" that this will not be serviced > should be there. The lack of a promise is enough. > > Then, you stand here and demand things? You sir, are just wastewater. > > I simply suggested a line to be put on the front or back cover of the CD > case. That sentence is completely false. It is the first time you have suggested it. And I won't do it, I don't bow down to demands. > >> they can spend their money wisely. > > Text like this occurs 40,000 times throughout just the base source tree: > > > > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > > > You are way out of line with the software development community. Your > > interpretations are hostile. > > To whom? The person buying your plastic? For someone to read the > source code license (which isn't even the book) they have to purchase > the CD's and open them, or they write down the ISBN and go home and > educate themselves on the product they consider buying. But in this > fast-paced life who really does that? People see, and buy it. That is pure fiction. Everyone knows what the purpose of OpenBSD is. It will not twist in the directions you want.
Re: Security updates and packages
> OK I have done a lot of cutting and I may have put your words out of context, > this isn't intended of course, however I feel when you say "OpenBSD isn't a > PRODUCT" that this just can't be. By that I mean, that I buy every CD that > comes out, a) it has an ISBN number so it's a book (but not really) b) It > has a booklet inside so perhaps it is a book. It has 3 awesomely decorated > CD's inside too, that contain binary code to run on a set of computer > architectures and the last CD has source code so the purchaser can study the > inner workings of the binary, *) these are expected to be synced. When > running the contents of your product it's able to compile itself from the > provided source code with means of a GCC compiler. hmm, the difference is very subtle indeed. Man, what you bought is OpenBSD version x.x, not OpenBSD. Look on your CD label.
Re: Security updates and packages
Hi, on a lighter note, 'cause i usually (with exceptions :) like doing what i like to do better than arguing with people who happen to misunderstand it... Theo de Raadt screamed on Fri, Aug 19, 2016 at 08:25:40AM -0600: > AND WHERE IS THE PONY. Right here: https://plus.google.com/collection/4SI_e And it was already here: http://www.openbsd.org/papers/bsdcan11-mandoc-openbsd.html Watch out, more than one pony hides in the latter! Admittedly, it has grown somewhat since that time: http://www.openbsd.org/papers/bsdcan15-mandoc.pdf So Theo, don't make us smaller than we are. We have been having a pony in the base system for more than half a decade now! Even if you don't count this one, which is enabled in the default install as well: schwarze@dino $ psl | grep ': pony' _smtpd 77747 91072 ?? 10:18AM Ip 0.2 0.0 smtpd: pony express (smtpd) SCNR, Ingo
DPB can't do it's job in 6.0
Hi misc@ I'm a bit disappointed with dpb in 6.0, I haven't tried the chrooting stuff but was hoping it could still work as before. All I can get it to do now is start downloading src tarballs, and more often than not fail at that (manual make -j5 package will build anything). It can barely build anything, much less x11/gnome. I'd love to know what I can to do rectify this... Cheers, Noth
Re: Upgrading from 5.8 to 5.9: Can't install patches
On 2016-08-19, Jay Hart wrote: > According to the documentation I could find, I need to delete everything in > /usr/src and /usr/obj, > then untar the 5.9 tar files. Once this is done, I can start patching. > > I was just going to remove all files and directories under these two > locations. > > Is this the correct procedure? Yes.
Re: DPB can't do it's job in 6.0
On 2016-08-19, Noth wrote: > Hi misc@ > > >I'm a bit disappointed with dpb in 6.0, I haven't tried the chrooting > stuff but was hoping it could still work as before. All I can get it to > do now is start downloading src tarballs, and more often than not fail > at that (manual make -j5 package will build anything). It can barely > build anything, much less x11/gnome. I'd love to know what I can to do > rectify this... > > > Cheers, > > > Noth > > The chroot support is currently optional, but you do need to create the user accounts if sysmerge didn't do it for you (_pbuuld, _pfetch), and start dpb as root. Beyond that, we need command lines, logs and console output to help if things aren't working.
Re: DPB can't do it's job in 6.0
On 2016-08-19, Stuart Henderson wrote: > The chroot support is currently optional, but you do need to create the > user accounts if sysmerge didn't do it for you (_pbuuld, _pfetch), and > start dpb as root. No, running dpb as root is also optional. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: DPB can't do it's job in 6.0
On 8/19/16, Christian Weisgerber wrote:
> On 2016-08-19, Stuart Henderson wrote:
>
>> The chroot support is currently optional, but you do need to create the
>> user accounts if sysmerge didn't do it for you (_pbuuld, _pfetch), and
>> start dpb as root.
>
> No, running dpb as root is also optional.
true, but then it doesn't switch users to _p{build,fetch}. it runs
as user starting it. Or am I missing a subtlety?
--patrick
Re: DPB can't do it's job in 6.0
patrick keshishian:
> > No, running dpb as root is also optional.
>
> true, but then it doesn't switch users to _p{build,fetch}. it runs
> as user starting it.
That is correct.
Setting up your system so that dpb switches to different users is
great for bulk builds but renders ports development more or less
impossible.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: graphics acceleration, DRI2, DRM problem
This is totally fucked up code, but if you like hazard...
I mean that I really just called some random ACPI (aml) methods
not knowing what they should do.
Additionally this code is for my laptop. I have GEFORCE 620M
GPU, so I added this to pcidevs. Another thing is that patched
code recognizes my GPU device through ACPI name
"\\_SB_.PCI0.PEG0.PEGP". I have discovered name when I was
using Linux kernel's module called acpi_call. Other laptops
may have differently named GPUs.
You use this at your own risk and you must *not* report bugs
to Project when using patched kernel.
File: GENERIC Status: Locally Modified
Working revision:1.427
Repository revision: 1.427 /cvs/src/sys/arch/amd64/conf/GENERIC,v
Commit Identifier: xNzAQvg5oqM2b0pn
File: acpi.cStatus: Locally Modified
Working revision:1.313
Repository revision: 1.313 /cvs/src/sys/dev/acpi/acpi.c,v
Commit Identifier: h0GHFDGWnEdswfbK
File: dsdt.cStatus: Locally Modified
Working revision:1.223
Repository revision: 1.223 /cvs/src/sys/dev/acpi/dsdt.c,v
Commit Identifier: SBTJg3diM8lXHXRE
File: files.pci Status: Locally Modified
Working revision:1.324
Repository revision: 1.324 /cvs/src/sys/dev/pci/files.pci,v
Commit Identifier: aeD3LK9Qomrjecge
File: pcidevs Status: Locally Modified
Working revision:1.1802
Repository revision: 1.1802 /cvs/src/sys/dev/pci/pcidevs,v
Commit Identifier: ZupaPoe9OBu6iKll
File: pcidevs.h Status: Locally Modified
Working revision:1.1796
Repository revision: 1.1796 /cvs/src/sys/dev/pci/pcidevs.h,v
Commit Identifier: Z3aUcOQiFLoINK6d
File: pcidevs_data.hStatus: Locally Modified
Working revision:1.1791
Repository revision: 1.1791 /cvs/src/sys/dev/pci/pcidevs_data.h,v
Commit Identifier: Z3aUcOQiFLoINK6d
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.427
diff -u -p -r1.427 GENERIC
--- sys/arch/amd64/conf/GENERIC 3 Aug 2016 17:23:38 - 1.427
+++ sys/arch/amd64/conf/GENERIC 19 Aug 2016 21:31:07 -
@@ -11,7 +11,7 @@
machineamd64
include"../../../conf/GENERIC"
-maxusers 80 # estimated number of users
+maxusers 100 # estimated number of users
option USER_PCICONF# user-space PCI configuration
@@ -22,10 +22,14 @@ option MTRR# CPU memory range
attribu
#optionKGDB# Remote debugger support; exclusive of
DDB
#option"KGDB_DEVNAME=\"com\"",KGDBADDR=0x2f8,KGDBRATE=9600
-option NTFS# NTFS support
+#optionNTFS# NTFS support
option HIBERNATE # Hibernate support
+
+option HZ=300
+
config bsd swap generic
+#optionDEBUG
mainbus0 at root
@@ -399,6 +403,7 @@ adw*at pci? # AdvanSys
ULTRA WIDE SC
pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI
#trm* at pci? # Tekram DC-3x5U SCSI Controllers
vmwpvs*at pci? # VMware ParaVirtual SCSI
+nvdsbl* at pci? # Nvidia PCI Driver for disabling
nvme* at pci? # NVMe controllers
scsibus* at scsi?
Index: sys/dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.313
diff -u -p -r1.313 acpi.c
--- sys/dev/acpi/acpi.c 28 Jul 2016 21:57:56 - 1.313
+++ sys/dev/acpi/acpi.c 19 Aug 2016 21:31:44 -
@@ -562,11 +562,11 @@ acpi_getpci(struct aml_node *node, void
{
const char *pcihid[] = { ACPI_DEV_PCIB, ACPI_DEV_PCIEB, "HWP0002", 0 };
struct acpi_pci *pci, *ppci;
- struct aml_value res;
+ struct aml_value res,res2;
struct acpi_softc *sc = arg;
pci_chipset_tag_t pc = NULL;
pcitag_t tag;
- uint64_t val;
+ uint64_t val,val2;
uint32_t reg;
if (!node->value || node->value->type != AML_OBJTYPE_DEVICE)
@@ -620,6 +620,35 @@ acpi_getpci(struct aml_node *node, void
pci->bus, pci->dev, pci->fun,
aml_nodename(node));
+
+ bool czyNvidiaGPU = false;
+if (!(strcmp("\\_SB_.PCI0.PEG0.PEGP",aml_nodename(node
+czyNvidiaGPU = true;
+
+if (czyNvidiaGPU) {
+printf("bedzie evalname na GPU\n");
+bool czyPoprawnieName = false;
+if(aml_evalname(sc, node, "_OFF", 0, NULL, &res2)){
+printf("evalname na GPU true\n");
+czyPoprawnieName = true;
+aml_freevalue(&res2);
+} else {
+prin
Re: graphics acceleration, DRI2, DRM problem
Lampshade wrote: > This is totally fucked up code, but if you like hazard... > I mean that I really just called some random ACPI (aml) methods > not knowing what they should do. > +#Acer Optimus nvdsbl disable nvidia gpu PCI > +device nvdsbl > +attach nvdsbl at pci > +filedev/pci/nvdsbl.c can you include this file? and any new .h files as well?
Re: Upgrading from 5.8 to 5.9: Can't install patches
> On 2016/08/19 14:48, Jay Hart wrote: >> >> Thank You Stuart. I can get moving ahead and will file this as a new process >> moving forward. >> >> One last item: When sysmerge ran the only 'file' it came up with to merge >> was the cert file. I installed the new temp file as presented to me. Are there other files I need to check? Did I do >> right? > > In most cases, if you didn't edit a config file, sysmerge can update it > automatically without you having to do anything, so there aren't usually many to merge by hand. Do check over the upgrade notes if you haven't already though. > > Are the upgrade notes (referenced above) the notes associated on the openbsd page for upgrading say, from 5.8 to 5.9? I noticed there are a significant number of patches that require a kernel rebuild. Can I apply all patches and then do one kernel compile at the end? If I go this route, I assume I need to apply/compile all the patches that do not require a kernel compile, then do the one kernel compile last? I usually just install the patches as they come out (usually don't have 25 to do), hence why I'm asking. I'm currently compiling patch #2, and would like to avoid a very lengthy process. DDclient: sysmerge stated I needed to check the config file. I noticed that the user may be different from original user (I have to check this) but I consider this a minor item I can deal with in a few days. Reboot will take care of short-term issues, if any... Many thanks for answering my questions. Jay
Re: graphics acceleration, DRI2, DRM problem
> > +filedev/pci/nvdsbl.c
>
> can you include this file? and any new .h files as well?
I think that this was just for registering a dummy driver
for that Nvidia device. It does nothing useful itself.
# cat /usr/src/sys/dev/pci/nvdsbl.c
/* $OpenBSD: nvdsbl.c,v 0.1 2015/07/28 12:00:01 somebody Exp $ */
/*
* Driver changes power state / disables Nvidia GPU
*/
#include
#include
#include
#include
#include
#include
struct nvdsbl_softc {
struct device dev;
struct pci_attach_args nvdsbl_pa;
};
int nvdsbl_probe(struct device *, void *, void *);
void nvdsbl_attach(struct device *, struct device *, void *);
struct cfattach nvdsbl_ca = {
sizeof(struct nvdsbl_softc), nvdsbl_probe, nvdsbl_attach, NULL, NULL
};
struct cfdriver nvdsbl_cd = {
NULL, "nvdsbl", DV_DULL
};
static const struct pci_matchid nvdsbl_devices[] = {
{ 0x10de, 0x1140 }
};
int
nvdsbl_probe(struct device *parent, void *match, void *aux)
{
pci_matchbyid((struct pci_attach_args
*)aux,nvdsbl_devices,nitems(nvdsbl_devices));
}
void
nvdsbl_attach(struct device *parent, struct device *self, void *aux)
{
printf("inside pci nvdsbl attach\n");
}
Re: graphics acceleration, DRI2, DRM problem
I think that actual, real job is done by: aml_evalname(sc, node, "_OFF", 0, NULL, &res2) or aml_evalinteger(sc, node, "_OFF", 0, NULL, &val2) inside acpi.c file. The only good thing about this patch is that it works for me.
