Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
Probably worth mentioning here, since it's apparently not obvious enough: Changing everything all at once can never be progress - and "discussions" with that aim are noise, at best (wholesale destruction if attempted). -- Raul On Tue, Jan 30, 2024 at 11:09 AM Bruce Jagid wrote: > > If you actually thought you knew what you were talking about, you wouldn’t > feel the need to insert “I’m not an OS Dev” after everything you say > > On Tue, Jan 30, 2024 at 11:05 AM wrote: > > > oh, Theo, if I were to start changing thing to the perfect OS > > security-wise, > > it wouldn't even look like OpenBSD code anymore, but OpenBSD still best > > what > > world have to offer > > > > so do you agree with my logic? at least give me that > > at least tell me is this how things stand FD-wise/limit-wise/whatever, you > > probably know the best out of all I e-mailed with > > > > no attempt yet,in future I hope,it's not a I am too lazy reason > > > > On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote: > > > beecdadd...@danwin1210.de wrote: > > > > > >> I know system shares all resources including FDs > > >> as far as I know there's what kernel/OS needs and is using and the rest > > of > > >> users including but not limited to staff and daemon users/programs like > > >> i2pd all I was wondering is the limit or amount of FDs and other > > resources > > >> the rest of users of daemon can use in my head is a total amount which > > >> apparently is unknown (I have been told why, but how can anyone work > > with > > >> that? it's like relying on someone mentally unstable) which is then > > devided, > > >> kernel/OS gets all that it needs, users and daemons get the rest which > > IS > > >> DIVIDED (in my head) until there is no more to > > >> divide/give away/share am I close? > > >> > > >> okay maybe not make all available resources to 1 program is not how it > > >> works but why not if that's the only programs that's running? I do not > > >> understand if it's even possible to do what I'm asking or questioning, > > I am > > >> not a OS dev because of reasons, but I like discussing such because I > > like > > >> OS-dev > > >> > > >> > > >> and just because what I ask isn't how it works doesn't mean it's bad? it > > >> could mean > > > > > > You've been provided with all the source code. > > > > > > > > > Where is your attempt to change things? > > > > > > > > > > > > > > >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
I don't know, I told you, all I worked with are what you guys told me, what made sense and what I could found online I did not read code because I am not OS dev and don't have as much time as I would like, so this is the best I could do, Theo didn't tell me if I was wrong or right, he told me to make changes to source code and he is out.. does that mean I am right or to just read source code? I maybe make no sense always, but neither do you guys I am as friendly as I can be, I said what I tried and didn't try, and who I am and who I am not - best regards, I hope we can make friendships regardless of out differences and knowledge, enemies are easy to make On Tue, January 30, 2024 4:08 pm, Bruce Jagid wrote: > If you actually thought you knew what you were talking about, you wouldn’t > feel the need to insert “I’m not an OS Dev” after everything you say > > On Tue, Jan 30, 2024 at 11:05 AM wrote: > > >> oh, Theo, if I were to start changing thing to the perfect OS security-wise, >> it wouldn't even look like OpenBSD code anymore, but OpenBSD still best >> what world have to offer >> >> so do you agree with my logic? at least give me that at least tell me is >> this how things stand FD-wise/limit-wise/whatever, you probably know the >> best out of all I e-mailed with >> >> no attempt yet,in future I hope,it's not a I am too lazy reason >> >> On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote: >> >>> beecdadd...@danwin1210.de wrote: >>> I know system shares all resources including FDs as far as I know there's what kernel/OS needs and is using and the rest >> of users including but not limited to staff and daemon users/programs like i2pd all I was wondering is the limit or amount of FDs and other >> resources the rest of users of daemon can use in my head is a total amount which apparently is unknown (I have been told why, but how can anyone work >> with that? it's like relying on someone mentally unstable) which is then >> devided, kernel/OS gets all that it needs, users and daemons get the rest which >> IS >> DIVIDED (in my head) until there is no more to divide/give away/share am I close? okay maybe not make all available resources to 1 program is not how it works but why not if that's the only programs that's running? I do not understand if it's even possible to do what I'm asking or questioning, >> I am >> not a OS dev because of reasons, but I like discussing such because I >> like OS-dev and just because what I ask isn't how it works doesn't mean it's bad? it could mean >>> >>> You've been provided with all the source code. >>> >>> >>> >>> Where is your attempt to change things? >>> >>> >>> >>> >> >> >> >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
If you actually thought you knew what you were talking about, you wouldn’t feel the need to insert “I’m not an OS Dev” after everything you say On Tue, Jan 30, 2024 at 11:05 AM wrote: > oh, Theo, if I were to start changing thing to the perfect OS > security-wise, > it wouldn't even look like OpenBSD code anymore, but OpenBSD still best > what > world have to offer > > so do you agree with my logic? at least give me that > at least tell me is this how things stand FD-wise/limit-wise/whatever, you > probably know the best out of all I e-mailed with > > no attempt yet,in future I hope,it's not a I am too lazy reason > > On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote: > > beecdadd...@danwin1210.de wrote: > > > >> I know system shares all resources including FDs > >> as far as I know there's what kernel/OS needs and is using and the rest > of > >> users including but not limited to staff and daemon users/programs like > >> i2pd all I was wondering is the limit or amount of FDs and other > resources > >> the rest of users of daemon can use in my head is a total amount which > >> apparently is unknown (I have been told why, but how can anyone work > with > >> that? it's like relying on someone mentally unstable) which is then > devided, > >> kernel/OS gets all that it needs, users and daemons get the rest which > IS > >> DIVIDED (in my head) until there is no more to > >> divide/give away/share am I close? > >> > >> okay maybe not make all available resources to 1 program is not how it > >> works but why not if that's the only programs that's running? I do not > >> understand if it's even possible to do what I'm asking or questioning, > I am > >> not a OS dev because of reasons, but I like discussing such because I > like > >> OS-dev > >> > >> > >> and just because what I ask isn't how it works doesn't mean it's bad? it > >> could mean > > > > You've been provided with all the source code. > > > > > > Where is your attempt to change things? > > > > > > > > >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
I'm out of here. beecdadd...@danwin1210.de wrote: > oh, Theo, if I were to start changing thing to the perfect OS security-wise, > it wouldn't even look like OpenBSD code anymore, but OpenBSD still best what > world have to offer > > so do you agree with my logic? at least give me that > at least tell me is this how things stand FD-wise/limit-wise/whatever, you > probably know the best out of all I e-mailed with > > no attempt yet,in future I hope,it's not a I am too lazy reason > > On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote: > > beecdadd...@danwin1210.de wrote: > > > >> I know system shares all resources including FDs > >> as far as I know there's what kernel/OS needs and is using and the rest of > >> users including but not limited to staff and daemon users/programs like > >> i2pd all I was wondering is the limit or amount of FDs and other resources > >> the rest of users of daemon can use in my head is a total amount which > >> apparently is unknown (I have been told why, but how can anyone work with > >> that? it's like relying on someone mentally unstable) which is then > >> devided, > >> kernel/OS gets all that it needs, users and daemons get the rest which IS > >> DIVIDED (in my head) until there is no more to > >> divide/give away/share am I close? > >> > >> okay maybe not make all available resources to 1 program is not how it > >> works but why not if that's the only programs that's running? I do not > >> understand if it's even possible to do what I'm asking or questioning, I am > >> not a OS dev because of reasons, but I like discussing such because I like > >> OS-dev > >> > >> > >> and just because what I ask isn't how it works doesn't mean it's bad? it > >> could mean > > > > You've been provided with all the source code. > > > > > > Where is your attempt to change things? > > > > > > > >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
oh, Theo, if I were to start changing thing to the perfect OS security-wise, it wouldn't even look like OpenBSD code anymore, but OpenBSD still best what world have to offer so do you agree with my logic? at least give me that at least tell me is this how things stand FD-wise/limit-wise/whatever, you probably know the best out of all I e-mailed with no attempt yet,in future I hope,it's not a I am too lazy reason On Tue, January 30, 2024 3:58 pm, Theo de Raadt wrote: > beecdadd...@danwin1210.de wrote: > >> I know system shares all resources including FDs >> as far as I know there's what kernel/OS needs and is using and the rest of >> users including but not limited to staff and daemon users/programs like >> i2pd all I was wondering is the limit or amount of FDs and other resources >> the rest of users of daemon can use in my head is a total amount which >> apparently is unknown (I have been told why, but how can anyone work with >> that? it's like relying on someone mentally unstable) which is then devided, >> kernel/OS gets all that it needs, users and daemons get the rest which IS >> DIVIDED (in my head) until there is no more to >> divide/give away/share am I close? >> >> okay maybe not make all available resources to 1 program is not how it >> works but why not if that's the only programs that's running? I do not >> understand if it's even possible to do what I'm asking or questioning, I am >> not a OS dev because of reasons, but I like discussing such because I like >> OS-dev >> >> >> and just because what I ask isn't how it works doesn't mean it's bad? it >> could mean > > You've been provided with all the source code. > > > Where is your attempt to change things? > > >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
beecdadd...@danwin1210.de wrote: > I know system shares all resources including FDs > as far as I know there's what kernel/OS needs and is using and the rest of > users including but not limited to staff and daemon users/programs like i2pd > all I was wondering is the limit or amount of FDs and other resources the rest > of users of daemon can use > in my head is a total amount which apparently is unknown (I have been told > why, but how can anyone work with that? it's like relying on someone mentally > unstable) which is then devided, kernel/OS gets all that it needs, users and > daemons get the rest which IS DIVIDED (in my head) until there is no more to > divide/give away/share > am I close? > > okay maybe not make all available resources to 1 program is not how it works > but why not if that's the only programs that's running? > I do not understand if it's even possible to do what I'm asking or > questioning, I am not a OS dev because of reasons, but I like discussing such > because I like OS-dev > > and just because what I ask isn't how it works doesn't mean it's bad? it could > mean You've been provided with all the source code. Where is your attempt to change things?
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
I know system shares all resources including FDs as far as I know there's what kernel/OS needs and is using and the rest of users including but not limited to staff and daemon users/programs like i2pd all I was wondering is the limit or amount of FDs and other resources the rest of users of daemon can use in my head is a total amount which apparently is unknown (I have been told why, but how can anyone work with that? it's like relying on someone mentally unstable) which is then devided, kernel/OS gets all that it needs, users and daemons get the rest which IS DIVIDED (in my head) until there is no more to divide/give away/share am I close? okay maybe not make all available resources to 1 program is not how it works but why not if that's the only programs that's running? I do not understand if it's even possible to do what I'm asking or questioning, I am not a OS dev because of reasons, but I like discussing such because I like OS-dev and just because what I ask isn't how it works doesn't mean it's bad? it could mean - best regards, my man On Tue, January 30, 2024 3:45 pm, Theo de Raadt wrote: > beecdadd...@danwin1210.de wrote: > >> maybe not automatically, but having a utility that does this for you and >> you can run it once after each hardare change to find out, but I am not sure >> you say it depends on use-case, I do not understand what you mean >> >> if you read my earlier replies, you would find out that I said I already >> tried searching online for like 1 hour, there is some sort of crazy formula >> one dude did a lot of math, snipets from code, is that what you mean? because >> what you say sound like there are multiple types of FDs, maybe network FDs >> and normal FDs? > > > You are failing to understand the operating system is intending to be a > "sharing" environment -- it is sharing limited resources among multiple > consumers. > > A large number of heuristics exist to defend this sharing, rather than > making resources available to just the 1 piece of software you want. > > What you want isn't how it works. > > > > >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
beecdadd...@danwin1210.de wrote: > maybe not automatically, but having a utility that does this for you and you > can run it once after each hardare change to find out, but I am not sure you > say it depends on use-case, I do not understand what you mean > > if you read my earlier replies, you would find out that I said I already tried > searching online for like 1 hour, there is some sort of crazy formula one dude > did a lot of math, snipets from code, is that what you mean? > because what you say sound like there are multiple types of FDs, maybe network > FDs and normal FDs? You are failing to understand the operating system is intending to be a "sharing" environment -- it is sharing limited resources among multiple consumers. A large number of heuristics exist to defend this sharing, rather than making resources available to just the 1 piece of software you want. What you want isn't how it works.
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
human body changes: different energy levels, tiredness, soar muscle, andrenaline, weight of curls, type of curl like you said computer has same exact hardware every time unless changed like I mentioned nothing changes most servers have different and changing software programs on it, yes but we are talking about system hard limit, not soft limits, the hard limit should stay the same of course you're done, you make no sense to me maybe because you know more or you maybe misunderstand me I think this is far too off-topic and not for ports@ but let's end this topic so I can go maybe to tech@ and misc@ On Tue, January 30, 2024 3:39 pm, Bruce Jagid wrote: > no, YOU know more or less based on earlier curls, just like YOU know more or > less based on other programs you’ve run on your OS. And that guess would be > incredibly inaccurate. You can’t just ask for a concrete hard limit and then > relax the conditions such that it becomes a guesstimate. You don’t even > believe your own bs, I’m done arguing. > > On Tue, Jan 30, 2024 at 10:33 AM wrote: > > >> On Tue, January 30, 2024 3:25 pm, Bruce Jagid wrote: >> I'm also not a OS dev cannot the OS do some testing/benchmarking >to get a grasp on what the >>> limit could be? YOU are the OS in your example, and you >would know the limit >> when you >>> would do curls slower and maybe you would get more >and more pain.. and crash in >> your example would be your >muscle being in such pain you >>> wouldn't be able to do anything with your >arm/whatever >>> >>> So your body automatically benchmarks how many bicep curls you can do in >>> >> an >>> hour without you having to think about it? You use your body to measure >> the >>> bicep curls it can do, it doesn’t automatically do that. You can use >> your OS >>> to perform the benchmark, but to expect the OS to designate resources >>> automatically to benchmark itself is equal portions naïve and obtuse. >> You have >> >>> a very specific use-case, you should do the work to find your answer. >> >> it can know limit more-less, yes, based on earlier curls >> >> maybe not automatically, but having a utility that does this for you and you >> can run it once after each hardare change to find out, but I am not sure >> you say it depends on use-case, I do not understand what you mean >> >> if you read my earlier replies, you would find out that I said I already >> tried searching online for like 1 hour, there is some sort of crazy formula >> one dude did a lot of math, snipets from code, is that what you mean? because >> what you say sound like there are multiple types of FDs, maybe network FDs >> and normal FDs? >> >> - best regards >> >> >>> >>> >>> On Tue, Jan 30, 2024 at 10:20 AM wrote: >>> >>> >>> I'm also not a OS dev cannot the OS do some testing/benchmarking to get a grasp on what the >> limit could be? YOU are the OS in your example, and you would know the limit >> when you would do curls slower and maybe you would get more and more pain.. >> and crash in your example would be your muscle being in such pain you >> wouldn't be able to do anything with your arm/whatever so you're saying the only fucking way to know a true hardware limit is >> the worst that could be - a crash??? what if crash doesn't happen right >> away? in my case hardware ISP router could be limiting the potential of i2pd >> software or torrenting software boom corrupted data, processes, uncompleted >> important work, lost important work, pain in ass, etc literally couldn't that >> corrupt the entire system, a crash? tell me I am worrying too much, but even then a crash is the worst thing someone can rely on, I think it's unprofessional that the OS allows for >> that sort of insecurity if all you said and I said is correct, I consider >> that to be a security vulnerability at least, not to mention other vulnerabilities On Tue, January 30, 2024 1:32 pm, Bruce Jagid wrote: like I asked and no one answered: where >>>can I check HARD LIMIT of my computer? >>> >>> you can't really. you can try increasing >>until you run into >>> problems > and back >>> off a bit, but it probably depends on what >>else the kernel is >>> doing. > usual >>> approach is to restrict the software to >>using the resources >>> that you > expect it >>> to actually need and restrict it from making >>more demands than >>> that >>> to > orotect >>> the rest of the system. > >> this sounds like a bug to me hard limit must be known, else is like >> playing >>> cards, you never know when > you >> lose (you crash) and no one answered my question yet about >i2pd's >> connections to other > routhers >> with can well surpass 8192 up to +3 >connections, and if I am >>
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
I'm sorry, it felt applicable reasons outside of OpenBSD I got no problem with swearing back at me I felt kernel crashes are off-topic, I thought it would be fine because I didn't know it would go for so long this topic of course it is not your problem me crashing non-OpenBSD el-cheapo home router, but OpenBSD guys know networking and maybe routers the best, and maybe benefit others, do I do this on misc@ ? On Tue, January 30, 2024 3:26 pm, Ian Darwin wrote: > On 1/30/24 10:20, beecdadd...@danwin1210.de wrote: > >> so you're saying the only fucking way to know a true hardware limit is the >> worst that could be - a crash??? > > Once you start swearing, most people will tune you out. Others will > swear back at you. > > Neither is very productive. > > > Anyway, discussion of kernel crashes belongs on tech@, and discussion of > crashing your non-OpenBSD el-cheapo home router is not our problem anyway. >
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
On Tue, January 30, 2024 3:25 pm, Bruce Jagid wrote: >> I'm also not a OS dev >> cannot the OS do some testing/benchmarking >to get a grasp on what the > limit >> could be? YOU are the OS in your example, and you >would know the limit when >> you > would do >> curls slower and maybe you would get more >and more pain.. and crash in your >> example would be your >muscle being in such pain you > wouldn't >> be able to do anything with your >arm/whatever > > So your body automatically benchmarks how many bicep curls you can do in an > hour without you having to think about it? You use your body to measure the > bicep curls it can do, it doesn’t automatically do that. You can use your OS > to perform the benchmark, but to expect the OS to designate resources > automatically to benchmark itself is equal portions naïve and obtuse. You have > a very specific use-case, you should do the work to find your answer. it can know limit more-less, yes, based on earlier curls maybe not automatically, but having a utility that does this for you and you can run it once after each hardare change to find out, but I am not sure you say it depends on use-case, I do not understand what you mean if you read my earlier replies, you would find out that I said I already tried searching online for like 1 hour, there is some sort of crazy formula one dude did a lot of math, snipets from code, is that what you mean? because what you say sound like there are multiple types of FDs, maybe network FDs and normal FDs? - best regards > > > On Tue, Jan 30, 2024 at 10:20 AM wrote: > > >> I'm also not a OS dev >> cannot the OS do some testing/benchmarking to get a grasp on what the limit >> could be? YOU are the OS in your example, and you would know the limit when >> you would do curls slower and maybe you would get more and more pain.. and >> crash in your example would be your muscle being in such pain you wouldn't be >> able to do anything with your arm/whatever >> >> so you're saying the only fucking way to know a true hardware limit is the >> worst that could be - a crash??? what if crash doesn't happen right away? in >> my case hardware ISP router could be limiting the potential of i2pd software >> or torrenting software boom corrupted data, processes, uncompleted important >> work, lost important work, pain in ass, etc literally couldn't that corrupt >> the entire system, a crash? >> >> tell me I am worrying too much, but even then a crash is the worst thing >> someone can rely on, I think it's unprofessional that the OS allows for that >> sort of insecurity if all you said and I said is correct, I consider that >> to be a security vulnerability at least, not to mention other >> vulnerabilities >> >> On Tue, January 30, 2024 1:32 pm, Bruce Jagid wrote: >> >> >> >> like I asked and no one answered: where >>>can I check HARD LIMIT >> of >> my >> computer? > > you can't really. you can try increasing >>until you run into > problems >>> and back > off a bit, but it probably depends on what >>else the kernel is > doing. >>> usual > approach is to restrict the software to >>using the resources that > you >>> expect it > to actually need and restrict it from making >>more demands than that > >> to >>> orotect > the rest of the system. >>> this sounds like a bug to me hard limit must be known, else is like >> playing > cards, you never know when >>> you lose (you crash) and no one answered my question yet about >i2pd's connections to other >>> routhers with can well surpass 8192 up to +3 >connections, and if I am right >>> then each connection needs a FD? I worked with >networking and programming a >>> little, so this makes sense to me can anyone >verify? if yes, then yes this is >> a bug and I am >disappointed that the only way is >>> to run blindly and trust before crash >>> >>> I might be out of line here since I’m new to OS dev stuff, but what >>> >> you’re >>> asking doesn’t really make sense to me. A file descriptor is a software >>> abstraction built onto the hardware and the exact implementation changes >> from >>> case to case dependent on hardware. It’s like if I asked my doctor “give >> me >>> the exact limit of bicep curls I can do in an hour.” In the same way the >> body >>> has no conception of a bicep curl(only the fatigue from moving), the >> hardware >>> doesn’t know what you mean by a file descriptor(only the residual >> resources >>> needed to maintain one), and there’s like 20 ways of doing a bicep curl, >> so >>> demanding such a concrete hard limit number makes no sense. >>> >>> - Bruce >>> >>> >>> >>> On Tue, Jan 30, 2024 at 6:52 AM wrote: >>> >>> >>> On Tue, January 30, 2024 11:23 am, Stuart Henderson wrote: > On 2024/01/30 10:53, beecdadd...@danwin1210.de wrote: > > > >> I see the confusion I made I am sorry, when I said routers crash I >> meant actual ISP
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
>I'm also not a OS dev >cannot the OS do some testing/benchmarking >to get a grasp on what the limit >could be? >YOU are the OS in your example, and you >would know the limit when you would do >curls slower and maybe you would get more >and more pain.. >and crash in your example would be your >muscle being in such pain you wouldn't >be able to do anything with your >arm/whatever So your body automatically benchmarks how many bicep curls you can do in an hour without you having to think about it? You use your body to measure the bicep curls it can do, it doesn’t automatically do that. You can use your OS to perform the benchmark, but to expect the OS to designate resources automatically to benchmark itself is equal portions naïve and obtuse. You have a very specific use-case, you should do the work to find your answer. On Tue, Jan 30, 2024 at 10:20 AM wrote: > I'm also not a OS dev > cannot the OS do some testing/benchmarking to get a grasp on what the limit > could be? > YOU are the OS in your example, and you would know the limit when you > would do > curls slower and maybe you would get more and more pain.. > and crash in your example would be your muscle being in such pain you > wouldn't > be able to do anything with your arm/whatever > > so you're saying the only fucking way to know a true hardware limit is the > worst that could be - a crash??? > what if crash doesn't happen right away? in my case hardware ISP router > could > be limiting the potential of i2pd software or torrenting software > boom corrupted data, processes, uncompleted important work, lost important > work, pain in ass, etc > literally couldn't that corrupt the entire system, a crash? > > tell me I am worrying too much, but even then a crash is the worst thing > someone can rely on, I think it's unprofessional that the OS allows for > that > sort of insecurity > if all you said and I said is correct, I consider that to be a security > vulnerability at least, not to mention other vulnerabilities > > On Tue, January 30, 2024 1:32 pm, Bruce Jagid wrote: > > > like I asked and no one answered: where >>>can I check HARD LIMIT of > my > computer? > >>> > >>> you can't really. you can try increasing >>until you run into problems > > and back > >>> off a bit, but it probably depends on what >>else the kernel is doing. > > usual > >>> approach is to restrict the software to >>using the resources that you > > expect it > >>> to actually need and restrict it from making >>more demands than that > to > > orotect > >>> the rest of the system. > > > >> this sounds like a bug to me hard limit must be known, else is like > playing > >> >cards, you never know when > > you > >> lose (you crash) and no one answered my question yet about >i2pd's > >> connections to other > > routhers > >> with can well surpass 8192 up to +3 >connections, and if I am right > > then > >> each connection needs a FD? I worked with >networking and programming a > > little, > >> so this makes sense to me can anyone >verify? if yes, then yes this is > a bug > >> and I am >disappointed that the only way is > > to > >> run blindly and trust before crash > > > > I might be out of line here since I’m new to OS dev stuff, but what > you’re > > asking doesn’t really make sense to me. A file descriptor is a software > > abstraction built onto the hardware and the exact implementation changes > from > > case to case dependent on hardware. It’s like if I asked my doctor “give > me > > the exact limit of bicep curls I can do in an hour.” In the same way the > body > > has no conception of a bicep curl(only the fatigue from moving), the > hardware > > doesn’t know what you mean by a file descriptor(only the residual > resources > > needed to maintain one), and there’s like 20 ways of doing a bicep curl, > so > > demanding such a concrete hard limit number makes no sense. > > > > - Bruce > > > > > > On Tue, Jan 30, 2024 at 6:52 AM wrote: > > > > > >> On Tue, January 30, 2024 11:23 am, Stuart Henderson wrote: > >> > >>> On 2024/01/30 10:53, beecdadd...@danwin1210.de wrote: > >>> > >>> > I see the confusion I made I am sorry, when I said routers crash I > meant actual ISP hardware routers. > >>> > >>> For an ISP "customer premises equipment" router (home/officr router)? > >>> That often means you made too many connections and exceeded the size of > >>> NAT/firewall state table that they can cope with. Also for ISPs with > >>> CGN, you might have a limited port-range that you're allowed to use and > >>> can't make more connections once that has been exceeded. > >> > >> is there way to verify it's the 1st thing, which can be fixed by custom > >> router, yes? any computer with 2 NICs can be a OpenBSD router, yes? I > seen > >> people do that, is cool > >> > >>> > like I asked and no one answered: where can I check HARD LIMIT of my > computer? > >>> > >>> you can't really. you can try increasing until you run into problems > and > >> back > >>> off
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
I'm also not a OS dev cannot the OS do some testing/benchmarking to get a grasp on what the limit could be? YOU are the OS in your example, and you would know the limit when you would do curls slower and maybe you would get more and more pain.. and crash in your example would be your muscle being in such pain you wouldn't be able to do anything with your arm/whatever so you're saying the only fucking way to know a true hardware limit is the worst that could be - a crash??? what if crash doesn't happen right away? in my case hardware ISP router could be limiting the potential of i2pd software or torrenting software boom corrupted data, processes, uncompleted important work, lost important work, pain in ass, etc literally couldn't that corrupt the entire system, a crash? tell me I am worrying too much, but even then a crash is the worst thing someone can rely on, I think it's unprofessional that the OS allows for that sort of insecurity if all you said and I said is correct, I consider that to be a security vulnerability at least, not to mention other vulnerabilities On Tue, January 30, 2024 1:32 pm, Bruce Jagid wrote: like I asked and no one answered: where >>>can I check HARD LIMIT of my computer? >>> >>> you can't really. you can try increasing >>until you run into problems > and back >>> off a bit, but it probably depends on what >>else the kernel is doing. > usual >>> approach is to restrict the software to >>using the resources that you > expect it >>> to actually need and restrict it from making >>more demands than that to > orotect >>> the rest of the system. > >> this sounds like a bug to me hard limit must be known, else is like playing >> >cards, you never know when > you >> lose (you crash) and no one answered my question yet about >i2pd's >> connections to other > routhers >> with can well surpass 8192 up to +3 >connections, and if I am right > then >> each connection needs a FD? I worked with >networking and programming a > little, >> so this makes sense to me can anyone >verify? if yes, then yes this is a bug >> and I am >disappointed that the only way is > to >> run blindly and trust before crash > > I might be out of line here since I’m new to OS dev stuff, but what you’re > asking doesn’t really make sense to me. A file descriptor is a software > abstraction built onto the hardware and the exact implementation changes from > case to case dependent on hardware. It’s like if I asked my doctor “give me > the exact limit of bicep curls I can do in an hour.” In the same way the body > has no conception of a bicep curl(only the fatigue from moving), the hardware > doesn’t know what you mean by a file descriptor(only the residual resources > needed to maintain one), and there’s like 20 ways of doing a bicep curl, so > demanding such a concrete hard limit number makes no sense. > > - Bruce > > > On Tue, Jan 30, 2024 at 6:52 AM wrote: > > >> On Tue, January 30, 2024 11:23 am, Stuart Henderson wrote: >> >>> On 2024/01/30 10:53, beecdadd...@danwin1210.de wrote: >>> >>> I see the confusion I made I am sorry, when I said routers crash I meant actual ISP hardware routers. >>> >>> For an ISP "customer premises equipment" router (home/officr router)? >>> That often means you made too many connections and exceeded the size of >>> NAT/firewall state table that they can cope with. Also for ISPs with >>> CGN, you might have a limited port-range that you're allowed to use and >>> can't make more connections once that has been exceeded. >> >> is there way to verify it's the 1st thing, which can be fixed by custom >> router, yes? any computer with 2 NICs can be a OpenBSD router, yes? I seen >> people do that, is cool >> >>> like I asked and no one answered: where can I check HARD LIMIT of my computer? >>> >>> you can't really. you can try increasing until you run into problems and >> back >>> off a bit, but it probably depends on what else the kernel is doing. >> usual >>> approach is to restrict the software to using the resources that you >> expect it >>> to actually need and restrict it from making more demands than that to >> orotect >>> the rest of the system. >> >> this sounds like a bug to me hard limit must be known, else is like playing >> cards, you never know when you lose (you crash) and no one answered my >> question yet about i2pd's connections to other routhers with can well surpass >> 8192 up to +3 connections, and if I am right then >> each connection needs a FD? I worked with networking and programming a >> little, so this makes sense to me can anyone verify? if yes, then yes this is >> a bug and I am disappointed that the only way is to run blindly and trust >> before crash >> >>> what it depends on, on CPU? where is utility that shows max FDs, and per-running-process FD usage and their max setting? if this does not >> exist, I think why not? I think if user has to manually set FD limits and know potential of >> programs
Re: (changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
>>> >>> like I asked and no one answered: where >>>can I check HARD LIMIT of my >>> computer? >> >> you can't really. you can try increasing >>until you run into problems and back >> off a bit, but it probably depends on what >>else the kernel is doing. usual >> approach is to restrict the software to >>using the resources that you expect it >> to actually need and restrict it from making >>more demands than that to orotect >> the rest of the system. >this sounds like a bug to me >hard limit must be known, else is like playing >cards, you never know when you >lose (you crash) >and no one answered my question yet about >i2pd's connections to other routhers >with can well surpass 8192 up to +3 >connections, and if I am right then >each connection needs a FD? I worked with >networking and programming a little, >so this makes sense to me can anyone >verify? >if yes, then yes this is a bug and I am >disappointed that the only way is to >run blindly and trust before crash I might be out of line here since I’m new to OS dev stuff, but what you’re asking doesn’t really make sense to me. A file descriptor is a software abstraction built onto the hardware and the exact implementation changes from case to case dependent on hardware. It’s like if I asked my doctor “give me the exact limit of bicep curls I can do in an hour.” In the same way the body has no conception of a bicep curl(only the fatigue from moving), the hardware doesn’t know what you mean by a file descriptor(only the residual resources needed to maintain one), and there’s like 20 ways of doing a bicep curl, so demanding such a concrete hard limit number makes no sense. - Bruce On Tue, Jan 30, 2024 at 6:52 AM wrote: > On Tue, January 30, 2024 11:23 am, Stuart Henderson wrote: > > On 2024/01/30 10:53, beecdadd...@danwin1210.de wrote: > > > >> I see the confusion I made I am sorry, when I said routers crash I meant > >> actual ISP hardware routers. > > > > For an ISP "customer premises equipment" router (home/officr router)? > > That often means you made too many connections and exceeded the size of > > NAT/firewall state table that they can cope with. Also for ISPs with > > CGN, you might have a limited port-range that you're allowed to use and > > can't make more connections once that has been exceeded. > > is there way to verify it's the 1st thing, which can be fixed by custom > router, yes? > any computer with 2 NICs can be a OpenBSD router, yes? I seen people do > that, > is cool > > > > >> like I asked and no one answered: where can I check HARD LIMIT of my > >> computer? > > > > you can't really. you can try increasing until you run into problems and > back > > off a bit, but it probably depends on what else the kernel is doing. > usual > > approach is to restrict the software to using the resources that you > expect it > > to actually need and restrict it from making more demands than that to > orotect > > the rest of the system. > > this sounds like a bug to me > hard limit must be known, else is like playing cards, you never know when > you > lose (you crash) > and no one answered my question yet about i2pd's connections to other > routhers > with can well surpass 8192 up to +3 connections, and if I am right then > each connection needs a FD? I worked with networking and programming a > little, > so this makes sense to me can anyone verify? > if yes, then yes this is a bug and I am disappointed that the only way is > to > run blindly and trust before crash > > > > >> what it depends on, on CPU? where is utility that shows max FDs, and > >> per-running-process FD usage and their max setting? if this does not > exist, > >> I think why not? > >> I think if user has to manually set FD limits and know potential of > programs > >> and OpenBSD and hardware, where is utility to help with that? I did > search > >> on the internet, all shit.. > > > > fstat shows per-process FD use, but the kernel backend for it is a bit > buggy > > and can sometimes crash the kernel, so it is best to avoid running it on > an > > important system. > > > > > > oh really > I probably cannot verify the usage of I2Pd if it exceeds 8192 because my > router goes stupid and crashes, can you? > if you can't I'll give it a try, please tell me if you can.. I would try > increasing bandwidth speed to X and transit tunnels to maybe 10k, try with > a > floodfill maybe, too.. because even many tunnels - there can be many to 1 > i2pd > peer(i2pd router) which translates to 1 FD, right? > and if you go to web console of i2pd and go to Transit Tunnels tab, you > can see > => [some number like ID] 5.0 KiB, and then you see more of same, but the > arrow > '=>' is not there, so that maybe indicates it's the same peer/i2pd router > that > the following tunnels are to/from.. most have 1 tunnel, some have 6 > tunnels, a > lot have 2 tunnels > > but I am not getting FD count with fstat, the number is not the same with > 'Routers' in web console of i2pd, so maybe I was wrong > or
(changed subject) Re: net/i2pd: FD talk and limits and ISP routers too weak maybe
On Tue, January 30, 2024 11:23 am, Stuart Henderson wrote: > On 2024/01/30 10:53, beecdadd...@danwin1210.de wrote: > >> I see the confusion I made I am sorry, when I said routers crash I meant >> actual ISP hardware routers. > > For an ISP "customer premises equipment" router (home/officr router)? > That often means you made too many connections and exceeded the size of > NAT/firewall state table that they can cope with. Also for ISPs with > CGN, you might have a limited port-range that you're allowed to use and > can't make more connections once that has been exceeded. is there way to verify it's the 1st thing, which can be fixed by custom router, yes? any computer with 2 NICs can be a OpenBSD router, yes? I seen people do that, is cool > >> like I asked and no one answered: where can I check HARD LIMIT of my >> computer? > > you can't really. you can try increasing until you run into problems and back > off a bit, but it probably depends on what else the kernel is doing. usual > approach is to restrict the software to using the resources that you expect it > to actually need and restrict it from making more demands than that to orotect > the rest of the system. this sounds like a bug to me hard limit must be known, else is like playing cards, you never know when you lose (you crash) and no one answered my question yet about i2pd's connections to other routhers with can well surpass 8192 up to +3 connections, and if I am right then each connection needs a FD? I worked with networking and programming a little, so this makes sense to me can anyone verify? if yes, then yes this is a bug and I am disappointed that the only way is to run blindly and trust before crash > >> what it depends on, on CPU? where is utility that shows max FDs, and >> per-running-process FD usage and their max setting? if this does not exist, >> I think why not? >> I think if user has to manually set FD limits and know potential of programs >> and OpenBSD and hardware, where is utility to help with that? I did search >> on the internet, all shit.. > > fstat shows per-process FD use, but the kernel backend for it is a bit buggy > and can sometimes crash the kernel, so it is best to avoid running it on an > important system. > > oh really I probably cannot verify the usage of I2Pd if it exceeds 8192 because my router goes stupid and crashes, can you? if you can't I'll give it a try, please tell me if you can.. I would try increasing bandwidth speed to X and transit tunnels to maybe 10k, try with a floodfill maybe, too.. because even many tunnels - there can be many to 1 i2pd peer(i2pd router) which translates to 1 FD, right? and if you go to web console of i2pd and go to Transit Tunnels tab, you can see => [some number like ID] 5.0 KiB, and then you see more of same, but the arrow '=>' is not there, so that maybe indicates it's the same peer/i2pd router that the following tunnels are to/from.. most have 1 tunnel, some have 6 tunnels, a lot have 2 tunnels but I am not getting FD count with fstat, the number is not the same with 'Routers' in web console of i2pd, so maybe I was wrong or maybe i2pd recycles FDs to be much better at efficiency so it has Routers stored addresses somewhere, and makes connections only if needed (which take up FD spots) - best regards, I like talking to you, you care about this and want to help, it can be seen
[no subject]
serioussam-alpha.tar.gz Description: GNU Zip compressed data serioussam.tar.gz Description: GNU Zip compressed data
[no subject]
[no subject]
Hi
[no subject]
Hello,
This updates sam to the latest commit. The changelog is just:
- set dot correctly after applying the < command
- add ssam (streaming sam); no man page :(
- clean up the manpage
Works fine here. I've only briefily played with ssam, but as it just
run sam on a temp file I assume it's fine.
While here also adds it to the editors category and tweak a bit the
post-install target.
ok?
Index: Makefile
===
RCS file: /home/cvs/ports/plan9/sam/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- Makefile11 Mar 2022 19:49:08 - 1.34
+++ Makefile6 Nov 2022 22:01:47 -
@@ -1,12 +1,11 @@
COMMENT= X11 version of Rob Pike's editor, sam
-DISTNAME= sam-4.3.20190427
+DISTNAME= sam-4.3.20200714
GH_ACCOUNT=deadpixi
GH_PROJECT=sam
-GH_COMMIT= 5893679bbbab2f50ceb6ef0805e4bb63f5f51df8
-REVISION= 0
+GH_COMMIT= 5d8acb35d78c327d76f00a54857cbd566ed9bc11
-CATEGORIES=plan9
+CATEGORIES=plan9 editors
PERMIT_PACKAGE=Yes
WANTLIB= X11 Xft Xi Xt c
@@ -15,16 +14,12 @@ RUN_DEPENDS+= devel/desktop-file-utils
NO_TEST= Yes
-SAMDOCDIR= ${PREFIX}/share/doc/sam
-SAMDOCFILES= README.rst doc/sam.ps doc/sam.tut.ms doc/se.ps
-EXAMPLEDIR=${PREFIX}/share/examples/sam
-
post-install:
- ${INSTALL_DATA_DIR} ${SAMDOCDIR}
- ${INSTALL_DATA_DIR} ${EXAMPLEDIR}
- ${INSTALL_DATA} ${WRKSRC}/doc/samrc ${EXAMPLEDIR}
- @set -e; for f in ${SAMDOCFILES}; do \
-${INSTALL_DATA} ${WRKSRC}/$${f} ${SAMDOCDIR}; \
- done
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/sam
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/sam
+ ${INSTALL_DATA} ${WRKSRC}/doc/samrc ${PREFIX}/share/examples/sam
+.for f in README.rst doc/sam.ps doc/sam.tut.ms doc/se.ps
+ ${INSTALL_DATA} ${WRKSRC}/$f ${PREFIX}/share/doc/sam
+.endfor
.include
Index: distinfo
===
RCS file: /home/cvs/ports/plan9/sam/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo12 Nov 2019 02:45:32 - 1.5
+++ distinfo6 Nov 2022 19:27:08 -
@@ -1,2 +1,2 @@
-SHA256 (sam-4.3.20190427-5893679b.tar.gz) =
17k1wL+Rv5Z43t79sLyj0Vn9UYzSVfpVxOYZNiAfB0E=
-SIZE (sam-4.3.20190427-5893679b.tar.gz) = 311827
+SHA256 (sam-4.3.20200714-5d8acb35.tar.gz) =
hlWbfWSzWijxfBUOvrhO4HZp3mtO1ct4Bfj6zVRyRlo=
+SIZE (sam-4.3.20200714-5d8acb35.tar.gz) = 312453
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/plan9/sam/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST 11 Mar 2022 19:49:08 - 1.7
+++ pkg/PLIST 6 Nov 2022 19:40:00 -
@@ -1,6 +1,7 @@
@bin bin/B
@bin bin/sam
@bin bin/samterm
+bin/ssam
@man man/man1/sam.1
@man man/man5/samrc.5
share/applications/deadpixi-sam.desktop
[no subject]
Hello HDL programmers and porters, I am on my way to get cocotb [1] ported [2] to OpenBSD. UVM is the popular hardware verification library, but requires full SystemVerilog support, only available on proprietary tools. Cocotb requires python3, is in widespread and supports most open hardware simulators. Feel free to join the discussion here as well as upstream. All the best! Josuah. [1]: https://cocotb.org/ [2]: https://github.com/cocotb/cocotb/pull/3028
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Tue, Jan 25, 2022 at 11:22:50AM +, Stuart Henderson wrote: > On 2022/01/24 19:11, Dima Pasechnik wrote: > > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > > > On 2022/01/24 15:51, Dima Pasechnik wrote: > > > > Would a git-generated email with a diff be acceptable? > > > > https://git-send-email.io/ > > > > > > Yes as long as it's not one of those big [1/n] sequences of separate > > > emails that would be better dealt with in a single mail :) > > > > > > > In principle, such a patch would be very easy to apply (with git) > > > > to your local git repo - and it can be bounced to appropriately > > > > configured CI... > > > > > > Applying it with git isn't useful for someone who is going to commit > > > it to cvs because (even if they use a mixture of git/got+cvs themselves) > > > it still needs to get into their cvs checkout. > > > > I'm guessing here, but can't you overlay CVS and git trees? > > If it's possible then merging with git will produce a CVS diff. > > While you can sort-of do that for the odd directory, you can't do that > for a whole tree, updates won't work. And git doesn't allow partial > checkouts/updates. > > (this is one of the biggest problems I would have with any change to > using git in the ports tree actually; if I am working on a port which > has received a change since my last work, I want to be able to just > fix conflicts in the directories I care about and _not_ be messing > with the whole rest of the tree at that time). Working on some kind of semi-updated tree, yuck. I think that outlines one of big CVS hiccups pretty well, for I really cannot see how this can be a problem if working with git, as updates would just merge nicely in git. > > > > What would you propose a CI to do for ports submissions? > > > > building (maybe testing too) the new/updated port only, just on amd64, as a > > start. > > That's not amazingly useful as the submitter already needed to build > it. They built it on their machine, not on something surely nice and clean. > And a test build of a port is going to require root access in > order to install dependencies which is not ideal for something where > a run can be triggered by a random submission. Why? It's run on something that is empherical. Another CI run would be in a new, clean environment, anyway. That's how modern CI works. Best Dima >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/26 17:41, Damien Miller wrote: > On Fri, 21 Jan 2022, joshua stein wrote: > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > I'm late to the party (as usual), but we've been doing this for a while > in OpenSSH - we'll review pull requests on github and have one of the > developers do the final tidying and commit to CVS. I can certainly see this working for some areas of OpenBSD. Especially more defined areas where primarily a smaller group of people handle most diffs going in, and where the mechanics of getting something committed account for a small part of the overall time taken to handle a submission. i.e. a higher % of the overall time is taken for review etc than with the mechanics of committing than is often the case for ports. In particular I think it's the case for OpenSSH where the vast majority of people using it are not OpenBSD users at all. > It's worked pretty well, and the quality of submissions is about as > good as we get from other outside sources. I believe it's allowed > a number of people who would otherwise not have contributed to do so, > since the tools are familiar and the hassle factor is so much lower. Ports by its nature needs domain-specific knowledge to successfully prepare an update. Nothing difficult, just some things to learn and do. Things like bumping revision numbers when changes are made, regenerating plists to pick up new files, looking for ABI changes in shared libraries, working on -current. In the context of that, putting the diff in an email rather than in a github PR isn't a high extra hurdle,
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, 21 Jan 2022, joshua stein wrote: > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). I'm late to the party (as usual), but we've been doing this for a while in OpenSSH - we'll review pull requests on github and have one of the developers do the final tidying and commit to CVS. It's worked pretty well, and the quality of submissions is about as good as we get from other outside sources. I believe it's allowed a number of people who would otherwise not have contributed to do so, since the tools are familiar and the hassle factor is so much lower. -d
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Tue, Jan 25, 2022 at 04:42:28AM +, Yifei Zhan wrote: > However I'm more concerned about the mailing part of the process, > since problems in it can't be easily detected on sender's machine > (some mailhosters would mangle inline patches when sending to other > hosts (Protonmail once had this problem, not sure if they fixed it > now)), and there is no undo botton for this list. > I remember setting up my email client was a PITA and Thunderbird would > mangle my patch no matter what, solene@ helped me testing my patch > many times until the whole setup finally worked. > Perhaps there can be a loopback address e.g. test-loopb...@openbsd.org > which just check if the patch can be applied and not mangled. Send it to yourself through your mailer. Use the patch you receive. If it doesn't work, don't send it to the lists, keep fixing your email client. I can't take credit for this idea, stsp@ mentioned it in his talk about device driver development. --Kurt
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Tue, Jan 25, 2022, at 4:36 AM, Stuart Henderson wrote: > On 2022/01/24 11:42, Aaron Bieber wrote: >> Another issue is having a ports tree in the "runner".. a git checkout is >> large, but maybe since it would be "local" to github it wouldn't be >> _that_ bad?.. but a cvs checkout would be way to slow. > > A cvs checkout of the ports tree from anoncvs over my home internet > connection takes 3 minutes. In that case the client is an 8 year old > machine with SATA SSD, server HDD (though the tree is probably mostly > in cache on the server). > > I don't think is _way_ too slow when a build could easily take hours > and often 10-20 minutes. > > On a better connected machine that should be at least a bit better too. > > btw git clone from github on the same client machine takes about 5 > minutes. Now try from github infra to github infra - I haven’t done any tests but I bet it’s faster than going over the internet. cvs checkout does use less disk space though.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/25 05:10, Yifei Zhan wrote: > > Another issue is having a ports tree in the "runner".. a git checkout is > > large, but maybe since it would be "local" to github it wouldn't be > > _that_ bad?.. but a cvs checkout would be way to slow. > > I think checking out a fresh git tree is alright, but we can only have > ~8G of usable space for building. Should be enough for smaller ports, > but unsure about the larger ones... That is not enough space to install dependencies for some medium sized ports, let alone build them.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 11:42, Aaron Bieber wrote: > Another issue is having a ports tree in the "runner".. a git checkout is > large, but maybe since it would be "local" to github it wouldn't be > _that_ bad?.. but a cvs checkout would be way to slow. A cvs checkout of the ports tree from anoncvs over my home internet connection takes 3 minutes. In that case the client is an 8 year old machine with SATA SSD, server HDD (though the tree is probably mostly in cache on the server). I don't think is _way_ too slow when a build could easily take hours and often 10-20 minutes. On a better connected machine that should be at least a bit better too. btw git clone from github on the same client machine takes about 5 minutes.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 19:11, Dima Pasechnik wrote: > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > > On 2022/01/24 15:51, Dima Pasechnik wrote: > > > Would a git-generated email with a diff be acceptable? > > > https://git-send-email.io/ > > > > Yes as long as it's not one of those big [1/n] sequences of separate > > emails that would be better dealt with in a single mail :) > > > > > In principle, such a patch would be very easy to apply (with git) > > > to your local git repo - and it can be bounced to appropriately > > > configured CI... > > > > Applying it with git isn't useful for someone who is going to commit > > it to cvs because (even if they use a mixture of git/got+cvs themselves) > > it still needs to get into their cvs checkout. > > I'm guessing here, but can't you overlay CVS and git trees? > If it's possible then merging with git will produce a CVS diff. While you can sort-of do that for the odd directory, you can't do that for a whole tree, updates won't work. And git doesn't allow partial checkouts/updates. (this is one of the biggest problems I would have with any change to using git in the ports tree actually; if I am working on a port which has received a change since my last work, I want to be able to just fix conflicts in the directories I care about and _not_ be messing with the whole rest of the tree at that time). > > What would you propose a CI to do for ports submissions? > > building (maybe testing too) the new/updated port only, just on amd64, as a > start. That's not amazingly useful as the submitter already needed to build it. And a test build of a port is going to require root access in order to install dependencies which is not ideal for something where a run can be triggered by a random submission.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Hi all, Re: fresh blood Can name you quite a few contributors that can be committers today, because they are demoin'g constant input to the project: 1) Caspar Schutijser 2) Wen Heping 3) Dimitri Karamazov There will be still some others I missed but the regular port committers will know, because you commit their contributions. There is nobody to propose for them. Thanks On Fri, Jan 21, 2022 at 11:31 AM Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > We have chronically fewer people who can give okays than ports waiting. > > One big "meta" stuff that needs doing is pointing out (especially from > new guys) what can be improved in the documentation of the porting process... > sometimes pointing people in the right direction. > > Informal poll: what thing weirded you guys out the first time you touched > OpenBSD ports coming from other platforms. > > What kind of gotcha can we get rid of, so that "new ports" will tend to > be squeaky clean, infrastructure-wise, and ready for import. > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > main differences to (say) deb, rpm, freebsd ?... >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Dima Pasechnik writes: > On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: >> On 2022/01/24 15:51, Dima Pasechnik wrote: >> > Would a git-generated email with a diff be acceptable? >> > https://git-send-email.io/ >> >> Yes as long as it's not one of those big [1/n] sequences of separate >> emails that would be better dealt with in a single mail :) >> >> > In principle, such a patch would be very easy to apply (with git) >> > to your local git repo - and it can be bounced to appropriately configured >> > CI... >> >> Applying it with git isn't useful for someone who is going to commit >> it to cvs because (even if they use a mixture of git/got+cvs themselves) >> it still needs to get into their cvs checkout. > > I'm guessing here, but can't you overlay CVS and git trees? > If it's possible then merging with git will produce a CVS diff. > >> >> > > At the moment it's hidden in a page named 'Building the System from >> > > Source', not very clear. Maybe put in on porter's handbook? >> > > >> > > - Some kind of automated pre-submission sanity test would be nice. >> > > Should be simpler than a full CI setup. (is my diff mangled? is my >> > > tree outdated?) >> > The OpenBSD-supporting CI I mentioned in my other email >> > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd >> > would be very easy to set up for this. >> >> What would you propose a CI to do for ports submissions? > > building (maybe testing too) the new/updated port only, just on amd64, as a > start. > > Dima My thought on this is basically: cd /usr/ports/thing/thatchanged && \ portcheck && \ make FETHC_PACKAGES= Also as far as CI "runners" go, this one looks promising: https://github.com/mario-campos/emulate Obviously 7.0 wouldn't be sufficient to do ports testing, but maybe current could be added without much hassle. Another issue is having a ports tree in the "runner".. a git checkout is large, but maybe since it would be "local" to github it wouldn't be _that_ bad?.. but a cvs checkout would be way to slow. > >> >> Identifying and building ports that depend on a particular port and >> doing a build of all of them on a clean -current OpenBSD system could >> be useful in some cases, though complete overkill in most, and would >> take long enough that it would be silly to do before a basic review. >> >> There's another consideration with this. In a way it's good if a diff >> from a less-experienced porter has some easier-to-spot issues (i.e. >> the sort of issues that an automated check would be likely to identify) >> because it's a bit of a flag that other, harder to spot, issues are >> likely to be present too. >>
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 04:57:49PM +, Stuart Henderson wrote: > On 2022/01/24 15:51, Dima Pasechnik wrote: > > Would a git-generated email with a diff be acceptable? > > https://git-send-email.io/ > > Yes as long as it's not one of those big [1/n] sequences of separate > emails that would be better dealt with in a single mail :) > > > In principle, such a patch would be very easy to apply (with git) > > to your local git repo - and it can be bounced to appropriately configured > > CI... > > Applying it with git isn't useful for someone who is going to commit > it to cvs because (even if they use a mixture of git/got+cvs themselves) > it still needs to get into their cvs checkout. I'm guessing here, but can't you overlay CVS and git trees? If it's possible then merging with git will produce a CVS diff. > > > > At the moment it's hidden in a page named 'Building the System from > > > Source', not very clear. Maybe put in on porter's handbook? > > > > > > - Some kind of automated pre-submission sanity test would be nice. > > > Should be simpler than a full CI setup. (is my diff mangled? is my > > > tree outdated?) > > The OpenBSD-supporting CI I mentioned in my other email > > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd > > would be very easy to set up for this. > > What would you propose a CI to do for ports submissions? building (maybe testing too) the new/updated port only, just on amd64, as a start. Dima > > Identifying and building ports that depend on a particular port and > doing a build of all of them on a clean -current OpenBSD system could > be useful in some cases, though complete overkill in most, and would > take long enough that it would be silly to do before a basic review. > > There's another consideration with this. In a way it's good if a diff > from a less-experienced porter has some easier-to-spot issues (i.e. > the sort of issues that an automated check would be likely to identify) > because it's a bit of a flag that other, harder to spot, issues are > likely to be present too. >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/24 15:51, Dima Pasechnik wrote: > Would a git-generated email with a diff be acceptable? > https://git-send-email.io/ Yes as long as it's not one of those big [1/n] sequences of separate emails that would be better dealt with in a single mail :) > In principle, such a patch would be very easy to apply (with git) > to your local git repo - and it can be bounced to appropriately configured > CI... Applying it with git isn't useful for someone who is going to commit it to cvs because (even if they use a mixture of git/got+cvs themselves) it still needs to get into their cvs checkout. > > At the moment it's hidden in a page named 'Building the System from > > Source', not very clear. Maybe put in on porter's handbook? > > > > - Some kind of automated pre-submission sanity test would be nice. > > Should be simpler than a full CI setup. (is my diff mangled? is my > > tree outdated?) > The OpenBSD-supporting CI I mentioned in my other email > https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd > would be very easy to set up for this. What would you propose a CI to do for ports submissions? Identifying and building ports that depend on a particular port and doing a build of all of them on a clean -current OpenBSD system could be useful in some cases, though complete overkill in most, and would take long enough that it would be silly to do before a basic review. There's another consideration with this. In a way it's good if a diff from a less-experienced porter has some easier-to-spot issues (i.e. the sort of issues that an automated check would be likely to identify) because it's a bit of a flag that other, harder to spot, issues are likely to be present too.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:49:26PM +, Yifei Zhan wrote: > On 22/01/22 02:30AM, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > > Volker Schlecht writes: > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend > > > > > to > > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > An FAQ of sorts might *help*, particularly one addressing the more > > > > typical beginner mistakes. What are the things that you guys > > > > immediately > > > > look out for when a new name offers up a diff because they're usually > > > > done wrong? > > > > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > > suggestions and improvements including possibly large-scale rewriting... > > > Feel free to send a diff for it to ports@. > > > > > > > > Any kind of pointers (including diffs to manpages or whatever) that > > would make it easier for newcomers to find that > > would be a great addition to the system. > > > > Especially from "newer" people who have been figuring it out. > > > > Us old-timers have about ZERO idea what's actually needed. > > > > Some ideas: > > - How to find LIBDEP: > https://marc.info/?l=openbsd-ports=164089356505525=2 > > - A simple CVS quick start guide would be nice, I spent way too long > to learn it and I'm still not totally sure how it works. (e.g. how to > generate a diff properly/how to apply an inline patch/how to handle > new directory...etc) > > yes there are countless guides alrealy on the internet, but most of > them are confusing and not really suitable for OpenBSD's workflow. > > and since we are here, what's your workflow of testing/generating > diff? often I would corrupt my ports tree while testing/generating > diff and have to check out a fresh copy) > > - Make it more clear that git generated diff is acceptable Would a git-generated email with a diff be acceptable? https://git-send-email.io/ In principle, such a patch would be very easy to apply (with git) to your local git repo - and it can be bounced to appropriately configured CI... > > At the moment it's hidden in a page named 'Building the System from > Source', not very clear. Maybe put in on porter's handbook? > > - Some kind of automated pre-submission sanity test would be nice. > Should be simpler than a full CI setup. (is my diff mangled? is my > tree outdated?) The OpenBSD-supporting CI I mentioned in my other email https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd would be very easy to set up for this. Dima
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:49:26PM +, Yifei Zhan wrote: > On 22/01/22 02:30AM, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > > Volker Schlecht writes: > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend > > > > > to > > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > An FAQ of sorts might *help*, particularly one addressing the more > > > > typical beginner mistakes. What are the things that you guys > > > > immediately > > > > look out for when a new name offers up a diff because they're usually > > > > done wrong? > > > > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > > suggestions and improvements including possibly large-scale rewriting... > > > Feel free to send a diff for it to ports@. > > > > > > > > Any kind of pointers (including diffs to manpages or whatever) that > > would make it easier for newcomers to find that > > would be a great addition to the system. > > > > Especially from "newer" people who have been figuring it out. > > > > Us old-timers have about ZERO idea what's actually needed. > > > > Some ideas: > > - How to find LIBDEP: > https://marc.info/?l=openbsd-ports=164089356505525=2 > There's some supplementary work I need to do in port-lib-depends, namely interface it with the pkglocatedb so that missing dependencies can be located more easily. Also, yeah, that code is rather hard to read, I know. > - A simple CVS quick start guide would be nice, I spent way too long > to learn it and I'm still not totally sure how it works. (e.g. how to > generate a diff properly/how to apply an inline patch/how to handle > new directory...etc) It's a complete pain in the ass in any case. > yes there are countless guides alrealy on the internet, but most of > them are confusing and not really suitable for OpenBSD's workflow. > > and since we are here, what's your workflow of testing/generating > diff? often I would corrupt my ports tree while testing/generating > diff and have to check out a fresh copy) > > - Make it more clear that git generated diff is acceptable Yeah, that's a really good point. > At the moment it's hidden in a page named 'Building the System from > Source', not very clear. Maybe put in on porter's handbook? > > - Some kind of automated pre-submission sanity test would be nice. > Should be simpler than a full CI setup. (is my diff mangled? is my > tree outdated?) > You got portcheck for that one. It does validate new ports and ports after diff. Notice that https://www.openbsd.org/faq/index.html contains a Porter's handbook and a Port Testing guide. If those are not apparent enough, diffs are welcome. If things are missing in there, again, diffs are welcome.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Mon, Jan 24, 2022 at 01:39:50PM +0100, Dima Pasechnik wrote: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > > In my opinion, our main issue is the lack of new blood. > > > > > > We have chronically fewer people who can give okays than ports waiting. > > > > > > One big "meta" stuff that needs doing is pointing out (especially from > > > new guys) what can be improved in the documentation of the porting > > > process... > > > sometimes pointing people in the right direction. > > > > > > Informal poll: what thing weirded you guys out the first time you touched > > > OpenBSD ports coming from other platforms. > > > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > > main differences to (say) deb, rpm, freebsd ?... > > > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > > > Maybe we can do something radical like enable GitHub pull requests > > to let people submit changes against the ports repo on GitHub, do > > review and feedback on those on GitHub, and once it's been approved > > by a developer, that developer can do the final legwork of > > committing it to CVS and closing the pull request (since we can't > > commit directly to the Git repo). > > > I read this, and the whole following thread, and noone mentioned CI > (continuous integration) > - something that made GitHub much more useful than merely a git server > hosting service. > > In a CI-enabled world, one could usually see the results of applying a diff, > and > building+testing, it's there, done for you, automatically. > Indeed, using GitHub's CI with OpenBSD is tricky (if possible at all), but > fortunately We got a framework for bulk-building ports: dpb(1) That's the whole integration we get... the full ports tree is generally rebuilt every few days (or weeks) or supported architectures. Good luck getting a proper infrastructure off the ground, especially on lesser known architectures. We do frown on cross-compilation for various reasons.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). I read this, and the whole following thread, and noone mentioned CI (continuous integration) - something that made GitHub much more useful than merely a git server hosting service. In a CI-enabled world, one could usually see the results of applying a diff, and building+testing, it's there, done for you, automatically. Indeed, using GitHub's CI with OpenBSD is tricky (if possible at all), but fortunately there are other similar free services, such as one by Sourcehut: https://man.sr.ht/builds.sr.ht/compatibility.md#openbsd Second point: I'd agree that GitHub is far from an ideal solution here, but the underlying tool, git, is certainly way more powerful than CVS. Hey, I used CVS a bit in 1999, and fogot all about it. Yes, CVS can be helped with extra tooling, but this kind of tooling is made largely obsolete by git. (The theme CVS vs Subversion vs git has certainly been explored in all the details on the net, I don't want to repeat it here.) Switching to git would certainly be very welcoming for newcomers. HTH Dima users.ox.ac.uk/~coml0531/ > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > Volker Schlecht writes: > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > An FAQ of sorts might *help*, particularly one addressing the more > > typical beginner mistakes. What are the things that you guys immediately > > look out for when a new name offers up a diff because they're usually > > done wrong? > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > suggestions and improvements including possibly large-scale rewriting... > Feel free to send a diff for it to ports@. > > Any kind of pointers (including diffs to manpages or whatever) that would make it easier for newcomers to find that would be a great addition to the system. Especially from "newer" people who have been figuring it out. Us old-timers have about ZERO idea what's actually needed.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 04:13:10PM -0500, Kurt Mosiejczuk wrote: > On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > > Volker Schlecht writes: > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > > be squeaky clean, infrastructure-wise, and ready for import. > > > An FAQ of sorts might *help*, particularly one addressing the more > > > typical beginner mistakes. What are the things that you guys immediately > > > look out for when a new name offers up a diff because they're usually > > > done wrong? > > > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > > suggestions and improvements including possibly large-scale rewriting... > > Feel free to send a diff for it to ports@. > > Yes. Those of us well-versed in it are those most likely to miss putting > important details in the FAQ. > > --Kurt > This thread has some great tips in it: https://marc.info/?l=openbsd-ports=163950488420152=2 It deals with BUILD, RUN and TEST_DEPENDS and when to use what. -- Chris
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Am Fri, Jan 21, 2022 at 07:24:34PM +0100 schrieb Marc Espie: > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > > Using CVS and dealing with tarballs is probably pretty > > > ancient-feeling for many outsiders. I don't know that more > > > documentation is really the problem. > > > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > > can easily view in my e-mail client because it's a hassle to save > > > the attachment, tar -t it to see what its directory structure is, > > > untar it in the proper place, try to build it, then provide feedback > > > by copying parts of the Makefile to an e-mail or doing some other > > > work to produce a diff. > > > > I never understood why new ports have to submitted as a tarball. > > Why not accept new ports as a diff which only creates new files? > > It is trivial to create such a diff. > > Give me the magical recipie that does NOT create directories in the actual > CVS repository/is usable without write access to the OpenBSD CVS repo or > a copy ! > > They DON'T create new files, they create NEW DIRECTORIES. > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > without a local repository! Sounds like a reason to ditch CVS and switch to git.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 02:07:10PM -0700, Anthony J. Bentley wrote: > Volker Schlecht writes: > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > > be squeaky clean, infrastructure-wise, and ready for import. > > An FAQ of sorts might *help*, particularly one addressing the more > > typical beginner mistakes. What are the things that you guys immediately > > look out for when a new name offers up a diff because they're usually > > done wrong? > There's https://www.openbsd.org/faq/ports/ ; it's wide open for > suggestions and improvements including possibly large-scale rewriting... > Feel free to send a diff for it to ports@. Yes. Those of us well-versed in it are those most likely to miss putting important details in the FAQ. --Kurt
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Volker Schlecht writes: > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > An FAQ of sorts might *help*, particularly one addressing the more > typical beginner mistakes. What are the things that you guys immediately > look out for when a new name offers up a diff because they're usually > done wrong? There's https://www.openbsd.org/faq/ports/ ; it's wide open for suggestions and improvements including possibly large-scale rewriting... Feel free to send a diff for it to ports@.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 2022/01/21 11:42, joshua stein wrote: > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. this helps a lot: $ grep vim .mailcap application/x-tar; vim '%s' application/x-xz; vim '%s' application/x-tar-gz; vim '%s' application/x-gzip; vim '%s' application/gzip; vim '%s' application/x-gunzip; vim '%s' application/x-gtar; vim '%s' application/x-xz; vim '%s' application/x-gtar-compressed; vim '%s' application/x-compressed-tar; vim '%s' application/octet-stream; vim '%s' > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). No way. Way too much burden for regular ports committers. This takes the existing work, adds a bunch of extra steps required, and encourage submissions from people that aren't keeping on top of how OpenBSD works which are likely to add even more work for us.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 08:55:57PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2022 at 08:44:14PM +0100, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > > > On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > > > > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > > > > I never understood why new ports have to submitted as a tarball. > > > > > Why not accept new ports as a diff which only creates new files? > > > > > It is trivial to create such a diff. > > > > > > > > Give me the magical recipie that does NOT create directories in the > > > > actual > > > > CVS repository/is usable without write access to the OpenBSD CVS repo or > > > > a copy ! > > > > > > > > They DON'T create new files, they create NEW DIRECTORIES. > > > > > > > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > > > > without a local repository! > > > > > > cvsdo can do it by faking new directories entries in CVS/Entries files. > > > This does not require adding directories to the repository (see below). > > > I am not suggesting this is a great solution, but it can be done. > > > > Is this documented anywhere for new people? > > I doubt it. > But before recommending this approach, a few people should try to work > through entire submissions of non-trivial ports with it. There might be > some gotchas which the trivial cases I've used this for cannot uncover. > I last used cvsdo years ago while submitting diffs for both src and ports, > and only in the rare cases where I had to add new files. > Nothing like tor-browser or chromium :P > > Nowadays, I would use devel/got to create such a diff against ports.git > cloned from github. But that is not CVS and it is probably too early to > generally recommend got instead of git to work on ports. Though I would > be happy to receive bug reports against got from interested ports devs. > I use a hybrid system of sorts. My ports tree is from CVS. My mystuff directory in my ports tree is got controlled. When I work on a port, the cvs directory is copied to mystuff and added to got. That way, I can track changes the way I am comfortable, adding and removing files from both got and CVS, etc. I can then generate diffs from either got or CVS, but this way it's easy for me to revert something in got if I need to. When finished, I can simply commit from this directory to CVS and update my ports tree, then remove from got. May sound weird, but it works for me and helps me keep things straight on some of the more complicated junk I work on, simultaneously keeping my github wip repo up-to-date, since mystuff is a bare clone from my github account. -- Tracey Emery
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 1/21/22 18:29, Marc Espie wrote: Informal poll: what thing weirded you guys out the first time you touched OpenBSD ports coming from other platforms. Wouldn't say it weirded me out, but it took me quite a while to create some sort of mental model about what's going on with everything involving WANTLIB. And I'm sure the one I have now is wrong ;) That and I don't know how often I've wiped my ports tree in the beginning because I accidentally used 'CVS up' with a 027 umask ... What kind of gotcha can we get rid of, so that "new ports" will tend to be squeaky clean, infrastructure-wise, and ready for import. An FAQ of sorts might *help*, particularly one addressing the more typical beginner mistakes. What are the things that you guys immediately look out for when a new name offers up a diff because they're usually done wrong? If you give *me* a list of common beginner's mistakes however, that just means that I'll make less common ones. I've yet to meet anyone for whom that's substantially different, so "squeaky clean" diffs from first timers may generally out of reach, no matter how great the documentation. As to the causes for the mistakes I made so far, I can however confirm that none of them were attributable to CVS or any part of the toolchain ;-p
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 08:44:14PM +0100, Marc Espie wrote: > On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > > On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > > > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > > > I never understood why new ports have to submitted as a tarball. > > > > Why not accept new ports as a diff which only creates new files? > > > > It is trivial to create such a diff. > > > > > > Give me the magical recipie that does NOT create directories in the actual > > > CVS repository/is usable without write access to the OpenBSD CVS repo or > > > a copy ! > > > > > > They DON'T create new files, they create NEW DIRECTORIES. > > > > > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > > > without a local repository! > > > > cvsdo can do it by faking new directories entries in CVS/Entries files. > > This does not require adding directories to the repository (see below). > > I am not suggesting this is a great solution, but it can be done. > > Is this documented anywhere for new people? I doubt it. But before recommending this approach, a few people should try to work through entire submissions of non-trivial ports with it. There might be some gotchas which the trivial cases I've used this for cannot uncover. I last used cvsdo years ago while submitting diffs for both src and ports, and only in the rare cases where I had to add new files. Nothing like tor-browser or chromium :P Nowadays, I would use devel/got to create such a diff against ports.git cloned from github. But that is not CVS and it is probably too early to generally recommend got instead of git to work on ports. Though I would be happy to receive bug reports against got from interested ports devs.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > > I never understood why new ports have to submitted as a tarball. > > > Why not accept new ports as a diff which only creates new files? > > > It is trivial to create such a diff. > > > > Give me the magical recipie that does NOT create directories in the actual > > CVS repository/is usable without write access to the OpenBSD CVS repo or > > a copy ! > > > > They DON'T create new files, they create NEW DIRECTORIES. > > > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > > without a local repository! > > cvsdo can do it by faking new directories entries in CVS/Entries files. > This does not require adding directories to the repository (see below). > I am not suggesting this is a great solution, but it can be done. Is this documented anywhere for new people?
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 01:12:05PM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 16:06:00 -0300, Crystal Kolipe wrote: > > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > > > Here is my experience: http://www.oxide.org/cvs/abieber.html > > > > Wow, that server is slow. And doesn't even support https. > > So you want to enforce your "standard", I.E. https, on everybody? > > If we're going to have a "standard", why not make it the lowest > common denominator, so that people who are comfortable with browsing > with their own tools can easily handle it the way they want to? > Which is, basically, the whole unix philosophy anyway. Thankyou! I totally agree! And the lowest common denominator would be to post the content to the list, (or preferably to me personally and to stop spamming the list with off-topic drivel). That way I wouldn't have to fetch an external resource, be it over http or https or gopher, or whatever. Which was, ironically, one of my original rants about the proposed use of GitHub. Nevertheless, if you ARE going to post an external link, at least give people the OPTION of pulling it over https.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, 21 Jan 2022 at 16:06:00 -0300, Crystal Kolipe wrote: > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > > Here is my experience: http://www.oxide.org/cvs/abieber.html > > Wow, that server is slow. And doesn't even support https. So you want to enforce your "standard", I.E. https, on everybody? If we're going to have a "standard", why not make it the lowest common denominator, so that people who are comfortable with browsing with their own tools can easily handle it the way they want to? Which is, basically, the whole unix philosophy anyway.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: >> Here is my experience: http://www.oxide.org/cvs/abieber.html > > Wow, that server is slow. And doesn't even support https. Alternatively - you could look through cvs history :)
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:35AM -0700, Aaron Bieber wrote: > Here is my experience: http://www.oxide.org/cvs/abieber.html Wow, that server is slow. And doesn't even support https.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:24:34AM -0700, Aaron Bieber wrote: >> >> Crystal Kolipe writes: >> >> > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: >> >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know >> >> how to use tar. The problem is that people send things totally >> >> differently and there is no agreed upon "standard". GH would remedy this >> >> because everything would become a diff - plain text! >> > >> > So you want to enforce your "standard", I.E. GitHub, on everybody? >> > >> > If we're going to have a "standard", why not make it the lowest common >> > denominator, so that people who are comfortable with creating their own >> > tools can easily handle it the way they want to? Which is, basically, >> > the whole unix philosophy anyway. >> > >> >> Also if people don't want to use the GH approach - they don't have to! >> > >> > But the use of GitHub would become like a virus, in that it also affects >> > people who don't want to use it. >> > >> >> at no point did jcs suggest that we make everyone get a GH account and >> >> switch to using it exclusively. >> > >> > Go and read the Linux kernel archives from 20 years ago, and the flamewars >> > over the use of BitKeeper to manage the kernel source. >> >> I don't even know how to respond to this. You are saying that GH usage >> will infect people and then they will be forced to use it? > > Not really, no. > > I'm saying that once some people start using GitHub to automatically generate > diffs and send them to this mailing list, then the next step will likely be > that development starts moving off of the mailing list altogether, and only > accessible via a tedious pointy-clicky webbrowser interface, rather than as > free-format conversation on a mailing list, which has worked fine ever since > the OpenBSD project first began. > >> That seems a bit far fetched to me. But maybe that's the mindvirus at >> work! >> >> No idea what linux kernel archievs from 20 years ago have to do with any >> of this. > > Well, you've really answered your own question there. > I mean contextually with the conversation around openbsd, cvs and a new process. Obviously. > Do you even know why git was created? What came before it? I feel like you are trying to undermine my credibility with this statement. How much experience do you have committing things in OpenBSD with cvs? Here is my experience: http://www.oxide.org/cvs/abieber.html Maybe we should change the topic to "On the subject of non-OpenBSD developers opinions on the process of developing OpenBSD" :P
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:47:44PM +0100, Stefan Sperling wrote: > cvsdo can do it by faking new directories entries in CVS/Entries files. > This does not require adding directories to the repository (see below). > I am not suggesting this is a great solution, but it can be done. For those playing at home, cvsdo is in the super-useful cvsutils package. --Kurt > $ ls /tmp/repo/ > CVSROOT/ test/ > $ cvs -d /tmp/repo co -P test > cvs checkout: Updating test > U test/alpha > $ cd test > $ mkdir foo > $ cvsdo add foo > $ echo 'hello world' > foo/new > $ cvsdo add foo/new > $ cvs -R diff -uNp foo > cvs diff: Diffing foo > Index: foo/new > === > RCS file: foo/new > diff -N foo/new > --- /dev/null 1 Jan 1970 00:00:00 - > +++ foo/new 21 Jan 2022 18:38:57 - > @@ -0,0 +1 @@ > +hello world > $ mkdir foo/patches > $ echo new patch > foo/patches/patch1 > $ cvsdo add foo/patches/patch1 > $ cvs -R diff -uNp foo foo/patches > cvs diff: Diffing foo > Index: foo/new > === > RCS file: foo/new > diff -N foo/new > --- /dev/null 1 Jan 1970 00:00:00 - > +++ foo/new 21 Jan 2022 18:38:57 - > @@ -0,0 +1 @@ > +hello world > cvs diff: Diffing foo/patches > Index: foo/patches/patch1 > === > RCS file: foo/patches/patch1 > diff -N foo/patches/patch1 > --- /dev/null 1 Jan 1970 00:00:00 - > +++ foo/patches/patch1 21 Jan 2022 18:41:50 - > @@ -0,0 +1 @@ > +new patch > $ ls /tmp/repo/test/ > alpha,v > $ >
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:24:34PM +0100, Marc Espie wrote: > On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > > I never understood why new ports have to submitted as a tarball. > > Why not accept new ports as a diff which only creates new files? > > It is trivial to create such a diff. > > Give me the magical recipie that does NOT create directories in the actual > CVS repository/is usable without write access to the OpenBSD CVS repo or > a copy ! > > They DON'T create new files, they create NEW DIRECTORIES. > > Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO > without a local repository! cvsdo can do it by faking new directories entries in CVS/Entries files. This does not require adding directories to the repository (see below). I am not suggesting this is a great solution, but it can be done. $ ls /tmp/repo/ CVSROOT/ test/ $ cvs -d /tmp/repo co -P test cvs checkout: Updating test U test/alpha $ cd test $ mkdir foo $ cvsdo add foo $ echo 'hello world' > foo/new $ cvsdo add foo/new $ cvs -R diff -uNp foo cvs diff: Diffing foo Index: foo/new === RCS file: foo/new diff -N foo/new --- /dev/null 1 Jan 1970 00:00:00 - +++ foo/new 21 Jan 2022 18:38:57 - @@ -0,0 +1 @@ +hello world $ mkdir foo/patches $ echo new patch > foo/patches/patch1 $ cvsdo add foo/patches/patch1 $ cvs -R diff -uNp foo foo/patches cvs diff: Diffing foo Index: foo/new === RCS file: foo/new diff -N foo/new --- /dev/null 1 Jan 1970 00:00:00 - +++ foo/new 21 Jan 2022 18:38:57 - @@ -0,0 +1 @@ +hello world cvs diff: Diffing foo/patches Index: foo/patches/patch1 === RCS file: foo/patches/patch1 diff -N foo/patches/patch1 --- /dev/null 1 Jan 1970 00:00:00 - +++ foo/patches/patch1 21 Jan 2022 18:41:50 - @@ -0,0 +1 @@ +new patch $ ls /tmp/repo/test/ alpha,v $
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:24:34AM -0700, Aaron Bieber wrote: > > Crystal Kolipe writes: > > > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: > >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know > >> how to use tar. The problem is that people send things totally > >> differently and there is no agreed upon "standard". GH would remedy this > >> because everything would become a diff - plain text! > > > > So you want to enforce your "standard", I.E. GitHub, on everybody? > > > > If we're going to have a "standard", why not make it the lowest common > > denominator, so that people who are comfortable with creating their own > > tools can easily handle it the way they want to? Which is, basically, > > the whole unix philosophy anyway. > > > >> Also if people don't want to use the GH approach - they don't have to! > > > > But the use of GitHub would become like a virus, in that it also affects > > people who don't want to use it. > > > >> at no point did jcs suggest that we make everyone get a GH account and > >> switch to using it exclusively. > > > > Go and read the Linux kernel archives from 20 years ago, and the flamewars > > over the use of BitKeeper to manage the kernel source. > > I don't even know how to respond to this. You are saying that GH usage > will infect people and then they will be forced to use it? Not really, no. I'm saying that once some people start using GitHub to automatically generate diffs and send them to this mailing list, then the next step will likely be that development starts moving off of the mailing list altogether, and only accessible via a tedious pointy-clicky webbrowser interface, rather than as free-format conversation on a mailing list, which has worked fine ever since the OpenBSD project first began. > That seems a bit far fetched to me. But maybe that's the mindvirus at > work! > > No idea what linux kernel archievs from 20 years ago have to do with any > of this. Well, you've really answered your own question there. Do you even know why git was created? What came before it?
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: >> "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know >> how to use tar. The problem is that people send things totally >> differently and there is no agreed upon "standard". GH would remedy this >> because everything would become a diff - plain text! > > So you want to enforce your "standard", I.E. GitHub, on everybody? > > If we're going to have a "standard", why not make it the lowest common > denominator, so that people who are comfortable with creating their own > tools can easily handle it the way they want to? Which is, basically, > the whole unix philosophy anyway. > >> Also if people don't want to use the GH approach - they don't have to! > > But the use of GitHub would become like a virus, in that it also affects > people who don't want to use it. > >> at no point did jcs suggest that we make everyone get a GH account and >> switch to using it exclusively. > > Go and read the Linux kernel archives from 20 years ago, and the flamewars > over the use of BitKeeper to manage the kernel source. I don't even know how to respond to this. You are saying that GH usage will infect people and then they will be forced to use it? That seems a bit far fetched to me. But maybe that's the mindvirus at work! No idea what linux kernel archievs from 20 years ago have to do with any of this.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > > Using CVS and dealing with tarballs is probably pretty > > ancient-feeling for many outsiders. I don't know that more > > documentation is really the problem. > > > > I personally tend to ignore most ports@ emails that aren't diffs I > > can easily view in my e-mail client because it's a hassle to save > > the attachment, tar -t it to see what its directory structure is, > > untar it in the proper place, try to build it, then provide feedback > > by copying parts of the Makefile to an e-mail or doing some other > > work to produce a diff. > > I never understood why new ports have to submitted as a tarball. > Why not accept new ports as a diff which only creates new files? > It is trivial to create such a diff. Give me the magical recipie that does NOT create directories in the actual CVS repository/is usable without write access to the OpenBSD CVS repo or a copy ! They DON'T create new files, they create NEW DIRECTORIES. Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO without a local repository!
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. We could have some kind of script that checks the directory structure of a tarball AND explicitly ask that new ports are tarballs that are based under ports (or maybe have a script that packages new ports for that). Doing "full diffs" for new ports under CVS is 100% a pain in the butt: you either have to have a CVS mirror locally, and add directories in there, OR you must create directories before-hand for that on the "real" repository CVS SUCKS THAT WAY BIG TIME. (I haven't said this loud enough) CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. CVS SUCKS THAT WAY BIG TIME. > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). We have have git diff format support in our patch for a while. I'm pretty sure I *DO NOT WANT* automated stuff between github and this mailing list. That said, instructions on - where the "official" github mirror is - how to clone it and possibly: - directions/scripts on how to prepare a submission from there to here might be a good idea.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
I have to say no also to this idea. While using Github separately for working on a particular group of ports with a few others is fine, having 12 WIP ports would make a real mess. For example, portgen with Perl makes a cpan directory with a good, but very flawed start on a port, usually with quite a few new dependencies. These would also need to go up into the tree for future work, by myself or someday by others. Some people put a new or updated port into devel or other category. I put mine into mystuff in order to get a fresh tree, but keep my work on a separate partition and safe. The mountain of email messages I get from Github requires a different email to endure it. -- Chris Bennett
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:05:12AM -0700, Aaron Bieber wrote: > "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know > how to use tar. The problem is that people send things totally > differently and there is no agreed upon "standard". GH would remedy this > because everything would become a diff - plain text! So you want to enforce your "standard", I.E. GitHub, on everybody? If we're going to have a "standard", why not make it the lowest common denominator, so that people who are comfortable with creating their own tools can easily handle it the way they want to? Which is, basically, the whole unix philosophy anyway. > Also if people don't want to use the GH approach - they don't have to! But the use of GitHub would become like a virus, in that it also affects people who don't want to use it. > at no point did jcs suggest that we make everyone get a GH account and > switch to using it exclusively. Go and read the Linux kernel archives from 20 years ago, and the flamewars over the use of BitKeeper to manage the kernel source.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
Crystal Kolipe writes: > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: >> Maybe we can do something radical like enable GitHub pull requests >> to let people submit changes against the ports repo on GitHub > > Cringe. > > I sincerely hope that this doesn't happen. > > Just look at the typical quality of the projects hosted on GitHub, and > you'll see how relying on a set of third-party managed tools to do your > work instead of taking the time to learn the basic tools, (tar, diff, > an email program, etc), yourself can lead to laziness and poor quality. > > If people can't be bothered to do things themselves or make their own > tools to automate a process, how dedicated are they likely to be? > >> I believe that the GitHub repo can be configured to also email >> ports@openbsd.org on any submissions/comments there, so the mailing >> list would still be in the loop on everything for anyone that >> doesn't want to use GitHub. > > So the mailing list is going to be flooded with automated mails from > GitHub, that become tedious, leading people to just skim over them > or OK them without really reviewing the content. > > Honestly, I think we all want to keep the quality of the ports tree > as high as possible, and if learing to use tar and diff as a barrier to > entry for some people is doing that, I suggest we continue as we are. "Knowing" the tools isn't the problem. jcs@ knows how to use tar. I know how to use tar. The problem is that people send things totally differently and there is no agreed upon "standard". GH would remedy this because everything would become a diff - plain text! Also if people don't want to use the GH approach - they don't have to! at no point did jcs suggest that we make everyone get a GH account and switch to using it exclusively.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. I never understood why new ports have to submitted as a tarball. Why not accept new ports as a diff which only creates new files? It is trivial to create such a diff. Well, CVS makes it somewhat non-trivial for people without write access to the main repository, but not impossible. You could pkg_add cvsutils and use cvsdo add to make new files and directories appear (I have done this before, it works). Or you could add new directories against a local repository mirror and produce a diff against it. And of course there is the Git conversion on github. With a Git repository it is very trivial to create a diff which adds a new port. I don't think we would even need to explain how. People who become curious about OpenBSD development today will very likely already be comfortable with Git. Allowing pull requests has the downside that the mailing list cannot easily respond to what is going on at Github. Splitting the conversation across two disparate communiation channels won't work very well. Github tends to assume that it is the only place where all the action is.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote: > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub Cringe. I sincerely hope that this doesn't happen. Just look at the typical quality of the projects hosted on GitHub, and you'll see how relying on a set of third-party managed tools to do your work instead of taking the time to learn the basic tools, (tar, diff, an email program, etc), yourself can lead to laziness and poor quality. If people can't be bothered to do things themselves or make their own tools to automate a process, how dedicated are they likely to be? > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. So the mailing list is going to be flooded with automated mails from GitHub, that become tedious, leading people to just skim over them or OK them without really reviewing the content. Honestly, I think we all want to keep the quality of the ports tree as high as possible, and if learing to use tar and diff as a barrier to entry for some people is doing that, I suggest we continue as we are.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
joshua stein writes: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: >> In my opinion, our main issue is the lack of new blood. >> >> We have chronically fewer people who can give okays than ports waiting. >> >> One big "meta" stuff that needs doing is pointing out (especially from >> new guys) what can be improved in the documentation of the porting process... >> sometimes pointing people in the right direction. >> >> Informal poll: what thing weirded you guys out the first time you touched >> OpenBSD ports coming from other platforms. >> >> What kind of gotcha can we get rid of, so that "new ports" will tend to >> be squeaky clean, infrastructure-wise, and ready for import. >> >> Maybe we'd need an FAQ from people coming from elsewhere explaining the >> main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. This would be awesome! I bet we could even automate the closing after something was committed to CVS!
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On 21/01/22 11:42 -0600, joshua stein wrote: > On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > > In my opinion, our main issue is the lack of new blood. > > > > We have chronically fewer people who can give okays than ports waiting. > > > > One big "meta" stuff that needs doing is pointing out (especially from > > new guys) what can be improved in the documentation of the porting > > process... > > sometimes pointing people in the right direction. > > > > Informal poll: what thing weirded you guys out the first time you touched > > OpenBSD ports coming from other platforms. > > > > What kind of gotcha can we get rid of, so that "new ports" will tend to > > be squeaky clean, infrastructure-wise, and ready for import. > > > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > > main differences to (say) deb, rpm, freebsd ?... > > Using CVS and dealing with tarballs is probably pretty > ancient-feeling for many outsiders. I don't know that more > documentation is really the problem. > > I personally tend to ignore most ports@ emails that aren't diffs I > can easily view in my e-mail client because it's a hassle to save > the attachment, tar -t it to see what its directory structure is, > untar it in the proper place, try to build it, then provide feedback > by copying parts of the Makefile to an e-mail or doing some other > work to produce a diff. > > Maybe we can do something radical like enable GitHub pull requests > to let people submit changes against the ports repo on GitHub, do > review and feedback on those on GitHub, and once it's been approved > by a developer, that developer can do the final legwork of > committing it to CVS and closing the pull request (since we can't > commit directly to the Git repo). > > I believe that the GitHub repo can be configured to also email > ports@openbsd.org on any submissions/comments there, so the mailing > list would still be in the loop on everything for anyone that > doesn't want to use GitHub. > Big NO. We use CVS, deal with it. If you want to help people who are lazy to cvs diff and send an email, write a script that that does a submission for them automatically in a format we prefer. If you want to use git, fine, you can send git diffs to the mailing list. If someone does not have enough brain to figure out how to do things our way then we probably do not want that submission either. On the other hand, I think the issue here is not the version control system or the development method we are using, but the lack of interest or need. The openbsd ports and packages are quiet good compared to others and things just work. There is always room for imrovement of course.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Fri, 21 Jan 2022 at 18:29:27 +0100, Marc Espie wrote: > In my opinion, our main issue is the lack of new blood. > > We have chronically fewer people who can give okays than ports waiting. > > One big "meta" stuff that needs doing is pointing out (especially from > new guys) what can be improved in the documentation of the porting process... > sometimes pointing people in the right direction. > > Informal poll: what thing weirded you guys out the first time you touched > OpenBSD ports coming from other platforms. > > What kind of gotcha can we get rid of, so that "new ports" will tend to > be squeaky clean, infrastructure-wise, and ready for import. > > Maybe we'd need an FAQ from people coming from elsewhere explaining the > main differences to (say) deb, rpm, freebsd ?... Using CVS and dealing with tarballs is probably pretty ancient-feeling for many outsiders. I don't know that more documentation is really the problem. I personally tend to ignore most ports@ emails that aren't diffs I can easily view in my e-mail client because it's a hassle to save the attachment, tar -t it to see what its directory structure is, untar it in the proper place, try to build it, then provide feedback by copying parts of the Makefile to an e-mail or doing some other work to produce a diff. Maybe we can do something radical like enable GitHub pull requests to let people submit changes against the ports repo on GitHub, do review and feedback on those on GitHub, and once it's been approved by a developer, that developer can do the final legwork of committing it to CVS and closing the pull request (since we can't commit directly to the Git repo). I believe that the GitHub repo can be configured to also email ports@openbsd.org on any submissions/comments there, so the mailing list would still be in the loop on everything for anyone that doesn't want to use GitHub.
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
In my opinion, our main issue is the lack of new blood. We have chronically fewer people who can give okays than ports waiting. One big "meta" stuff that needs doing is pointing out (especially from new guys) what can be improved in the documentation of the porting process... sometimes pointing people in the right direction. Informal poll: what thing weirded you guys out the first time you touched OpenBSD ports coming from other platforms. What kind of gotcha can we get rid of, so that "new ports" will tend to be squeaky clean, infrastructure-wise, and ready for import. Maybe we'd need an FAQ from people coming from elsewhere explaining the main differences to (say) deb, rpm, freebsd ?...
Re: FYI - On the subject of non-OpenBSD developers asking "ok?"
On Thu, Jan 20, 2022 at 11:33:41PM -0500, Kurt Mosiejczuk wrote: > Generally only folks who can commit to CVS should be asking "ok?" > > It signals to others that you are also an OpenBSD dev. One might think > that doing this may get you quicker reivew attention, except it may also > mean that you get an ok and your work never gets committed. Why? Because > we'll assume you can do so yourself. We try not to "steal" other > developer's commits. So you may get "ok" as an answer and no one will > follow up on it. > > So it's not that I'm saying "you're not part of the club, don't use our > secret handshake", it's more that by using the secret handshake you may > end up hurting yourself. :) > > --Kurt (kmos@) > So what is the best way to ask for comments and then a commit from someone? I see several situations: 1. New Port (2 OK's) 2. Revised New Port in the thread (2 OK's) 3. Update to a Port (1 OK, right?) 4. Revised Update to a Port (1 OK, right?) I've gotten tied up in working on something I would like to offer as a new port I'm working on and coding. Also figuring out how to do responsive CSS. I also have another set of ports to get in for another project. Apart from the above, I would really love some sort of template for new/updated ports that are for bigger projects. An email template stating what bigger project it is, what type of ports are for. Maybe something like? [NEW] Ports for Great Project, core depends, amd64 tested. [NEW] Ports for Great Project, optional depends, arm64 tested [NEW] Ports for Great Project, development depends, i386 tested [UPDATE] Ports for Great Project, core depends, i386 tested [NEW] Port of Great Project Also, what is a "proper" timing for pinging? In the Porter Handbook, I would really like to see some examples of harder ports to bring in. I see the same questions repeated over and over on the mailing lists. I wouldn't mind spending that time myself, with a little pointing at good, existing candidates to document. "RTFPH and then ask questions" might save a lot of the work giving advice by the porting pro's. I would love to see fvwm3 brought in, since it's the latest. I use fvwm2 right now. But projects like that are a lot of work. Which I don't know how to do. -- Thanks, Chris Bennett
FYI - On the subject of non-OpenBSD developers asking "ok?"
Generally only folks who can commit to CVS should be asking "ok?" It signals to others that you are also an OpenBSD dev. One might think that doing this may get you quicker reivew attention, except it may also mean that you get an ok and your work never gets committed. Why? Because we'll assume you can do so yourself. We try not to "steal" other developer's commits. So you may get "ok" as an answer and no one will follow up on it. So it's not that I'm saying "you're not part of the club, don't use our secret handshake", it's more that by using the secret handshake you may end up hurting yourself. :) --Kurt (kmos@)
[no subject]
Are there any existing attempts to port docker's daemon to run natively on openBSD
[no subject]
Hola SSH hash tags
(No Subject)
subscribe
[no subject]
I'm trying to build freenet, but it requires posix_fallocate for most of it's file sharing capabilities. Apparently OpenBSD doesn't have it. There is nothing I could find regarding this in the mailing list archives. Could I know the reason and what alternative call I could use if any. Nov 04, 2020 10:56:42:345 (freenet.node.UptimeEstimator, WrapperListener_start_runner, ERROR): Unable to read old uptime file: /var/freenet/uptime.old.dat - we will assume we weren't online during that period Nov 04, 2020 10:56:42:548 (freenet.support.PooledExecutor$MyThread, Start store(4), ERROR): Caught java.lang.UnsatisfiedLinkError: Error looking up function 'posix_fallocate': Unable to resolve symbol running job freenet.support.PooledExecutor$Job@5711ee95 java.lang.UnsatisfiedLinkError: Error looking up function 'posix_fallocate': Unable to resolve symbol at com.sun.jna.Function.(Function.java:245) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:566) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:542) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:528) at com.sun.jna.Native.register(Native.java:1777) at com.sun.jna.Native.register(Native.java:1648) at com.sun.jna.Native.register(Native.java:1360) at freenet.support.io.Fallocate$FallocateHolderPOSIX.(Fallocate.java:93) at freenet.support.io.Fallocate.execute(Fallocate.java:72) at freenet.store.saltedhash.SaltedHashFreenetStore.setStoreFileSize(SaltedHashFreenetStore.java:1087) at freenet.store.saltedhash.SaltedHashFreenetStore.start(SaltedHashFreenetStore.java:284) at freenet.store.caching.CachingFreenetStore.start(CachingFreenetStore.java:222) at freenet.node.Node$54.run(Node.java:2942) at freenet.support.PooledExecutor$MyThread.innerRun(PooledExecutor.java:249) at freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:189) at freenet.support.io.NativeThread.run(NativeThread.java:156) Nov 04, 2020 10:56:42:548 (freenet.support.PooledExecutor$MyThread, Migrate store(1), ERROR): Caught java.lang.NoClassDefFoundError: Could not initialize class freenet.support.io.Fallocate$FallocateHolderPOSIX running job freenet.support.PooledExecutor$Job@a877a2c java.lang.NoClassDefFoundError: Could not initialize class freenet.support.io.Fallocate$FallocateHolderPOSIX at freenet.support.io.Fallocate.execute(Fallocate.java:72) at freenet.store.saltedhash.SaltedHashFreenetStore.setStoreFileSize(SaltedHashFreenetStore.java:1087) at freenet.store.saltedhash.SaltedHashFreenetStore.start(SaltedHashFreenetStore.java:284) at freenet.store.caching.CachingFreenetStore.start(CachingFreenetStore.java:222) at freenet.node.Node$56.run(Node.java:3035) at freenet.support.PooledExecutor$MyThread.innerRun(PooledExecutor.java:249) at freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:189) at freenet.support.io.NativeThread.run(NativeThread.java:156) Nov 04, 2020 10:57:36:939 (freenet.client.async.SingleFileInserter, (16), ERROR): Caught in OffThreadCompressor: java.lang.NoClassDefFoundError: Could not initialize class freenet.support.io.Fallocate$FallocateHolderPOSIX java.lang.NoClassDefFoundError: Could not initialize class freenet.support.io.Fallocate$FallocateHolderPOSIX at freenet.support.io.Fallocate.execute(Fallocate.java:72) at freenet.support.io.PooledFileRandomAccessBuffer.(PooledFileRandomAccessBuffer.java:106) at freenet.support.io.PooledFileRandomAccessBuffer.(PooledFileRandomAccessBuffer.java:85) at freenet.support.io.PooledFileRandomAccessBufferFactory.makeRAF(PooledFileRandomAccessBufferFactory.java:32) at freenet.support.io.DiskSpaceCheckingRandomAccessBufferFactory.makeRAF(DiskSpaceCheckingRandomAccessBufferFactory.java:42) at freenet.support.io.MaybeEncryptedRandomAccessBufferFactory.makeRAF(MaybeEncryptedRandomAccessBufferFactory.java:42) at freenet.client.async.SplitFileInserterStorage.(SplitFileInserterStorage.java:532) at freenet.client.async.SplitFileInserter.(SplitFileInserter.java:86) at freenet.client.async.SingleFileInserter.onCompressedInner(SingleFileInserter.java:380) at freenet.client.async.SingleFileInserter.onCompressed(SingleFileInserter.java:165) at freenet.client.async.InsertCompressor$3.run(InsertCompressor.java:227) at freenet.client.async.PersistentJobRunnerImpl$JobRunnable.run(PersistentJobRunnerImpl.java:136) at freenet.support.PooledExecutor$MyThread.innerRun(PooledExecutor.java:249) at freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:189) at freenet.support.io.NativeThread.run(NativeThread.java:156) Nov 04, 2020 10:57:36:940 (freenet.client.InsertException, (16), ERROR): Internal error: freenet.client.InsertException: Internal error:
[no subject]
Subject: Update to Jinja2 2.11.2
Another port I work on requires py3-jinja2>=2.10.1.
"make test" passes and sysutils/ansible is still happy.
Switch to stable PYPI releases and update HOMEPAGE while here.
OK?
---
www/py-jinja2/Makefile | 10 +++---
www/py-jinja2/distinfo | 4 ++--
www/py-jinja2/pkg/PLIST | 1 -
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/www/py-jinja2/Makefile b/www/py-jinja2/Makefile
index 7fbb984dcb0..376c18fdcb4 100644
--- a/www/py-jinja2/Makefile
+++ b/www/py-jinja2/Makefile
@@ -2,18 +2,13 @@
COMMENT = fast, optionally sandboxed, Python template engine
-MODPY_EGG_VERSION =2.10
+MODPY_EGG_VERSION =2.11.2
DISTNAME = Jinja2-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME:L}
-REVISION= 0
-
-GH_ACCOUNT=pallets
-GH_PROJECT=jinja
-GH_TAGNAME=${MODPY_EGG_VERSION}
CATEGORIES = www devel
-HOMEPAGE = http://jinja.pocoo.org/
+HOMEPAGE = https://jinja.palletsprojects.com
MAINTAINER = frantisek holop
@@ -28,5 +23,6 @@ FLAVOR ?=
MODPY_SETUPTOOLS = Yes
MODPY_PYTEST = Yes
+MODPY_PI = Yes
.include
diff --git a/www/py-jinja2/distinfo b/www/py-jinja2/distinfo
index f6fb2b2ba63..a85018aa47b 100644
--- a/www/py-jinja2/distinfo
+++ b/www/py-jinja2/distinfo
@@ -1,2 +1,2 @@
-SHA256 (Jinja2-2.10.tar.gz) = DTHTRmwxOpygFKLZBP7RjNrIc6W6H3twuP2LIGzYYNY=
-SIZE (Jinja2-2.10.tar.gz) = 267508
+SHA256 (Jinja2-2.11.2.tar.gz) = iaqyFUJ+9Zw0rVhzUmnrWLGlgIEDBn97udWDbGUbO7A=
+SIZE (Jinja2-2.11.2.tar.gz) = 257594
diff --git a/www/py-jinja2/pkg/PLIST b/www/py-jinja2/pkg/PLIST
index 5d8c747efe2..8f8cb60c8b3 100644
--- a/www/py-jinja2/pkg/PLIST
+++ b/www/py-jinja2/pkg/PLIST
@@ -4,7 +4,6 @@
lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_V
lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/entry_points.txt
-lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/Jinja2-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/jinja2/
--
2.27.0
[no subject]
Bcc:
Subject: Re: sparc64 bulk build report
Reply-To:
In-Reply-To: <1bebe74f6a8d3...@sparc64-0.ports.openbsd.org>
On Wed, May 20, 2020 at 05:27:42PM -0600, k...@openbsd.org wrote:
> Bulk build on sparc64-0.ports.openbsd.org
> Started : Sun May 17 19:51:14 MDT 2020
> Finished: Wed May 20 17:27:14 MDT 2020
> Duration: 2 Days 21 hours 36 minutes
> http://build-failures.rhaalovely.net/sparc64/2020-05-17/devel/glade.log
glade-settings.c: In function 'glade_settings_load':
glade-settings.c:239: error: 'for' loop initial declaration used outside C99
mode
gmake[3]: *** [Makefile:686: glade-glade-settings.o] Error 1
This diff adds -std=gnu99 to CFLAGS to fix compilation on sparc64 (and
other base-gcc arches).
I tested this in the following build. It fixes the build for sparc64.
ok?
(cc maintainers)
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/glade/Makefile,v
retrieving revision 1.88
diff -u -p -r1.88 Makefile
--- Makefile14 May 2020 15:13:34 - 1.88
+++ Makefile21 May 2020 05:28:21 -
@@ -45,6 +45,8 @@ MODGNOME_TOOLS += gobject-introspection
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS += --disable-webkit2gtk
+CFLAGS += -std=gnu99
+
DEBUG_PACKAGES = ${BUILD_PACKAGES}
post-install:
(No Subject)
subscribe
[no subject]
Updated url for simh pkg/DESC file. cvs server: Diffing . cvs server: Diffing patches cvs server: Diffing pkg Index: pkg/DESCR === RCS file: /cvs/ports/emulators/simh/pkg/DESCR,v retrieving revision 1.10 diff -u -p -r1.10 DESCR --- pkg/DESCR 10 May 2007 21:01:15 - 1.10 +++ pkg/DESCR 1 Mar 2019 07:43:51 - @@ -20,5 +20,5 @@ Simulators included in this package: - Royal-Mcbee LGP-30, LGP-21 - Scientific Data Systems SDS 940 -See http://www.openbsd.org/vax-simh.html for instructions on how to run +See http://www.openbsd.org/vax.html for instructions on how to run OpenBSD/vax on simh-vax. 02:44:57 /usr/ports/emulators/simh $ doas cvs diff cvs server: Diffing . cvs server: Diffing patches cvs server: Diffing pkg Index: pkg/DESCR === RCS file: /cvs/ports/emulators/simh/pkg/DESCR,v retrieving revision 1.10 diff -u -p -r1.10 DESCR --- pkg/DESCR 10 May 2007 21:01:15 - 1.10 +++ pkg/DESCR 1 Mar 2019 07:45:03 - @@ -20,5 +20,5 @@ Simulators included in this package: - Royal-Mcbee LGP-30, LGP-21 - Scientific Data Systems SDS 940 -See http://www.openbsd.org/vax-simh.html for instructions on how to run +See http://www.openbsd.org/vax.html for instructions on how to run OpenBSD/vax on simh-vax.
[no subject]
ikhbarkeba06
[no subject]
ส่งจากสมาร์ทโฟน vivo ของฉัน
[no subject]
ok? Index: Makefile === RCS file: /cvs/ports/textproc/elasticsearch/Makefile,v retrieving revision 1.53 diff -u -p -r1.53 Makefile --- Makefile4 Apr 2018 17:18:18 - 1.53 +++ Makefile25 Apr 2018 18:52:45 - @@ -5,7 +5,7 @@ COMMENT=distributed RESTful search and V= 5.6.4 DISTNAME= elasticsearch-$V CATEGORIES=textproc -REVISION= 1 +REVISION= 2 HOMEPAGE= https://www.elastic.co/products/elasticsearch Index: pkg/README === RCS file: /cvs/ports/textproc/elasticsearch/pkg/README,v retrieving revision 1.5 diff -u -p -r1.5 README --- pkg/README 17 Dec 2016 12:11:02 - 1.5 +++ pkg/README 25 Apr 2018 18:52:45 - @@ -35,6 +35,12 @@ the open files limit in login.conf(5): # sysctl -w kern.maxfiles=32768 # echo "kern.maxfiles=32768" >> /etc/sysctl.conf +If you are getting "java.io.IOException: No locks available" errors, +you need to increase kern.maxlocksperuid over the deafault of 1024: + + # sysctl -w kern.maxlocksperuid=2048 + # echo "kern.maxlocksperuid=2048" >> /etc/sysctl.conf + Elasticsearch Plugins Management Elasticsearch plugins management involves running Java code which can download
[no subject]
So what's the damaged Sent from Yahoo Mail on Android
[no subject]
[no subject]
[no subject]
[no subject]
K Sent using CloudMagic [https://cloudmagic.com/k/d/mailapp?ct=pacv=6.3.45pv=4.4.2]
[no subject]
Fuck u pussy boy
[no subject]
[no subject]
[no subject]
[no subject]
[no subject]
unsubscribe
[no subject]
unsubscripbe
[no subject]
[no subject]
I'd like to remove this write_size constraint, as suggested by
jakemsr@ some time ago:
http://marc.info/?l=openbsd-portsm=128630571914847
http://marc.info/?l=openbsd-portsm=128630890119517
As jake said, 1024 bytes is only 256 samples of 16-bit stereo.
At 44.1kHz, that's only 5.8 miliseconds. If mpd takes more than
5.8 ms between writes, for whatever reason, it will skip.
So, this represents a performance penalty on fast machines and
afaik sndiod should already cope with eventual stuffups just
fine on slower ones...
Alexandre, what do you think about this? Is it reasonable?
ciao
David
Index: Makefile
===
RCS file: /cvs/ports/audio/mpd/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- Makefile4 Mar 2012 16:57:19 - 1.43
+++ Makefile5 Mar 2012 09:48:13 -
@@ -2,6 +2,7 @@
COMMENT = Music Player Daemon
DISTNAME = mpd-0.16.7
+REVISION = 0
CATEGORIES = audio
HOMEPAGE = http://www.musicpd.org/
MAINTAINER = David Coppa dco...@openbsd.org
Index: patches/patch-doc_mpd_conf_5
===
RCS file: patches/patch-doc_mpd_conf_5
diff -N patches/patch-doc_mpd_conf_5
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-doc_mpd_conf_55 Mar 2012 09:48:13 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Remove write_size constraint. See:
+http://marc.info/?l=openbsd-portsm=128630571914847
+http://marc.info/?l=openbsd-portsm=128630890119517
+
+--- doc/mpd.conf.5.origMon Mar 5 10:33:42 2012
doc/mpd.conf.5 Mon Mar 5 10:34:09 2012
+@@ -390,11 +390,6 @@ for available options for some commonly used drivers.
+ using =, and ; is used to separate options. An example for oss:
+ dsp=/dev/dsp. An example for alsa09: dev=hw:0,0;buf_size=4096. The
+ default is .
+-.TP
+-.B write_size size in bytes
+-This specifies how many bytes to write to the audio device at once. This
+-parameter is to work around a bug in older versions of libao on sound cards
+-with very small buffers. The default is 1024.
+ .SH REQUIRED FIFO OUTPUT PARAMETERS
+ .TP
+ .B path path
Index: patches/patch-src_output_ao_plugin_c
===
RCS file: patches/patch-src_output_ao_plugin_c
diff -N patches/patch-src_output_ao_plugin_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_output_ao_plugin_c5 Mar 2012 09:48:13 -
@@ -0,0 +1,35 @@
+$OpenBSD$
+
+Remove write_size constraint. See:
+http://marc.info/?l=openbsd-portsm=128630571914847
+http://marc.info/?l=openbsd-portsm=128630890119517
+
+--- src/output/ao_plugin.c.origMon Mar 5 10:34:57 2012
src/output/ao_plugin.c Mon Mar 5 10:35:21 2012
+@@ -32,7 +32,6 @@ static const ao_sample_format OUR_AO_FORMAT_INITIALIZE
+ static unsigned ao_output_ref;
+
+ struct ao_data {
+- size_t write_size;
+ int driver;
+ ao_option *options;
+ ao_device *device;
+@@ -89,8 +88,6 @@ ao_output_init(G_GNUC_UNUSED const struct audio_format
+
+ ad-options = NULL;
+
+- ad-write_size = config_get_block_unsigned(param, write_size, 1024);
+-
+ if (ao_output_ref == 0) {
+ ao_initialize();
+ }
+@@ -230,9 +227,6 @@ ao_output_play(void *data, const void *chunk, size_t s
+ GError **error)
+ {
+ struct ao_data *ad = (struct ao_data *)data;
+-
+- if (size ad-write_size)
+- size = ad-write_size;
+
+ if (ao_play_deconst(ad-device, chunk, size) == 0) {
+ ao_output_error(error);
[no subject]
FAÇA UM ORÇAMENTO SEM COMPROMISSO!
[no subject]
Richiesta di autorizzazione all'invio dell'email L'Altra Dimensione esegue lavori di Ristrutturazione, imbiancature, controsoffittature, decorazione, coibentazioni termoacustici, trattamenti antimuffa, rifacimento tetti, canne fumarie ecc... Fornitura e posa di parquet, porte, finestre, zanzariere, sanitari, rubinetteria, piastrelle ... www.laltradimensione.it Informativa sulla Privacy: Non abbiamo alcun Vs. dato personale, h stato raccolto da elenchi pubblici disponibili sia in forma cartacea che on-line (Pagine Gialle, Pagine bianche, motori di ricerca) e sono trattati secondo le disposizioni del D.Lgs 196/03. Qualora non desideriate ricevere in futuro comunicazioni commerciali dalla ditta scrivente potete opporVi ed esercitare i diritti previsti dall'art. 7 del codice della privacy inviando un messaggio di posta elettronica cliccando NON AUTORIZZO e indicando i dati da cancellare. Un messaggio Vi confermer` l'accoglimento della Vs. istanza e la conseguente cancellazione della vostra posta elettronica. NON AUTORIZZO
[no subject]
Richiesta di autorizzazione all'invio dell'email L'Altra Dimensione esegue lavori di Ristrutturazione, imbiancature, controsoffittature, decorazione, coibentazioni termoacustici, trattamenti antimuffa, rifacimento tetti, canne fumarie ecc... Fornitura e posa di parquet, porte, finestre, zanzariere, sanitari, rubinetteria, piastrelle ... www.laltradimensione.it Informativa sulla Privacy: Non abbiamo alcun Vs. dato personale, è stato raccolto da elenchi pubblici disponibili sia in forma cartacea che on-line (Pagine Gialle, Pagine bianche, motori di ricerca) e sono trattati secondo le disposizioni del D.Lgs 196/03. Qualora non desideriate ricevere in futuro comunicazioni commerciali dalla ditta scrivente potete opporVi ed esercitare i diritti previsti dall'art. 7 del codice della privacy inviando un messaggio di posta elettronica cliccando NON AUTORIZZO e indicando i dati da cancellare. Un messaggio Vi confermerà l'accoglimento della Vs. istanza e la conseguente cancellazione della vostra posta elettronica. NON AUTORIZZO
[no subject]
Simon Bertrang si...@openbsd.org Bcc: Subject: Re: UPDATE: textproc/p5-Text-Markdown and MultiMarkdown Reply-To: Mikolaj Kucharski miko...@kucharski.name In-Reply-To: 20101221211237.gr16...@openbsd-stable.my.domain On Tue, Dec 21, 2010 at 09:12:37PM +, Mikolaj Kucharski wrote: Hi Okan, Attached is a patch for p5-Text-Markdown update to version 1.31. This version drops previously included Text::MultiMarkdown module, so I'm attaching separate port for that. - regress tests pass for both modules - not sure how to handle @conflict and @pkgpath markers for this situation, I think removing them should be fine, as those ports do not conflict any more, as they could in the past - I think devel/quirks should be involved in this upgrade as someone who had previous p5-Text-Markdown installed and was using Text::MultiMarkdown module will get issues. - scripts from $PREFIX/bin got renamed Regards the ports dependant on above. I've checked textproc/p5-Catalyst-Plugin-Markdown textproc/p5-Template-Plugin-Markdown by searching for MultiMarkdown string: grep -R MultiMarkdown `make show=WRKDIR` and found no matching lines. I think this update shouldn't break anything currently in ports tree. Re quirks, I agree with what sthen@ wrote. I would skip any complications too. Any okays? Attachments: http://marc.info/?l=openbsd-portsm=129296684700341w=2 -- best regards q#
[no subject]
Hi, appended patch fixes the build of archivers/xz on sparc. Without the patch, configure was looking for a C99 compatible compiler but was not lucky with gcc-2.95. The patch uses the gcc3 module. Make regress passed all tests. please review and commit. cheers, Sebastian
[no subject]
We must protect our planet. Turn off your computer! Nous devons protéger notre planète. Ãteignez votre ordinateur! Debemos proteger nuestro planeta. Apague su ordenador! Musimy chroniÄ naszÄ planetÄ. WyÅÄ cz komputer! ÐÑ Ð´Ð¾Ð»Ð¶Ð½Ñ Ð·Ð°ÑиÑиÑÑ Ð½Ð°ÑÑ Ð¿Ð»Ð°Ð½ÐµÑÑ. ÐÑклÑÑиÑе компÑÑÑеÑ! http://www.theworld.su Send this message to all your contacts, thank you.
[no subject]
Has anyone succeeded in getting Class::MOP upgraded to 0.76 in their tree? I get 'make: don't know how to make t/pp_072_immutable_w_constructors.t. Stop in /usr/ports/devel/p5-Class-MOP/w-p5-Class-MOP-0.76/Class-MOP-0.76.'. Possibly worth noting is that between 0.75 and 0.76 the position, contents and name of create_pp_tests|get_pp_tests was changed. It works in cpan shell (make, make test and make install) though. ~/portslog/p5-Class-MOP-0.76.log and script(1) output of cpan -MCPAN -e'test Class::MOP' attached. (i386, February 6th snapshot, and I have p5-Class-MOP-0.75 and dependencies installed) Script started on Sun Feb 8 23:11:41 2009 # perl -MCPAN -e'test Class::MOP' CPAN: File::HomeDir loaded ok (v0.82) CPAN: Storable loaded ok (v2.18) Going to read /home/jamesw/.cpan/Metadata Database was generated on Sun, 08 Feb 2009 08:28:22 GMT Running test for module 'Class::MOP' Running make for D/DR/DROLSKY/Class-MOP-0.76.tar.gz CPAN: Digest::SHA loaded ok (v5.45) CPAN: Compress::Zlib loaded ok (v2.008) Checksum for /home/jamesw/.cpan/sources/authors/id/D/DR/DROLSKY/Class-MOP-0.76.tar.gz ok Class-MOP-0.76 Class-MOP-0.76/t Class-MOP-0.76/t/072_immutable_w_constructors.t Class-MOP-0.76/t/101_InstanceCountingClass_test.t Class-MOP-0.76/t/015_metaclass_inheritance.t Class-MOP-0.76/t/012_package_variables.t Class-MOP-0.76/t/019_anon_class_keep_alive.t Class-MOP-0.76/t/023_attribute_get_read_write.t Class-MOP-0.76/t/044_instance_metaclass_incompat_dyn.t Class-MOP-0.76/t/014_attribute_introspection.t Class-MOP-0.76/t/018_anon_class.t Class-MOP-0.76/t/302_modify_parent_method.t Class-MOP-0.76/t/041_metaclass_incompatibility.t Class-MOP-0.76/t/021_attribute_errors_and_edge_cases.t Class-MOP-0.76/t/046_rebless_instance.t Class-MOP-0.76/t/100_BinaryTree_test.t Class-MOP-0.76/t/200_Class_C3_compatibility.t Class-MOP-0.76/t/103_Perl6Attribute_test.t Class-MOP-0.76/t/005_attributes.t Class-MOP-0.76/t/010_self_introspection.t Class-MOP-0.76/t/001_basic.t Class-MOP-0.76/t/header_pp.inc Class-MOP-0.76/t/081_meta_package_extension.t Class-MOP-0.76/t/004_advanced_methods.t Class-MOP-0.76/t/000_load.t Class-MOP-0.76/t/107_C3MethodDispatchOrder_test.t Class-MOP-0.76/t/071_immutable_w_custom_metaclass.t Class-MOP-0.76/t/301_RT_27329_fix.t Class-MOP-0.76/t/013_add_attribute_alternate.t Class-MOP-0.76/t/048_anon_class_create_init.t Class-MOP-0.76/t/060_instance.t Class-MOP-0.76/t/011_create_class.t Class-MOP-0.76/t/022_attribute_duplication.t Class-MOP-0.76/t/303_RT_39001_fix.t Class-MOP-0.76/t/073_make_mutable.t Class-MOP-0.76/t/020_attribute.t Class-MOP-0.76/t/304_constant_codeinfo.t Class-MOP-0.76/t/082_get_code_info.t Class-MOP-0.76/t/305_RT_41255.t Class-MOP-0.76/t/300_random_eval_bug.t Class-MOP-0.76/t/105_ClassEncapsulatedAttributes_test.t Class-MOP-0.76/t/106_LazyClass_test.t Class-MOP-0.76/t/006_new_and_clone_metaclasses.t Class-MOP-0.76/t/017_add_method_modifier.t Class-MOP-0.76/t/003_methods.t Class-MOP-0.76/t/030_method.t Class-MOP-0.76/t/104_AttributesWithHistory_test.t Class-MOP-0.76/t/045_metaclass_loads_classes.t Class-MOP-0.76/t/031_method_modifiers.t Class-MOP-0.76/t/043_instance_metaclass_incompat.t Class-MOP-0.76/t/047_rebless_with_extra_params.t Class-MOP-0.76/t/lib Class-MOP-0.76/t/lib/MyMetaClass Class-MOP-0.76/t/lib/MyMetaClass/Instance.pm Class-MOP-0.76/t/lib/MyMetaClass/Random.pm Class-MOP-0.76/t/lib/MyMetaClass/Method.pm Class-MOP-0.76/t/lib/MyMetaClass/Attribute.pm Class-MOP-0.76/t/lib/BinaryTree.pm Class-MOP-0.76/t/lib/MyMetaClass.pm Class-MOP-0.76/t/lib/TestClassLoaded.pm Class-MOP-0.76/t/lib/SyntaxError.pm Class-MOP-0.76/t/042_metaclass_incompatibility_dyn.t Class-MOP-0.76/t/083_load_class.t Class-MOP-0.76/t/024_attribute_initializer.t Class-MOP-0.76/t/050_scala_style_mixin_composition.t Class-MOP-0.76/t/040_metaclass.t Class-MOP-0.76/t/016_class_errors_and_edge_cases.t Class-MOP-0.76/t/108_ArrayBasedStorage_test.t Class-MOP-0.76/t/080_meta_package.t Class-MOP-0.76/t/061_instance_inline.t Class-MOP-0.76/t/102_InsideOutClass_test.t Class-MOP-0.76/t/070_immutable_metaclass.t Class-MOP-0.76/t/306_is_class_loaded.t Class-MOP-0.76/t/002_class_precedence_list.t Class-MOP-0.76/examples Class-MOP-0.76/examples/InstanceCountingClass.pod Class-MOP-0.76/examples/C3MethodDispatchOrder.pod Class-MOP-0.76/examples/Perl6Attribute.pod Class-MOP-0.76/examples/ArrayBasedStorage.pod Class-MOP-0.76/examples/InsideOutClass.pod Class-MOP-0.76/examples/LazyClass.pod Class-MOP-0.76/examples/AttributesWithHistory.pod Class-MOP-0.76/examples/ClassEncapsulatedAttributes.pod Class-MOP-0.76/META.yml Class-MOP-0.76/Changes Class-MOP-0.76/README Class-MOP-0.76/MANIFEST.SKIP Class-MOP-0.76/MANIFEST Class-MOP-0.76/Makefile.PL Class-MOP-0.76/typemap Class-MOP-0.76/ppport.h Class-MOP-0.76/MOP.xs Class-MOP-0.76/lib Class-MOP-0.76/lib/metaclass.pm Class-MOP-0.76/lib/Class Class-MOP-0.76/lib/Class/MOP.pm Class-MOP-0.76/lib/Class/MOP Class-MOP-0.76/lib/Class/MOP/Package.pm Class-MOP-0.76/lib/Class/MOP/Instance.pm
