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.

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!

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.

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".

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: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 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: 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.

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: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.

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.

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.

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.

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.

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.

ericbsd wrote:

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".

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.

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 ...

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 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.

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.

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.

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.

same as above.

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.

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.

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.

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).

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.

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.

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.

It is not a rant and I agree with you (jenkins or not, that's a different thing).

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.

That would be indeed a better solution compared to using the same server, so yes, thanks for considering that.

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.

Sorry I have no idea why I put latest instead quarterly. It should have been:

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.

OK, seems we agree.

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.

ASX wrote:[

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 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.

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.

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.

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.

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).

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.

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.

ASX wrote:OK, seems we agree.

Yea I just put the wrong word I did not read back the part also.

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 know that, and the fact is that without our own repo there was no other choice, even if we all disagreed about, including convbsd.

I would take the chance to fix this problem once for all, possibly *before* the final release of gbsd-11.

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 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.

I have no idea why you bring postmaster

Because you mentioned portupgrade, (sorry, in my mind they are both broken the same way).

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.

Exactly.