[oi-dev] some Newbie questions
Friedrich Kink
friedrich.kink at fkink.de
Wed Dec 29 20:35:17 UTC 2021
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 stes at 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-dev at 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 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 at openindiana.org
>>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>> _______________________________________________
>>>> oi-dev mailing list
>>>> oi-dev at openindiana.org
>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>
>> _______________________________________________
>> oi-dev mailing list
>> oi-dev at openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20211229/1eb07f52/attachment.html>
More information about the oi-dev
mailing list