AUR (en) - pgl

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: pgl 2.3.1-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/pgl.git (read-only, click to copy)
Package Base:	pgl
Description:	A privacy oriented firewall application (GUI).
Upstream URL:	http://sourceforge.net/projects/peerguardian/
Licenses:	GPL3
Conflicts:	pgl-cli, pgl-git
Submitter:	Gilrain
Maintainer:	Gilrain
Last Packager:	Gilrain
Votes:	34
Popularity:	0.000000
First Submitted:	2011-08-25 13:05 (UTC)
Last Updated:	2022-03-31 11:18 (UTC)

Dependencies (18)

bash (bash-devel-git, bash-devel-static-git, bash-git, bash-xdg)
coreutils (coreutils-git, coreutils-selinux, coreutils-hybrid, coreutils-hybrid-git)
dbus (dbus-elogind, dbus-git, dbus-nosystemd-minimal-git, dbus-nosystemd, dbus-selinux, dbus-x11, dbus-xdg-docs)
iptables (iptables-nosystemd-minimal-git, iptables-minimal-git, iptables-git, iptables-fullconenat, iptables-fullconenat-nft, iptables-nft)
libnetfilter_queue (libnetfilter_queue-git)
logrotate (logrotate-git, logrotate-selinux)
procps-ng (procps-ng-static, procps-ng-nosystemd-minimal-git, procps-ng-nosystemd, procps-ng-git)
qt4 (qt4-bin, qt4-revert80e3108)
systemd (systemd-homed-containers, systemd-selinux, systemd-git, systemd-pr23511)
wget (wget-git, wget-xdg)
whois (whois-git)
zlib (zlib-static, zlib-git, zlib-ng, zlib-ng-compat-git) (make)
net-tools (net-tools-debian-ifconfig, net-tools-git) (optional) – to whitelist local IP addresses
networkmanager (networkmanager-consolekit, networkmanager-iwd, networkmanager-git) (optional) – to whitelist newly started network interfaces
p7zip (p7zip-jinfeihan57-git, p7zip-natspec, 7-zip-full) (optional) – for 7z blocklists
smtp-forwarder (femtomail-git, ssmtp-plain, dma, esmtp, sendmail, ssmtp, exim-heavy, courier-mta, exim, msmtp-mta, nullmailer, opensmtpd, postfix) (optional) – to send reports
tcptraceroute (optional) – to diagnose connection problems
unzip (unzip-natspec) (optional) – for zipped blocklists

Required by (0)

Sources (2)

Latest Comments

Dawa commented on 2016-02-28 02:35 (UTC)

Just confirming that lwinch2006's ASCII-only blocklist works with no errors. Definitely the unicode characters in the default blocklists causing the "broken pipe" problem.

lwinch2006 commented on 2016-02-27 17:07 (UTC)

Hello. I have experienced this problem with "no valid ASCII format" recently too " WARN: No valid ASCII blocklist format line: cat: write error: Broken pipe " As I have discovered this happens because of the many non-ASCII symbols like "¬ ® µ ¼ Ñ" and others that appears in blocklist files and that PeerGuardian cannot parse while constructing master blocklist. As it has happened just recently I can suppose that blocklists have been updated on https://www.iblocklist.com/lists with many non-ASCII symbols and were downloaded as an update after this by PeerGuardian program. So now I suppose the only way is to wait until lists on www.iblocklist.com will be fixed and all non-ASCII symbols will be removed. Also if anybody know how to compile PeerGuardian with the support of Unicode please comment the method here. As for me I've created manually a common blocklist that includes IP-ranges from the following blocklists presented below and manually deleted all non-ASCII symbolds from it. So in case anybody needs this blocklist too there is a link below for downloading. Blocklists included in "full-ascii-blocklist.p2p" bluetack_ads-trackers-and-bad-pr0n bluetack_bad-peers bluetack_bogon bluetack_dshield bluetack_edu bluetack_for-non-lan-computers bluetack_forum-spam bluetack_hijacked bluetack_iana-multicast bluetack_iana-private bluetack_iana-reserved bluetack_level1 bluetack_level2 bluetack_level3 bluetack_microsoft bluetack_proxy bluetack_range-test bluetack_spider bluetack_spyware bluetack_web-exploit bluetack_webexploit-forumspam cidr-report_bogon dchubad_faker dchubad_hacker dchubad_pedophiles dchubad_spammer peerblock_rapidshare spamhaus_drop Link for the "full-ascii-blocklist.p2p" https://www.sendspace.com/file/uffnr8

