hello there!
I'm reading about a few issues with Xserver, both here on GhostBSD and in FreeBSD forum.
The recent update to Xorg 1.18.x has broken quite a few things, work is in progress, but right now it is not as stable as it used to be.
Just as an example, in some case a workaround is to manually load the i915kms modules (intel), in other cases the removal of old llvm versions is required, in other the reinstallation of a few GL related libs is required.
https://svnweb.freebsd.org/ports?view=r ... ion=434213
https://forums.freebsd.org/threads/59717/
https://forums.freebsd.org/threads/59728/
https://forums.freebsd.org/threads/59694/
I know an event like this is rare, but as you can see it happens, from time to time.
And that is an hint why using the "quarterly" repository may be a better choice compared to "latest".
~~~
The other question that come to my mind is:
what is the state of the GhostBSD recently released Alpha ISOs in respect to the above mentioned issues ?
And the answer is: no one know, it depend entirely on "when" the ISOs were build (before of after the introduction of the problems) and that is rather random, some user may have build the ISO before, some may have build the ISO later, ultimately what I want to say is that the current build process doesn't assure the same result for two different builds.
That problem was supposedly going to be solved by using our own repository and a copy of the port tree.
Right now can not find the post, but I read (from ericbsd) that you are going to avoid the "own repository" for now and rely on an updated software to update ghostbsd own packages directly from source.
I kindly disagree with this approach, because it clearly cannot allow for repeatable results, thus making debug very difficult: you may have reports from users but you really don't know what is ports tree versions they are using.
~~~
In addition to all the above, it was repeated many times in FreeBSD forum to not mix ports and packages, not even when using the default options, because there are however ports tree differences which can lead to problems.
~~~
OK, may be it is me ... but I think those issue should be solved, especially now that there is all is needed to make up our own repository:
a) a make up a base repository (I could say this is already ready, pkg lists can be changed at any time)
b) make the own repository public as "ghostbsd-test-repo"
c) change the build utility to fetch packages from the above repo instead of FreeBSD repo.
d) add our own ghostbsd packages into the port-tree
All that should allow to make ISOs which will be 100% identical, no matter when they are made and no matter from who.
When we are satisfied from tests, the ghostbsd-test-repo will be cloned to ghostbsd-stable-repo, and also made public.
Up to your evaluations.
X server issues and ports
Re: X server issues and ports
I was hit by this as well. Since January or so I followed your advice and used Synth to update my system to get used to it (thanks for the recommendation, BTW! It's much better that using portmaster as I did before!). After doing updates last Sunday X wouldn't start on Monday. I "fixed" this by disabeling the Synth repo and forcing package reinstalls from the FreeBSD repo. But I did not yet have the time to look into what actually broke. So thanks for this information!
Re: X server issues and ports
I was hit too, only on a laptop with intel graphics. Use Synth of FreeBSD repo is irrelevant anyway, both will work or not, the problems are upstream.
Re: X server issues and ports
This why I will stay with latest until we get our own repository and even there depending how the ports are going we might stay with something more stable.ASX wrote:hello there!
I'm reading about a few issues with Xserver, both here on GhostBSD and in FreeBSD forum.
The recent update to Xorg 1.18.x has broken quite a few things, work is in progress, but right now it is not as stable as it used to be.
Just as an example, in some case a workaround is to manually load the i915kms modules (intel), in other cases the removal of old llvm versions is required, in other the reinstallation of a few GL related libs is required.
https://svnweb.freebsd.org/ports?view=r ... ion=434213
https://forums.freebsd.org/threads/59717/
https://forums.freebsd.org/threads/59728/
https://forums.freebsd.org/threads/59694/
I know an event like this is rare, but as you can see it happens, from time to time.
And that is an hint why using the "quarterly" repository may be a better choice compared to "latest".
The problem I have with X right now it is not related to the problem from Xorg, I was trying to make something to configure card to fix a problem for user but it did cause more problem, I was not able to install mate in any of my computer, I did remove that code and let boot like it was booting in 10.3 and that fix the random problem of X and MATE for me.ASX wrote:The other question that come to my mind is:
what is the state of the GhostBSD recently released Alpha ISOs in respect to the above mentioned issues ?
And the answer is: no one know, it depend entirely on "when" the ISOs were build (before of after the introduction of the problems) and that is rather random, some user may have build the ISO before, some may have build the ISO later, ultimately what I want to say is that the current build process doesn't assure the same result for two different builds.
The thing I am not avoiding GhostBSD own repository I made the update manger the ability to update some tool like the update manage and networkmgr, but since networkmgr is in FreeBSD ports there is no need for that one, the idea is that as soon that GhostBSD repository is ready, change could be push form GitHub ports that was what I was looking for. To point I am not gonna stick for long with FreeBSD repository, I do knot like that I have remove some line pkg-install of the networkmgr ports, but he FreeBSD user got what they wanted. I know you might not like the fact updating some GhostBSD from the ports it self, it is temporary and might not even get in final 11.0 release.ASX wrote: That problem was supposedly going to be solved by using our own repository and a copy of the port tree.
Right now can not find the post, but I read (from ericbsd) that you are going to avoid the "own repository" for now and rely on an updated software to update ghostbsd own packages directly from source.
I kindly disagree with this approach, because it clearly cannot allow for repeatable results, thus making debug very difficult: you may have reports from users but you really don't know what is ports tree versions they are using.
This is a grey area, I would say that for latest drivers of Nvidia there is no problem using ports, but for installing Gnome or XFCE on with MATE that install form packages not good idea, I install ports with packages, but ports that I install is mostly ports that have few dependency and never have problem.ASX wrote:In addition to all the above, it was repeated many times in FreeBSD forum to not mix ports and packages, not even when using the default options, because there are however ports tree differences which can lead to problems.
There is still the old mentality of pkg_add on the FreeBSD forums to, with pkg_add you add to stay with pkg_add because the repository was not updated until the next release and ports would try to install back dependency and fail and broke, today if the install ports understand pkg and even update the pkg data base, thing that was not happening with pkg_add and if there is package with pkg that is not compatible to the ports dependency version doing make reinstall might reinstall that port if not it would stop saying that software need to be update, and it is why I use portupgrade. I always say if you want a stable way to install software use pkg and not ports unless you know what you are doing. This is basically why I say it is a grey area.
I have been using FreeBSD way longer that I have use windows or Linux and I was use to compile ports to have the latest software, I only started to use packages since pkgng replace pkgrc.
OK follow is a rant about FreeBSD ports and not our repository just make on thing clear. GhostBSD repository will solve lots of problem, but it will not solve problem that is in FreeBSD ports, if an issue like Xorg get in ports and we do not know about it, we will get the same result then FreeBSD pkg, there is a lot of ports that is not well maintain like xorriso for example we will still get the same issue. I do not want to sound pessimist, but it is the reality.ASX wrote:OK, may be it is me ... but I think those issue should be solved, especially now that there is all is needed to make up our own repository:
a) a make up a base repository (I could say this is already ready, pkg lists can be changed at any time)
b) make the own repository public as "ghostbsd-test-repo"
c) change the build utility to fetch packages from the above repo instead of FreeBSD repo.
d) add our own ghostbsd packages into the port-tree
All that should allow to make ISOs which will be 100% identical, no matter when they are made and no matter from who.
When we are satisfied from tests, the ghostbsd-test-repo will be cloned to ghostbsd-stable-repo, and also made public.
Up to your evaluations.
The thing that we would have control over is ghostbsd-stable-repo because we could have ghostbsd-test-repo building on any ports change and when the build is stable it could go in ghostbsd-stable-repo, if I have understand you point. An other thing lately I have play with Jenkins in ixbuild and I will build a Jenkins for building ISO and packages in the future.
For building pkg we might need an other server, we gain lot of donation lately and it is stable, we could get an other server, this is still a topic to discuss.
Re: X server issues and ports
Kindly disagree, may be I'm wrong but I though we were using quarterly .... and we should continue ... but may be I'm completely out of sync ...ericbsd wrote:This why I will stay with latest until we get our own repository and even there depending how the ports are going we might stay with something more stable.ASX wrote:hello there!
I'm reading about a few issues with Xserver, both here on GhostBSD and in FreeBSD forum.
The recent update to Xorg 1.18.x has broken quite a few things, work is in progress, but right now it is not as stable as it used to be.
Just as an example, in some case a workaround is to manually load the i915kms modules (intel), in other cases the removal of old llvm versions is required, in other the reinstallation of a few GL related libs is required.
https://svnweb.freebsd.org/ports?view=r ... ion=434213
https://forums.freebsd.org/threads/59717/
https://forums.freebsd.org/threads/59728/
https://forums.freebsd.org/threads/59694/
I know an event like this is rare, but as you can see it happens, from time to time.
And that is an hint why using the "quarterly" repository may be a better choice compared to "latest".
Sorry, you are skipping the issue, or I failed to explain myself: the point is about: are we able (all of us testers) to build the same ISO at any given point n time ? AFAIK actually no.The problem I have with X right now it is not related to the problem from Xorg, I was trying to make something to configure card to fix a problem for user but it did cause more problem, I was not able to install mate in any of my computer, I did remove that code and let boot like it was booting in 10.3 and that fix the random problem of X and MATE for me.ASX wrote:The other question that come to my mind is:
what is the state of the GhostBSD recently released Alpha ISOs in respect to the above mentioned issues ?
And the answer is: no one know, it depend entirely on "when" the ISOs were build (before of after the introduction of the problems) and that is rather random, some user may have build the ISO before, some may have build the ISO later, ultimately what I want to say is that the current build process doesn't assure the same result for two different builds.
same as above.The thing I am not avoiding GhostBSD own repository I made the update manger the ability to update some tool like the update manage and networkmgr, but since networkmgr is in FreeBSD ports there is no need for that one, the idea is that as soon that GhostBSD repository is ready, change could be push form GitHub ports that was what I was looking for. To point I am not gonna stick for long with FreeBSD repository, I do knot like that I have remove some line pkg-install of the networkmgr ports, but he FreeBSD user got what they wanted. I know you might not like the fact updating some GhostBSD from the ports it self, it is temporary and might not even get in final 11.0 release.ASX wrote: That problem was supposedly going to be solved by using our own repository and a copy of the port tree.
Right now can not find the post, but I read (from ericbsd) that you are going to avoid the "own repository" for now and rely on an updated software to update ghostbsd own packages directly from source.
I kindly disagree with this approach, because it clearly cannot allow for repeatable results, thus making debug very difficult: you may have reports from users but you really don't know what is ports tree versions they are using.
What you call gray area, it is something I now consider black area, if not else because portmaster doesn't build in a clean environment. (only poudriere and synth do that).This is a grey area, I would say that for latest drivers of Nvidia there is no problem using ports, but for installing Gnome or XFCE on with MATE that install form packages not good idea, I install ports with packages, but ports that I install is mostly ports that have few dependency and never have problem.ASX wrote:In addition to all the above, it was repeated many times in FreeBSD forum to not mix ports and packages, not even when using the default options, because there are however ports tree differences which can lead to problems.
There is still the old mentality of pkg_add on the FreeBSD forums to, with pkg_add you add to stay with pkg_add because the repository was not updated until the next release and ports would try to install back dependency and fail and broke, today if the install ports understand pkg and even update the pkg data base, thing that was not happening with pkg_add and if there is package with pkg that is not compatible to the ports dependency version doing make reinstall might reinstall that port if not it would stop saying that software need to be update, and it is why I use portupgrade. I always say if you want a stable way to install software use pkg and not ports unless you know what you are doing. This is basically why I say it is a grey area.
I have been using FreeBSD way longer that I have use windows or Linux and I was use to compile ports to have the latest software, I only started to use packages since pkgng replace pkgrc.
It is not a rant and I agree with you (jenkins or not, that's a different thing).OK follow is a rant about FreeBSD ports and not our repository just make on thing clear. GhostBSD repository will solve lots of problem, but it will not solve problem that is in FreeBSD ports, if an issue like Xorg get in ports and we do not know about it, we will get the same result then FreeBSD pkg, there is a lot of ports that is not well maintain like xorriso for example we will still get the same issue. I do not want to sound pessimist, but it is the reality.ASX wrote:OK, may be it is me ... but I think those issue should be solved, especially now that there is all is needed to make up our own repository:
a) a make up a base repository (I could say this is already ready, pkg lists can be changed at any time)
b) make the own repository public as "ghostbsd-test-repo"
c) change the build utility to fetch packages from the above repo instead of FreeBSD repo.
d) add our own ghostbsd packages into the port-tree
All that should allow to make ISOs which will be 100% identical, no matter when they are made and no matter from who.
When we are satisfied from tests, the ghostbsd-test-repo will be cloned to ghostbsd-stable-repo, and also made public.
Up to your evaluations.
The thing that we would have control over is ghostbsd-stable-repo because we could have ghostbsd-test-repo building on any ports change and when the build is stable it could go in ghostbsd-stable-repo, if I have understand you point. An other thing lately I have play with Jenkins in ixbuild and I will build a Jenkins for building ISO and packages in the future.
That would be indeed a better solution compared to using the same server, so yes, thanks for considering that.For building pkg we might need an other server, we gain lot of donation lately and it is stable, we could get an other server, this is still a topic to discuss.
Re: X server issues and ports
Sorry I have no idea why I put latest instead quarterly. It should have been:This why I will stay with latest until we get our own repository and even there depending how the ports are going we might stay with something more stable.
This why I will stay with quarterly until we get our own repository and even there depending how the ports are going we might stay with something more stable.
Re: X server issues and ports
OK, seems we agree.
Re: X server issues and ports
The ISO are build on quarterly and not on Latest to clarify, every build should be same, but for the part that is build from ports which I always had disagree, but I have let convbsd do this part that is an other story.
For the current state of 11.0 there is not mush left to do, I did revert back to booting directly to slim, witch fix the X problem I had, since the X problem is not in quarterly that was not the issue. The only thing now is to I make sure that update manager behave like expected with the change to doas.
And I still maintain it is a grey area to build ports and pkg to together, but like I said I will not say to any one to do it. I will not debate on further on that.
Yea I just notice that I skip most of it, but X was part of it. Package are install form quarterly i am gonna make sure this time to I specify quarterly, the only part that is build from ports is GhostBSD stuff which change all the time and all dependency are install by pkg and not ports, I did not look much if there is software build from ports on ghostbsd-build. From there ghostbsd ports change all the time and you will never have build that is the same this is for sure.ASX wrote:[Sorry, you are skipping the issue, or I failed to explain myself: the point is about: are we able (all of us testers) to build the same ISO at any given point n time ? AFAIK actually no.The problem I have with X right now it is not related to the problem from Xorg, I was trying to make something to configure card to fix a problem for user but it did cause more problem, I was not able to install mate in any of my computer, I did remove that code and let boot like it was booting in 10.3 and that fix the random problem of X and MATE for me.ASX wrote:The other question that come to my mind is:
what is the state of the GhostBSD recently released Alpha ISOs in respect to the above mentioned issues ?
And the answer is: no one know, it depend entirely on "when" the ISOs were build (before of after the introduction of the problems) and that is rather random, some user may have build the ISO before, some may have build the ISO later, ultimately what I want to say is that the current build process doesn't assure the same result for two different builds.
For the current state of 11.0 there is not mush left to do, I did revert back to booting directly to slim, witch fix the X problem I had, since the X problem is not in quarterly that was not the issue. The only thing now is to I make sure that update manager behave like expected with the change to doas.
I have no idea why you bring postmaster, it is not part of GhostBSD and it will never be in GhostBSD and I did not mention it also. I did use portmaster on time and never use it back. I was using portupgrade for years, but now I build ports my self since it is easier now becuase of pkgng. Portupgrade is far to be like poudriere and synth, because it is not for the same purpose and portsupgrade was build for the old pkgsrc system.What you call gray area, it is something I now consider black area, if not else because portmaster doesn't build in a clean environment. (only poudriere and synth do that).
And I still maintain it is a grey area to build ports and pkg to together, but like I said I will not say to any one to do it. I will not debate on further on that.
Re: X server issues and ports
Yea I just put the wrong word I did not read back the part also.ASX wrote:OK, seems we agree.
Re: X server issues and ports
I know that, and the fact is that without our own repo there was no other choice, even if we all disagreed about, including convbsd.ericbsd wrote:The ISO are build on quarterly and not on Latest to clarify, every build should be same, but for the part that is build from ports which I always had disagree, but I have let convbsd do this part that is an other story.
I would take the chance to fix this problem once for all, possibly *before* the final release of gbsd-11.
I have much higher targets in my mind ... I would easily delay the release in favour of a better result, I'm sure quality of result will pay off.For the current state of 11.0 there is not mush left to do, I did revert back to booting directly to slim, witch fix the X problem I had, since the X problem is not in quarterly that was not the issue. The only thing now is to I make sure that update manager behave like expected with the change to doas.
Because you mentioned portupgrade, (sorry, in my mind they are both broken the same way).I have no idea why you bring postmaster
Exactly.Portupgrade is far to be like poudriere and synth, because it is not for the same purpose and portsupgrade was build for the old pkgsrc system.