> ...
> > 2. Figure out how to tell sysupgrade the right answers in advance i.e.
> > via the auto_upgrade.conf mechanism
>
> This is fairly easy:
>
> sysupgrade -s -n
> vi /auto_upgrade.conf, edit "Pathname to the sets"
> reboot
> ...
FYI, or for the record, I just tried the above and it
On Mon, Oct 5, 2020 at 12:27 PM Roderick wrote:
...
> Back to tar files: there is place for 11 octal digits, that is
> only twice the time you can count with 32 bits, in years:
>
> 2^33/(60*60*24*365.25*2)=136.09930083403047126524
>
> Also not too much. Is it not a better solution to begin a new
On Mon, 5 Oct 2020, Christian Weisgerber wrote:
There's an #ifdef __LP64__ ...
Yes. That is not to oversee, but I oversaw it, because I wanted to
oversee it.
For lazyness I use snprintf to fill the mtime field of a component of
a v7 tar file I generate:
snprintf([136],12,"%011lo",
The source of my confusion with FreeBSD:
/usr/include/time.h contains: typedef __time_t time_t; and includes
/usr/include/sys/types.h includes
/usr/include/machine/_types.h includes
/usr/include/x86/_types.h contains:
typedef __int32_t __time_t;
typedef int __int32_t;
Of course I
Thanks anybody for the instructive answers!
On Mon, 5 Oct 2020, Todd C. Miller wrote:
Are you sure about that? FreeBSD declares __time_t to be __int64_t
on amd64. On FreeBSD/amd64 __int64_t is defined as a long.
You are right. My error. I just run:
#include
#include
int main()
On 2020-10-05, Roderick wrote:
> The source of my confusion with FreeBSD:
> /usr/include/x86/_types.h contains:
>typedef __int32_t __time_t;
>typedef int __int32_t;
$ fgrep time_t /usr/include/x86/_types.h
typedef __int64_t __time_t; /* time()... */
typedef
It looks like OpenBSD's cmake port patches cmake to remove the use of
-O2 in Release and RelWithDebInfo builds -
/usr/ports/devel/cmake/patches/patch-Modules_Compiler_GNU_cmake has:
- string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
- string(APPEND
On 2020-10-05, "Peter N. M. Hansteen" wrote:
> I hadn't looked in a while, but it amazes me that FreeBSD still has
> 32-bit time_t.
Only on FreeBSD/i386. On all other architectures, time_t is int64_t.
See src/sys/*/include/_types.h.
--
Christian "naddy" Weisgerber
Hello,
Scott Seekamp :
> I had a similar speed drop on an Edge Router 4. I don?t know if it?s the same
> situation on the Lite, but I believe it?s expected due to hardware
> acceleration support (or lack of) and single core performance on the pf side.
The last time I logged on an ubiquiti
On 2020-10-04, Amarendra Godbole wrote:
> 1. config #1: MacBook - Linksys WRT1200AC - xfinity cable modem
> (speed: ~210 Mbits/s down, 6 Mbits/s up)
> 2. config #2: MacBook - Linksys WRT1200AC - Ubiquiti ERL - xfinity
> cable modem (speed: ~90 MBits down, 6 Mbits/s up)
> 3. config #3 (Line
I don't know if it can be related to
https://marc.info/?l=openbsd-bugs=158755394912063=2
In my case I had to (sadly) switch to nginx, as a fix for httpd is
required and I am not familiar with its code to start working on it.
On Mon, Oct 5, 2020 at 1:08 AM Stuart Henderson wrote:
>
> On 2020-10-04, Amarendra Godbole wrote:
> > 1. config #1: MacBook - Linksys WRT1200AC - xfinity cable modem
> > (speed: ~210 Mbits/s down, 6 Mbits/s up)
> > 2. config #2: MacBook - Linksys WRT1200AC - Ubiquiti ERL - xfinity
> > cable
The result of time() has type time_t and we know what kind of number
goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
1970, Coordinated Universal Time.
In my FreeBSD running on a 64 bit processor this type is: int (__32_t).
It considers this size enough for above
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type
On Mon, 05 Oct 2020 15:16:24 -, Roderick wrote:
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
32-bit time_t rolls over at 03:14:07 on Tuesday, 19 January 2038.
Hi Rodrick,
Roderick wrote on Mon, Oct 05, 2020 at 03:16:24PM +:
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor
The universe didn't start in 1970
On Monday, October 5, 2020, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit
On Mon, Oct 05, 2020 at 03:16:24PM +, Roderick wrote:
>
> The result of time() has type time_t and we know what kind of number
> goes there: seconds since 0 hours, 0 minutes, 0 seconds, January 1,
> 1970, Coordinated Universal Time.
>
> In my FreeBSD running on a 64 bit processor this type
Hi Peter,
Peter J. Philipp wrote on Mon, Oct 05, 2020 at 05:47:59PM +0200:
> When time_t was made, I think, positive integers meant time forwards, and
> negative integers meant time backwards from epoch so that people born in
> 1938 for example could be processed.
20 matches
Mail list logo
