Re: Planning out Core Update 117

Re: Planning out Core Update 117

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

Hi,
normally i agree but in that case it differs at least only here ?

Check over HTTP:
-> curl -O http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core115.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   185  100   185    0     0    326      0 --:--:-- --:--:-- --:--:--   326

-> sha256sum ovpn_244_64_v3_core115.tar.gz 
b8a7ebde1eec9fbba3790e31136fdfe3c7ea5b8c27900df1942f28cbe7b9f9f7  ovpn_244_64_v3_core115.tar.gz

-> ll ovpn_244_64_v3_core115.tar.gz 
-rw-r--r-- 1 root root 185 Nov 22 11:26 ovpn_244_64_v3_core115.tar.gz

-> rm -rf ovpn_244_64_v3_core115.tar.gz

Check over HTTPS:
-> curl -O https://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core115.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  484k  100  484k    0     0  1302k      0 --:--:-- --:--:-- --:--:-- 1304k

-> sha256sum ovpn_244_64_v3_core115.tar.gz 
10bc3162d6f061b291fe6e3b4284700431f061d55903f719cafa16bd33c48f40  ovpn_244_64_v3_core115.tar.gz

-> ll ovpn_244_64_v3_core115.tar.gz 
-rw-r--r-- 1 root root 495633 Nov 22 11:22 ovpn_244_64_v3_core115.tar.gz


whereby i get the same results as Michael Horace, smaller package same SHA256 sum. Nevertheless please use only the package with the correct SHA256 sum !

Greetings,

Erik



> Indeed, the transport method should not impact the file being downloaded.
> Today I did the download again using both HTTP and HTTPS: the size & hash are the same no matter the transport method used.
> Something went wrong on my previous download (the size was only 185K instead of 485): there is no need to change the install procedure.
> 
> I'll continue the tests for OpenVPN 2.4.4 and post results on forum topic.
> 
> 
> Best regards,
> Horace
> 
> 
> 
>> Sent: Tuesday, November 21, 2017 at 1:49 PM
>> From: "Michael Tremer" <michael.tremer(a)ipfire.org>
>> To: ummeegge <ummeegge(a)ipfire.org>, "Horace Michael" <horace.michael(a)gmx.com>, development(a)lists.ipfire.org
>> Subject: Re: Planning out Core Update 117
>> 
>> The checksum should be exactly the same no matter what the protocol is used to
>> transfer it.
>> 
>> -Michael

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 6070 bytes --]

Hi,

On Tue, 2017-11-21 at 18:35 +0100, Matthias Fischer wrote:
> Hi,
> 
> On 21.11.2017 15:42, Michael Tremer wrote:
> > Hello,
> > 
> > any progress on this?
> 
> Not much, because I've been struggling with a flu for the past two
> weeks, and its not over yet, but:
> 
> In the meantime I ran several builds with different parameters.
> 
> IMHO we could use:
> 
> 'export XZ_OPT = --threads=0 -8 --memory=700MiB'
> 
> in 'lfs/cdrom'
> 
> and
> 
> cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8 --memory=700MiB" tar -c -p
> --numeric-owner -J -f /install/packages/package/files.tar.xz *
> 
> in 'lfs/Config'.
> 
> Using '9' or '--extreme'-parameter brought no further improvements,
> on the other hand, build time and RAM consumption increased
> strongly. With '-8', minimal RAM consumption was about 680 MiB, using
> '700 Mib' was always safe. So this is the minimum I would recommend.

Yes, I observed the same thing. -9 compresses a little bit better and extreme
doesn't change a bit.

-8 seems to be optimal since it won't require too much memory to decompress
either. So let's go with that.

> Results:
> 
> (Buildtime: 5 hours 20 minutes 59 seconds)
> 
> 255866764  ipfire-2.19.1gb-ext4.i586-full-core117.img.gz
> 252262006  ipfire-2.19.1gb-ext4-scon.i586-full-core117.img.gz
> 175112192  ipfire-2.19.i586-full-core117.iso
>  
> > -Michael
> > 
> > On Tue, 2017-11-07 at 22:47 +0000, Michael Tremer wrote:
> > > Hi,
> > > 
> > > On Tue, 2017-11-07 at 19:41 +0100, Matthias Fischer wrote:
> > > > Hi,
> > > > 
> > > > On 07.11.2017 16:05, Michael Tremer wrote:
> > > > > Hi,
> > > > > 
> > > > > maybe this function helps:
> > > > > 
> > > > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822
> > > > > a63d
> > > > > c5d06d214b48f973b14f29
> > > > 
> > > > Thanks. I'll take a look...
> 
> This would help, indeed, but how to implement(!?), and... (see below)

Just run it somewhere in the script, figure out what is about 80% of that and if
that is smaller than 800 MB, we should just fail.

It would be good to have a function that determines the xz parameters and we use
that where ever we call xz. We don't want any duplicated code.

> > > > > On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
> > > > > > On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
> > > > > > ...
> > > > > > > 
> > > > > > > I forgot: Tuning the XZ-parameters... ;-)
> > > > > > 
> > > > > > Good that you are bringing this up. So I think what we should do
> > > > > > here is
> > > > > > bringing back XZ compression with -8 so that we do not waste too
> > > > > > much
> > > > > > space
> > > > > > when
> > > > > > extracting the image again.
> > > > 
> > > > Right now I'm testing how much RAM I need.
> > > > 
> > > > Current 'next'-build is running with:
> > > > 
> > > > 'lfs/cdrom':
> > > > ...
> > > > export XZ_OPT = --threads=0 -8 --memory=500MiB
> > > > ...
> > > > 
> > > > 'lfs/Config':
> > > > ...
> > > > cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8" ...
> > > > ...
> > > > 
> > > > I'm waiting for the results. Takes a while.
> > > 
> > > You can just run it like this and it will tell you:
> > > 
> > > [ms(a)hughes ~]$ xz -vv8 -T0
> > > xz: Filter chain: --
> > > lzma2=dict=32MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
> > > xz: Using up to 4 threads.
> > > xz: 2,629 MiB of memory is required. The limiter is disabled.
> > > xz: Decompression will need 33 MiB of memory.
> > > xz: Compressed data cannot be written to a terminal
> > > xz: Try `xz --help' for more information.
> > > 
> > > > > > To not run into memory limits we should detect how much memory the
> > > > > > build
> > > > > > host
> > > > > > has and set the memory limit to maybe 80% of that. xz will then
> > > > > > automatically
> > > > > > scale down to a number of parallel processes that it can fit into
> > > > > > memory.
> 
> This is something I couldn't get to work. First, I couldn't specify not less
> than '700 MiB'. If I specify '600 MiB', building stops and tells me it needs
> at least about 680 MiB. If I use '70%', building stops. And I never saw that
> 'xz' "automatically scaled down". It just stopped everytime.

Yes, ~700M is the minimum.

It will just reduce the number of threads again to make sure everything fits
into memory.

>  
> > > > I'm a bit puzzled about this: I tried using '--memory=70%' as mentioned
> > > > in the xz man pages, but is seems to have no effect. It looks as if the
> > > > percent parameter isn't recognized and ignored. It always ends up in
> > > > "cannot allocate memory". Any hints on this? Do both 'lfs/cdrom' AND
> > > > 'lfs/Config' need the '--memory'-parameter?
> 
> This was the next problem: 'percent'-parameter does not work as expected.

No, don't use it. Just determine yourself what it is.

I think we could even try to set 100% of the memory, because as far as I can see
this is worst case and xz won't use everything that we allow.

If that does't work, let's scale down to 90%, or 80%, etc...

> > > Yes, but it would be good to have one place where the parameters are
> > > being generated and then we just use them from a variable.
> 
> Probably beyond my capabilities for the moment. Any thoughts?
> 
> > > > > > ...
> > > > > > We will at least need about half a GB which should be a sensible
> > > > > > requirement
> > > > > > for a build system any ways.
> 
> I'm afraid '500 MiB' are not enough...

No, so we will now make 1G the minimum for a build.

I tried to build the OS on an ARM board with only 512MB of RAM the other day and
even with a lot of swap it doesn't work. So we are past this any way.

> 
> > > > Agreed. Because of this I'm testing with '500Mib'.
> > > > 
> > > > > > Will you work on this bringing it into the build system?!
> > > > 
> > > > "I'll do my very best!" :-))
> > > 
> > > Very well Miss Sophie...
> > > ...
> 
> Best™,
> Matthias

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 4483 bytes --]

Hi,

On 21.11.2017 15:42, Michael Tremer wrote:
> Hello,
> 
> any progress on this?

Not much, because I've been struggling with a flu for the past two
weeks, and its not over yet, but:

In the meantime I ran several builds with different parameters.

IMHO we could use:

'export XZ_OPT = --threads=0 -8 --memory=700MiB'

in 'lfs/cdrom'

and

cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8 --memory=700MiB" tar -c -p --numeric-owner -J -f /install/packages/package/files.tar.xz *

in 'lfs/Config'.

Using '9' or '--extreme'-parameter brought no further improvements,
on the other hand, build time and RAM consumption increased
strongly. With '-8', minimal RAM consumption was about 680 MiB, using
'700 Mib' was always safe. So this is the minimum I would recommend.

Results:

(Buildtime: 5 hours 20 minutes 59 seconds)

255866764  ipfire-2.19.1gb-ext4.i586-full-core117.img.gz
252262006  ipfire-2.19.1gb-ext4-scon.i586-full-core117.img.gz
175112192  ipfire-2.19.i586-full-core117.iso
 
> -Michael
> 
> On Tue, 2017-11-07 at 22:47 +0000, Michael Tremer wrote:
>> Hi,
>> 
>> On Tue, 2017-11-07 at 19:41 +0100, Matthias Fischer wrote:
>> > Hi,
>> > 
>> > On 07.11.2017 16:05, Michael Tremer wrote:
>> > > Hi,
>> > > 
>> > > maybe this function helps:
>> > > 
>> > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822a63d
>> > > c5d06d214b48f973b14f29
>> > 
>> > Thanks. I'll take a look...

This would help, indeed, but how to implement(!?), and... (see below)

>> > > On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
>> > > > On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
>> > > > ...
>> > > > > 
>> > > > > I forgot: Tuning the XZ-parameters... ;-)
>> > > > 
>> > > > Good that you are bringing this up. So I think what we should do here is
>> > > > bringing back XZ compression with -8 so that we do not waste too much
>> > > > space
>> > > > when
>> > > > extracting the image again.
>> > 
>> > Right now I'm testing how much RAM I need.
>> > 
>> > Current 'next'-build is running with:
>> > 
>> > 'lfs/cdrom':
>> > ...
>> > export XZ_OPT = --threads=0 -8 --memory=500MiB
>> > ...
>> > 
>> > 'lfs/Config':
>> > ...
>> > cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8" ...
>> > ...
>> > 
>> > I'm waiting for the results. Takes a while.
>> 
>> You can just run it like this and it will tell you:
>> 
>> [ms(a)hughes ~]$ xz -vv8 -T0
>> xz: Filter chain: --
>> lzma2=dict=32MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
>> xz: Using up to 4 threads.
>> xz: 2,629 MiB of memory is required. The limiter is disabled.
>> xz: Decompression will need 33 MiB of memory.
>> xz: Compressed data cannot be written to a terminal
>> xz: Try `xz --help' for more information.
>> 
>> > > > To not run into memory limits we should detect how much memory the build
>> > > > host
>> > > > has and set the memory limit to maybe 80% of that. xz will then
>> > > > automatically
>> > > > scale down to a number of parallel processes that it can fit into
>> > > > memory.