Dawa commented on 2016-02-24 15:11 (UTC)

I'm using the default blocklists available through pgl-gui's "Config" tab. My /bin/sh points to /bin/bash. Editing the first line of /usr/bin/pglcmd to #!/bin/bash had no effect. Also, it seems like pgl is only loading the ip ranges from the first blocklist it downloads. i.e. no matter what combinations of other lists I select, I get the error and pgl only loads the ips from the initial bluetack/ads-trackers-and-bad-pr0n blocklist. For now I've deselected everything but bluetack/level-1. I checked pglcmd show_config and the IP_REMOVE field is blank.

jre commented on 2016-02-24 11:51 (UTC)

Either there is some unexpected problem with the blocklists that you want to use. Are they local or remote? Can you send me all URLs/filepaths? Or the script code does not work for your shell. Which shell do you use (check where /bin/sh points to)? Test if it works if you force bash, edit /usr/bin/pglcmd and change the first line to: #!/bin/bash Then the probably problematic code is in pglcmd.lib: cat --squeeze-blank $BLOCKLISTSCAT | # Ignore comment lines grep -Ev "^[[:space:]]*#" [...] BLOCKLISTSCAT yields the filepaths of all local and remote blocklists that are configured to be used (those in /var/spool/pgl/LIST/extracted/NAME). Maybe some shells have problems with the command being spread over several lines, including comments. Disclaimer: your filepaths may vary, didn't check them for arch. Just to be sure: I guess you don't have any IP_REMOVE settings? Check "pglcmd show_config".

Dawa commented on 2016-02-24 05:05 (UTC)

Been seeing this if I try to update the blocklists with more than one blocklist selected: Building blocklist ... WARN: No valid ASCII blocklist format line: cat: write error: Broken pipe WARN: No valid ASCII blocklist format line: Binary file standard input matches ...etc. The update "finishes" normally but the number of blocked IPs doesn't change after adding more blocklists, so something is failing.

glitsj16 commented on 2016-01-02 03:59 (UTC)

2.3.1 is out since 2015-11-17.

Gilrain commented on 2014-06-17 12:51 (UTC)

> The documentation ("Requisite") says the service will fail and there is no mention of 'retry'. You're absolutely right but remember that there are 2 parts to pgl integration to systemd timer: a service and a timer. Just like the "old" cron.daily script, the timer is programmed to be called every 24 hours if the system is on. It also emulates the anacron functionality to call the service if the system has been down for more than 24 hours. So the retry should happen the next day at the earliest or as soon as the computer is on when the downtime is superior to 24h, just as (ana)cron used to do it (including failures when a connection wasn't established prior to launching the script). So again and AFAIK, failure of the service is only temporary until another call is placed by the timer. What I need to clarify is whether the network (and possibly timeout) checks are more appropriate in the timer or service file. As for my reluctance to implement a hard dependency on network.target, it's born by the fact that it would force a network connection regardless of whether the admin or user wants one. It feels wrong to have this behavior by default. I'll make the changes you suggested to the PKGBUILDs. Thank you for spotting them.

willemw commented on 2014-06-17 11:43 (UTC)

@Gilrain: The documentation ("Requisite") says the service will fail and there is no mention of 'retry'. Minor suggestion: make use of 'provides'. Other pgl packages (pgl-git, pgl-cli) could define provides=('pgl') and then remove pgl-git and pgl-cli from the 'conflicts' lists.

Gilrain commented on 2014-06-16 14:44 (UTC)

> Say I reboot once everyday and at reboot pgl-update starts before the network is ready, then pgl will never get updated. Adding an After=network.target will take care of that case. Even without it the timer should not permanently fail and start the service again in 24 hours (from what I understand of systemd).

willemw commented on 2014-06-16 13:57 (UTC)

> My preference would be to ship with Requisite and let the users add a Requires if they need/wish it. How will people know they need/wish this? Why the softer directive? Say I reboot once everyday and at reboot pgl-update starts before the network is ready, then pgl will never get updated.

jre commented on 2014-06-16 13:46 (UTC)

