Page 14 of 15

Re: Porteus-v3.2rc5 bug reports

Posted: 07 Nov 2016, 23:49
by brokenman
Well that's because these are not command to be run from a command line, but rather part of a programming language to be compiled. Anyway, back on topic.

Re: Porteus-v3.2rc5 bug reports

Posted: 08 Nov 2016, 00:23
by Ed_P
brokenman wrote:Anyway, back on topic.
OK. So can 3.2 be configured to support timezones when the pc's clock is set to localtime like prior releases of Porteus?

Re: Porteus-v3.2rc5 bug reports

Posted: 08 Nov 2016, 02:04
by brokenman
No. It is either one or the other. Either the rclock is set to UTC or local time. If set to localtime then there will be problems between distros. mac, linux and azure will all adopt the UTC standard so that's where we will be. Best thing to do is to set up ntp to automatically set your clock for you.

Re: Porteus-v3.2rc5 bug reports

Posted: 08 Nov 2016, 03:53
by Ed_P
brokenman wrote: If set to localtime then there will be problems between distros.
That has not been my experience so far with a variety of distros.
mac, linux and azure will all adopt the UTC standard so that's where we will be.
And when the standards change then so should you. But the standards haven't changed yet and Porteus 3.2 should support the current standards.

Re: Porteus-v3.2rc5 bug reports

Posted: 08 Nov 2016, 05:44
by jssouza
Does the hardware clock also set the timezone? This is the output from my system:
[root:/home/guest]# hwclock --show
Tue 08 Nov 2016 07:01:42 AM CET .088982 seconds
[root:/home/guest]# date
Tue Nov 8 06:01:46 CET 2016
Strangely, the system time (output of date) is the correct actual time here. This would mean, that even if I had the correct time, my hardware clock time is screwed up.

I think Porteus, being a live OS should never write to the hardware clock, even if time is set through ntp. The variables that determine system time are: the hardware clock, the file /etc/hardwareclock, and the cheatcodes 'timezone=' and 'utc'. Of these, except for the hardware clock itself none are persistent (unless a saving mechanism has been created by the user).
If a user:
* Uses timezone=cheatcode, /etc/hardwareclock says localtime but the hardware clock itself was in UTC, then the hardware clock would be written the localtime.
* Along with timezone=, also uses 'utc' (wrongly) but the hardware clock itself was localtime, again wrong information would be written to the hardware clock.
In both cases persistence is not used, but the time would have changed, not only in subsequent live porteus sessions, but on other operating systems as well.

Re: Porteus-v3.2rc5 bug reports

Posted: 08 Nov 2016, 06:32
by Ed_P
Thanks jssouza. I didn't know about the hwclock command.

Porteus 3.0.1 RazorQT 64-bit

Code: Select all

root@porteus:/home/guest# hwclock --show
Mon 07 Nov 2016 07:34:33 PM EST  -0.603666 seconds
root@porteus:/home/guest# date
Tue Nov  8 00:34:51 EST 2016
root@porteus:/home/guest# 
Porteus 3.2rc5 Cinnamon 64-bit

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# hwclock
Mon 07 Nov 2016 07:54:13 PM EST  .328298 seconds
root@porteus:/home/guest# date
Tue Nov  8 00:54:19 EST 2016
root@porteus:/home/guest# 
Everything looks great. :good: And the clock and timezone look good on Windows too. :)

Then this
Image
Which to me indicates the timezone with 3.2rc5 is Europe/London. :pardon:

Re: Porteus-v3.2rc5 bug reports

Posted: 08 Nov 2016, 10:52
by brokenman
@Ed_P
Please read the code in /etc/rc.d/rc.S

Porteus does not touch your hardware clock unless you set your own time. If you find otherwise then please let me know, otherwise stop polluting this thread.

Re: Porteus-v3.2rc5 bug reports

Posted: 09 Nov 2016, 06:43
by Ed_P
brokenman wrote:@Ed_P
Please read the code in /etc/rc.d/rc.S
OK. The file in 3.2 is different than the one in 3.0.

Code: Select all