This is something I couldn't get to work. First, I couldn't specify not less
than '700 MiB'. If I specify '600 MiB', building stops and tells me it needs
at least about 680 MiB. If I use '70%', building stops. And I never saw that
'xz' "automatically scaled down". It just stopped everytime.
 
>> > I'm a bit puzzled about this: I tried using '--memory=70%' as mentioned
>> > in the xz man pages, but is seems to have no effect. It looks as if the
>> > percent parameter isn't recognized and ignored. It always ends up in
>> > "cannot allocate memory". Any hints on this? Do both 'lfs/cdrom' AND
>> > 'lfs/Config' need the '--memory'-parameter?

This was the next problem: 'percent'-parameter does not work as expected.

>> Yes, but it would be good to have one place where the parameters are
>> being generated and then we just use them from a variable.

Probably beyond my capabilities for the moment. Any thoughts?

>> > > > ...
>> > > > We will at least need about half a GB which should be a sensible
>> > > > requirement
>> > > > for a build system any ways.

I'm afraid '500 MiB' are not enough...

>> > Agreed. Because of this I'm testing with '500Mib'.
>> > 
>> > > > Will you work on this bringing it into the build system?!
>> > 
>> > "I'll do my very best!" :-))
>> 
>> Very well Miss Sophie...
>> ...

Best™,
Matthias

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

Hello,

any progress on this?

-Michael