I fully agree to use "Requisite". I added you (gilrain) to the pgl project at sourceforge. So you can add this directly to the master branch (or any other if you want to) of the git repository). If you don't do it, I will do it sometime/soon.

Gilrain commented on 2014-06-16 13:20 (UTC)

> you can implement something like "Requires: network" in pgl-update.service, so that the update only happens when the local network is up. The «Requires» directive would automatically initiate a full network connection, whereas the softer «Requisite» only starts the service if the network is already up. My preference would be to ship with Requisite and let the users add a Requires if they need/wish it.

jre commented on 2014-06-16 11:02 (UTC)

That is/was correct and normal pgl behavior: whenever pgl is not available to retrieve the site defined in TESTHOST (whether the local network is down or the remote site is down doesn't matter) it will emit error 171. I had no look in the new systemd pgl[-update].service, yet (but I will, soon, especially since my system Debian now also moves there). But probably you can implement something like "Requires: network" in pgl-update.service, so that the update only happens when the local network is up. Are there any experiences with the systemd stuff and pglgui, yet? - I strongly assume the Start and Upgrade stuff in the pglgui Configure tab don't work. - What about manually stopping pgl in pglgui after it was started automatically by systemd --> does the system restart pgl automatically, because it thinks pgl crashed? Keep on your good work!

willemw commented on 2014-06-16 10:45 (UTC)

pgl-update fails if there is no network (status=171/n/a; E_NETWORK_DOWN="171").

Gilrain commented on 2014-06-07 09:15 (UTC)

Now that Arch migrated to systemd timer, I thought it was time to make the jump with pgl: Cron is no longer a dependency, the pgl-update timer being enabled when pgl.service is itself enabled. Upgrading requires reenabling pgl.service to load the timer and a system reboot or manually starting pgl-update.timer.

Gilrain commented on 2013-10-23 13:12 (UTC)

Don't worry about upgrading systemd, its package only touch the files it installed, not the ones added by other packages. /etc is used as a 2nd source of service files (copied, included or altere.d) to replace, complement or override properties found in the files distributed by packages in /usr. In short, /usr is the standard base upon which a sysadmin might customize, in /etc, the behavior of a service to suit his needs (see <https://wiki.archlinux.org/index.php/Systemd#Editing_provided_unit_files> for further info and justifications).

msx commented on 2013-10-23 04:08 (UTC)

@Gilrain: I think that the service unit should be placed inside /etc/systemd/system instead /usr/lib/systemd/system as this last directory is trampled on every systemd update. If I'm not mistaken the official place to put user's service units is in /etc/systemd/system as it also takes precedent over /usr/lib/systemd/system. Cheers!

msx commented on 2013-07-13 04:20 (UTC)

Just stopping by to thank you for actively maintaining pgl, thanks to your work we can enjoy it in Chakra too. Cheers.

Gilrain commented on 2013-06-13 07:14 (UTC)

* 2.2.2-7 : definitely solves the initial blocklists download problem (TimeoutStartSec=0), iptables and shorewall added to firewalls list.

Gilrain commented on 2013-06-03 09:13 (UTC)

* 2.2.2-6 : RemainAfterExit solves the startup timing out, fixed pgld.log access when using "pglcmd test", added tcptraceroute as an optional dependency.

Gilrain commented on 2013-06-01 11:49 (UTC)

* 2.2.2-5 : improved service menu to start after some firewalls forks service instead of using dbus pgld.log accessible through journald move everything to /usr/bin

jre commented on 2013-05-18 08:30 (UTC)

I just committed your systemd file with complete integration in the build-system to the git repository. The release of 2.2.3 is planned hopefully for next monday, it would be awesome if you could test it before. Please note that it is a file called systemd.in. If you pass "--with-systemdsystemunitdir=/usr/lib/systemd/system/" (or another path) to configure the real systemd file is created and later on installed. Now I had a pedantic look at the systemd file: The condition "ConditionPathExists=|/etc/pgl/blocklists.list" is not strictly necessary, you can also run pgl with only local blocklists instead (files or links in /etc/pgl/blocklists.local/). There are some fixes regarding this in the git repository. I suggest to just remove that line. Your opinion? ConditionDirectoryNotEmpty=|/usr/lib/pgl True, although you could check much more precisely for this (and much other stuff). If other systemd files also take this quite simplistic approach we should stay with this and leave it to pglcmd to log errors to pglcmd.log if something else is missing. If you want to expand the tests, we can discuss the necessary details. Greets, and thanks again! (btw: I had an typo in my email address here at archlinux. So if anybody contacted me this way, please try again.)

Gilrain commented on 2013-05-16 16:14 (UTC)

Ask and you shall receive, albeit with a bit of delay ;-) * 2.2.2-4 : fix qt4 compilation, deletes pgl spool on package removal, post upgrade notice removed.

