Re: [oi-dev] some Newbie questions
In regard to: Re: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: finally I was able to push my new package. May I ask the maintainers to check the perl module Tk (components/per/Tk) in my branch Tk. If this is not the right way for asking please let me know. Once you pushed from your build box to your fork of oi-userland in your github account, the next step is for you to open a "pull request" (PR). At least with git on my build box, when I *first* push a new branch from my build box to my forked repository in my github account, the git client actually outputs a URL that I can just cut-and-paste into a browser to go right to the new pull request. If that wasn't the case for you, that's no problem. You just need to go to your forked copy of oi-userland in github (the drop-down from your profile in the upper-right corner has a "Your repositories" selection, you can find your copy of oi-userland in that list). Once you're viewing your fork of oi-userland, there should be a bit of information near the top that talks about your "Tk" branch, with a button for you to open a pull (or merge) request. If you click that and fill in any additional information you feel is relevant, your pull request will become visible to the OpenIndiana/oi-userland, under pull requests. The rest of the review and merge workflow will happen within that pull request. PS: I'm not much ahead of you on github workflow and git, and virtually everything I've learned has been from patient coaching of OI maintainers like Alexander, Aurélien, Michal, and now Andreas. Don't be afraid to ask questions here, and don't worry about being a github "newbie". I am too, but I'll happily help when I can, as will others I'm sure. Tim Thanks a lot, Fritz Am 29.12.2021 um 20:52 schrieb Andreas Wacknitz: Am 12/29/21 um 20:46 schrieb Friedrich Kink via oi-dev: Hi David, basically I prepared the package ;-) but I'm not able to push it as described at the end at https://docs.openindiana.org/dev/userland/. I get (I did |git checkout -b Tk before) | git push origin Tk remote: Permission to OpenIndiana/oi-userland.git denied to fritzkink. You'll need to check what origin is. "git remote -v" will tell you about your configured remotes. You are only allowed to push to Github repositories that you have sufficient rights for. This is typically your own fork. When you push to your own fork (which is usually but not necessarily named origin) you can then create a PR (pull request) against the repository you have forked from on Github. which is probably ok as it most likely has to be reviewed by maintainers first. Otherwise I'm just struggling with my limited git experience. kind regards, Fritz Am 28.12.2021 um 20:19 schrieb s...@pandora.be: Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the pagehttps://tug.org/texlive/distro.html lists: Debian: aptitude install perl-tk Ubuntu: apt-get install perl-tk Gentoo: emerge dev-perl/Tk # older: dev-perl/tk ... but no OpenIndiana. However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl. It would be nice if you could just do "pkg install perl-tk" in OpenIndiana. This is a personal opinion, I do not know whether such a package would be hard/difficult to make, and whether it would be accepted. But TCL/Tk is in the OpenIndiana repo. TCL version 8.6.12, which should be fine for TexLive as this requests TCL 8.5 or higher. In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui: http://docs.openindiana.org/handbook/community/texlive/ Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution. Regards, David Stes - Op 28 dec 2021 om 13:11 schreef oi-devoi-...@openindiana.org: Hello Tim, thank you for the warm welcome. And thank you for the very valuable answers and hints. They helped already a lot. I guess I 'll need some more time to get to the nitty-gritty details. But I hope to be able to upload a first package soon. Fritz Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it tu
Re: [oi-dev] some Newbie questions
finally I was able to push my new package. May I ask the maintainers to check the perl module Tk (components/per/Tk) in my branch Tk. If this is not the right way for asking please let me know. Thanks a lot, Fritz Am 29.12.2021 um 20:52 schrieb Andreas Wacknitz: Am 12/29/21 um 20:46 schrieb Friedrich Kink via oi-dev: Hi David, basically I prepared the package ;-) but I'm not able to push it as described at the end at https://docs.openindiana.org/dev/userland/. I get (I did |git checkout -b Tk before) | git push origin Tk remote: Permission to OpenIndiana/oi-userland.git denied to fritzkink. You'll need to check what origin is. "git remote -v" will tell you about your configured remotes. You are only allowed to push to Github repositories that you have sufficient rights for. This is typically your own fork. When you push to your own fork (which is usually but not necessarily named origin) you can then create a PR (pull request) against the repository you have forked from on Github. which is probably ok as it most likely has to be reviewed by maintainers first. Otherwise I'm just struggling with my limited git experience. kind regards, Fritz Am 28.12.2021 um 20:19 schrieb s...@pandora.be: Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the pagehttps://tug.org/texlive/distro.html lists: Debian: aptitude install perl-tk Ubuntu: apt-get install perl-tk Gentoo: emerge dev-perl/Tk # older: dev-perl/tk ... but no OpenIndiana. However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl. It would be nice if you could just do "pkg install perl-tk" in OpenIndiana. This is a personal opinion, I do not know whether such a package would be hard/difficult to make, and whether it would be accepted. But TCL/Tk is in the OpenIndiana repo. TCL version 8.6.12, which should be fine for TexLive as this requests TCL 8.5 or higher. In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui: http://docs.openindiana.org/handbook/community/texlive/ Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution. Regards, David Stes - Op 28 dec 2021 om 13:11 schreef oi-devoi-...@openindiana.org: Hello Tim, thank you for the warm welcome. And thank you for the very valuable answers and hints. They helped already a lot. I guess I 'll need some more time to get to the nitty-gritty details. But I hope to be able to upload a first package soon. Fritz Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? It's likely a combination of - limited contributor time - contributor interest - complexity of the task I do have an update to perl planned, but there are some details to work out and I probably won't be back to looking at the perl modules until I'm done with some MATE-related stuff. Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a question for me and my understanding ;-))? That reason for that is probably documented in the documentation for pkg, http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf though I would have to do some searching to find the exact section. I think it comes down to "design choice". As much as I like perl and have done lots of programming with it over the years, its module numbering system leaves a lot to be desired. The standardization on "semantic versioning" that most other software has done would be a welcome change in the perl module community, IMHO. That, of course, will never happen, but it sure would be nice if it did. Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? There is a file in oi-userland that
Re: [oi-dev] some Newbie questions
Am 12/29/21 um 20:46 schrieb Friedrich Kink via oi-dev: Hi David, basically I prepared the package ;-) but I'm not able to push it as described at the end at https://docs.openindiana.org/dev/userland/. I get (I did |git checkout -b Tk before) | git push origin Tk remote: Permission to OpenIndiana/oi-userland.git denied to fritzkink. You'll need to check what origin is. "git remote -v" will tell you about your configured remotes. You are only allowed to push to Github repositories that you have sufficient rights for. This is typically your own fork. When you push to your own fork (which is usually but not necessarily named origin) you can then create a PR (pull request) against the repository you have forked from on Github. which is probably ok as it most likely has to be reviewed by maintainers first. Otherwise I'm just struggling with my limited git experience. kind regards, Fritz Am 28.12.2021 um 20:19 schrieb s...@pandora.be: Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the pagehttps://tug.org/texlive/distro.html lists: Debian: aptitude install perl-tk Ubuntu: apt-get install perl-tk Gentoo: emerge dev-perl/Tk # older: dev-perl/tk ... but no OpenIndiana. However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl. It would be nice if you could just do "pkg install perl-tk" in OpenIndiana. This is a personal opinion, I do not know whether such a package would be hard/difficult to make, and whether it would be accepted. But TCL/Tk is in the OpenIndiana repo. TCL version 8.6.12, which should be fine for TexLive as this requests TCL 8.5 or higher. In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui: http://docs.openindiana.org/handbook/community/texlive/ Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution. Regards, David Stes - Op 28 dec 2021 om 13:11 schreef oi-devoi-...@openindiana.org: Hello Tim, thank you for the warm welcome. And thank you for the very valuable answers and hints. They helped already a lot. I guess I 'll need some more time to get to the nitty-gritty details. But I hope to be able to upload a first package soon. Fritz Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? It's likely a combination of - limited contributor time - contributor interest - complexity of the task I do have an update to perl planned, but there are some details to work out and I probably won't be back to looking at the perl modules until I'm done with some MATE-related stuff. Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a question for me and my understanding ;-))? That reason for that is probably documented in the documentation for pkg, http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf though I would have to do some searching to find the exact section. I think it comes down to "design choice". As much as I like perl and have done lots of programming with it over the years, its module numbering system leaves a lot to be desired. The standardization on "semantic versioning" that most other software has done would be a welcome change in the perl module community, IMHO. That, of course, will never happen, but it sure would be nice if it did. Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? There is a file in oi-userland that documents the reserved IDs: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md If you need to add to that list, starting with a PR for that file is probably the way to go. How to store test results (I haven't found the trick where the
Re: [oi-dev] some Newbie questions
Hi David, basically I prepared the package ;-) but I'm not able to push it as described at the end at https://docs.openindiana.org/dev/userland/. I get (I did |git checkout -b Tk before) | git push origin Tk remote: Permission to OpenIndiana/oi-userland.git denied to fritzkink. which is probably ok as it most likely has to be reviewed by maintainers first. Otherwise I'm just struggling with my limited git experience. kind regards, Fritz Am 28.12.2021 um 20:19 schrieb s...@pandora.be: Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the pagehttps://tug.org/texlive/distro.html lists: Debian: aptitude install perl-tk Ubuntu: apt-get install perl-tk Gentoo: emerge dev-perl/Tk # older: dev-perl/tk ... but no OpenIndiana. However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl. It would be nice if you could just do "pkg install perl-tk" in OpenIndiana. This is a personal opinion, I do not know whether such a package would be hard/difficult to make, and whether it would be accepted. But TCL/Tk is in the OpenIndiana repo. TCL version 8.6.12, which should be fine for TexLive as this requests TCL 8.5 or higher. In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui: http://docs.openindiana.org/handbook/community/texlive/ Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution. Regards, David Stes - Op 28 dec 2021 om 13:11 schreef oi-devoi-...@openindiana.org: Hello Tim, thank you for the warm welcome. And thank you for the very valuable answers and hints. They helped already a lot. I guess I 'll need some more time to get to the nitty-gritty details. But I hope to be able to upload a first package soon. Fritz Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? It's likely a combination of - limited contributor time - contributor interest - complexity of the task I do have an update to perl planned, but there are some details to work out and I probably won't be back to looking at the perl modules until I'm done with some MATE-related stuff. Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a question for me and my understanding ;-))? That reason for that is probably documented in the documentation for pkg, http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf though I would have to do some searching to find the exact section. I think it comes down to "design choice". As much as I like perl and have done lots of programming with it over the years, its module numbering system leaves a lot to be desired. The standardization on "semantic versioning" that most other software has done would be a welcome change in the perl module community, IMHO. That, of course, will never happen, but it sure would be nice if it did. Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? There is a file in oi-userland that documents the reserved IDs: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md If you need to add to that list, starting with a PR for that file is probably the way to go. How to store test results (I haven't found the trick where the results get stored in the test directory while comparing existing packages with mine). Create the test directory and within there create (touch) results-32.master # if your component has a 32 bit build results-64.master # if your component has a 64 bit build there are other possible variants the file could be named, for special build conditions. Look through the test directories for the various components in oi-userland to get
Re: [oi-dev] some Newbie questions
Personally I'd like to request a perl tk package. This can be used for TeXLive on OpenIndiana. Currently the page https://tug.org/texlive/distro.html lists: Debian: aptitude install perl-tk Ubuntu: apt-get install perl-tk Gentoo: emerge dev-perl/Tk # older: dev-perl/tk ... but no OpenIndiana. However I'm sure that if there were a perl-tk package, then it'd work for TexLive install-tl. It would be nice if you could just do "pkg install perl-tk" in OpenIndiana. This is a personal opinion, I do not know whether such a package would be hard/difficult to make, and whether it would be accepted. But TCL/Tk is in the OpenIndiana repo. TCL version 8.6.12, which should be fine for TexLive as this requests TCL 8.5 or higher. In fact I am sure perl/tk works, I compile it manually for the tlmgr -gui: http://docs.openindiana.org/handbook/community/texlive/ Anyway if you would have a look at the Perl packages, I guess that would be a most welcome contribution. Regards, David Stes - Op 28 dec 2021 om 13:11 schreef oi-dev oi-dev@openindiana.org: > Hello Tim, > > thank you for the warm welcome. And thank you for the very valuable > answers and hints. They helped already a lot. I guess I 'll need some > more time to get to the nitty-gritty details. But I hope to be able to > upload a first package soon. > > Fritz > > Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: >> In regard to: [oi-dev] some Newbie questions, Friedrich Kink via >> oi-dev...: >> >> Hello and welcom, Fritz! >> >>> reading silently for a couple of years this mailing list I decided >>> now to contribute to the community my extensions I made over the >>> years to my system (at least I'd like to try ;-)). The main purpose >>> of my system is to act as mail server supporting all modern security >>> features like DANE, SPF, DKIM, DMARC etc (which works btw for couple >>> of years already, basically I started with opensolaris). That's why >>> I'll focus on those packages. Of course I've some questions after >>> starting this endeavor. Especially when trying to build Spamassassin >>> which requires a lot of additional Perl modules. While start building >>> these modules it turned out that the provided 64bit Perl version 5.24 >>> is pretty outdated. So I built the current stable version 5.34 based >>> on the existing 5.24 setup. Worked like a charm ;-). Now first >>> question: Is there a reason/dependency for not upgrading to a newer >>> version? >> >> It's likely a combination of >> >> - limited contributor time >> - contributor interest >> - complexity of the task >> >> I do have an update to perl planned, but there are some details >> to work out and I probably won't be back to looking at the perl modules >> until I'm done with some MATE-related stuff. >> >>> Next question: Some Perl modules have odd version like 1.04 which >>> makes publishing a package impossible because of the padding zero in >>> the number after the dot. What is the reason for bailing out on a >>> padding zero (just a question for me and my understanding ;-))? >> >> That reason for that is probably documented in the documentation for pkg, >> >> http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf >> >> though I would have to do some searching to find the exact section. I >> think it comes down to "design choice". >> >> As much as I like perl and have done lots of programming with it over >> the years, its module numbering system leaves a lot to be desired. The >> standardization on "semantic versioning" that most other software has >> done would be a welcome change in the perl module community, IMHO. That, >> of course, will never happen, but it sure would be nice if it did. >> >>> Also, some packages will require a new user and/or group. Are >>> uids/gids managed centrally or can I just choose some numbers <100 >>> not used to my best knowledge? >> >> There is a file in oi-userland that documents the reserved IDs: >> >> >> https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md >> >> >> If you need to add to that list, starting with a PR for that file is >> probably the way to go. >> >>> How to store test results (I haven't found the trick where the >>> results get stored in the test directory while comparing existing >>> packages with mine). >> >> Create the test directory and within there create (touch) >> >> results-32.master # if your component has a 32 bit build >> results-64.master # if your component has a 64 bit build >> >> there are other possible variants the file could be named, for special >> build conditions. Look through the test directories for the various >> components in oi-userland to get an idea of other possibilities. >> >> Then, add various COMPONENT_TEST_TRANSFORMS to your Makefile, to filter >> out any of the test output that will vary between build systems (PATHs, >> timing, etc.). >> >> Once you have (empty) results files, the test target will
Re: [oi-dev] some Newbie questions
Am 27.12.21 um 21:19 schrieb Friedrich Kink via oi-dev: Hi all, Hi Friedrich, welcome to OpenIndiana. I am happy that you will provide help for some interesting areas where we miss specialists. reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a I recommend to clone our main repository: OpenIndiana/oi-userland (https://github.com/OpenIndiana/oi-userland). Within this you'll find a folder named "doc" that contains important information, eg. reserved_uids_and_gids.md, which may answer your question regarding user and group ids (hint: the file needs an update if you add something). Start reading on our documentation server, eg. "Building with oi-userland" (https://docs.openindiana.org/dev/userland/). Regarding odd version numbers like 1.04 in your example. Alas we are restricted to what FMRI gave us and the version numbers are just a part of the package's FMRI. While we are stuck on this there are some helping definitions possible, eg. by additionally use IPS_COMPONENT_VERSION (this is the one that ends in the FMRI and is automatically set by COMPONENT_VERSION if not explicitly set to another value) and HUMAN_VERSION, which can additionally be used to add the "real" version information for a package. See for an example what actual components/sysutils/sudo does to provide the HUMAN_VERSION (hint: you'll need to have a definition in the Makefile and also a reference in the manifest). It is always a good idea to look for existing solutions for a problem you encounter. Typically it has already been solved by other packages. question for me and my understanding ;-))? Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? How to store test results (I haven't found the trick where the results get stored in the test directory while comparing existing packages with mine). And finally when I think I'm ready to release my package would this list be the place to ask for integration? thanks a lot for all the work already, Fritz Regards, Andreas ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] some Newbie questions
Hello Tim, thank you for the warm welcome. And thank you for the very valuable answers and hints. They helped already a lot. I guess I 'll need some more time to get to the nitty-gritty details. But I hope to be able to upload a first package soon. Fritz Am 27.12.2021 um 23:11 schrieb Tim Mooney via oi-dev: In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? It's likely a combination of - limited contributor time - contributor interest - complexity of the task I do have an update to perl planned, but there are some details to work out and I probably won't be back to looking at the perl modules until I'm done with some MATE-related stuff. Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a question for me and my understanding ;-))? That reason for that is probably documented in the documentation for pkg, http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf though I would have to do some searching to find the exact section. I think it comes down to "design choice". As much as I like perl and have done lots of programming with it over the years, its module numbering system leaves a lot to be desired. The standardization on "semantic versioning" that most other software has done would be a welcome change in the perl module community, IMHO. That, of course, will never happen, but it sure would be nice if it did. Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? There is a file in oi-userland that documents the reserved IDs: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md If you need to add to that list, starting with a PR for that file is probably the way to go. How to store test results (I haven't found the trick where the results get stored in the test directory while comparing existing packages with mine). Create the test directory and within there create (touch) results-32.master # if your component has a 32 bit build results-64.master # if your component has a 64 bit build there are other possible variants the file could be named, for special build conditions. Look through the test directories for the various components in oi-userland to get an idea of other possibilities. Then, add various COMPONENT_TEST_TRANSFORMS to your Makefile, to filter out any of the test output that will vary between build systems (PATHs, timing, etc.). Once you have (empty) results files, the test target will start outputting diffs. Incorporate the output into your results files until there are no more diffs. And finally when I think I'm ready to release my package would this list be the place to ask for integration? You can mention it here if you want, but following the "Building with oi-userland" guide has a section on preparing your Github pull request (PR). Most of the component update work happens following that guide, and the final integration piece comes via the pull request. http://docs.openindiana.org/dev/userland/ Tim ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] some Newbie questions
In regard to: [oi-dev] some Newbie questions, Friedrich Kink via oi-dev...: Hello and welcom, Fritz! reading silently for a couple of years this mailing list I decided now to contribute to the community my extensions I made over the years to my system (at least I'd like to try ;-)). The main purpose of my system is to act as mail server supporting all modern security features like DANE, SPF, DKIM, DMARC etc (which works btw for couple of years already, basically I started with opensolaris). That's why I'll focus on those packages. Of course I've some questions after starting this endeavor. Especially when trying to build Spamassassin which requires a lot of additional Perl modules. While start building these modules it turned out that the provided 64bit Perl version 5.24 is pretty outdated. So I built the current stable version 5.34 based on the existing 5.24 setup. Worked like a charm ;-). Now first question: Is there a reason/dependency for not upgrading to a newer version? It's likely a combination of - limited contributor time - contributor interest - complexity of the task I do have an update to perl planned, but there are some details to work out and I probably won't be back to looking at the perl modules until I'm done with some MATE-related stuff. Next question: Some Perl modules have odd version like 1.04 which makes publishing a package impossible because of the padding zero in the number after the dot. What is the reason for bailing out on a padding zero (just a question for me and my understanding ;-))? That reason for that is probably documented in the documentation for pkg, http://docs.openindiana.org/dev/pdf/ips-dev-guide.pdf though I would have to do some searching to find the exact section. I think it comes down to "design choice". As much as I like perl and have done lots of programming with it over the years, its module numbering system leaves a lot to be desired. The standardization on "semantic versioning" that most other software has done would be a welcome change in the perl module community, IMHO. That, of course, will never happen, but it sure would be nice if it did. Also, some packages will require a new user and/or group. Are uids/gids managed centrally or can I just choose some numbers <100 not used to my best knowledge? There is a file in oi-userland that documents the reserved IDs: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/doc/reserved_uids_and_gids.md If you need to add to that list, starting with a PR for that file is probably the way to go. How to store test results (I haven't found the trick where the results get stored in the test directory while comparing existing packages with mine). Create the test directory and within there create (touch) results-32.master # if your component has a 32 bit build results-64.master # if your component has a 64 bit build there are other possible variants the file could be named, for special build conditions. Look through the test directories for the various components in oi-userland to get an idea of other possibilities. Then, add various COMPONENT_TEST_TRANSFORMS to your Makefile, to filter out any of the test output that will vary between build systems (PATHs, timing, etc.). Once you have (empty) results files, the test target will start outputting diffs. Incorporate the output into your results files until there are no more diffs. And finally when I think I'm ready to release my package would this list be the place to ask for integration? You can mention it here if you want, but following the "Building with oi-userland" guide has a section on preparing your Github pull request (PR). Most of the component update work happens following that guide, and the final integration piece comes via the pull request. http://docs.openindiana.org/dev/userland/ Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
