Difference between pages "Ebuild Functions" and "Package:Irssi"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
== Ebuild Functions ==
{{Ebuild
|Summary=A modular textUI IRC client with IPv6 support.
|CatPkg=net-irc/irssi
|Maintainer=
|Homepage=http://www.irssi.org/
}}


Ebuilds provide the ability to define various shell functions that are used to specify various actions relating to building and installing a source or binary package on a user's system. When an ebuild is emerged, the following functions are called, in order:
=== Description ===
irssi is a small command line IRC client based on ncurses. It's a great thing to use when you SSH into a server, or just simply for your main IRC client.  


* <tt>pkg_setup</tt> - variable intialization and sanity checks
=== Installation ===
* <tt>src_unpack</tt>
The install of irssi is pretty straight forward. There are not many USE flags, but one that is worth looking at is the {{c|SSL}} flag. This enables you to use SSL when connecting to servers.
* <tt>src_prepare</tt>
{{console|body=
* <tt>src_configure</tt>
###i## echo "net-irc/irssi ssl" >> /etc/portage/package.use
* <tt>src_compile</tt>
###i## emerge irssi
* <tt>src_install</tt>
}}
=== Using irssi ===
Using irssi initially can be a little intimidating if you're not used to command line programs. To first start irssi, you just simply run:
{{console|body=
$ ##i##irssi
}}
There are flags you can pass to the command line while starting irssi, such as:
{{console|body=
$ ##i##irssi -n mynick -c irc.freenode.org
}}
This would connect you to Freenode with the nick 'mynick'. Or alternatively you can just run the {{c|irssi}} command and connect via SSL if you need to:
{{file|body=
/connect -ssl irc.freenode.org
}}
This will automatically connect you over port 6697.


At this point, the files are ready to be "merged" into the live filesystem. This is when they are copied from the temporary build directory into <tt>/usr</tt>, etc. At this point, the following functions are executed:
When you have connected to the server of your choice, you can join a channel simply by:
{{file|body=
/j #funtoo
}}
If you want to leave any channel you've entered you can use the {{c|part}} command:
{{file|body=
/part #funtoo reasons...
}}
There are a few ways of navigating through your channels, you can use {{c|alt+<nowiki>{1-9}{q-p}</nowiki>}}, or alternatively you can use the {{c|window}} command that is in irssi:
{{file|body=
/window 1
/window 2
/window 3
}}
For as many channels you are apart of.


* <tt>pkg_preinst</tt>
When you're ready to leave, you can simply type in:
* (files are merged)
{{file|body=
* <tt>pkg_postinst</tt>
/exit
}}
Which will close out connections to the IRC networks you've joined, and take you back to your console window.
=== Themes and scripts ===
==== Scripts ====
There are a few things you can do to make irssi look a little bit better and add some cool features. There are a few plugins that are pretty useful, such as {{c|fnotify.pl}} which is a script that utilizes {{f|libnotify}} to send you popup notifications for when your nick is pinged or you are sent a private message.