On Tue, 2017-11-07 at 22:47 +0000, Michael Tremer wrote:
> Hi,
> 
> On Tue, 2017-11-07 at 19:41 +0100, Matthias Fischer wrote:
> > Hi,
> > 
> > On 07.11.2017 16:05, Michael Tremer wrote:
> > > Hi,
> > > 
> > > maybe this function helps:
> > > 
> > > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822a63d
> > > c5d06d214b48f973b14f29
> > 
> > Thanks. I'll take a look...
> > 
> > > On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
> > > > On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
> > > > ...
> > > > > 
> > > > > I forgot: Tuning the XZ-parameters... ;-)
> > > > 
> > > > Good that you are bringing this up. So I think what we should do here is
> > > > bringing back XZ compression with -8 so that we do not waste too much
> > > > space
> > > > when
> > > > extracting the image again.
> > 
> > Right now I'm testing how much RAM I need.
> > 
> > Current 'next'-build is running with:
> > 
> > 'lfs/cdrom':
> > ...
> > export XZ_OPT = --threads=0 -8 --memory=500MiB
> > ...
> > 
> > 'lfs/Config':
> > ...
> > cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8" ...
> > ...
> > 
> > I'm waiting for the results. Takes a while.
> 
> You can just run it like this and it will tell you:
> 
> [ms(a)hughes ~]$ xz -vv8 -T0
> xz: Filter chain: --
> lzma2=dict=32MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
> xz: Using up to 4 threads.
> xz: 2,629 MiB of memory is required. The limiter is disabled.
> xz: Decompression will need 33 MiB of memory.
> xz: Compressed data cannot be written to a terminal
> xz: Try `xz --help' for more information.
> 
> > > > To not run into memory limits we should detect how much memory the build
> > > > host
> > > > has and set the memory limit to maybe 80% of that. xz will then
> > > > automatically
> > > > scale down to a number of parallel processes that it can fit into
> > > > memory.
> > 
> > I'm a bit puzzled about this: I tried using '--memory=70%' as mentioned
> > in the xz man pages, but is seems to have no effect. It looks as if the
> > percent parameter isn't recognized and ignored. It always ends up in
> > "cannot allocate memory". Any hints on this? Do both 'lfs/cdrom' AND
> > 'lfs/Config' need the '--memory'-parameter?
> 
> Yes, but it would be good to have one place where the parameters are
> being generated and then we just use them from a variable.
> 
> > > > ...
> > > > We will at least need about half a GB which should be a sensible
> > > > requirement
> > > > for a build system any ways.
> > 
> > Agreed. Because of this I'm testing with '500Mib'.
> > 
> > > > Will you work on this bringing it into the build system?!
> > 
> > "I'll do my very best!" :-))
> 
> Very well Miss Sophie...
> 
> > Best™,
> > Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Horace Michael]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

Dear all,

Indeed, the transport method should not impact the file being downloaded.
Today I did the download again using both HTTP and HTTPS: the size & hash are the same no matter the transport method used.
Something went wrong on my previous download (the size was only 185K instead of 485): there is no need to change the install procedure.

I'll continue the tests for OpenVPN 2.4.4 and post results on forum topic.


Best regards,
Horace



> Sent: Tuesday, November 21, 2017 at 1:49 PM
> From: "Michael Tremer" <michael.tremer(a)ipfire.org>
> To: ummeegge <ummeegge(a)ipfire.org>, "Horace Michael" <horace.michael(a)gmx.com>, development(a)lists.ipfire.org
> Subject: Re: Planning out Core Update 117
>
> The checksum should be exactly the same no matter what the protocol is used to
> transfer it.
> 
> -Michael
> 
> On Tue, 2017-11-21 at 11:25 +0100, ummeegge wrote:
> > Hello Michael,
> > i think this happens causing the switch from http to https. Can you use
> > instead of
> > curl -O http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_
> > core115.tar.gz
> > please
> > curl -O https://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3
> > _core115.tar.gz
> > 
> > ? Thanks.
> > 
> > Will correct this in the README-install.txt.
> > 
> > Greetings,
> > 
> > Erik
> > 
> > > Good evening Erik,
> > > 
> > > The package OpenVPN package hash from folder Core115 does not match with the
> > > ones posted by you in the .png snapshot:
> > > 
> > > [root(a)ipfire-vm tmp]# curl -O
> > > http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core11
> > > 5.tar.gz
> > >  % Total    % Received % Xferd  Average Speed   Time    Time     Time
> > > Current
> > >                                 Dload  Upload   Total   Spent    Left
> > > Speed
> > > 100   185  100   185    0     0    774      0 --:--:-- --:--:-- --:--:--
> > > 777
> > > [root(a)ipfire-vm tmp]# sha256sum ovpn_244_64_v3_core115.tar.gz
> > > b8a7ebde1eec9fbba3790e31136fdfe3c7ea5b8c27900df1942f28cbe7b9f9f7
> > > ovpn_244_64_v3_core115.tar.gz
> > > 
> > > Can you confirm the above hash for the ovpn_244_64_v3_core115.tar.gz
> > > 
> > > Thank you,
> > > Horace
> > > 
> > 
> > 

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

The checksum should be exactly the same no matter what the protocol is used to
transfer it.

-Michael

On Tue, 2017-11-21 at 11:25 +0100, ummeegge wrote:
> Hello Michael,
> i think this happens causing the switch from http to https. Can you use
> instead of
> curl -O http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_
> core115.tar.gz
> please
> curl -O https://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3
> _core115.tar.gz
> 
> ? Thanks.
> 
> Will correct this in the README-install.txt.
> 
> Greetings,
> 
> Erik
> 
> > Good evening Erik,
> > 
> > The package OpenVPN package hash from folder Core115 does not match with the
> > ones posted by you in the .png snapshot:
> > 
> > [root(a)ipfire-vm tmp]# curl -O
> > http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core11
> > 5.tar.gz
> >  % Total    % Received % Xferd  Average Speed   Time    Time     Time
> > Current
> >                                 Dload  Upload   Total   Spent    Left
> > Speed
> > 100   185  100   185    0     0    774      0 --:--:-- --:--:-- --:--:--
> > 777
> > [root(a)ipfire-vm tmp]# sha256sum ovpn_244_64_v3_core115.tar.gz
> > b8a7ebde1eec9fbba3790e31136fdfe3c7ea5b8c27900df1942f28cbe7b9f9f7
> > ovpn_244_64_v3_core115.tar.gz
> > 
> > Can you confirm the above hash for the ovpn_244_64_v3_core115.tar.gz
> > 
> > Thank you,
> > Horace
> > 
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Hello Michael,
i think this happens causing the switch from http to https. Can you use instead of
curl -O http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core115.tar.gz
please
curl -O https://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core115.tar.gz

? Thanks.

Will correct this in the README-install.txt.

Greetings,

Erik

> Good evening Erik,
> 
> The package OpenVPN package hash from folder Core115 does not match with the
> ones posted by you in the .png snapshot:
> 
> [root(a)ipfire-vm tmp]# curl -O
> http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core11
> 5.tar.gz
>  % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
>                                 Dload  Upload   Total   Spent    Left
> Speed
> 100   185  100   185    0     0    774      0 --:--:-- --:--:-- --:--:--
> 777
> [root(a)ipfire-vm tmp]# sha256sum ovpn_244_64_v3_core115.tar.gz
> b8a7ebde1eec9fbba3790e31136fdfe3c7ea5b8c27900df1942f28cbe7b9f9f7
> ovpn_244_64_v3_core115.tar.gz
> 
> Can you confirm the above hash for the ovpn_244_64_v3_core115.tar.gz
> 
> Thank you,
> Horace
> 

RE: Planning out Core Update 117

[Horace Michael]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

Good evening Erik,

The package OpenVPN package hash from folder Core115 does not match with the
ones posted by you in the .png snapshot:

 [root(a)ipfire-vm tmp]# curl -O
http://people.ipfire.org/~ummeegge/OpenVPN-2.4/Core115/ovpn_244_64_v3_core11
5.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
Current
                                 Dload  Upload   Total   Spent    Left
Speed
100   185  100   185    0     0    774      0 --:--:-- --:--:-- --:--:--
777
[root(a)ipfire-vm tmp]# sha256sum ovpn_244_64_v3_core115.tar.gz
b8a7ebde1eec9fbba3790e31136fdfe3c7ea5b8c27900df1942f28cbe7b9f9f7
ovpn_244_64_v3_core115.tar.gz

Can you confirm the above hash for the ovpn_244_64_v3_core115.tar.gz

Thank you,
Horace

-----Original Message-----
From: ummeegge [mailto:ummeegge(a)ipfire.org] 
Sent: vineri, 10 noiembrie 2017 17:36
To: Horace Michael <horace.michael(a)gmx.com>; development(a)lists.ipfire.org
Subject: Re: Planning out Core Update 117

Hi Michael,
thanks for your interest. You can find in here -->
https://people.ipfire.org/~ummeegge/OpenVPN-2.4/ the files and dev history .
Since Core 116 have no changes in the language files, the OpenVPN Core 115
development should also be valid for the actual IPFire version (try to keep
it in the forum as updated as possible).

Please CC your mails here also to development(a)lists.ipfire.org .

All the best,

Erik

> Hi Erik,
> 
> I'll join the testing as I am very interested in OpenVPN - N2N and road
warrior for Android clients.
> Sorry - I don't follow forum anymore, just the e-mail distribution list.
> 
> Best regards,
> h&m
> Horace




-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

owGVVWtMFFcUBh9Ety7aajXxUY9RFC277LLAwqIIouCCPBSkCrU4jzu7gzNzpzN3
F7GWGKJp6otaY1s1pmrRNhiNz/pqtam2vmJb+6A+sQG0any2jRWt2juzLPrD1HSz
O3Pn7L3nfOc73znznrVzRLdI5qW9lwZebOkVeeIaG1HWa80PORjzgIJIERUfTNDE
WXFWi9VS4kegMtwsxoegUEVKaVFBx7Of0f0gaFgGAUs80iALa8jpTAIeIx0UTEBm
COeHKpH4gVBHWKF2FesE8cBWQzUOgKiY/9hVGlRXGFX3Y+IxAkO5hjHJEFVB1JAt
KAOR1RlDgQtoEtgKwU+I6omPVxFWJWQP7bJjzRdfE5BlhHw+FN8O15ZgT4xvRxaP
g6pSkZCYWJGcWBF0VXAhs50wmt03hwaFGCjBhJEAjOUUxCExSMHGwDQBaTxAZhBp
RurFKqJmgBJRRvDUvX2RFdA0pBDD4XM+4yXMUEdT1dC9IzoNoBBjwyQkEAjFs1qc
Dgc1OVOS6OXJEsABHVe3OxHan2w2j/l9xsLY57Zans2x7mcSkpL1gAzPoYtNYdyI
5ZETIS5VYFnG5U51IJfT6UoWeAG5ODdiktgULoGaHbzgTE1MEBJSOBa52VQhVXDD
8wJYLVmMYuqEwwoFKZtiYVgcDKsPayFlPc9PiZ9RZhmeqKonYo3hkGG1GZ9CTfSJ
CmU9H+k6La5ptFqyqbA9EFYTlMuMKBHsCRsynmhuBlgtxbRcHgiKCtLEOFocKn8R
yawmIkhwON3gdHtcyRQG9kAoPOSLnJ9BEoz2m892OfSc4ZNn2zksp6cBT7tRwqpM
XWdIok70p3ROIwbYSsTRoFOQB4okRjEbFweI2YZUUTxDEDidbiPRiWI4Hs2fGFzo
JneUEA2uigpBGtKJHaYbVFPKBVHhjd70UztVTbrZb/r/aDizKoIo0YZnqCuaCvhp
ClirBjsUiwolwITpdCbTStJyKhgoPsVHD7TPBJqSL2A0m+kmzrSFR1D72aSnOaK6
xQGJB0bSMbAIgowk8h0KYTgSoDX2FmVT4EDbWBexArGEAiIYZiGkgkjCoekhqn5G
h4DJIm8s6dzSRVZCI5vnbTQoLZIQo9MsskIkGvLQQ3yZAKjT/6of2A0fmZJkxmMp
+ea4NeaucU8HWrH2IZwOxs87gu6txO0ACT1glJvi8gIjG/lUQ7iMyCxdmCobFCQU
mEXQjBFTxWiaSDkxeMlUeA1TjuZxkkhB6nYjUDHWqC8b9ctjZQQxZruEq8KUKNUy
pT4OKgM6MZEgm5E58DQ/TWQDxGDVSNYeBj6OIgIN+RiN181s/MNlM8GOLrRa3u00
sEtEZLeIqK6djFdRhKV7r/D7qWlQr4iG423x0/980O+t+Y+/GBDZ0CWtf918wTss
d9KpZVGlE7YodZvbwPtZ44Y3XbU7a99/bfetGpLorVqflz5QiNsR/cK5O1euPxw0
4MzlL9e8PaTtdtG9Zr5u8fpTt6OUj45W9smKHMuebLrmGOXecv3OqiVj0hzNFQVH
s3DjkeaTUy/lbOoZE/lOvtJ6/uGhlyectucUJEWdv/D6ozn5Pf5afPGrsfYuG4r3
f7ivLWX76sbvu7ccmZCWEdh6eL2FzCYba6bZZuZ1OhGTvbPp0dbfRC6nqfRUwTRL
jz491v29wPKp8I0tonxq08hhtQ2lB1zRnrIbKTnJi725M8ngf1o6H1p0M61zQ80H
Swff3XN8QKxn2bIdDxx98qaviK797hz6vTR3Tlf1ev39DfeO1W+61dDYUjN9wc2z
0sp+q/ofG7Lvk62tJZPndpdfJCPWpi13DCN//Dz3YMztspM9z93oU7+928K8AXNr
k6/OH7pwj2YZ1HtDnvPE0n7W8rJhK+/UeSctWrLrzNLdb5wd//jXfUlStykH5k0e
fWZkd8f+m5/P3Xc5c+O22L6jdvQ9MiV29cevWLL9B+vSFv90/eKD2GDrlfJmN341
InttU1TZo69/nIHLDqw7vHWXN37Fum17rerylsbIpgpScGbT6cK4Ra2eC6WxvV33
y+fkZlbd7Fq96tTgba1Vm6Pbfrlwctnd4fV9l6wYtxyP+3bjmH8B
=EIyW
-----END PGP MESSAGE-----

Re: Planning out Core Update 117

[Marcel Lorenz]

[-- Attachment #1: Type: text/plain, Size: 3618 bytes --]

Hi Matthias, hi Michael,

my test images work with this configure warnings. I think, we can 
certain remove
this old switches. I will send v2 patches for gmp/e2fsprogs and a 
cleanup patch for mpfr.

Some other packages brings this warnings: autoconf, automake, gzip, 
libtool, m4, patch

Best,
Marcel

Am 2017-11-17 20:37, schrieb Matthias Fischer:
> Hi,
> 
> On 17.11.2017 13:59, Matthias Fischer wrote:
>> Hi,
>> 
>> On 07.11.2017 11:44, Michael Tremer wrote:
>>> ...
>>> Could you also please review at least some of the patches that Marcel 
>>> sent
>>> last week?
>>> ...
>> 
>> Done.
>> 
>> Applied all patches (19 commits) from '2017-10-31' against the current 
>> 'next':
>> 
>> ***SNIP***
>> ...
>> On branch next
>> Changes not staged for commit:
>>   (use "git add <file>..." to update what will be committed)
>>   (use "git checkout -- <file>..." to discard changes in working 
>> directory)
>> 
>> 	modified:   config/rootfiles/common/boost
>> 	modified:   config/rootfiles/common/cmake
>> 	modified:   config/rootfiles/common/e2fsprogs
>> 	modified:   config/rootfiles/common/expat
>> 	modified:   config/rootfiles/common/gawk
>> 	modified:   config/rootfiles/common/glib
>> 	modified:   config/rootfiles/common/libarchive
>> 	modified:   config/rootfiles/common/libupnp
>> 	modified:   config/rootfiles/common/libxml2
>> 	modified:   config/rootfiles/common/libxslt
>> 	modified:   config/rootfiles/common/mpfr
>> 	modified:   config/rootfiles/common/pciutils
>> 	modified:   config/rootfiles/common/tcl
>> 	modified:   config/rootfiles/common/texinfo
>> 	modified:   config/rootfiles/common/xfsprogs
>> 	modified:   config/rootfiles/packages/minidlna
>> 	modified:   config/rootfiles/packages/nmap
>> 	modified:   config/rootfiles/packages/stunnel
>> 	modified:   lfs/boost
>> 	modified:   lfs/cmake
>> 	modified:   lfs/e2fsprogs
>> 	modified:   lfs/expat
>> 	modified:   lfs/gawk
>> 	modified:   lfs/glib
>> 	modified:   lfs/libarchive
>> 	modified:   lfs/libupnp
>> 	modified:   lfs/libxml2
>> 	modified:   lfs/libxslt
>> 	modified:   lfs/minidlna
>> 	modified:   lfs/mpfr
>> 	modified:   lfs/nmap
>> 	modified:   lfs/pciutils
>> 	modified:   lfs/rpcbind
>> 	modified:   lfs/stunnel
>> 	modified:   lfs/tcl
>> 	modified:   lfs/texinfo
>> 	modified:   lfs/xfsprogs
>> 
>> Untracked files:
>>   (use "git add <file>..." to include in what will be committed)
>> 
>>         src/patches/rpcbind-0.2.4-vulnerability_fixes-1.patch
>> ...
>> ***SNAP***
>> 
>> Results:
>> 
>> Source for 'e2fsprogs 1.43.6' were missing, copied them to 
>> git.ipfire.org. No problem.
>> Besides, in the meantime there's an update to '1.43.7', will test that 
>> with a clean build, too.
>> 
>> 'poppler 0.52.0' is complaining:
>> 
>> Changes in poppler-0.52.0 check rootfile! [see attachment]
>> 
>> Besides that, building was ok for now.
> 
> Final results:
> 
> All patches applied - 'poppler 0.52.0' needs rootfile fix.
> 
> The 'e2fsprogs'-update to 1.43.7 also applied - no further changes seem
> to be necessary for this update so far.
> 
> @Marcel: would you do these changes or shall I?
> 
> Found by chance:
> 
> I found about 70 'configure: WARNING: unrecognized
> options:'-notifications in '_build.base.log' and 'build.ipfire.log'.
> 
> These deal with '--enable-mpbsd', '--disable-nls' (gmp-6.1.2,
> mpfr-3.1.6, e.g.), '--disable-evms', --enable-multibyte'
> '--enable-zlib', '--disable-static' , '--disable-kernel-module' and so 
> on.
> 
> I don't know why these option switches are still included or why they
> exist, but: shouldn't we take a look at this?
> 
> Best,
> Matthias

-- 
Gesendet mit Roundcube

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 4186 bytes --]

Hi,

On 17.11.2017 22:25, Michael Tremer wrote:
> Hi,
> 
> and when you apply only a few? Are there any conflicts to expect?

Good question, I thought something like that. It's really a lot. But
sorry, my knowledge isn't good enough to be able to assess whether
conflicts will arise. BUILDING was ok, but BEHAVIOUR during productive
use? Don't know, sorry. Hopefully Marcel has tested this prior to
comitting? Any comments from him?

Surely I could test only with "only a few". Which ones would you have in
mind? For a start, I can't assess the 'packages' - I never used any of
these.

Best,
Matthias

> On Fri, 2017-11-17 at 20:37 +0100, Matthias Fischer wrote:
>> Hi,
>> 
>> On 17.11.2017 13:59, Matthias Fischer wrote:
>> > Hi,
>> > 
>> > On 07.11.2017 11:44, Michael Tremer wrote:
>> > > ...
>> > > Could you also please review at least some of the patches that Marcel sent
>> > > last week?
>> > > ...
>> > 
>> > Done.
>> > 
>> > Applied all patches (19 commits) from '2017-10-31' against the current 'next':
>> > 
>> > ***SNIP***
>> > ...
>> > On branch next
>> > Changes not staged for commit:
>> >   (use "git add <file>..." to update what will be committed)
>> >   (use "git checkout -- <file>..." to discard changes in working directory)
>> > 
>> > 	modified:   config/rootfiles/common/boost
>> > 	modified:   config/rootfiles/common/cmake
>> > 	modified:   config/rootfiles/common/e2fsprogs
>> > 	modified:   config/rootfiles/common/expat
>> > 	modified:   config/rootfiles/common/gawk
>> > 	modified:   config/rootfiles/common/glib
>> > 	modified:   config/rootfiles/common/libarchive
>> > 	modified:   config/rootfiles/common/libupnp
>> > 	modified:   config/rootfiles/common/libxml2
>> > 	modified:   config/rootfiles/common/libxslt
>> > 	modified:   config/rootfiles/common/mpfr
>> > 	modified:   config/rootfiles/common/pciutils
>> > 	modified:   config/rootfiles/common/tcl
>> > 	modified:   config/rootfiles/common/texinfo
>> > 	modified:   config/rootfiles/common/xfsprogs
>> > 	modified:   config/rootfiles/packages/minidlna
>> > 	modified:   config/rootfiles/packages/nmap
>> > 	modified:   config/rootfiles/packages/stunnel
>> > 	modified:   lfs/boost
>> > 	modified:   lfs/cmake
>> > 	modified:   lfs/e2fsprogs
>> > 	modified:   lfs/expat
>> > 	modified:   lfs/gawk
>> > 	modified:   lfs/glib
>> > 	modified:   lfs/libarchive
>> > 	modified:   lfs/libupnp
>> > 	modified:   lfs/libxml2
>> > 	modified:   lfs/libxslt
>> > 	modified:   lfs/minidlna
>> > 	modified:   lfs/mpfr
>> > 	modified:   lfs/nmap
>> > 	modified:   lfs/pciutils
>> > 	modified:   lfs/rpcbind
>> > 	modified:   lfs/stunnel
>> > 	modified:   lfs/tcl
>> > 	modified:   lfs/texinfo
>> > 	modified:   lfs/xfsprogs
>> > 
>> > Untracked files:
>> >   (use "git add <file>..." to include in what will be committed)
>> > 
>> >         src/patches/rpcbind-0.2.4-vulnerability_fixes-1.patch
>> > ...
>> > ***SNAP***
>> > 
>> > Results:
>> > 
>> > Source for 'e2fsprogs 1.43.6' were missing, copied them to git.ipfire.org. No problem.
>> > Besides, in the meantime there's an update to '1.43.7', will test that with a clean build, too.
>> > 
>> > 'poppler 0.52.0' is complaining:
>> > 
>> > Changes in poppler-0.52.0 check rootfile! [see attachment]
>> > 
>> > Besides that, building was ok for now.
>> 
>> Final results:
>> 
>> All patches applied - 'poppler 0.52.0' needs rootfile fix.
>> 
>> The 'e2fsprogs'-update to 1.43.7 also applied - no further changes seem
>> to be necessary for this update so far.
>> 
>> @Marcel: would you do these changes or shall I?
>> 
>> Found by chance:
>> 
>> I found about 70 'configure: WARNING: unrecognized
>> options:'-notifications in '_build.base.log' and 'build.ipfire.log'.
>> 
>> These deal with '--enable-mpbsd', '--disable-nls' (gmp-6.1.2,
>> mpfr-3.1.6, e.g.), '--disable-evms', --enable-multibyte'
>> '--enable-zlib', '--disable-static' , '--disable-kernel-module' and so on.
>> 
>> I don't know why these option switches are still included or why they
>> exist, but: shouldn't we take a look at this?
>> 
>> Best,
>> Matthias
> 

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3531 bytes --]

Hi,

and when you apply only a few? Are there any conflicts to expect?

On Fri, 2017-11-17 at 20:37 +0100, Matthias Fischer wrote:
> Hi,
> 
> On 17.11.2017 13:59, Matthias Fischer wrote:
> > Hi,
> > 
> > On 07.11.2017 11:44, Michael Tremer wrote:
> > > ...
> > > Could you also please review at least some of the patches that Marcel sent
> > > last week?
> > > ...
> > 
> > Done.
> > 
> > Applied all patches (19 commits) from '2017-10-31' against the current 'next':
> > 
> > ***SNIP***
> > ...
> > On branch next
> > Changes not staged for commit:
> >   (use "git add <file>..." to update what will be committed)
> >   (use "git checkout -- <file>..." to discard changes in working directory)
> > 
> > 	modified:   config/rootfiles/common/boost
> > 	modified:   config/rootfiles/common/cmake
> > 	modified:   config/rootfiles/common/e2fsprogs
> > 	modified:   config/rootfiles/common/expat
> > 	modified:   config/rootfiles/common/gawk
> > 	modified:   config/rootfiles/common/glib
> > 	modified:   config/rootfiles/common/libarchive
> > 	modified:   config/rootfiles/common/libupnp
> > 	modified:   config/rootfiles/common/libxml2
> > 	modified:   config/rootfiles/common/libxslt
> > 	modified:   config/rootfiles/common/mpfr
> > 	modified:   config/rootfiles/common/pciutils
> > 	modified:   config/rootfiles/common/tcl
> > 	modified:   config/rootfiles/common/texinfo
> > 	modified:   config/rootfiles/common/xfsprogs
> > 	modified:   config/rootfiles/packages/minidlna
> > 	modified:   config/rootfiles/packages/nmap
> > 	modified:   config/rootfiles/packages/stunnel
> > 	modified:   lfs/boost
> > 	modified:   lfs/cmake
> > 	modified:   lfs/e2fsprogs
> > 	modified:   lfs/expat
> > 	modified:   lfs/gawk
> > 	modified:   lfs/glib
> > 	modified:   lfs/libarchive
> > 	modified:   lfs/libupnp
> > 	modified:   lfs/libxml2
> > 	modified:   lfs/libxslt
> > 	modified:   lfs/minidlna
> > 	modified:   lfs/mpfr
> > 	modified:   lfs/nmap
> > 	modified:   lfs/pciutils
> > 	modified:   lfs/rpcbind
> > 	modified:   lfs/stunnel
> > 	modified:   lfs/tcl
> > 	modified:   lfs/texinfo
> > 	modified:   lfs/xfsprogs
> > 
> > Untracked files:
> >   (use "git add <file>..." to include in what will be committed)
> > 
> >         src/patches/rpcbind-0.2.4-vulnerability_fixes-1.patch
> > ...
> > ***SNAP***
> > 
> > Results:
> > 
> > Source for 'e2fsprogs 1.43.6' were missing, copied them to git.ipfire.org. No problem.
> > Besides, in the meantime there's an update to '1.43.7', will test that with a clean build, too.
> > 
> > 'poppler 0.52.0' is complaining:
> > 
> > Changes in poppler-0.52.0 check rootfile! [see attachment]
> > 
> > Besides that, building was ok for now.
> 
> Final results:
> 
> All patches applied - 'poppler 0.52.0' needs rootfile fix.
> 
> The 'e2fsprogs'-update to 1.43.7 also applied - no further changes seem
> to be necessary for this update so far.
> 
> @Marcel: would you do these changes or shall I?
> 
> Found by chance:
> 
> I found about 70 'configure: WARNING: unrecognized
> options:'-notifications in '_build.base.log' and 'build.ipfire.log'.
> 
> These deal with '--enable-mpbsd', '--disable-nls' (gmp-6.1.2,
> mpfr-3.1.6, e.g.), '--disable-evms', --enable-multibyte'
> '--enable-zlib', '--disable-static' , '--disable-kernel-module' and so on.
> 
> I don't know why these option switches are still included or why they
> exist, but: shouldn't we take a look at this?
> 
> Best,
> Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 3189 bytes --]

Hi,

On 17.11.2017 13:59, Matthias Fischer wrote:
> Hi,
> 
> On 07.11.2017 11:44, Michael Tremer wrote:
>> ...
>> Could you also please review at least some of the patches that Marcel sent
>> last week?
>> ...
> 
> Done.
> 
> Applied all patches (19 commits) from '2017-10-31' against the current 'next':
> 
> ***SNIP***
> ...
> On branch next
> Changes not staged for commit:
>   (use "git add <file>..." to update what will be committed)
>   (use "git checkout -- <file>..." to discard changes in working directory)
> 
> 	modified:   config/rootfiles/common/boost
> 	modified:   config/rootfiles/common/cmake
> 	modified:   config/rootfiles/common/e2fsprogs
> 	modified:   config/rootfiles/common/expat
> 	modified:   config/rootfiles/common/gawk
> 	modified:   config/rootfiles/common/glib
> 	modified:   config/rootfiles/common/libarchive
> 	modified:   config/rootfiles/common/libupnp
> 	modified:   config/rootfiles/common/libxml2
> 	modified:   config/rootfiles/common/libxslt
> 	modified:   config/rootfiles/common/mpfr
> 	modified:   config/rootfiles/common/pciutils
> 	modified:   config/rootfiles/common/tcl
> 	modified:   config/rootfiles/common/texinfo
> 	modified:   config/rootfiles/common/xfsprogs
> 	modified:   config/rootfiles/packages/minidlna
> 	modified:   config/rootfiles/packages/nmap
> 	modified:   config/rootfiles/packages/stunnel
> 	modified:   lfs/boost
> 	modified:   lfs/cmake
> 	modified:   lfs/e2fsprogs
> 	modified:   lfs/expat
> 	modified:   lfs/gawk
> 	modified:   lfs/glib
> 	modified:   lfs/libarchive
> 	modified:   lfs/libupnp
> 	modified:   lfs/libxml2
> 	modified:   lfs/libxslt
> 	modified:   lfs/minidlna
> 	modified:   lfs/mpfr
> 	modified:   lfs/nmap
> 	modified:   lfs/pciutils
> 	modified:   lfs/rpcbind
> 	modified:   lfs/stunnel
> 	modified:   lfs/tcl
> 	modified:   lfs/texinfo
> 	modified:   lfs/xfsprogs
> 
> Untracked files:
>   (use "git add <file>..." to include in what will be committed)
> 
>         src/patches/rpcbind-0.2.4-vulnerability_fixes-1.patch
> ...
> ***SNAP***
> 
> Results:
> 
> Source for 'e2fsprogs 1.43.6' were missing, copied them to git.ipfire.org. No problem.
> Besides, in the meantime there's an update to '1.43.7', will test that with a clean build, too.
> 
> 'poppler 0.52.0' is complaining:
> 
> Changes in poppler-0.52.0 check rootfile! [see attachment]
> 
> Besides that, building was ok for now.

Final results:

All patches applied - 'poppler 0.52.0' needs rootfile fix.

The 'e2fsprogs'-update to 1.43.7 also applied - no further changes seem
to be necessary for this update so far.

@Marcel: would you do these changes or shall I?

Found by chance:

I found about 70 'configure: WARNING: unrecognized
options:'-notifications in '_build.base.log' and 'build.ipfire.log'.

These deal with '--enable-mpbsd', '--disable-nls' (gmp-6.1.2,
mpfr-3.1.6, e.g.), '--disable-evms', --enable-multibyte'
'--enable-zlib', '--disable-static' , '--disable-kernel-module' and so on.

I don't know why these option switches are still included or why they
exist, but: shouldn't we take a look at this?

Best,
Matthias

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

Hi,

On 07.11.2017 11:44, Michael Tremer wrote:
> ...
> Could you also please review at least some of the patches that Marcel sent
> last week?
> ...

Done.

Applied all patches (19 commits) from '2017-10-31' against the current 'next':

***SNIP***
...
On branch next
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   config/rootfiles/common/boost
	modified:   config/rootfiles/common/cmake
	modified:   config/rootfiles/common/e2fsprogs
	modified:   config/rootfiles/common/expat
	modified:   config/rootfiles/common/gawk
	modified:   config/rootfiles/common/glib
	modified:   config/rootfiles/common/libarchive
	modified:   config/rootfiles/common/libupnp
	modified:   config/rootfiles/common/libxml2
	modified:   config/rootfiles/common/libxslt
	modified:   config/rootfiles/common/mpfr
	modified:   config/rootfiles/common/pciutils
	modified:   config/rootfiles/common/tcl
	modified:   config/rootfiles/common/texinfo
	modified:   config/rootfiles/common/xfsprogs
	modified:   config/rootfiles/packages/minidlna
	modified:   config/rootfiles/packages/nmap
	modified:   config/rootfiles/packages/stunnel
	modified:   lfs/boost
	modified:   lfs/cmake
	modified:   lfs/e2fsprogs
	modified:   lfs/expat
	modified:   lfs/gawk
	modified:   lfs/glib
	modified:   lfs/libarchive
	modified:   lfs/libupnp
	modified:   lfs/libxml2
	modified:   lfs/libxslt
	modified:   lfs/minidlna
	modified:   lfs/mpfr
	modified:   lfs/nmap
	modified:   lfs/pciutils
	modified:   lfs/rpcbind
	modified:   lfs/stunnel
	modified:   lfs/tcl
	modified:   lfs/texinfo
	modified:   lfs/xfsprogs

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        src/patches/rpcbind-0.2.4-vulnerability_fixes-1.patch
...
***SNAP***

Results:

Source for 'e2fsprogs 1.43.6' were missing, copied them to git.ipfire.org. No problem.
Besides, in the meantime there's an update to '1.43.7', will test that with a clean build, too.

'poppler 0.52.0' is complaining:

Changes in poppler-0.52.0 check rootfile! [see attachment]

Besides that, building was ok for now.

HTH,
Matthias



[-- Attachment #2: poppler-0.52.0 --]
[-- Type: text/plain, Size: 8848 bytes --]

usr/bin/pdfdetach
usr/bin/pdffonts
usr/bin/pdfimages
usr/bin/pdfinfo
usr/bin/pdfseparate
usr/bin/pdftocairo
usr/bin/pdftohtml
usr/bin/pdftoppm
usr/bin/pdftops
usr/bin/pdftotext
usr/bin/pdfunite
#usr/include/poppler
#usr/include/poppler/Annot.h
#usr/include/poppler/Array.h
#usr/include/poppler/BuiltinFont.h
#usr/include/poppler/BuiltinFontTables.h
#usr/include/poppler/CMap.h
#usr/include/poppler/CachedFile.h
#usr/include/poppler/Catalog.h
#usr/include/poppler/CharCodeToUnicode.h
#usr/include/poppler/CharTypes.h
#usr/include/poppler/CompactFontTables.h
#usr/include/poppler/DateInfo.h
#usr/include/poppler/Decrypt.h
#usr/include/poppler/Dict.h
#usr/include/poppler/Error.h
#usr/include/poppler/ErrorCodes.h
#usr/include/poppler/FileSpec.h
#usr/include/poppler/FontEncodingTables.h
#usr/include/poppler/FontInfo.h
#usr/include/poppler/Form.h
#usr/include/poppler/Function.h
#usr/include/poppler/Gfx.h
#usr/include/poppler/GfxFont.h
#usr/include/poppler/GfxState.h
#usr/include/poppler/GfxState_helpers.h
#usr/include/poppler/GlobalParams.h
#usr/include/poppler/Hints.h
#usr/include/poppler/JArithmeticDecoder.h
#usr/include/poppler/JBIG2Stream.h
#usr/include/poppler/Lexer.h
#usr/include/poppler/Linearization.h
#usr/include/poppler/Link.h
#usr/include/poppler/LocalPDFDocBuilder.h
#usr/include/poppler/MarkedContentOutputDev.h
#usr/include/poppler/Movie.h
#usr/include/poppler/NameToCharCode.h
#usr/include/poppler/NameToUnicodeTable.h
#usr/include/poppler/Object.h
#usr/include/poppler/OptionalContent.h
#usr/include/poppler/Outline.h
#usr/include/poppler/OutputDev.h
#usr/include/poppler/PDFDoc.h
#usr/include/poppler/PDFDocBuilder.h
#usr/include/poppler/PDFDocEncoding.h
#usr/include/poppler/PDFDocFactory.h
#usr/include/poppler/PSOutputDev.h
#usr/include/poppler/PSTokenizer.h
#usr/include/poppler/Page.h
#usr/include/poppler/PageTransition.h
#usr/include/poppler/Parser.h
#usr/include/poppler/PopplerCache.h
#usr/include/poppler/PreScanOutputDev.h
#usr/include/poppler/ProfileData.h
#usr/include/poppler/Rendition.h
#usr/include/poppler/SecurityHandler.h
#usr/include/poppler/SignatureInfo.h
#usr/include/poppler/Sound.h
#usr/include/poppler/SplashOutputDev.h
#usr/include/poppler/StdinCachedFile.h
#usr/include/poppler/StdinPDFDocBuilder.h
#usr/include/poppler/Stream-CCITT.h
#usr/include/poppler/Stream.h
#usr/include/poppler/StructElement.h
#usr/include/poppler/StructTreeRoot.h
#usr/include/poppler/TextOutputDev.h
#usr/include/poppler/UTF.h
#usr/include/poppler/UTF8.h
#usr/include/poppler/UnicodeCClassTables.h
#usr/include/poppler/UnicodeCompTables.h
#usr/include/poppler/UnicodeDecompTables.h
#usr/include/poppler/UnicodeMap.h
#usr/include/poppler/UnicodeMapTables.h
#usr/include/poppler/UnicodeTypeTable.h
#usr/include/poppler/ViewerPreferences.h
#usr/include/poppler/XRef.h
#usr/include/poppler/XpdfPluginAPI.h
#usr/include/poppler/cpp
#usr/include/poppler/cpp/poppler-document.h
#usr/include/poppler/cpp/poppler-embedded-file.h
#usr/include/poppler/cpp/poppler-font.h
#usr/include/poppler/cpp/poppler-global.h
#usr/include/poppler/cpp/poppler-image.h
#usr/include/poppler/cpp/poppler-page-renderer.h
#usr/include/poppler/cpp/poppler-page-transition.h
#usr/include/poppler/cpp/poppler-page.h
#usr/include/poppler/cpp/poppler-rectangle.h
#usr/include/poppler/cpp/poppler-toc.h
#usr/include/poppler/cpp/poppler-version.h
#usr/include/poppler/fofi
#usr/include/poppler/fofi/FoFiBase.h
#usr/include/poppler/fofi/FoFiEncodings.h
#usr/include/poppler/fofi/FoFiIdentifier.h
#usr/include/poppler/fofi/FoFiTrueType.h
#usr/include/poppler/fofi/FoFiType1.h
#usr/include/poppler/fofi/FoFiType1C.h
+usr/include/poppler/glib
+usr/include/poppler/glib/poppler-action.h
+usr/include/poppler/glib/poppler-annot.h
+usr/include/poppler/glib/poppler-attachment.h
+usr/include/poppler/glib/poppler-date.h
+usr/include/poppler/glib/poppler-document.h
+usr/include/poppler/glib/poppler-enums.h
+usr/include/poppler/glib/poppler-features.h
+usr/include/poppler/glib/poppler-form-field.h
+usr/include/poppler/glib/poppler-layer.h
+usr/include/poppler/glib/poppler-media.h
+usr/include/poppler/glib/poppler-movie.h
+usr/include/poppler/glib/poppler-page.h
+usr/include/poppler/glib/poppler-structure-element.h
+usr/include/poppler/glib/poppler.h
#usr/include/poppler/goo
#usr/include/poppler/goo/FixedPoint.h
#usr/include/poppler/goo/GooHash.h
#usr/include/poppler/goo/GooLikely.h
#usr/include/poppler/goo/GooList.h
#usr/include/poppler/goo/GooMutex.h
#usr/include/poppler/goo/GooString.h
#usr/include/poppler/goo/GooTimer.h
#usr/include/poppler/goo/ImgWriter.h
#usr/include/poppler/goo/JpegWriter.h
#usr/include/poppler/goo/NetPBMWriter.h
#usr/include/poppler/goo/PNGWriter.h
#usr/include/poppler/goo/TiffWriter.h
#usr/include/poppler/goo/gfile.h
#usr/include/poppler/goo/gmem.h
#usr/include/poppler/goo/grandom.h
#usr/include/poppler/goo/gstrtod.h
#usr/include/poppler/goo/gtypes.h
#usr/include/poppler/poppler-config.h
#usr/include/poppler/splash
#usr/include/poppler/splash/Splash.h
#usr/include/poppler/splash/SplashBitmap.h
#usr/include/poppler/splash/SplashClip.h
#usr/include/poppler/splash/SplashErrorCodes.h
#usr/include/poppler/splash/SplashFTFont.h
#usr/include/poppler/splash/SplashFTFontEngine.h
#usr/include/poppler/splash/SplashFTFontFile.h
#usr/include/poppler/splash/SplashFont.h
#usr/include/poppler/splash/SplashFontEngine.h
#usr/include/poppler/splash/SplashFontFile.h
#usr/include/poppler/splash/SplashFontFileID.h
#usr/include/poppler/splash/SplashGlyphBitmap.h
#usr/include/poppler/splash/SplashMath.h
#usr/include/poppler/splash/SplashPath.h
#usr/include/poppler/splash/SplashPattern.h
#usr/include/poppler/splash/SplashScreen.h
#usr/include/poppler/splash/SplashState.h
#usr/include/poppler/splash/SplashT1Font.h
#usr/include/poppler/splash/SplashT1FontEngine.h
#usr/include/poppler/splash/SplashT1FontFile.h
#usr/include/poppler/splash/SplashTypes.h
#usr/include/poppler/splash/SplashXPath.h
#usr/include/poppler/splash/SplashXPathScanner.h
#usr/lib/libpoppler-cpp.a
#usr/lib/libpoppler-cpp.la
#usr/lib/libpoppler-cpp.so
usr/lib/libpoppler-cpp.so.0
usr/lib/libpoppler-cpp.so.0.3.0
+usr/lib/libpoppler-glib.a
+usr/lib/libpoppler-glib.la
+usr/lib/libpoppler-glib.so
+usr/lib/libpoppler-glib.so.8
+usr/lib/libpoppler-glib.so.8.8.0
#usr/lib/libpoppler.a
#usr/lib/libpoppler.la
#usr/lib/libpoppler.so
usr/lib/libpoppler.so.66
usr/lib/libpoppler.so.66.0.0
#usr/lib/pkgconfig/poppler-cairo.pc
#usr/lib/pkgconfig/poppler-cpp.pc
+usr/lib/pkgconfig/poppler-glib.pc
#usr/lib/pkgconfig/poppler-splash.pc
#usr/lib/pkgconfig/poppler.pc
+usr/share/gtk-doc/html/poppler
+usr/share/gtk-doc/html/poppler/PopplerAnnot.html
+usr/share/gtk-doc/html/poppler/PopplerAttachment.html
+usr/share/gtk-doc/html/poppler/PopplerDocument.html
+usr/share/gtk-doc/html/poppler/PopplerFormField.html
+usr/share/gtk-doc/html/poppler/PopplerLayer.html
+usr/share/gtk-doc/html/poppler/PopplerMedia.html
+usr/share/gtk-doc/html/poppler/PopplerMovie.html
+usr/share/gtk-doc/html/poppler/PopplerPage.html
+usr/share/gtk-doc/html/poppler/PopplerStructureElement.html
+usr/share/gtk-doc/html/poppler/annotation-glossary.html
+usr/share/gtk-doc/html/poppler/api-index-0-12.html
+usr/share/gtk-doc/html/poppler/api-index-0-14.html
+usr/share/gtk-doc/html/poppler/api-index-0-16.html
+usr/share/gtk-doc/html/poppler/api-index-0-18.html
+usr/share/gtk-doc/html/poppler/api-index-0-20.html
+usr/share/gtk-doc/html/poppler/api-index-0-22.html
+usr/share/gtk-doc/html/poppler/api-index-0-26.html
+usr/share/gtk-doc/html/poppler/api-index-0-33.html
+usr/share/gtk-doc/html/poppler/api-index-0-46.html
+usr/share/gtk-doc/html/poppler/api-index-deprecated.html
+usr/share/gtk-doc/html/poppler/api-index-full.html
+usr/share/gtk-doc/html/poppler/ch01.html
+usr/share/gtk-doc/html/poppler/home.png
+usr/share/gtk-doc/html/poppler/index.html
+usr/share/gtk-doc/html/poppler/left-insensitive.png
+usr/share/gtk-doc/html/poppler/left.png
+usr/share/gtk-doc/html/poppler/poppler-Error-handling.html
+usr/share/gtk-doc/html/poppler/poppler-PDF-Utility-functions.html
+usr/share/gtk-doc/html/poppler/poppler-PopplerAction.html
+usr/share/gtk-doc/html/poppler/poppler-PopplerColor.html
+usr/share/gtk-doc/html/poppler/poppler-Version-and-Features-Information.html
+usr/share/gtk-doc/html/poppler/poppler.devhelp2
+usr/share/gtk-doc/html/poppler/right-insensitive.png
+usr/share/gtk-doc/html/poppler/right.png
+usr/share/gtk-doc/html/poppler/style.css
+usr/share/gtk-doc/html/poppler/up-insensitive.png
+usr/share/gtk-doc/html/poppler/up.png
#usr/share/man/man1/pdfdetach.1
#usr/share/man/man1/pdffonts.1
#usr/share/man/man1/pdfimages.1
#usr/share/man/man1/pdfinfo.1
#usr/share/man/man1/pdfseparate.1
#usr/share/man/man1/pdftocairo.1
#usr/share/man/man1/pdftohtml.1
#usr/share/man/man1/pdftoppm.1
#usr/share/man/man1/pdftops.1
#usr/share/man/man1/pdftotext.1
#usr/share/man/man1/pdfunite.1

Re: Planning out Core Update 117

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Hi Michael,
thanks for your interest. You can find in here --> https://people.ipfire.org/~ummeegge/OpenVPN-2.4/ the files and dev history . Since Core 116 have no changes in the language files, the OpenVPN Core 115 development should also be valid for the actual IPFire version (try to keep it in the forum as updated as possible)…

Please CC your mails here also to development(a)lists.ipfire.org .

All the best,

Erik

> Hi Erik,
> 
> I'll join the testing as I am very interested in OpenVPN - N2N and road warrior for Android clients.
> Sorry - I don't follow forum anymore, just the e-mail distribution list.
> 
> Best regards,
> h&m
> Horace

Re: Planning out Core Update 117

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Hi Michael,

> Great.
> 
> Could you send the patch to the list so that we can comment on it?
OK will adapt the patches to Core 116 and send it as soon as possible to the dev list.

> 
> Also, do you have any plans to migrate to OpenVPN 2.4? Not sure how long 2.3
> will be patched.
Have builded and also tested the 2.4 from Alpha version to the until now actual 2.4.4 and have had no issues at all. The development in there --> https://forum.ipfire.org/viewtopic.php?f=50&t=18067#p104536 is relatively lonely since i do the testings on my own accept one user which made a very quick positive test. Since i normally want some more testers before i go for a merge request i am there a little lost until now since there is no feedback at all.
I developed a minimal solution which includes the needed changes to bring the 2.4.x version to life on IPFire but there is also an extended one with several new features also available over the ovpnmain.cgi.

Larger testing round can also be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=17656 whereby i tried to explain also the new and for interesting features also al little.

I think 2.3 will be supported for longer time but 2.4 has some very good improvements under the hood and above and i think it might be nice for IPFire even some more testers might be great for that may it is nevertheless time to push it to mainline ?

Best,

Erik

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Great.

Could you send the patch to the list so that we can comment on it?

Also, do you have any plans to migrate to OpenVPN 2.4? Not sure how long 2.3
will be patched.

Best,
-Michael

On Fri, 2017-11-10 at 12:01 +0100, ummeegge wrote:
> Hi Michael,
> have here some fixes from Bugzilla causing OpenVPN --> https://bugzilla.ipfire
> .org/show_bug.cgi?id=10482 a clean patch can be found in here --> https://gith
> ub.com/ummeegge/ipfire_core111_ovpn_fixes/commit/da7349461630ce9e38a9a5b47f41b
> c644e907ef8#diff-2011d5d928fd214cacb83844729c65cc but needs to be patched for
> Core 115 and this here --> https://bugzilla.ipfire.org/show_bug.cgi?id=11364
> with a couples of patches whereby the "--ns-cert-type" patch is already merged
> .
> 
> If you think some of them are useful, let it me know ;-) .
> 
> Greetings,
> 
> Erik
> 
> 
> Am 06.11.2017 um 19:32 schrieb Michael Tremer:
> 
> > Hello,
> > 
> > so the big Core Update 115 has been shipped last week. Core Update 116 is
> > coming
> > today. So the next one should be a little bit calmer please :)
> > 
> > I do not have anything so far except some smaller bug fixes here and there.
> > Does
> > anyone have anything big? It doesn't have to be another big update. We could
> > also just improve IPFire where ever it is needed with loads of smaller
> > changes
> > and start working on 3 and other sub-projects that are floating around...
> > 
> > Best,
> > -Michael
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

Hi Michael,
have here some fixes from Bugzilla causing OpenVPN --> https://bugzilla.ipfire.org/show_bug.cgi?id=10482 a clean patch can be found in here --> https://github.com/ummeegge/ipfire_core111_ovpn_fixes/commit/da7349461630ce9e38a9a5b47f41bc644e907ef8#diff-2011d5d928fd214cacb83844729c65cc but needs to be patched for Core 115 and this here --> https://bugzilla.ipfire.org/show_bug.cgi?id=11364 with a couples of patches whereby the "--ns-cert-type" patch is already merged .

If you think some of them are useful, let it me know ;-) .

Greetings,

Erik


Am 06.11.2017 um 19:32 schrieb Michael Tremer:

> Hello,
> 
> so the big Core Update 115 has been shipped last week. Core Update 116 is coming
> today. So the next one should be a little bit calmer please :)
> 
> I do not have anything so far except some smaller bug fixes here and there. Does
> anyone have anything big? It doesn't have to be another big update. We could
> also just improve IPFire where ever it is needed with loads of smaller changes
> and start working on 3 and other sub-projects that are floating around...
> 
> Best,
> -Michael

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

Hi,

On Tue, 2017-11-07 at 19:41 +0100, Matthias Fischer wrote:
> Hi,
> 
> On 07.11.2017 16:05, Michael Tremer wrote:
> > Hi,
> > 
> > maybe this function helps:
> > 
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822a63dc5d06d214b48f973b14f29
> 
> Thanks. I'll take a look...
> 
> > On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
> > > On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
> > > ...
> > > > 
> > > > I forgot: Tuning the XZ-parameters... ;-)
> > > 
> > > Good that you are bringing this up. So I think what we should do here is
> > > bringing back XZ compression with -8 so that we do not waste too much space
> > > when
> > > extracting the image again.
> 
> Right now I'm testing how much RAM I need.
> 
> Current 'next'-build is running with:
> 
> 'lfs/cdrom':
> ...
> export XZ_OPT = --threads=0 -8 --memory=500MiB
> ...
> 
> 'lfs/Config':
> ...
> cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8" ...
> ...
> 
> I'm waiting for the results. Takes a while.

You can just run it like this and it will tell you:

[ms(a)hughes ~]$ xz -vv8 -T0
xz: Filter chain: --lzma2=dict=32MiB,lc=3,lp=0,pb=2,mode=normal,nice=64,mf=bt4,depth=0
xz: Using up to 4 threads.
xz: 2,629 MiB of memory is required. The limiter is disabled.
xz: Decompression will need 33 MiB of memory.
xz: Compressed data cannot be written to a terminal
xz: Try `xz --help' for more information.

