Question regarding package updates, applying patches, and building

Question regarding package updates, applying patches, and building

[Peter Müller]

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

Hello,

while trying to update entire packages in IPFire (some
of them are outdated) and to fix some bugs, I ran into
a couple of questions:

(a) How to update entire packages?

As far as I understood, to every package belongs a file
in lfs/[package_name], containing information about how
to build, apply patches to it, and so on.

It seems like packages are downloaded from https://source.ipfire.org/ ,
but it did not became clear to me how to upload a new
version of a package to this server. Of course, the
download URL can be changed manually, but that seems rather
ugly to me.

Unfortunately, I was unable to find a sort of tutorial
in the wiki for this issue.


(b) How to apply patches to downloaded packages with changed filenames?

As discussed in December (https://wiki.ipfire.org/devel/telco/2017-12-04),
I am supposed to have a look at the DEFAULT cipher suite in
OpenSSL.

To change this value, the .tar.gz file needs to be downloaded
and unpacked first. After that, the file "ssl/ssl.h" needs to be
changed.

The patch at src/patches/openssl-1.0.2h-weak-ciphers.patch does
something similar:

diff -Naur openssl-1.0.2h.org/ssl/ssl.h openssl-1.0.2h/ssl/ssl.h
--- openssl-1.0.2h.org/ssl/ssl.h	2016-05-03 15:44:42.000000000 +0200
+++ openssl-1.0.2h/ssl/ssl.h	2016-05-03 18:49:10.393302264 +0200
@@ -338,7 +338,7 @@
  * The following cipher list is used by default. It also is substituted when
  * an application-defined cipher list string starts with 'DEFAULT'.
  */
-# define SSL_DEFAULT_CIPHER_LIST "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2"
+# define SSL_DEFAULT_CIPHER_LIST "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2:!RC2:!DES"
 /*
  * As of OpenSSL 1.0.0, ssl_create_cipher_list() in ssl/ssl_ciph.c always
  * starts with a reasonable order, and all we have to do for DEFAULT is

But where does the file openssl-[...].org came from?


(c) How to build the distribution partly?

In the past, I handed in some patches to allow remote syslogging via
TCP, too. After some struggles (settings are written by a C program, not
the CGI file itself), I modified syslogdctrl.c, and the changes were shipped.
(See https://bugzilla.ipfire.org/show_bug.cgi?id=11540 for details.)

But since this program now crashes with a segfault on my machine (*sigh*),
it seems like my patch contained some errors.

However, building the entire distribution is somewhat time-consuming
and not worth the effort for a probably small error. Is there any way
of just building this C program, and omit the rest?


Thanks in advance!

Best regards,
Peter Müller

Re: Question regarding package updates, applying patches, and building

[Michael Tremer]

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

Hi,

On Sun, 2018-01-07 at 14:42 +0100, Peter Müller wrote:
> Hello,
> 
> while trying to update entire packages in IPFire (some
> of them are outdated) and to fix some bugs, I ran into
> a couple of questions:
> 
> (a) How to update entire packages?
> 
> As far as I understood, to every package belongs a file
> in lfs/[package_name], containing information about how
> to build, apply patches to it, and so on.

Yes.

> It seems like packages are downloaded from https://source.ipfire.org/ ,
> but it did not became clear to me how to upload a new
> version of a package to this server. Of course, the
> download URL can be changed manually, but that seems rather
> ugly to me.

We usually upload everything here manually since the official download mirrors
are always a bit slow and maintainers seem to move their packages around a lot
by moving them to an /old/ directory and then the URLs break. That's not fun.

So we need to create an LDAP account for you and then you can login to
git.ipfire.org and upload them to /pub/sources/...

> Unfortunately, I was unable to find a sort of tutorial
> in the wiki for this issue.

Indeed this isn't being documented.

> (b) How to apply patches to downloaded packages with changed filenames?
> 
> As discussed in December (https://wiki.ipfire.org/devel/telco/2017-12-04),
> I am supposed to have a look at the DEFAULT cipher suite in
> OpenSSL.
> 
> To change this value, the .tar.gz file needs to be downloaded
> and unpacked first. After that, the file "ssl/ssl.h" needs to be
> changed.

We NEVER change the original archives that we download from some project's
website. That makes it impossible to track what has been changed compared to the
official release. So, we use patches.

> The patch at src/patches/openssl-1.0.2h-weak-ciphers.patch does
> something similar:
> 
> diff -Naur openssl-1.0.2h.org/ssl/ssl.h openssl-1.0.2h/ssl/ssl.h
> --- openssl-1.0.2h.org/ssl/ssl.h	2016-05-03 15:44:42.000000000 +0200
> +++ openssl-1.0.2h/ssl/ssl.h	2016-05-03 18:49:10.393302264 +0200
> @@ -338,7 +338,7 @@
>   * The following cipher list is used by default. It also is substituted when
>   * an application-defined cipher list string starts with 'DEFAULT'.
>   */
> -# define SSL_DEFAULT_CIPHER_LIST "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2"
> +# define SSL_DEFAULT_CIPHER_LIST
> "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2:!RC2:!DES"
>  /*
>   * As of OpenSSL 1.0.0, ssl_create_cipher_list() in ssl/ssl_ciph.c always
>   * starts with a reasonable order, and all we have to do for DEFAULT is
> 
> But where does the file openssl-[...].org came from?

That isn't a domain name. It is usually that I extract the archive like this:

  tar xvfa openssl-1.0.2h.tar.gz

Then I move everything to a new directory that usually gets a ".org" or "-
vanilla" suffix. This is the original version as it comes from the upstream
project.

Then I extract the tarball again and modify my files.

And finally I just diff the changed directory against the original one like
this:

  diff -Nur openssl-1.0.2h.org/ openssl-1.0.2h/

And that creates the patch.

For bigger changes I just check out their Git repository and create a new branch
based on the latest release. This is also handy when submitting the patches
upstream.

> (c) How to build the distribution partly?
> 
> In the past, I handed in some patches to allow remote syslogging via
> TCP, too. After some struggles (settings are written by a C program, not
> the CGI file itself), I modified syslogdctrl.c, and the changes were shipped.
> (See https://bugzilla.ipfire.org/show_bug.cgi?id=11540 for details.)
> 
> But since this program now crashes with a segfault on my machine (*sigh*),
> it seems like my patch contained some errors.
> 
> However, building the entire distribution is somewhat time-consuming
> and not worth the effort for a probably small error. Is there any way
> of just building this C program, and omit the rest?

You have to build the entire distribution the first time. If you want to rebuild
a single package, you have to delete the log file for that package from the
logs/ directory and run "./make.sh build" again.

Hope this helps so far. If you have any more questions, please ask.

Best,
-Michael

> 
> 
> Thanks in advance!
> 
> Best regards,
> Peter Müller

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

Re: Question regarding package updates, applying patches, and building

[Peter Müller]

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

Hello,

while updating gnupg, I stumbled over an empty log file (log/gunpg-1.4.23).
However, it seems to compile successfully. What is this supposed to mean?

Thanks, and best regards,
Peter Müller

> Hi,
> 
> On Sun, 2018-01-07 at 14:42 +0100, Peter Müller wrote:
>> Hello,
>>
>> while trying to update entire packages in IPFire (some
>> of them are outdated) and to fix some bugs, I ran into
>> a couple of questions:
>>
>> (a) How to update entire packages?
>>
>> As far as I understood, to every package belongs a file
>> in lfs/[package_name], containing information about how
>> to build, apply patches to it, and so on.
> 
> Yes.
> 
>> It seems like packages are downloaded from https://source.ipfire.org/ ,
>> but it did not became clear to me how to upload a new
>> version of a package to this server. Of course, the
>> download URL can be changed manually, but that seems rather
>> ugly to me.
> 
> We usually upload everything here manually since the official download mirrors
> are always a bit slow and maintainers seem to move their packages around a lot
> by moving them to an /old/ directory and then the URLs break. That's not fun.
> 
> So we need to create an LDAP account for you and then you can login to
> git.ipfire.org and upload them to /pub/sources/...
> 
>> Unfortunately, I was unable to find a sort of tutorial
>> in the wiki for this issue.
> 
> Indeed this isn't being documented.
> 
>> (b) How to apply patches to downloaded packages with changed filenames?
>>
>> As discussed in December (https://wiki.ipfire.org/devel/telco/2017-12-04),
>> I am supposed to have a look at the DEFAULT cipher suite in
>> OpenSSL.
>>
>> To change this value, the .tar.gz file needs to be downloaded
>> and unpacked first. After that, the file "ssl/ssl.h" needs to be
>> changed.
> 
> We NEVER change the original archives that we download from some project's
> website. That makes it impossible to track what has been changed compared to the
> official release. So, we use patches.
> 
>> The patch at src/patches/openssl-1.0.2h-weak-ciphers.patch does
>> something similar:
>>
>> diff -Naur openssl-1.0.2h.org/ssl/ssl.h openssl-1.0.2h/ssl/ssl.h
>> --- openssl-1.0.2h.org/ssl/ssl.h	2016-05-03 15:44:42.000000000 +0200
>> +++ openssl-1.0.2h/ssl/ssl.h	2016-05-03 18:49:10.393302264 +0200
>> @@ -338,7 +338,7 @@
>>   * The following cipher list is used by default. It also is substituted when
>>   * an application-defined cipher list string starts with 'DEFAULT'.
>>   */
>> -# define SSL_DEFAULT_CIPHER_LIST "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2"
>> +# define SSL_DEFAULT_CIPHER_LIST
>> "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2:!RC2:!DES"
>>  /*
>>   * As of OpenSSL 1.0.0, ssl_create_cipher_list() in ssl/ssl_ciph.c always
>>   * starts with a reasonable order, and all we have to do for DEFAULT is
>>
>> But where does the file openssl-[...].org came from?
> 
> That isn't a domain name. It is usually that I extract the archive like this:
> 
>   tar xvfa openssl-1.0.2h.tar.gz
> 
> Then I move everything to a new directory that usually gets a ".org" or "-
> vanilla" suffix. This is the original version as it comes from the upstream
> project.
> 
> Then I extract the tarball again and modify my files.
> 
> And finally I just diff the changed directory against the original one like
> this:
> 
>   diff -Nur openssl-1.0.2h.org/ openssl-1.0.2h/
> 
> And that creates the patch.
> 
> For bigger changes I just check out their Git repository and create a new branch
> based on the latest release. This is also handy when submitting the patches
> upstream.
> 
>> (c) How to build the distribution partly?
>>
>> In the past, I handed in some patches to allow remote syslogging via
>> TCP, too. After some struggles (settings are written by a C program, not
>> the CGI file itself), I modified syslogdctrl.c, and the changes were shipped.
>> (See https://bugzilla.ipfire.org/show_bug.cgi?id=11540 for details.)
>>
>> But since this program now crashes with a segfault on my machine (*sigh*),
>> it seems like my patch contained some errors.
>>
>> However, building the entire distribution is somewhat time-consuming
>> and not worth the effort for a probably small error. Is there any way
>> of just building this C program, and omit the rest?
> 
> You have to build the entire distribution the first time. If you want to rebuild
> a single package, you have to delete the log file for that package from the
> logs/ directory and run "./make.sh build" again.
> 
> Hope this helps so far. If you have any more questions, please ask.
> 
> Best,
> -Michael
> 
>>
>>
>> Thanks in advance!
>>
>> Best regards,
>> Peter Müller

-- 
"We don't care.  We don't have to.  We're the Phone Company."


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

Re: Question regarding package updates, applying patches, and building

[Michael Tremer]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

That means that that package did not install any files.

That should of course not happen. Check if you are calling "make install" and
perform a clean build.

Best,
- -Michael

On Sun, 2018-06-17 at 10:37 +0200, Peter Müller wrote:
> Hello,
> 
> while updating gnupg, I stumbled over an empty log file (log/gunpg-1.4.23).
> However, it seems to compile successfully. What is this supposed to mean?
> 
> Thanks, and best regards,
> Peter Müller
> 
> > Hi,
> > 
> > On Sun, 2018-01-07 at 14:42 +0100, Peter Müller wrote:
> > > Hello,
> > > 
> > > while trying to update entire packages in IPFire (some
> > > of them are outdated) and to fix some bugs, I ran into
> > > a couple of questions:
> > > 
> > > (a) How to update entire packages?
> > > 
> > > As far as I understood, to every package belongs a file
> > > in lfs/[package_name], containing information about how
> > > to build, apply patches to it, and so on.
> > 
> > Yes.
> > 
> > > It seems like packages are downloaded from https://source.ipfire.org/ ,
> > > but it did not became clear to me how to upload a new
> > > version of a package to this server. Of course, the
> > > download URL can be changed manually, but that seems rather
> > > ugly to me.
> > 
> > We usually upload everything here manually since the official download
> > mirrors
> > are always a bit slow and maintainers seem to move their packages around a
> > lot
> > by moving them to an /old/ directory and then the URLs break. That's not
> > fun.
> > 
> > So we need to create an LDAP account for you and then you can login to
> > git.ipfire.org and upload them to /pub/sources/...
> > 
> > > Unfortunately, I was unable to find a sort of tutorial
> > > in the wiki for this issue.
> > 
> > Indeed this isn't being documented.
> > 
> > > (b) How to apply patches to downloaded packages with changed filenames?
> > > 
> > > As discussed in December (https://wiki.ipfire.org/devel/telco/2017-12-04),
> > > I am supposed to have a look at the DEFAULT cipher suite in
> > > OpenSSL.
> > > 
> > > To change this value, the .tar.gz file needs to be downloaded
> > > and unpacked first. After that, the file "ssl/ssl.h" needs to be
> > > changed.
> > 
> > We NEVER change the original archives that we download from some project's
> > website. That makes it impossible to track what has been changed compared to
> > the
> > official release. So, we use patches.
> > 
> > > The patch at src/patches/openssl-1.0.2h-weak-ciphers.patch does
> > > something similar:
> > > 
> > > diff -Naur openssl-1.0.2h.org/ssl/ssl.h openssl-1.0.2h/ssl/ssl.h
> > > --- openssl-1.0.2h.org/ssl/ssl.h	2016-05-03 15:44:42.000000000
> > > +0200
> > > +++ openssl-1.0.2h/ssl/ssl.h	2016-05-03 18:49:10.393302264 +0200
> > > @@ -338,7 +338,7 @@
> > >   * The following cipher list is used by default. It also is substituted
> > > when
> > >   * an application-defined cipher list string starts with 'DEFAULT'.
> > >   */
> > > -# define SSL_DEFAULT_CIPHER_LIST "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2"
> > > +# define SSL_DEFAULT_CIPHER_LIST
> > > "ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2:!RC2:!DES"
> > >  /*
> > >   * As of OpenSSL 1.0.0, ssl_create_cipher_list() in ssl/ssl_ciph.c always
> > >   * starts with a reasonable order, and all we have to do for DEFAULT is
> > > 
> > > But where does the file openssl-[...].org came from?
> > 
> > That isn't a domain name. It is usually that I extract the archive like
> > this:
> > 
> >   tar xvfa openssl-1.0.2h.tar.gz
> > 
> > Then I move everything to a new directory that usually gets a ".org" or "-
> > vanilla" suffix. This is the original version as it comes from the upstream
> > project.
> > 
> > Then I extract the tarball again and modify my files.
> > 
> > And finally I just diff the changed directory against the original one like
> > this:
> > 
> >   diff -Nur openssl-1.0.2h.org/ openssl-1.0.2h/
> > 
> > And that creates the patch.
> > 
> > For bigger changes I just check out their Git repository and create a new
> > branch
> > based on the latest release. This is also handy when submitting the patches
> > upstream.
> > 
> > > (c) How to build the distribution partly?
> > > 
> > > In the past, I handed in some patches to allow remote syslogging via
> > > TCP, too. After some struggles (settings are written by a C program, not
> > > the CGI file itself), I modified syslogdctrl.c, and the changes were
> > > shipped.
> > > (See https://bugzilla.ipfire.org/show_bug.cgi?id=11540 for details.)
> > > 
> > > But since this program now crashes with a segfault on my machine (*sigh*),
> > > it seems like my patch contained some errors.
> > > 
> > > However, building the entire distribution is somewhat time-consuming
> > > and not worth the effort for a probably small error. Is there any way
> > > of just building this C program, and omit the rest?
> > 
> > You have to build the entire distribution the first time. If you want to
> > rebuild
> > a single package, you have to delete the log file for that package from the
> > logs/ directory and run "./make.sh build" again.
> > 
> > Hope this helps so far. If you have any more questions, please ask.
> > 
> > Best,
> > -Michael
> > 
> > > 
> > > 
> > > Thanks in advance!
> > > 
> > > Best regards,
> > > Peter Müller
> 
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAlsmYPYACgkQgHnw/2+Q
CQeJCw/+O6SPT7VsVO+fdSq6zn7eN3WWFoPNaibCldfV/+jSRtNBCMQD9LRjhXW8
Qe7XPFrD0ApvRFTOSDwqgBlSstAB0pZ3cI0jdvdWFK2Oi39ZTvHxCWMxnHPyhdxH
AdPJp/QIKYbDpoCGnghvhBf644GmryooTxTaoTrntEI+aQQoESdkc0DxmZZ6QsbV
AtboCRSBQgc15g7vaZttakarHLIqyG8YKjQ+4AXJQ8Ntr7y6tpfCjan4MaMykbS1
f5gtIu0FBuRvpSAyoqCoLYTCME1J1Wk7w2evtkpm43f+ciBdBmQtRsBjC1jGJwBH
I5ZAR97PqG9cIDIBkOhXP0bZAKbiETEkMr0TIrEj0dPJRyHUn+imtM1RujtybURb
1ybkT/SFpua7JSlrRVJzxH0DdSpbU6LQZDygwnduVCHe+fmfskRUWC8OtC6ERQJO
5jU5gFOqUmsEeuOsYpJUstNeekpAac/7gN+1IizCKfPwb5t0tjob02YhlVbHvKHq
uEylBrJA7R6kqGGrChfdev1j1zP3fmAXArQS7W8Y2BGex/U958LqXwmXjalW7dbR
XVJ0K8yZF8m3amYX0iGOzxc5BF+ot9DE9/bmxS5PQTkqKwv9BZBUnNCJvST0/Jg9
HIKGlC/dhrPNRAVT648XyCUiUFLuZf7OtQV2gzn+33knJsp9z6M=
=FSqs
-----END PGP SIGNATURE-----