[gentoo-portage-dev] Portage and SIGHUP

[gentoo-portage-dev] Portage and SIGHUP

[Fabian Groffen]

I recently noticed this:

(pegasus:portage/dev-libs/poppler) fabian% emerge --resume
Calculating dependencies... done!
*** Resuming merge...

>>> Verifying ebuild manifests

>>> Starting parallel fetch

>>> Emerging (1 of 9) dev-libs/libgpg-error-1.7
 * libgpg-error-1.7.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...              [ ok ]
 * checking ebuild checksums ;-) ...                                     [ ok ]
 * checking auxfile checksums ;-) ...                                    [ ok ]
 * checking miscfile checksums ;-) ...                                   [ ok ]
>>> Unpacking source...
>>> Unpacking libgpg-error-1.7.tar.bz2 to /net/pegasus.ins.cwi.nl/export/scratch/stripe/fabian/gentoo/prefix64/var/tmp/portage/dev-libs/libgpg-error-1.7/work
 * Running eautoreconf in '/net/pegasus.ins.cwi.nl/export/scratch/stripe/fabian/gentoo/prefix64/var/tmp/portage/dev-libs/libgpg-error-1.7/work/libgpg-error-1.7' ...
 * Running aclocal -I m4 -I /net/pegasus.ins.cwi.nl/export/scratch/stripe/fabian/gentoo/prefix64/usr/share/aclocal ...
Hangup
(pegasus:portage/dev-libs/poppler) fabian%

e.g. Portage terminating immediately on a SIGHUP.  If I sent SIGHUP myself to
Portage from another shell it immediately stops as well.

Can some one Linux try to reproduce this?  I tested it by doing emerge -av portage and from another terminal SIGHUP that emerge.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-portage-dev] Portage and SIGHUP

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fabian Groffen wrote:
> I recently noticed this:
> 
> (pegasus:portage/dev-libs/poppler) fabian% emerge --resume
> Calculating dependencies... done!
> *** Resuming merge...
> 
>>>> Verifying ebuild manifests
> 
>>>> Starting parallel fetch
> 
>>>> Emerging (1 of 9) dev-libs/libgpg-error-1.7
>  * libgpg-error-1.7.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...              [ ok ]
>  * checking ebuild checksums ;-) ...                                     [ ok ]
>  * checking auxfile checksums ;-) ...                                    [ ok ]
>  * checking miscfile checksums ;-) ...                                   [ ok ]
>>>> Unpacking source...
>>>> Unpacking libgpg-error-1.7.tar.bz2 to /net/pegasus.ins.cwi.nl/export/scratch/stripe/fabian/gentoo/prefix64/var/tmp/portage/dev-libs/libgpg-error-1.7/work
>  * Running eautoreconf in '/net/pegasus.ins.cwi.nl/export/scratch/stripe/fabian/gentoo/prefix64/var/tmp/portage/dev-libs/libgpg-error-1.7/work/libgpg-error-1.7' ...
>  * Running aclocal -I m4 -I /net/pegasus.ins.cwi.nl/export/scratch/stripe/fabian/gentoo/prefix64/usr/share/aclocal ...
> Hangup
> (pegasus:portage/dev-libs/poppler) fabian%
> 
> e.g. Portage terminating immediately on a SIGHUP.  If I sent SIGHUP myself to
> Portage from another shell it immediately stops as well.
> 
> Can some one Linux try to reproduce this?  I tested it by doing emerge -av portage and from another terminal SIGHUP that emerge.

Well, what else would you expect from SIGHUP? It's supposed to mean
that the terminal has been lost, right? That's what it says here:

  http://en.wikipedia.org/wiki/SIGHUP

If you want a program to continue running after the terminal is
lost, then you're supposed to do something like use nohup or run it
inside of a screen session.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAknwqtcACgkQ/ejvha5XGaN4OACeIluDFQ9wGAzYHKPp0OUL6y+K
BZcAnjtzQPlN3u+o8hOoaFrqY4jfNdPO
=w5IF
-----END PGP SIGNATURE-----

[gentoo-portage-dev] files in ${FILESDIR}

[Toha]

What about this idea: list all files in ${FILESDIR} (patches, init scripts), related to ebuild in this ebuild like:

FLS=( "some-init-script" "${PN}-patch1.patch" "${PN}-${PV}-patch2.patch" ... "${PN}-patchN.patch" )

then using this files by addressing his index in ${FLS} array

applying patches with command: epatch 1 ( or in batch mode: epatch 1 2 3 )
and init scripts like: doinitd 0
etc.

reason: easy automated way to moving ebuilds with all required files betwen repositories/overlays

Re: [gentoo-portage-dev] files in ${FILESDIR}

[Mike Frysinger]

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

On Tuesday 05 May 2009 02:26:21 Toha wrote:
> What about this idea: list all files in ${FILESDIR} (patches, init
> scripts), related to ebuild in this ebuild like:
>
> FLS=( "some-init-script" "${PN}-patch1.patch" "${PN}-${PV}-patch2.patch"
> ... "${PN}-patchN.patch" )
>
> then using this files by addressing his index in ${FLS} array
>
> applying patches with command: epatch 1 ( or in batch mode: epatch 1 2 3 )
> and init scripts like: doinitd 0
> etc.
>
> reason: easy automated way to moving ebuilds with all required files betwen
> repositories/overlays

downsides: updating of array causes ugly cascading of changes throughout the 
entire ebuild instead of one or two lines.  maintaining the info indirectly 
with numbers makes reading ebuilds harder to understand and harder to maintain 
(adding/dropping files).

such changes should be proposed on the gentoo-dev mailing list anyways ... 
you'll get a lot more feedback as to why this is more "con" than "pro".
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]