> > > To not run into memory limits we should detect how much memory the build host
> > > has and set the memory limit to maybe 80% of that. xz will then automatically
> > > scale down to a number of parallel processes that it can fit into memory.
> 
> I'm a bit puzzled about this: I tried using '--memory=70%' as mentioned
> in the xz man pages, but is seems to have no effect. It looks as if the
> percent parameter isn't recognized and ignored. It always ends up in
> "cannot allocate memory". Any hints on this? Do both 'lfs/cdrom' AND
> 'lfs/Config' need the '--memory'-parameter?

Yes, but it would be good to have one place where the parameters are
being generated and then we just use them from a variable.

> > > ...
> > > We will at least need about half a GB which should be a sensible requirement
> > > for a build system any ways.
> 
> Agreed. Because of this I'm testing with '500Mib'.
> 
> > > Will you work on this bringing it into the build system?!
> 
> "I'll do my very best!" :-))

Very well Miss Sophie...

> Best™,
> Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Hi,

On 07.11.2017 16:05, Michael Tremer wrote:
> Hi,
> 
> maybe this function helps:
> 
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822a63dc5d06d214b48f973b14f29

Thanks. I'll take a look...

> On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
>> On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
>> ...
>> > 
>> > I forgot: Tuning the XZ-parameters... ;-)
>> 
>> Good that you are bringing this up. So I think what we should do here is
>> bringing back XZ compression with -8 so that we do not waste too much space
>> when
>> extracting the image again.

