Built and tested locally.
nload is a console application which monitors network traffic and
bandwidth usage in real time. It visualizes the in- and outgoing traffic
using two graphs and provides additional info like total amount of
transfered [sic] data and min/max networking usage.
This commit adds `iptraf-ng` which is a fork of `iptraf`. The original
has not been updated in ~10 years. This fork is more modern but
development is a bit slow (last update to master 15 months ago).
Nevertheless, unlike `iptraf` this one doesn't barf around and works
properly.
Upstream changes to the build system required adjusting many packages'
dependencies. On the Nixpkgs side, we no longer propagate the dependency
on cmake (to reduce closure size), so downstream dependencies had to be
adjusted for most packages that depend on kdelibs.
The patch only applies for Firefox versions between 37.0 and 40.1.
Because we're on version 41.0 the changes are already included upstream
and thus the patch doesn't apply and is even unnecessary.
As for version 38.3 for ESR, the patch doesn't apply as well if compiled
with enableGTK3. Of course, this is a bit unfortunate but I don't have
the time right now to properly rebase the patch on 38.3.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: devhell <"^"@regexmail.net>
We were using HEAD for unreleased features. These features are now in
release builds so we should go back to using those. This also means we
won't have to deal with hash mismatches for all ruby packages.
Built and run successfully on local.
From the Changelog:
```
- GNU Readline
- OpenPGP support
- Message Carbons (xep-0280)
- Message Delivery Receipts (xep-0184)
- MUC Mediated Invitation support
- Configurable time formatting
- Option to show JIDs in roster
- Option to hide empty groups in roster
- Generate UUID for unnamed new MUC rooms
- Themable UI preference to indicate OTR and PGP messages
- Reformatted help
- devel: Added functional tests using libexpect and libstabber
```
It's another attempt to fix chromium builds.
See http://hydra.nixos.org/build/26086977/nixlog/4/raw
Unpacking sources is actually taking more than 2h so build fails.
Instead, rather build it remotely and then copy over the output as
we don't have limits for download time.
See 089bdce621 for reference
cc @aszlig
(cherry picked from commit cef54e7d67870ff68c9787ff60cd50ca4bf1d8af)
Signed-off-by: Domen Kožar <domen@dev.si>
This commit includes some rework since the original googlecode
repository redirects to the GitHub page.
Built and tested successfully on local.
From the Changelog:
```
* Wed Jun 11 2014 1.2
- A basic RSS reader which uses libmrss.
- Fix some 32bit platforms reporting 0 connected peers and unknown ETA.
- Resolve some GTK deprecations.
- Fix a crash in port test callback.
- Fix decimal marker in status bar version.
- Support for GeoIPCity.dat.
- Fix a crash when removing lots of columns (something changed in GTK).
- Optional and non-default support for validating SSL certs.
- Remove all GTK2 support.
- Allow alt-speed limits to override global speed limits in the statusbar
display.
```
Java's desktop integration on Linux relies on dlopen'ing some libraries (gtk2 or
gnome). This commit makes Java able to find gtk2, fixing the problem of Jitsi's
system tray icon not appearing.
Part of bug #4014.
Adds support for shared-mime-info to Claws, to fix attachments in
outgoing messages always having MIME type application/octet-stream
because Claws doesn't know where to look, instead complaining:
/nix/store/...-claws-mail-3.11.1/etc/mime.types: fopen: No such file or directory
Moreover, Claws relies on incoming MIME types for knowing when e.g. to
display an attached image, so sending application/octet-stream
unnecessarily is bad.
Tested against release-15.09.
Close#9754.
Otherwise, the wrong directory is changed into, and trying to start Jitsi gives:
$ jitsi
Error: Could not find or load main class net.java.sip.communicator.launcher.SIPCommunicator
This seems to have been confusing people, using both xlibs and xorg, etc.
- Avoided renaming local (and different) xlibs binding in gcc*.
- Fixed cases where both xorg and xlibs were used.
Hopefully everything still works as before.