Almin commented on 2013-05-16 16:03 (UTC)

Thanks, Peace4all, your example worked for me, while the current pkgbuild didn't! Thanks for your work!

jre commented on 2013-05-12 20:14 (UTC)

I just started working on adding your systemd and spotted this minor thing: You could also remove /var/spool/pgl post_remove() { # Deletes logs and consolidated blocklists rm -r /var/{log,lib,spool}/pgl/ }

Peace4all commented on 2013-03-03 10:37 (UTC)

If anyone is having trouble compiling with qt5 installed (I use sigil which now requires qt5), I added some exports to the PKGBUILD which works around this, I pasted an example: http://pastebin.com/q7pksTg3.

Gilrain commented on 2013-03-01 16:37 (UTC)

Here it is. Thanks for the heads up. * 2.2.2-3 : updated dependency for qt added condition checks to service file rc.d script removed

coopstah13 commented on 2013-03-01 16:19 (UTC)

Can you update the PKGBUILD for this? qt dependency is now qt4 thanks

Gilrain commented on 2012-11-13 08:42 (UTC)

pgl 2.2.2 [jre] * changed default to not log to syslog (LOG_SYSLOG="0") * fixed pending ";" in IP_REMOVE results in empty blocklist * added "env" to the example WGET_OPTS for proxies. Closes: SF bug #3581707 * fixed reading ipfilter.dat lines which contain a : in the decription * updated documentation [hasufell] * added gentoo init script, accessible via --with-gentoo-init * cleaned up configure.ac (AM_CFLAGS) [freemind] * fixed bug that prevented apply button from getting enabled. * modified iptables related functions to use always port numbers and not names (fix) * fixed pglgui crashes if you try to whitelist permanently, while pgl is not running. * code refacturing

Gilrain commented on 2012-06-21 07:04 (UTC)

@jre: Thanks for reviewing this PKGBUILD. > I just wondered why you use "--disable-networkmanager". It turns out that configure simply ignores whether NM is installed or not, copying automatically the dispatcher script. Autowhitelist of newly started network interfaces is again available, provided the optional "networkmanager" package is installed.

jre commented on 2012-06-20 21:15 (UTC)

Hey, I'm happy to see you're still active and quickly implemented the autotools change. From a quick glance I just wondered why you use "--disable-networkmanager". This is needed to automatically whitelist the LAN. The script normally gets called on start and whenever an network interface is brought up. As always, feel free to contact us/me directly at http://sourceforge.net/projects/peerguardian/ or jre-phoenix@users.sourceforge.net. I visit this forum just from time to time. Greets!

Babets commented on 2012-06-13 10:30 (UTC)

polkit-qt is needed but I don't have the time to test if only as makedepends or as depends, please test it.

trex279 commented on 2012-04-26 05:36 (UTC)

I get an error when I try to build it: ~/build/pgl/PKGBUILD: line 30: /bin/sed: Argument list too long ==> ERROR: A failure occurred in build(). Aborting...

Gilrain commented on 2012-01-29 17:01 (UTC)

@daktras: Indeed, the GUI seems to have some difficulty launching the pgl daemon. Since policykit is not yet implemented and kdesu is unable/unwilling to do anything, you could try gksu (as suggested by bluTaz), manually launching the daemon (i.e. rc.d start pgl) or start it at boot time by adding "@pgl" to your /etc/rc.conf

commented on 2012-01-26 18:38 (UTC)

when i start whether it be gui or from command line it starts but then when you click to start i get this error while trying to load i have razor-qt and it does have the razor-policy-agent running everything but this app runs fine what am i needing or doing wrong? ** Debug: Graphical Sudo: "/usr/bin/kdesu" ** Debug: Graphical Sudo: "/usr/bin/kdesu" ** Debug: Connection to DBus was successful. ** Warning: bool hasPermissions(const QString&) Could not read from file "/etc/test_file" ** Debug: void SuperUser::executeCommands(QStringList, bool) Executing commands: ("/usr/bin/kdesu "/usr/bin/pglcmd start"") ** Debug: virtual void ProcessT::run() Executing command "/usr/bin/kdesu "/usr/bin/pglcmd start"" () ... ** Debug: "kdesu(10530) startApp: Daemon not safe (not sgid), not using it. kdesu(10530)/kdesu (kdelibs) KDESu::PtyProcess::exec: [ /build/src/kdelibs-4.7.4/kdesu/process.cpp : 293 ] Running "/bin/su" kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "Password: " kdesu(10530)/kdesu (kdelibs) KDESu::PtyProcess::exec: [ /build/src/kdelibs-4.7.4/kdesu/process.cpp : 293 ] Running "/bin/su" kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "Password: " kdesu(10530)/kdesu (kdelibs) KDESu::PtyProcess::WaitSlave: [ /build/src/kdelibs-4.7.4/kdesu/process.cpp : 379 ] Child pid 10541 kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "" kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "kdesu_stub" kdesu(10530)/kdesu (kdelibs) KDESu::PtyProcess::exec: [ /build/src/kdelibs-4.7.4/kdesu/process.cpp : 293 ] Running "/bin/su" kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "Password: " kdesu(10530)/kdesu (kdelibs) KDESu::PtyProcess::WaitSlave: [ /build/src/kdelibs-4.7.4/kdesu/process.cpp : 379 ] Child pid 10544 kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "" kdesu(10530)/kdesu (kdelibs) KDESu::SuProcess::ConverseSU: [ /build/src/kdelibs-4.7.4/kdesu/su.cpp : 259 ] Read line "kdesu_stub"" ** Debug: virtual void ProcessT::run() Command execution finished.

commented on 2011-08-27 14:59 (UTC)

haha, nice, works. had already fixed it myself and got gksu working with it, will need to configure it to /usr/bin/gksu under settings. Just updated my quick fix to this one, so far seems good, hopefully I can leave moblock alone now :).