Right now I'm testing how much RAM I need.

Current 'next'-build is running with:

'lfs/cdrom':
...
export XZ_OPT = --threads=0 -8 --memory=500MiB
...

'lfs/Config':
...
cd /install/packages/package/tmp/ && XZ_OPT="-T0 -8" ...
...

I'm waiting for the results. Takes a while.

>> To not run into memory limits we should detect how much memory the build host
>> has and set the memory limit to maybe 80% of that. xz will then automatically
>> scale down to a number of parallel processes that it can fit into memory.

I'm a bit puzzled about this: I tried using '--memory=70%' as mentioned
in the xz man pages, but is seems to have no effect. It looks as if the
percent parameter isn't recognized and ignored. It always ends up in
"cannot allocate memory". Any hints on this? Do both 'lfs/cdrom' AND
'lfs/Config' need the '--memory'-parameter?

>> ...
>> We will at least need about half a GB which should be a sensible requirement
>> for a build system any ways.

Agreed. Because of this I'm testing with '500Mib'.

>> Will you work on this bringing it into the build system?!

"I'll do my very best!" :-))

Best™,
Matthias

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

Hi,

maybe this function helps:

https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=5190eea24f9822a63dc5d06d214b48f973b14f29

On Tue, 2017-11-07 at 10:46 +0000, Michael Tremer wrote:
> On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
> > On 06.11.2017 19:32, Michael Tremer wrote:
> > > Hello,
> > > 
> > > so the big Core Update 115 has been shipped last week. Core Update 116 is
> > > coming
> > > today. So the next one should be a little bit calmer please :)
> > > 
> > > I do not have anything so far except some smaller bug fixes here and
> > > there.
> > > Does
> > > anyone have anything big? It doesn't have to be another big update. We
> > > could
> > > also just improve IPFire where ever it is needed with loads of smaller
> > > changes
> > > and start working on 3 and other sub-projects that are floating around...
> > 
> > I forgot: Tuning the XZ-parameters... ;-)
> 
> Good that you are bringing this up. So I think what we should do here is
> bringing back XZ compression with -8 so that we do not waste too much space
> when
> extracting the image again.
> 
> To not run into memory limits we should detect how much memory the build host
> has and set the memory limit to maybe 80% of that. xz will then automatically
> scale down to a number of parallel processes that it can fit into memory.
> 
> We will at least need about half a GB which should be a sensible requirement
> for
> a build system any ways.
> 
> Will you work on this bringing it into the build system?!
> 
> -Michael
> 
> > 
> > Best,
> > Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Mon, 2017-11-06 at 22:09 +0100, Matthias Fischer wrote:
> On 06.11.2017 19:32, Michael Tremer wrote:
> > Hello,
> > 
> > so the big Core Update 115 has been shipped last week. Core Update 116 is
> > coming
> > today. So the next one should be a little bit calmer please :)
> > 
> > I do not have anything so far except some smaller bug fixes here and there.
> > Does
> > anyone have anything big? It doesn't have to be another big update. We could
> > also just improve IPFire where ever it is needed with loads of smaller
> > changes
> > and start working on 3 and other sub-projects that are floating around...
> 
> I forgot: Tuning the XZ-parameters... ;-)

