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

Wed Feb 18 14:15:32 UTC 2015

I use Hipster since the beginning on:
- three Westmere-based workstations and one X230 laptop for developing
parallel CFD code + personal use,
- one Atom-based media center.

Things did not break often for me.

I actually have less issues than with the Ubuntu LTS which was installed
initially on my "work" machine.
At least when things do not work, they just do not: they do not break every
second update and if they do I can rollback, if one disk is "toast" my root
is mirrored...

As far as Firefox and Thunderbird are concerned I admit that I use the
contrib tarballs version 30.0.

I think you should document your issues and file bug reports to pin point
the problems.
Possibly in a second step, you should reference them on a Wiki page so they
can be addressed in the structured way that you suggest.

I think I understood from Alexander's numerous emails that the first goal
is to be able to build the full distribution with oi-userland so that an
unstable/testing/release cycle can be actually considered: the same
discussion has been brought up several times with the same arguments.
I seem to understand that it is a *prerequisite* to further release work
and that the overhead of fixing dependencies/consolidation is not a
priority.
Also I remember that there are other paths than "pkg update" or
reinstalling, as with ZFS and IPS you can image-create (done that for some
SXCE/OpenSolaris -> OI upgrade a few years ago).

Although I understand your frustration, I think you could target your
energy to help documenting and fixing the issues.
Considering your interest in distribution planning I think that your best
shot would be to help document the steps towards a "fully buildable"
Hipster (i.e. missing components that Alexander mentioned), or the
showstoppers concerning the upgrade path /dev -> /hipster.

Best regards,

Aurelien

On Wed, Feb 18, 2015 at 2:35 PM, Nikola M <minikola at gmail.com> wrote:

>
> 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?
>
>
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>

-- 
-------------------------------------------------------------------------------
LARCHER Aurélien          | KTH, School of Computer Science and
Communication
Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm,
SWEDEN
-------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20150218/6649c40b/attachment-0005.html>