guest@porteus:~$ diff  /etc/rc.d/rc.S /mnt/sda5/porteus3.0/3.0rc.S.txt
0a1
>  cat /etc/rc.d/rc.S
14,22d14
< # Ensure sane guest perms
< for a in `find /home -maxdepth 1 -type d | sed '1d'`; do
< 	b=${a##*/}
< 	if [[ `grep "$b" /etc/passwd` ]]; then
< 		chown -R $b: /home/$b
< 	fi
< done
< #chown -R guest: /home/guest
< 
41,46d32
< # Make sure /dev/shm exists and is mounted tmpfs
< if [[ ! `grep /dev/shm /proc/mounts` ]]; then
< 	[ ! -d /dev/shm ] && mkdir /dev/shm
< 	mount -t tmpfs tmpfs /dev/shm
< fi
< 
48a35
>     echo > /proc/sys/kernel/hotplug
70,78d56
< 	# Sync the clock once we have internet connection:
< 	(
< 	sleep 10
< 	ntpdate pool.ntp.org >/dev/null 2>&1
< 	# Store systemtime to hardware clock:
< 	grep -wq rtc /proc/ioports || CLOCK_OPT="--directisa"
< 	grep -wq "^UTC" /etc/hardwareclock && CLOCK_OPT="$CLOCK_OPT --utc" || CLOCK_OPT="$CLOCK_OPT --localtime"
< 	hwclock $CLOCK_OPT -w
< 	) &
131a110
> guest@porteus:~$ 
guest@porteus:~$ 
And this line indicates that Porteus is indeed capable of changing the system's clock.

Code: Select all

< 	# Store systemtime to hardware clock:
http://forum.porteus.org/viewtopic.php?f=117&t=6187&start=165#p49904 wrote:Porteus doesn't write to the system clock so as not to upset other OSs' times.
Anyways, I'm done with this. There is a problem with Porteus 3.2 setting the user's timezone on pcs that multi-boot whose system time is set to localtime. I've pointed it out. I've posted examples.

Re: Porteus-v3.2rc5 bug reports

Posted: 09 Nov 2016, 07:09
by fulalas
Not exactly a bug, but could you update embedded Engrampa on XFCE build? The current 0.14.0 version can't open encrypted files. Here's the 0.16.0 txz package link:

https://www.mirrorservice.org/sites/dow ... 64-1gv.txz

EDITED: with this upgrade I think p7zip is no longer necessary once new Engrampa does everything. :)

Thanks!

Re: Porteus-v3.2rc5 bug reports

Posted: 10 Nov 2016, 00:45
by brokenman
The new version of Porteus (released tomorrow) has the updated version of Engrampa. Thanks.

@Ed_P
And when the standards change then so should you. But the standards haven't changed yet and Porteus 3.2 should support the current standards.
Please. Do your homework before arguing so much. Porteus is set to localtime by default (check /etc/hardwareclock). If you use a cheatcode then Porteus will write to your hardware clock. If you don't mess with it then it won't. A quick duckduckgo search will show that MANY people are confused by the differences in OSs handling of time and indeed this was the case in Poreus-3.0.1, hence the change.

And this line indicates that Porteus is indeed capable of changing the system's clock.
Of course it is. What operating system isn't capable of doing this? The fact IS that Porteus DOES NOT touch your hardware clock by default. If you read the code more carefully you will see that it only does this if you choose to use a timezone cheatcode.

http://forum.porteus.org/viewtopic.php?f=39&t=6369
This link explains it as best I can. If you find this isn't functioning as it should, then please make a bug report, otherwise we have just chewed through 2 pages of needless noise.

Re: Porteus-v3.2rc5 bug reports

Posted: 10 Nov 2016, 01:14
by fulalas
Cool! I've seen the new files here: dl.porteus.org/x86_64/Porteus-v3.2/
:good:

But I have a bug to report. It's a little bit weird, but if you create (don't need to execute it after creation) a xzm package from a tgz Nvidia driver the system behaves really oddly, not responding when you try to open new apps and sometimes even freezing. I'll give you the step by step soon.

EDITED: OK, so the step by step is really simple. You have to build a tgz package from here (doesn't matter which version of the driver you pick): https://slackbuilds.org/repository/14.2 ... ia-driver/ . After the build you'll have a tgz package of the driver with something around 54mb (here's a direct link of my build if you want to save your time), then right click on it and choose 'txz2xzm'. You'll notice that the system starts to behave really oddly -- the first thing is that you won't see a finish notification, and the worst: you can't open any new process. This behavior occurs with both Porteus 3.2rc5 XFCE x64 and Porteus 3.2 XFCE x64 (from the first link above), even booting on 'Always fresh' mode.

Re: Porteus-v3.2rc5 bug reports

Posted: 11 Nov 2016, 16:15
by fulalas
brokenman wrote:The new version of Porteus (released tomorrow) has the updated version of Engrampa. Thanks.
I checked and it's still on 0.14.x. And p7zip + GUI -- which in my opinion is not necessary with last Engrampa release -- is there too.

BTW, have you seen the bug I reported above?

Thanks!

Re: Porteus-v3.2rc5 bug reports

Posted: 11 Nov 2016, 20:48
by brokenman
Thanks fulalas.

Yes I see that mate has the updated engrampa but not xfce4. I am updating it now along with some other quite essential things and will repack the ISO on the server. I can not test your bug as I don't have access to an nvidia card right now.

Re: Porteus-v3.2rc5 bug reports

Posted: 11 Nov 2016, 23:17
by fulalas
brokenman wrote:Yes I see that mate has the updated engrampa but not xfce4. I am updating it now along with some other quite essential things and will repack the ISO on the server.
Great! :good:
brokenman wrote:I can not test your bug as I don't have access to an nvidia card right now.
Well, if you look carefully you'll see that the problem isn't related to Nvidia cards, but to xzm package creation. You don't need to install/run anything related to Nvidia driver, but just convert a tgz package to xzm and voilà. I think is just a coincidence that this happens with a Nvidia driver package.

Re: Porteus-v3.2rc5 bug reports

Posted: 12 Nov 2016, 00:31
by brokenman
Well, if you look carefully you'll see that the problem isn't related to Nvidia cards, but to xzm package creation.
I assumed it was the nvidia module since this GUI for txz2xzm is in 002 (same script in all desktops) and I have been right clicking on packages and converting them without any problems all day. Can anyone else confirm this bug?