Greetings Fedora 29 got officially released on 30 October last year but no packages have been built for that release [1] as of today hence installation on the distro fails with.... Failed to synchronize cache for repo 'fred', ignoring this repo. No match for argument: fred-* Any particular reason the components have not been built for the 29 release of Fedora? Regards Jóhann B. 1. http://archive.nic.cz/yum/fred/fedora/ _______________________________________________ fred-users mailing list fred-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users

Hi Jaromir I need to take a deeper look at this since I'm already hitting violation in Fedora package guidelines so the spec files are not up to "spec" as ironic as that sounds and I need those to be up to specs before RHEL/CentOS 8 get's releases if we decided here at ISNIC to migrate to FRED ;) I made sure when I handled the legacy sys-v migration to type systemd units in the distribution that no new legacy sys-v initscripts would be added and all major linux distributions should have made the systemd service manager the default init system by now and have deprecate legacy sysv initscripts ( with the exception of Debian due to it's Hurd/kFreeBSD part of it's community ) so by shipping an legacy initscript you ( read as an upstream or downstream packager ) have added direct ( unnecessary ) dependency on legacy sysv ( assuming you have packaged it correctly thou many packagers in Fedora just wrongly assumed certain components existed there indefinitely, which made in longer, harder and more painful to make changes on the core/baseOS level ) . As an upstream you should ship only type unit files ( service,timers etc ) upstream and have those downstream that still use legacy sys v initscript maintain their own ( or keep it in a separated downstream package with correct dependency and requirements on legacy sysv init and cron component for cron jobs ). That said I'm going to see if I cant find the time to review this is and make some pull request to fix this unless there is some specific reason why you ( as an upstream ) are still shipping legacy sysv initscripts. ( thou the documentation [1] clearly mentions type systemd units as in fred-rifd.service which btw is not being shipped with those components in the corp repository ). Unfortunately there are still some downstream distribution shenanigans related to the core/basesOS setup like different package names and file and directory names ( like apache vs httpd or /etc/sysconfig which is RH specific nonsense ) which creates administrative/end users confusion and unnecessary load on upstream communities ( support/documentation etc ). I'll keep going through this and testing this and will file pull- request for any issues I find and need fixing. Regards Jóhann B. 1. https://fred.nic.cz/documentation/html/AdminManual/Configuration.html On 1/3/19 11:29 AM, Jaromir Talir wrote: > Hi Jóhann, > > we have a delay in publication of new version FRED-2.38 that is now > in > the QA process. This new version will include packages for Fedora > 29. > Last release candidate packages are available at the build server: > https://copr.fedorainfracloud.org/coprs/jtalir/fred/monitor/ > > If you want to test this release candidate packages, you can attach > this repository via: > $ dnf copr enable jtalir/fred > > After this you can install Fred the same way as described on the > website. I still need to verify installation procedure so I'll be > happy > if you will give me feedback how it worked. > > Regards, > Jaromir > > On Thu, 2019-01-03 at 10:40 +0000, Jóhann B. Guðmundsson wrote: > > Greetings > > > > Fedora 29 got officially released on 30 October last year but no > > packages have been built for that release [1] as of today hence > > installation on the distro fails with.... > > > > Failed to synchronize cache for repo 'fred', ignoring this repo. > > No match for argument: fred-* > > > > Any particular reason the components have not been built for the > > 29 > > release of Fedora? > > > > Regards > > > > Jóhann B. > > > > 1. http://archive.nic.cz/yum/fred/fedora/ > > > > _______________________________________________ > > fred-users mailing list > > fred-users(a)lists.nic.cz > > https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users