Good that you are bringing this up. So I think what we should do here is
bringing back XZ compression with -8 so that we do not waste too much space when
extracting the image again.

To not run into memory limits we should detect how much memory the build host
has and set the memory limit to maybe 80% of that. xz will then automatically
scale down to a number of parallel processes that it can fit into memory.

We will at least need about half a GB which should be a sensible requirement for
a build system any ways.

Will you work on this bringing it into the build system?!

-Michael

> 
> Best,
> Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Hi,

On Mon, 2017-11-06 at 22:06 +0100, Matthias Fischer wrote:
> Hi,
> 
> On 06.11.2017 19:32, Michael Tremer wrote:
> > Hello,
> > 
> > so the big Core Update 115 has been shipped last week. Core Update 116 is
> > coming
> > today. So the next one should be a little bit calmer please :)
> 
> We'll see... ;-)
> 
> > I do not have anything so far except some smaller bug fixes here and there.
> > Does
> > anyone have anything big? It doesn't have to be another big update. We could
> > also just improve IPFire where ever it is needed with loads of smaller
> > changes
> > and start working on 3 and other sub-projects that are floating around...
> 
> Just back in town and getting a grip - I only have a few smaller fixes
> and features in mind:
> 
> 'captive portal'-localization: missing german translation for
> 'unlimited' - patch is being prepared.