=== src_* functions ===
{{file|name=fnotify.pl|lang=perl|desc=fnotify.pl|body=
# todo: grap topic changes


Ebuild functions starting with <tt>src_</tt> are all related to creating the ebuild or package from source code/artifacts, and are defined below:
use strict;
use vars qw($VERSION %IRSSI);


==== src_unpack ====
use Irssi;
$VERSION = '0.0.3';
%IRSSI = (
authors    => 'Thorsten Leemhuis',
contact    => 'fedora@leemhuis.info',
name        => 'fnotify',
description => 'Write a notification to a file that shows who is talking to you in which channel.',
url        => 'http://www.leemhuis.info/files/fnotify/',
license    => 'GNU General Public License',
changed    => '$Date: 2007-01-13 12:00:00 +0100 (Sat, 13 Jan 2007) $'
);


<tt>src_unpack</tt> is intended to be used to unpack the source code/artifacts that will be used by the other <tt>src_*</tt> functions. With EAPI 1 and earlier, it is also used for patching/modifying the source artifacts to prepare them for building, but with EAPI 2 or later the <tt>src_prepare</tt> function should be used for this instead. When <tt>src_unpack</tt> starts, the current working directory is set to <tt>$WORKDIR</tt>, which is the directory within which all source code/artifacts should be expanded. Note that the variable <tt>$A</tt> is set to the names of all the unique source files/artifacts specified in <tt>SRC_URI</tt>, and they will all be available in <tt>$DISTDIR</tt> by the time <tt>src_unpack</tt> starts. Also note that if no <tt>src_unpack</tt> function is specified, <tt>ebuild.sh</tt> will execute the following function for <tt>src_unpack</tt> by default:
#--------------------------------------------------------------------
# In parts based on knotify.pl 0.1.1 by Hugo Haas
# http://larve.net/people/hugo/2005/01/knotify.pl
# which is based on osd.pl 0.3.3 by Jeroen Coekaerts, Koenraad Heijlen
# http://www.irssi.org/scripts/scripts/osd.pl
#
# Other parts based on notify.pl from Luke Macken
# http://fedora.feedjack.org/user/918/
#
#--------------------------------------------------------------------


<pre>
#--------------------------------------------------------------------
src_unpack() {
# Private message parsing
  unpack ${A}
#--------------------------------------------------------------------
}
</pre>
 
==== src_prepare ====
 
EAPI 2 and above support the <tt>src_prepare</tt> function, which is intended to be used for applying patches or making other modifications to the source code. When <tt>src_prepare</tt> starts, the current working directory is set to <tt>$S</tt>.
 
==== src_configure ====
 
EAPI 2 and above support the <tt>src_configure</tt> function, which is used to configure the source code prior to compilation. With EAPI 2 and above, the following default <tt>src_configure</tt> is defined if none is specified:


<pre>
sub priv_msg {
src_configure() {
my ($server,$msg,$nick,$address,$target) = @_;
if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
filewrite($nick." " .$msg );
econf
fi
}
}
</pre>
==== src_compile ====


This function defines the steps necessary to compile source code. With EAPI 1 and earlier, this function is also used to configure the source code prior to compilation. However, starting with EAPI 2, the <tt>src_configure</tt> function must be used for configuration steps instead of bundling them inside <tt>src_compile</tt>. In addition, starting with EAPI 2, there is now a default <tt>src_compile</tt> function that will be executed if none is defined in the ebuild:
#--------------------------------------------------------------------
# Printing hilight's
#--------------------------------------------------------------------


<pre>
sub hilight {
src_compile() {
    my ($dest, $text, $stripped) = @_;
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ] ; then
    if ($dest->{level} & MSGLEVEL_HILIGHT) {
emake || die "emake failed"
filewrite($dest->{target}. " " .$stripped );
fi
    }
}
}
</pre>


==== src_test ====
#--------------------------------------------------------------------
# The actual printing
#--------------------------------------------------------------------


<tt>src_test</tt> is an interesting function - by default, an end-user's Portage does not have tests enabled. But if a user has <tt>test</tt> in <tt>FEATURES</tt>, or <tt>EBUILD_FORCE_TEST</tt> is defined, then <tt>ebuild.sh</tt> will attempt to run a test suite for this ebuild, by executing <tt>make check</tt> or <tt>make test</tt> if these targets are defined in the Makefile; otherwise, no tests will execute. If your Makefile supports <tt>make check</tt> or <tt>make test</tt> but the test suite is broken, then specify <tt>RESTRICT="test"</tt> in your ebuild to disable the test suite.  
sub filewrite {
 
my ($text) = @_;
==== src_install ====
# FIXME: there is probably a better way to get the irssi-dir...
 
        open(FILE,">>$ENV{HOME}/.irssi/fnotify");
<tt>src_install</tt> is used by the ebuild writer to install all to-be-installed files to the <tt>$D</tt> directory, which can be treated like an empty root filesystem, in that <tt>${D}/usr</tt> is the equivalent of the <tt>/usr</tt> directory, etc. When <tt>src_install</tt> runs, the Portage sandbox will be enabled, which will prevent any processes from creating or modifying files outside of the <tt>${D}</tt> filesystem tree, and a sandbox violation will occur (resulting in the termination of the ebuild) if any such sandbox violation should occur. Once <tt>src_install</tt> has perfomed all necessary steps to install all to-be-installed files to <tt>$D</tt>, Portage will take care of merging these files to the filesystem specified by the <tt>$ROOT</tt> environment variable, which defaults to <tt>/</tt> if not set. When Portage merges these files, it will also record information about the installed package to <tt>/var/db/pkg/(cat)/$P</tt>. Typically, a <tt>src_install</tt> function such as this is sufficient for ensuring that all to-be-installed files are installed to <tt>$D</tt>:
print FILE $text . "\n";
 
        close (FILE);
<pre>
src_install() {
  make DESTDIR="$D" install
}
}
</pre>
=== pkg_* functions ===
An ebuild's functions starting with <tt>pkg_*</tt> take a wider view of the package lifecycle, and may be executed very early or very late in the build or package installation process. They are also all executed even if installing a Portage binary package, so are the intended place for defining any global configuration changes that are also required during binary package installation, such as user and group creation. When these functions are executed, the <tt>$ROOT</tt> variable will be defined to point to the target root filesystem to which the package is to be (or has been) installed. All logic inside <tt>pkg_*</tt> functions must function properly even if <tt>$ROOT</tt> is something other than <tt>/</tt>.
==== pkg_setup ====
The <tt>pkg_setup</tt> function is unusual in that it runs prior to any <tt>src_*</tt> function, and also runs prior to any other <tt>pkg_*</tt> function that runs when a binary package is installed, so it provides a useful place for the ebuild writer to perform any sanity checks, global configuration changes to the system (such as user/group creation) or set any internal global variables that are used by the rest of the ebuild. Using this function for defining global variables that are needed in multiple other functions is a useful way of avoiding duplicate code. You should also look to <tt>pkg_setup</tt> as the ideal place to put any logic that would otherwise linger in the main body of the ebuild, which should be avoided at all costs as it will slow down dependency calculation by Portage. Also remember that Portage can build binary packages, and this function is a good place to execute any steps that are required to run both prior to building an ebuild, and prior to installing a package. Also consider using <tt>pkg_preinst</tt> and <tt>pkg_postinst</tt> for this purpose.
==== pkg_pretend ====
The <tt>pkg_pretend</tt> function was added with EAPI 3, and it's the opinion of Daniel Robbins that the use of this function should be avoided. This function is especially unusual in that it is intended to be run ''during dependency calculation'', and is intended to provide a polite mechanism to inform the user that a particular ebuild will fail due to a known incompatibility, typically a kernel incompatibility. That way, the user can know during <tt>emerge --pretend</tt> that a merge will fail. While this is useful, extending the dependency engine using <tt>bash</tt> is a very low-performance means to perform these tests. Therefore, The Funtoo core team recommends against using <tt>pkg_pretend</tt>. An extensible dependency engine would be a more appropriate and high-performance way to provide identical functionality.
==== pkg_preinst ====
The <tt>pkg_preinst</tt> function is called by Portage, prior to merging the to-be-installed files to the target filesystem specified by <tt>$ROOT</tt> environment variable (which defaults to <tt>/</tt>.) Keep in mind that these to-be-installed files were either just compiled and installed to <tt>$D</tt> by <tt>src_install</tt>, or they were just extracted from a <tt>.tbz2</tt> binary package. The <tt>pkg_preinst</tt> function provides an ideal place to perform any "just before install" actions, such as user and group creation or other necessary steps to ensure that the package merges successfully. It also provides a potential place to perform any sanity checks related to installing the package to the target filesystem. If any sanity checks fail, calling <tt>die</tt> from this function will cause the package to not be installed to the target filesystem.
==== pkg_postinst ====
The <tt>pkg_postinst</tt> function is called by Portage prior to the package being installed to the target filesystem specified by <tt>$ROOT</tt>. This is a good place to perform any post-install configuration actions as well as print any informational messages for the user's benefit related to the package that was just installed.
==== pkg_prerm ====
The <tt>pkg_prerm</tt> function is called by Portage before an ebuild is removed from the filesystem.
==== pkg_postrm ====
The <tt>pkg_postrm</tt> function is called by Portage after an ebuild is removed from the filesystem.
==== pkg_config ====
The <tt>pkg_config</tt> function is called by Portage when the user calls <tt>emerge --config</tt> for the ebuild. The current directory will be set to the current directory of the shell from where <tt>emerge --config</tt> is run.
=== Skipping over a function ===
To skip over a function, create a function that returns a value. For example:
<syntaxhighlight lang="bash">
# Skip src_prepare.
src_prepare() {
    return 0;
}
</syntaxhighlight>
=== Extra pre_ and post_ functions ===
Modern versions of Portage also support functions identical to the above functions but with '''pre_''' and '''post_''' at the beginning of the function name. For example, <tt>post_src_configure</tt> will be executed after <tt>src_configure</tt> and before <tt>src_compile</tt>. These additional functions are supported by all EAPIs, provided that the parent function is supported by the EAPI in use. The initial current working directory should be identical to the initial current working directory of the parent function.
=== Helper Functions ===
==== econf() ====
econf() is part of ebuild.sh and is intended to be a wrapper to the <tt>configure</tt> command that is typically used in the <tt>src_configure()</tt> stage. It has a number of behaviors that are important for ebuild writers to understand. Once you understand what <tt>econf()</tt> does, you are free to use it in your ebuilds. Note that the behavior of <tt>econf()</tt> is generally safe for most autoconf-based source archives, but in some cases it may be necessary to avoid using <tt>econf()</tt> to avoid some of its default behaviors.
===== Automatically set prefix =====
<tt>--prefix=/usr</tt> will be passed to <tt>configure</tt> automatically, unless a <tt>--prefix</tt> argument was specified to <tt>econf()</tt>, in which case, that <tt>--prefix</tt> setting will be used instead.
===== Automatically set libdir =====
If the <tt>ABI</tt> variable is set (typically done in the profile), then <tt>econf()</tt> will look for a variable named <tt>LIBDIR_$ABI</tt> (ie. <tt>LIBDIR_amd64</tt>). If this variable is set, the value of this variable will be used to set <tt>libdir</tt> to the value of <tt>{prefix}/LIBDIR_$ABI</tt>.
===== Automatically set CHOST and CTARGET =====
The <tt>--host=$CHOST</tt> argument will be passed to <tt>configure</tt>. <tt>$CHOST</tt> is defined in the system profile. In addition, the <tt>--target=$CTARGET</tt> argument will be passed to <tt>configure</tt> if <tt>$CTARGET</tt> is defined. This is not normally required but is done to make Portage more capable of cross-compiling the ebuild. However, this functionality is not a guarantee that your ebuild will successfully cross-compile, as other changes to the ebuild may be necessary.
===== Disable Dependency Tracking (EAPI 4) =====


In EAPI 4, the <tt>--disable-dependency-tracking</tt> argument will be passed to <tt>configure</tt> in order to optimize the performance of the configuration process. This option should have no impact other than on the performance of the <tt>configure</tt> script.
Irssi::signal_add_last("message private", "priv_msg");
Irssi::signal_add_last("print text", "hilight");


===== List of arguments =====
#- end
}}
Another very useful script is for colored nicks, to better tell people apart. Which can be found at [http://scripts.irssi.org irssi scripts] called {{f|nickcolor.pl}}. 


The following arguments are passed to <tt>configure</tt> and are all overrideable by the user by passing similar options to <tt>econf()</tt>:
When you have the scripts you would like you would put them into {{f|~/.irssi/scripts}} and set a link to {{f|~/.irssi/scripts/autorun}}.
{{console|body=
$ ##i##wget -O ~/.irssi/scripts/nickcolor.pl http://scripts.irssi.org/scripts/nickcolor.pl
$ ##i##cd ~/.irssi/scripts/autorun
$ ##i##ln -s ~/.irssi/scripts/nickcolor.pl .
$ ##i##ln -s ~/.irssi/scripts/fnotify.pl .
}}
You can do this for as many scripts as you've chosen to use. They will automatically load when you start irssi. You can also manually load scripts:
{{file|body=
/load ~/.irssi/scripts/fnotify.pl
Irssi: Loaded script fnotify
}}
Whichever works best for you is what you should do.
==== Themes ====
You can choose from many themes on the [http://irssi.org/themes irssi themes] page if you don't like the default look of it. Once you've chosen the them you like, you can simply put it in your {{f|~/.irssi/}} directory and when you run just run:
{{file|body=
/set theme mycooltheme
}}
And there you have it, the theme you have chosen is now there.
=== Conclusion ===
irssi is a great IRC client, and really helpful if you spend a lot of time in a terminal emulator or on a server.


* <tt>--prefix=/usr</tt>
== External Resources ==
* <tt>--libdir={prefix}/LIBDIR_$ABI</tt>
[http://www.irssi.org/documentation Further documentation]
* <tt>--host=${CHOST}</tt>
* if CTARGET is defined, then <tt>--target=${CTARGET}</tt>
* <tt>--mandir=/usr/share/man</tt>
* <tt>--infodir=/usr/share/info</tt>
* <tt>--datadir=/usr/share</tt>
* <tt>--sysconfdir=/etc</tt>
* <tt>--localstatedir=/var/lib</tt>
* if EAPI 4+, then <tt>--disable-dependency-tracking</tt>


[[Category:Internals]]
{{EbuildFooter}}
[[Category:Portage]]
[[Category:IRC]]
[[Category:Official Documentation]]

Revision as of 07:49, January 22, 2015

Irssi

   Tip

We welcome improvements to this page. To edit this page, Create a Funtoo account. Then log in and then click here to edit this page. See our editing guidelines to becoming a wiki-editing pro.


Description

irssi is a small command line IRC client based on ncurses. It's a great thing to use when you SSH into a server, or just simply for your main IRC client.

Installation

The install of irssi is pretty straight forward. There are not many USE flags, but one that is worth looking at is the SSL flag. This enables you to use SSL when connecting to servers.

root # echo "net-irc/irssi ssl" >> /etc/portage/package.use
root # emerge irssi

Using irssi

Using irssi initially can be a little intimidating if you're not used to command line programs. To first start irssi, you just simply run:

user $ irssi

There are flags you can pass to the command line while starting irssi, such as:

user $ irssi -n mynick -c irc.freenode.org

This would connect you to Freenode with the nick 'mynick'. Or alternatively you can just run the irssi command and connect via SSL if you need to:

   
/connect -ssl irc.freenode.org

This will automatically connect you over port 6697.

When you have connected to the server of your choice, you can join a channel simply by:

   
/j #funtoo

If you want to leave any channel you've entered you can use the part command:

   
/part #funtoo reasons...

There are a few ways of navigating through your channels, you can use alt+{1-9}{q-p}, or alternatively you can use the window command that is in irssi:

   
/window 1
/window 2
/window 3

For as many channels you are apart of.

When you're ready to leave, you can simply type in:

   
/exit

Which will close out connections to the IRC networks you've joined, and take you back to your console window.

Themes and scripts

Scripts

There are a few things you can do to make irssi look a little bit better and add some cool features. There are a few plugins that are pretty useful, such as fnotify.pl which is a script that utilizes libnotify to send you popup notifications for when your nick is pinged or you are sent a private message.

   fnotify.pl (perl source code) - fnotify.pl
# todo: grap topic changes

use strict;
use vars qw($VERSION %IRSSI);

use Irssi;
$VERSION = '0.0.3';
%IRSSI = (
	authors     => 'Thorsten Leemhuis',
	contact     => 'fedora@leemhuis.info',
	name        => 'fnotify',
	description => 'Write a notification to a file that shows who is talking to you in which channel.',
	url         => 'http://www.leemhuis.info/files/fnotify/',
	license     => 'GNU General Public License',
	changed     => '$Date: 2007-01-13 12:00:00 +0100 (Sat, 13 Jan 2007) $'
);

#--------------------------------------------------------------------
# In parts based on knotify.pl 0.1.1 by Hugo Haas
# http://larve.net/people/hugo/2005/01/knotify.pl
# which is based on osd.pl 0.3.3 by Jeroen Coekaerts, Koenraad Heijlen
# http://www.irssi.org/scripts/scripts/osd.pl
#
# Other parts based on notify.pl from Luke Macken
# http://fedora.feedjack.org/user/918/
#
#--------------------------------------------------------------------

#--------------------------------------------------------------------
# Private message parsing
#--------------------------------------------------------------------

sub priv_msg {
	my ($server,$msg,$nick,$address,$target) = @_;
	filewrite($nick." " .$msg );
}

#--------------------------------------------------------------------
# Printing hilight's
#--------------------------------------------------------------------

sub hilight {
    my ($dest, $text, $stripped) = @_;
    if ($dest->{level} & MSGLEVEL_HILIGHT) {
	filewrite($dest->{target}. " " .$stripped );
    }
}

#--------------------------------------------------------------------
# The actual printing
#--------------------------------------------------------------------

sub filewrite {
	my ($text) = @_;
	# FIXME: there is probably a better way to get the irssi-dir...
        open(FILE,">>$ENV{HOME}/.irssi/fnotify");
	print FILE $text . "\n";
        close (FILE);
}

Irssi::signal_add_last("message private", "priv_msg");
Irssi::signal_add_last("print text", "hilight");

#- end

Another very useful script is for colored nicks, to better tell people apart. Which can be found at irssi scripts called nickcolor.pl.

When you have the scripts you would like you would put them into ~/.irssi/scripts and set a link to ~/.irssi/scripts/autorun.

user $ wget -O ~/.irssi/scripts/nickcolor.pl http://scripts.irssi.org/scripts/nickcolor.pl
user $ cd ~/.irssi/scripts/autorun
user $ ln -s ~/.irssi/scripts/nickcolor.pl .
user $ ln -s ~/.irssi/scripts/fnotify.pl .

You can do this for as many scripts as you've chosen to use. They will automatically load when you start irssi. You can also manually load scripts:

   
/load ~/.irssi/scripts/fnotify.pl
Irssi: Loaded script fnotify

Whichever works best for you is what you should do.

Themes

You can choose from many themes on the irssi themes page if you don't like the default look of it. Once you've chosen the them you like, you can simply put it in your ~/.irssi/ directory and when you run just run:

   
/set theme mycooltheme

And there you have it, the theme you have chosen is now there.

Conclusion

irssi is a great IRC client, and really helpful if you spend a lot of time in a terminal emulator or on a server.

External Resources

Further documentation