On 1/4/19 9:27 AM, Jaromir Talir wrote: I'm in no doubt you would but this and reference to ( internal tracker? ) issues in commit's on github begs the question how much ( if any ) registry ( or the 3r's ) community product fred is and perhaps every open sourced project coming from the cz.nic development department? To further explain what I'm getting at is that the general association is made when hearing or reading the term ‘open source’ is that the software project is collaboratively developed and shared freely with whoever wants to see it (some licenses prohibit commercial use or abstraction, but in general anybody who wants to can look at the code and modify it for their private non-commercial use). It's an world where anyone can join the developer community and submit code and patches and other resources, and contribute to the roadmap of that project. Sometimes the new joiner may not have commit access until their credentials are proven, but the project is generally community based and community driven. In the case of Fred that community would most likely be made up of the registry, registrar and registrant, the target audience of such application or application stack ) The there is the "unenlightened" association in which projects commonly generated by universities,institutions, corporate and other entities in which they freely share their source code, but they provide no community mechanisms for contributing to it or helping guide its direction. Sure individuals can email in a patch or suggestion, make pull request in git(hub) and hope that it gets applied but there is no guarantee this will happen. The only way to get their voice(s) heard is to either know the right people within the developer team, or to establish a formal collaboration between universities,institutions, corporate and other entities so that they can co-develop the project together. Basically the open sourcing of the project is done in the strictest literal sense of the word, in that the source code is open for anyone to see but no more no less which more then often than not leads to fork offs.. Of the above, which one does Fred fall under? <snip> ..... </snip>

On 1/4/19 9:27 AM, Jaromir Talir wrote: I'm in no doubt you would but this and reference to ( internal tracker? ) issues in commit's on github begs the question how much ( if any ) registry ( or the 3r's ) community product fred is and perhaps every open sourced project coming from the cz.nic development department? To further explain what I'm getting at is that the general association is made when hearing or reading the term ‘open source’ is that the software project is collaboratively developed and shared freely with whoever wants to see it (some licenses prohibit commercial use or abstraction, but in general anybody who wants to can look at the code and modify it for their private non-commercial use). It's an world where anyone can join the developer community and submit code and patches and other resources, and contribute to the roadmap of that project. Sometimes the new joiner may not have commit access until their credentials are proven, but the project is generally community based and community driven. In the case of Fred that community would most likely be made up of the registry, registrar and registrant, the target audience of such application or application stack ) The there is the "unenlightened" association in which projects commonly generated by universities,institutions, corporate and other entities in which they freely share their source code, but they provide no community mechanisms for contributing to it or helping guide its direction. Sure individuals can email in a patch or suggestion, make pull request in git(hub) and hope that it gets applied but there is no guarantee this will happen.

The only way to get their voice(s) heard is to either know the right people within the developer team, or to establish a formal collaboration between universities,institutions, corporate and other entities so that they can co-develop the project together. Basically the open sourcing of the project is done in the strictest literal sense of the word, in that the source code is open for anyone to see but no more no less which more then often than not leads to fork offs.. Of the above, which one does Fred fall under?

<snip> ..... </snip> _______________________________________________ fred-users mailing list fred-users(a)lists.nic.cz https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users

On 1/7/19 2:56 PM, Miroslav Franc wrote: The cost becomes less not more so there is always a reason to try first by approaching this with an open community model from the get go for an project but can become more costly to open afterwards ( not in your case thou, just requires a change in internal workflow and a new mailinglist afaikt ).

Often people tend to overlook the resource savings that come with Documentation( Technical Writing ), QA and downstream integration etc. ( they fall into the trap of only count contributions in the form of code ) which allows for developers to do what they do best focus their time on the code base itself.

Agreed and if I put on my previous Fedora QA hat on even more difficult in downstream distribution as in there needs to be some form of carrot model to get contributors to devote their free time to test less "popular" but if not more important components.

Most projects dont adapt a full blown distribution governing models but steer themselves based on contributions and trust.

Which begs the question what was the project sight for Fred in the beginning and what future sight nic.cz has for Fred? Is your target audience atleast the ca 250 ccTLD'c registries or more?  Do you want to unify and ( try to ) get all the registries to use Fred? What are you currently aiming at?

That strikes me as bit odd since they should be testing the upstream releases in a test environment and provide feedback. Perhaps you guys have written the first ever bug free code yai! ;) but I somehow doubt it ;) I'm parsing the mailinglist from the get go ( in 2008 now ) so I will be able to determine to what extend and how experienced those administrators are.

Is it not more what you see in the future for Fred and if you want/need to grow that interest? > But, so far, it is an "undiscovered country" for I think very > obvious reasons. > >> The only way to get their voice(s) heard is to either know the right >> people within the developer team, or to establish a formal >> collaboration between universities,institutions, corporate and other >> entities so that they can co-develop the project together. >> >> Basically the open sourcing of the project is done in the strictest >> literal sense of the word, in that the source code is open for anyone >> to see but no more no less which more then often than not leads to >> fork offs.. >> >> Of the above, which one does Fred fall under? > >> <snip> >> >> ..... >> >> </snip> >> >> _______________________________________________ >> fred-users mailing list >> fred-users(a)lists.nic.cz >> https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users