[oi-dev] Updating Hipster and GUI log-in breakage with mounted ZFS datasets

Nikola M minikola at gmail.com
Wed Feb 18 13:35:04 UTC 2015


On 02/18/15 12:54 PM, Alexander Pyhalov wrote:

>
>>> 2) As for your system freezing after logging in - it's more 
>>> interesting.
>>> Could you get you ~/.xsession-erros log ?
> ...
>
> I've asked several questions, you started this bullshit. OK, let's 
> instead of solving your problem, discuss this.... I don't like 
> discussing similar topics, but ...

.xsession-errors  http://pastebin.com/gVDNjGHK
.xsession-errors.old  http://pastebin.com/9vtp3wT9

I also suspect some hardware malfunction (but not expressing like this 
on every log in),
I also did weird things trying to launch gnome-session you requested,
and I did it running as other user, running, screen, then ssh -l user -X 
localhost , then gnome-session, so beware of maybe weird things inside.
>
>> Things do not get tested before releases, releases are not being
>> discussed , made and polished for updates, priorities have not being 
>> set,
>> all we actually have is "updating packages" without idea where OI is
>> heading and why and who actually needs a system that does have only part
>> of functionality it had in 2009.
>> At least till 151a7 everything worked, after that it started falling a
>> part.
>
> Things are getting tested. If we had at least 10 developers and 2 
> testers, we could think about some QA. But as we have 2 non-full-day 
> developers and a lot of work, I'll leave it as it is. If you have a 
> reproducible bug, file it. If you like 151a7 so much, just use it.
I just hoped you won't mention recommendation of using old /dev release, 
(it is there for features and funcionality reference)  but seems like 
you like /dev releses more then you admit.

Numbering Hipster updates inside entire package is not QA, it's just 
distribution planning.
By the way, I said my current Hipster have Hipster ancestors all the way 
down to update done from 151a7 and I have log somewhere to prove it.
If there are some numbered Hipster releases, or if you wouldn't freeze 
unundatable package states in ISOs,
we would have update path from /dev to Hipster already.
How can anyone re-create update path from all those Hipster updates till 
now, to figure out when something was broken? (Like my standby on Laptop 
stopped working in Hipster last year)

>
>> Hipster was fun when I was thinking it leads to the next /dev.
>> It's not fun anymore for a very long time.
>> Rolling releases are just lunacy for general use and could exist only
>> between /dev releases,
>> And not every random package change should survive to next release).
> FreeBSD port system existed in continuously rolling state for a long 
> time. We have no power to do release. We have some objectives which I 
> periodically discuss.
As much I dislike GDA suggesting use of OSX, I also dislike suggesting 
use of FreeBSD. If I wanted FreeBSD I wouldn't be here.
FreeBSD and Linux never had stable APIs, and drivers and binaries that 
work on many different OS releases.
If I wanted ever changing environment with no rules on updates and releases,
I would certainly choose Linux or FreeBSD,
seems to me that importing that kind of way of looking at distros is not 
applicable to Solaris descendent.

There needs the process and procedures of doing things, thing get built 
that way.
"Periodically ad-hock discussing" things is not enough for distribution 
to grow,
especially if new people learn they can't (or can) change course of distro.

How would you for example react if your updated packages in Hipster, 
never end up in /release ?
And it is required that further development starts from /release 
onwards, not other way around?

Would you be mad if your work is actually never used in supported 
version of distro, would you accept that there are also other ways of 
doing things and your way is not always the best way for production use, 
ever?
>
> For the nearest future these are
> 1) Updating Gnome to 2.32
> 2) Importing changes from x-s12-clone
> 3) Updating cairo, pango and glibc.
If we have no power to have any release, what we are actually doing here?
If SOME release (updatable from /dev) is not the goal in at least one 
moment, where it is heading?

At least there must be some release before throwing 32bit cpu support..
>
> I use OI Hipster as my primary desktop. I know there issues (e.g., 
> brasero bugs, inability of 32-bit gdb to handle 64-bit binaries).
> But I don't know any catastrophic issues which prevents using system 
> (besides having a bunch of out-of-date software, which is not rather 
> easy to rebuild).
I understood you use FreeBSD because illumos, OI does not stupport WPA2 
encryption for Wireless on your laptop.  And you moved from there 
without fixing it but used something else instead.
Sometimes I think am the rare one that is actually using OI with 
Thunderbird.

Yeah, I've been using cdrecord instead of Brasero etc..
I used to do ssh -X to run Thunderbird and Firefox for 4 months, after 
that I was forced to abandon old user account and transfer minimal data.
It seems it happened again after Hipster update and I have no idea why.
Also I had one occasion few minutes ago when i actually were able to log 
in in 20141010 with original account (after running apps through ssh -X, 
logging in console, restarting gdm and what else, so It is hard to 
reproduce).
Maybe I could toss somewhere other GNOME settings or insights of that 
account?





More information about the oi-dev mailing list