Gilrain commented on 2011-08-27 14:26 (UTC)

Sorry about that. I didn't take the time to see if it would compile. My bad :-( Everything should be fine now. Thanks for the report.

commented on 2011-08-27 13:36 (UTC)

edt: correct paths /usr/include/{QtCore,QtGui,Qt}

commented on 2011-08-27 13:31 (UTC)

was unable to build: g++ \ -pipe -g -D_REENTRANT -Wall -W -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED \ -I/usr/share/qt4/include -I/usr/share/qt4/include/QtCore -I/usr/share/qt4/include/QtGui -I/usr/share/qt4/include/QtDBus -I. -Isrc -Iui \ -c src/main.cpp \ -o src/main.o src/main.cpp:22:24: fatal error: QApplication: No such file or directory compilation terminated. make[1]: *** [src/main.o] Error 1 make[1]: Leaving directory `/tmp/yaourt-tmp-david/aur-pgl/src/pgl-2.1.2/pgl-gui' ran a quick : find /usr -iname qtcore* -o -iname qapp* -o -iname qtgui /usr/lib/python3.2/site-packages/PyQt4/QtCore.so /usr/lib/python2.7/site-packages/PyQt4/QtCore.so /usr/lib/pkgconfig/QtCore.pc /usr/share/sip/PyQt4/QtCore /usr/share/sip/PyQt4/QtCore/QtCoremod.sip /usr/share/sip/PyQt4/QtGui /usr/share/sip/PyQt4/QtGui/qapplication.sip /usr/share/sip/QtCore /usr/share/sip/QtCore/QtCoremod.sip /usr/share/sip/QtGui /usr/share/sip/QtGui/qapplication.sip /usr/include/QtCore /usr/include/QtCore/QtCore /usr/include/QtGui /usr/include/QtGui/QtGui /usr/include/QtGui/QApplication /usr/include/QtGui/qapplication.h /usr/include/Qt/QtCore /usr/include/Qt/QtGui /usr/include/Qt/qapplication.h should mark qt as a dependency and update at least the pgl-gui folder's makefile to the correct qt locations (/usr/lib/{QtCore,QtGui,Qt}) as far as I've checked.

Gilrain commented on 2011-08-25 13:05 (UTC)

Untested. Please report any problem.

Arch Linux User Repository