Okay.

> https://forum.ipfire.org/viewtopic.php?f=17&t=19792 (Mini-Bug in
> 'captive portal'): couldn't test this by now

I fixed this one already:

  https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=ad1204e4eb397b4f7d10c3bdfa9214aa8c0a0575

> Updates in progress: 'ethtool' to 4.13, 'smartmontools' to 6.6, 'tor' to
> 0.3.1.8 (interested?)

Okay. Could you also please review at least some of the patches that Marcel sent
last week?

> 'squid-graph'-localization and package (if I get the time)
> 
> As I can see: nothing serious from my side... ;-)

That's good :)

> 
> Best,
> Matthias

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On 06.11.2017 19:32, Michael Tremer wrote:
> Hello,
> 
> so the big Core Update 115 has been shipped last week. Core Update 116 is coming
> today. So the next one should be a little bit calmer please :)
> 
> I do not have anything so far except some smaller bug fixes here and there. Does
> anyone have anything big? It doesn't have to be another big update. We could
> also just improve IPFire where ever it is needed with loads of smaller changes
> and start working on 3 and other sub-projects that are floating around...

I forgot: Tuning the XZ-parameters... ;-)

Best,
Matthias

Re: Planning out Core Update 117

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

Hi,

On 06.11.2017 19:32, Michael Tremer wrote:
> Hello,
> 
> so the big Core Update 115 has been shipped last week. Core Update 116 is coming
> today. So the next one should be a little bit calmer please :)

We'll see... ;-)

> I do not have anything so far except some smaller bug fixes here and there. Does
> anyone have anything big? It doesn't have to be another big update. We could
> also just improve IPFire where ever it is needed with loads of smaller changes
> and start working on 3 and other sub-projects that are floating around...

Just back in town and getting a grip - I only have a few smaller fixes
and features in mind:

'captive portal'-localization: missing german translation for
'unlimited' - patch is being prepared.

https://forum.ipfire.org/viewtopic.php?f=17&t=19792 (Mini-Bug in
'captive portal'): couldn't test this by now

Updates in progress: 'ethtool' to 4.13, 'smartmontools' to 6.6, 'tor' to
0.3.1.8 (interested?)

'squid-graph'-localization and package (if I get the time)

As I can see: nothing serious from my side... ;-)

Best,
Matthias

Planning out Core Update 117

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hello,

so the big Core Update 115 has been shipped last week. Core Update 116 is coming
today. So the next one should be a little bit calmer please :)

I do not have anything so far except some smaller bug fixes here and there. Does
anyone have anything big? It doesn't have to be another big update. We could
also just improve IPFire where ever it is needed with loads of smaller changes
and start working on 3 and other sub-projects that are floating around...

Best,
-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]