Bug#794669: confirmed: pdebuild ignores --pbuildersatisfydepends without --use-pdebuild-internal

2024-05-01 Thread Georgios Zarkadas
Package: pbuilder
Version: 0.231 (& current git version at salsa.debian.org)

By inspecting the code of pdebuild and pdebuild-checkparams:

1. When using the '--use-pdebuild-internal' option, then
PBUILDERSATISFYDEPENDSCMD is passed explicitly
to the script that is executed inside the chroot, at line:

67  --pbuildersatisfydepends "$PBUILDERSATISFYDEPENDSCMD"

2. When not using the '--use-pdebuild-internal' option, then
the remaining command line arguments are passed to
pbuilder --build, at line:

   107  "$@" \

Those are pbuilder arguments, since pdebuild-checkparams,
by shifting all recognised by pdebuild options, eats everything
up to the '--'.

So, the '--pbuildersatisfydepends' option is not honored in the
second case. This IMHO is a bug for the 'pdebuild' man page,
since this distinction is not mentioned in the text.

This is not a bug for pbuilder, since it does not honor this option
anyway; thus passing it by pdebuild at the second case would be
meaningless. The selection of satisfydepends has been delegated
to the system administrator, through the 'pbuilder-satisfydepends'
symlink at '/usr/lib/pbuilder/'. In the usual case, the developer is also
the administrator of his/her own computer and can set the symlink.

I don't currently have an opinion on whether a more "flexible"
approach on this subject (i.e. add the feature to the second
pdebuild case also) would be desirable, or not.

Gheers,
Georgios


Bug#1069979: pbuilder: please make APTGETOPT available to hook scripts

2024-04-27 Thread Georgios Zarkadas
Package: pbuilder
Version: 0.231
Severity: wishlist
Control: tags patch

Dear Maintainer,

There are eight hookscripts in the examples/ directory
that use ${APTGETOPT[@]} in their code. APTGETOPT is a
bash array and while it works fine inside pbuilder code
where all library modules are sourced, it is not get
exported to hookscripts, because they are executed as
a separate process and the array is not exported to
their environment.

I have tested this using explicit export APTGETOPT clause
in my pbuilderrc and hookscripts that print the environment
and, unless my configuration is fundamentally broken, it
is not get exported.

I file this as a bug, because including a large number
of scripts using this feature in the examples/ directory
implies the expectation that it actually works.

The attached patch exports the APTGETOPT array as a plain
environment variable in a way that scripts that use the
${APTGETOPT[@]} form in their code will run successfully
without modification. The second patch (...manpages) updates
the relevant hookscripts section of the pbuilder manpage.

Cheers,
Georgios

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 6 (excalibur/ceres)
Release:6
Codename:   excalibur ceres
Architecture: x86_64

Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  debootstrap1.0.134devuan2
ii  dpkg-dev   1.22.6

Versions of packages pbuilder recommends:
ii  devscripts  2.23.7
ii  eatmydata   131-1
ii  fakeroot1.34-1
ii  iproute26.8.0-1
ii  net-tools   2.10-0.1devuan1
ii  sudo1.9.15p5-3+b1

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7+nmu7

-- debconf information:
  pbuilder/mirrorsite: http://deb.devuan.org/merged
  pbuilder/rewrite: false
  pbuilder/nomirror:

-- debsums errors found:
debsums: changed file /usr/lib/pbuilder/pbuilder-modules (from pbuilder
package)

NOTE: I have patched pbuilder-modules with both the
patch I have proposed in bug #789401 and the patch
in this bug report, hence the failed debsums test.
diff --git a/pbuilder-modules b/pbuilder-modules
index 5695d0f2..d4df7ae6 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -1159,6 +1159,7 @@ function executehooks () {
DISTRIBUTION="$DISTRIBUTION" \
BUILD_ARCH="$ARCHITECTURE" \
HOST_ARCH="$HOST_ARCH" \
+   APTGETOPT="$(echo ${APTGETOPT[@]})" \
$CHROOTEXEC "/$hooks/$(basename "$fn")"
log.i "user script $fn finished"
else
diff --git a/pbuilder.8 b/pbuilder.8
index e59e207e..69fa56e8 100644
--- a/pbuilder.8
+++ b/pbuilder.8
@@ -432,6 +432,11 @@ contains the build architecture, the architecture the package is building on.
 .I HOST_ARCH
 contains the host architecture, the architecture the package is building for.
 .RE
+.RS 8
+.I APTGETOPT
+contains additional options to pass to apt-get. Since \fBAPTGETOPT()\fR is a
+bash array, the variable contains all its values concatenated with spaces.
+.RE
 \" End of hookdir description
 
 .TP


Bug#789401: Proposed patch to solve the issue.

2024-04-27 Thread Georgios Zarkadas
Hi Thorsten,

Limiting access to the expanded chroot is something that can be done.

I currently use a `build' group and have {mode 750, ug root:build}  the
build directory,
were the base tgzs are unpacked as subdirectories, and {mode 2775, ug
root:build}
the result directory, so that pdebuild-internal can copy back resulting
debs.

`build' group members are the developers that can use pbuilder. This is a
separate group
than the one that has sudo rights to run pbuilder (though both have the
same members);
its sole role is to allow write access to the result directory and read
access to the build
directory.

I made this setup recently and maybe it needs some tuning (probably mode 775
for the result directory is enough), but so far packages build successfully
with it.

However, this solution requires the creation of a system group during
pbuilder's installation
and setting permissions to the associated directories. Also whoever uses a
custom directory
setup should afterwards set the above permissions accordingly.

/tmp/buildd is already preserved by the compatibility symlink code inside
pbuilder, in the sense
that it is there after the base tgz unpacking. Even if the compatibility
code is removed, one can
set BUILDDIR=/tmp/buildd in pbuilderrc and have it there, as long as
BUILDDIR is always created
during unpacking. That's why I have shipped the patch with the modified
comments at that point.

Even if a choice is made for pbuilder to support limiting access to the
expanded chroot,
I believe that chroot's temporary directories should be cleaned before
creating the base tgz.
Other things also go there (hookdir, pbuildersatisfydepends package, etc.)
and, since by design
these directories are for temporary stuff, persistence should not be
anticipated.

Cheers,
Georgios

Στις Σάβ 27 Απρ 2024 στις 5:10 μ.μ., ο/η Thorsten Glaser 
έγραψε:

> Hi Georgios,
>
> why not just ensure the parent directory of the chroot is not
> traversable for just any normal user?
>
> That would allow preserving /tmp/buildd as build place as well
> as retaining stuff under /run which packages create and which
> is, in practice, often needed for chroots where initscripts are
> not run.
>
> In addition, I often do use the access to the /tmp in the chroot
> for debugging and bootstrapping, so maybe create a new system
> group, chown 0:_pbuilder /var/cache/pbuilder/build; chmod 0750
> that directory, and good is? (Untested.)
>
> Then, I could add my user to that group and continue doing so.
>
> bye,
> //mirabilos
> --
> „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
> mksh auf jedem System zu installieren.“
> -- XTaran auf der OpenRheinRuhr, ganz begeistert
> (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
>


Bug#789401: Proposed patch to solve the issue.

2024-04-27 Thread Georgios Zarkadas
The attached patch removes, during the recreation of base tgz,
all files from /tmp and /var/tmp (which is also world-writable).

It is made for the git version at salsa.debian.org but can also be applied
to the current (0.231) version as-is.

I have also modified a comment during the creation of BUILDDIR to alert for
the possibility of a user who keeps (still) in his/her configuration
/tmp/buildd
as the build directory.

It is not essential to the issue (only the tar command is), but I thought
it would be nice to have also. I can send a modified version of the patch,
if deemed necessary.

Cheers,
Georgios
diff --git a/pbuilder-modules b/pbuilder-modules
index aca876de..8d8a0c59 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -730,8 +730,9 @@ function extractbuildplace () {
 fi
 
 mountproc
-# FIXME maybe add more checks here? - actually it's not even really needed,
-# since it's created at chroot creation time too.
+# FIXME maybe add more checks here? - Always create it, since it may be set
+# in the configuration to be inside one of the excluded (at 'create_basetgz')
+# directories of the chroot (for example: '/tmp/buildd').
 mkdir -p "${BUILDPLACE}${BUILDDIR}"
 # XXX added in 0.216, to be deprecated in the future
 # Add a compatibility symlink from the old BUILDDIR (/tmp/buildd) to the new
@@ -834,7 +835,7 @@ function create_basetgz() {
 if [ -h "$BUILDPLACE/tmp/buildd" ] && [ "$(readlink -f "$BUILDPLACE/tmp/buildd")" = "${BUILDPLACE}$BUILDDIR" ]; then
 rm "$BUILDPLACE/tmp/buildd"
 fi
-if ! tar -c --use-compress-program "$COMPRESSPROG" -f "${BASETGZ}.tmp" --exclude ./sys/* --exclude ./proc/* ./* ; then
+if ! tar -c --use-compress-program "$COMPRESSPROG" -f "${BASETGZ}.tmp" --exclude "./sys/*" --exclude "./proc/*" --exclude "./tmp/*" --exclude "./tmp/.*" --exclude "./var/tmp/*" --exclude "./var/tmp/.*" ./* ; then
 log.e "failed building base tarball"
 rm -f "${BASETGZ}.tmp"
 exit 1;


Bug#1060448: patches for both debcheckout and chdist

2024-04-22 Thread Georgios Zarkadas
The attached patches, for the git repository at salsa.debian.org,
remove the depreciation warnings.

I have installed them in my system (version of devscripts: 2.23.7)
and they appear to work fine till now (note: I have tested only git,
bzr and svn repositories; could not find other types).

Cheers,
Georgios
diff --git a/scripts/chdist.pl b/scripts/chdist.pl
index b473b954..52832ed5 100755
--- a/scripts/chdist.pl
+++ b/scripts/chdist.pl
@@ -707,72 +707,53 @@ sub parseFile {
 my $recursed = 0;
 MAIN:
 my $command = shift @ARGV;
-given ($command) {
-when ('create') {
-dist_create(@ARGV);
-}
-when ('apt') {
-aptcmd('apt', @ARGV);
-}
-when ('apt-get') {
-aptcmd('apt-get', @ARGV);
-}
-when ('apt-cache') {
-aptcmd('apt-cache', @ARGV);
-}
-when ('apt-file') {
-apt_file(@ARGV);
-}
-when ('apt-rdepends') {
-aptcmd('apt-rdepends', @ARGV);
-}
-when ('aptitude') {
-aptcmd('aptitude', @ARGV);
-}
-when ('bin2src') {
-bin2src(@ARGV);
-}
-when ('src2bin') {
-src2bin(@ARGV);
-}
-when ('compare-packages') {
-dist_compare(@ARGV, 0, 'Sources');
-}
-when ('compare-bin-packages') {
-dist_compare(@ARGV, 0, 'Packages');
-}
-when ('compare-versions') {
-dist_compare(@ARGV, 1, 'Sources');
-}
-when ('compare-bin-versions') {
-dist_compare(@ARGV, 1, 'Packages');
-}
-when ('grep-dctrl-packages') {
-grep_file(@ARGV, 'Packages');
-}
-when ('grep-dctrl-sources') {
-grep_file(@ARGV, 'Sources');
-}
-when ('compare-src-bin-packages') {
-compare_src_bin(@ARGV, 0);
-}
-when ('compare-src-bin-versions') {
-compare_src_bin(@ARGV, 1);
-}
-when ('list') {
-list;
-}
-default {
-my $dist = $command;
-my $dir  = "$datadir/$dist";
-if (-d $dir && !$recursed) {
-splice @ARGV, 1, 0, $dist;
-$recursed = 1;
-goto MAIN;
-} elsif ($dist && !$recursed) {
-dist_check($dist);
-} else {
-usage(1);
-}
+if ($command eq 'create') {
+dist_create(@ARGV);
+} elsif ($command eq 'apt') {
+aptcmd('apt', @ARGV);
+} elsif ($command eq 'apt-get') {
+aptcmd('apt-get', @ARGV);
+} elsif ($command eq 'apt-cache') {
+aptcmd('apt-cache', @ARGV);
+} elsif ($command eq 'apt-file') {
+apt_file(@ARGV);
+} elsif ($command eq 'apt-rdepends') {
+aptcmd('apt-rdepends', @ARGV);
+} elsif ($command eq 'aptitude') {
+aptcmd('aptitude', @ARGV);
+} elsif ($command eq 'bin2src') {
+bin2src(@ARGV);
+} elsif ($command eq 'src2bin') {
+src2bin(@ARGV);
+} elsif ($command eq 'compare-packages') {
+dist_compare(@ARGV, 0, 'Sources');
+} elsif ($command eq 'compare-bin-packages') {
+dist_compare(@ARGV, 0, 'Packages');
+} elsif ($command eq 'compare-versions') {
+dist_compare(@ARGV, 1, 'Sources');
+} elsif ($command eq 'compare-bin-versions') {
+dist_compare(@ARGV, 1, 'Packages');
+} elsif ($command eq 'grep-dctrl-packages') {
+grep_file(@ARGV, 'Packages');
+} elsif ($command eq 'grep-dctrl-sources') {
+grep_file(@ARGV, 'Sources');
+} elsif ($command eq 'compare-src-bin-packages') {
+compare_src_bin(@ARGV, 0);
+} elsif ($command eq 'compare-src-bin-versions') {
+compare_src_bin(@ARGV, 1);
+} elsif ($command eq 'list') {
+list;
+} else {
+my $dist = $command;
+my $dir  = "$datadir/$dist";
+if (-d $dir && !$recursed) {
+splice @ARGV, 1, 0, $dist;
+$recursed = 1;
+goto MAIN;
+} elsif ($dist && !$recursed) {
+dist_check($dist);
+} else {
+usage(1);
 }
 }
+
diff --git a/scripts/debcheckout.pl b/scripts/debcheckout.pl
index 33520e78..85a63f3f 100755
--- a/scripts/debcheckout.pl
+++ b/scripts/debcheckout.pl
@@ -416,18 +416,14 @@ sub set_destdir($$@) {
 my ($repo_type, $destdir, @cmd) = @_;
 $destdir =~ s|^-d\s*||;
 
-given ($repo_type) {
-when ("cvs") {
-my $module = pop @cmd;
-push @cmd, ("-d", $destdir, $module);
-}
-when (/^(bzr|darcs|git|hg|svn)$/) {
-push @cmd, $destdir;
-}
-default {
-die
+if ($repo_type eq "cvs") {
+my $module = pop @cmd;
+push @cmd, ("-d", $destdir, $module);
+} elsif ($repo_type =~ /^(bzr|darcs|git|hg|svn)$/) {
+push @cmd, $destdir;
+} else {
+die
 "sorry, don't know how to set the destination directory for $repo_type repositories (patches welcome!)\n";
-}
 }
 return @cmd;
 }
@@ -461,20 +457,14 @@ sub set_auth() {
 # other providers
 $url =~ s!(?:git|https?)://github\.com/!git\@github.com:!;
 
-given ($repo_type) {
-when ("bzr") {
-$url
-  =~ s[^\w+://(?:(bazaar|code)\.)?(launchpad\.net/.*)][bzr+ssh://${user}bazaar.$2];
-}
-when ("git") 

Bug#924865: minissdpd: please eliminate an uneccesarily alarming startup message

2019-03-17 Thread Georgios Zarkadas
Package: minissdpd
Version: 1.5.20190210-1
Severity: wishlist
Tags: patch

If the MiniSSDPd_INTERFACE_ADDRESS variable in the default file
contains more than one interface, the init script issues an error
message which although it does not stop the starting of the daemon
it is uneccesarily alarming. The attached patch solves that issue.

regards
George Zarkadas
From a49c06d838c2f828e2879c732f8d87596d6a89c1 Mon Sep 17 00:00:00 2001
From: "Georgios M. Zarkadas" 
Date: Sun, 17 Mar 2019 20:30:57 +0200
Subject: [PATCH] Fixed annoying startup message "... unexpected operator" when
 MiniSSDPd_INTERFACE_ADDRESS contains more then one interface.

Signed-off-by: Georgios M. Zarkadas 
---
 debian/init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/init b/debian/init
index 95a0dfa..e01408f 100644
--- a/debian/init
+++ b/debian/init
@@ -45,7 +45,7 @@ start)
 		exit 1
 	fi
 
-	if [ -z ${MiniSSDPd_INTERFACE_ADDRESS} ] ; then
+	if [ -z "${MiniSSDPd_INTERFACE_ADDRESS}" ] ; then
 		log_daemon_msg "MiniSSDPd: no interface defined: exiting"
 		log_end_msg 1
 		exit 1
-- 
2.20.1



Bug#924864: sysstat: the init script always fails to start the service

2019-03-17 Thread Georgios Zarkadas
Package: sysstat
Version: 12.0.1-1
Severity: normal
Tags: patch

The /etc/init.d/sysstat init script does not include /etc/default/sysstat.
Thus, the daemon never starts (since $ENADLED remains unset).

The attached patch solves that issue.

regards
George Zarkadas
From c13834067a8fd3dd1d4d3e6910b512d8448f7455 Mon Sep 17 00:00:00 2001
From: "Georgios M. Zarkadas" 
Date: Sun, 17 Mar 2019 21:23:18 +0200
Subject: [PATCH] Fixed error that prevented the /etc/init.d/sysstat script to
 start the sysstat service.

Signed-off-by: Georgios M. Zarkadas 
---
 debian/sysstat.init.d | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/sysstat.init.d b/debian/sysstat.init.d
index a4a9fab..620ffd1 100644
--- a/debian/sysstat.init.d
+++ b/debian/sysstat.init.d
@@ -25,6 +25,10 @@ status=0
 
 . /lib/lsb/init-functions
 
+if [ -f /etc/default/sysstat ] ; then
+. /etc/default/sysstat
+fi
+
 case "$1" in
   start|restart|reload|force-reload)
 if [ "$ENABLED" = "true" ] ; then
-- 
2.20.1



Bug#924130: apt-mirror: please include partial mirroring support

2019-03-09 Thread Georgios Zarkadas
Package: apt-mirror
Version: 0.5.4-1
Severity: wishlist
Tags: patch

The attached set of patches allows apt-mirror to partially download a
distribution if an
optional regex is added at the end of a deb... line, at the
configuration file, inside square brackets.

The regex selects package names to be included; any package that does
not match is not downloaded.

If the regex is not supplied or is an empty pair of square brackets,
the entire distribution defined by the deb... line is downloaded, as
usual.

The partially downloaded distribution is not consistent in the sense
that its index files contain packages which do not exist in the
mirror, but an attempt to rewrite the index files would add a
significant amount of code, which I both do not need in my use-case of
this feature and I do not know if it interests the developers team.

I briefly present my use-case of the feature, to aid understanding the
rationale behind the patches.

I use a setup where most of the installed packages in my computers
come from the unstable distribution, while a specific subset (in my
case, kernel related packages mostly) comes from the stable
distribution (and its -backports , -security , -updates variants).

I also use a computer which does not have a landline internet
connection and a mirror onto a removable drive would be ideal to
update its software. But the disk is not big enough to hold five
binary and five source distributions in their entirety. It can hold
though a full binary and source distribution plus the subset of
packages I am interested in from the other eight ones.

To ensure the package manager will not accidentally pull a package
from the stable* distributions that is not downloaded in the mirror, I
use a custom apt preferences file.

The patches have been tested successfully with my target
distributions. I use Devuan, but I believe they will work with any
Debian-style archive, since they do not contain distribution specific
code; they just apply a filter using the current apt-mirror internal
workings.

Please consider including them in apt-mirror's source. I am available
for any comments or clarifications.

regards
George Zarkadas
From: "Georgios M. Zarkadas" 
Date: Fri, 8 Mar 2019 21:47:15 +0200
Subject: [PATCH 1/2] Support partial mirroring by appending an
 include packages regex (filter) to the end of each associated
 deb-line of the configuration file.

Signed-off-by: Georgios M. Zarkadas 
---

diff --git a/apt-mirror b/apt-mirror
index effac7e..fafd482 100755
--- a/apt-mirror
+++ b/apt-mirror
@@ -288,7 +288,11 @@ sub download_urls
 
 sub parse_config_line
 {
-my $pattern_deb_line = qr/^[\t ]*(?deb-src|deb)(?:-(?[\w\-]+))?[\t ]+(?:\[(?[^\]]+)\][\t ]+)?(?[^\s]+)[\t ]+(?.+)$/;
+# first of 'components' is the distribution; an optional include filter
+# may follow at the end, inside a [] pair so that it cannot be mistaken
+# as a component
+
+my $pattern_deb_line = qr/^[\t ]*(?deb-src|deb)(?:-(?[\w\-]+))?[\t ]+(?:\[(?[^\]]+)\][\t ]+)?(?[^\s]+)[\t ]+(?[^[]+)(?\[.*\])?$/;
 my $line = $_;
 my %config;
 if ( $line =~ $pattern_deb_line ) {
@@ -301,6 +305,9 @@ sub parse_config_line
 $config{'arch'} = $+{arch};
 }
 $config{'components'} = [ split /\s+/, $config{'components'} ];
+# the filter cannot be empty, since we always pop it;
+# if missing, set it equal to an empty [] pair
+$config{'filter'} = $+{filter} ? $+{filter} : "[]";
 } elsif ( $line =~ /set[\t ]+(?[^\s]+)[\t ]+(?"[^"]+"|'[^']+'|[^\s]+)/ ) {
 $config{'type'} = 'set';
 $config{'key'} = $+{key};
@@ -329,10 +336,10 @@ while ()
 } elsif ( $config_line{'type'} eq "deb" ) {
 my $arch = $config_line{'arch'};
 $arch = get_variable("defaultarch") if ! defined $config_line{'arch'};
-push @config_binaries, [ $arch, $config_line{'uri'}, @{$config_line{'components'}} ];
+push @config_binaries, [ $arch, $config_line{'uri'}, @{$config_line{'components'}}, $config_line{'filter'} ];
 next;
 } elsif ( $config_line{'type'} eq "deb-src" ) {
-push @config_sources, [ $config_line{'uri'}, @{$config_line{'components'}} ];
+push @config_sources, [ $config_line{'uri'}, @{$config_line{'components'}}, $config_line{'filter'} ];
 next;
 } elsif ( $config_line{'type'} =~ /(skip-clean|clean)/ ) {
 my $link = $config_line{'uri'};
@@ -393,6 +400,7 @@ sub add_url_to_download
 foreach (@config_sources)
 {
 my ( $uri, $distribution, @components ) = @{$_};
+my $filter = pop @components;
 
 if (@components)
 {
@@ -422,6 +430,7 @@ foreach (@config_sources)
 foreach (@config_binaries)
 {
 my ( $arch, $uri, $distribution, @components ) = @{$_};
+my $filter = pop @components;
 
 if (@components)
 {
@@ -605,6 +614,8 @@ print "Processing translation indexes: [";
 foreach (@config_binaries)
 {
 my ( $arch, $uri, $distribution, @components ) = @{$_};
+my $filter = pop 

Bug#883962: gmic: please make bash-completion code to load dynamically

2017-12-09 Thread Georgios Zarkadas
Package: gmic
Version: 1.7.9+zart-4+b1
Severity: wishlist
Tags: patch

Dear Maintainer,

The supplied patch converts gmic's bash-completion code to the new,
dynamically-loading format and moves it from /etc/bash_completion.d
to /usr/share/bash-completion/completions.  In parallel, it reduces file
size by about 33%, from 130 KB to 87 KB.

I currently use it in the 1.6.0.1 version and have succesfuly built it for
1.7.9+zart-4.  The format of the bash-completion code (being generated
programaticaly by the application itself) appears fairly stable across
version changes; thus the cost to maintain the added sed expressions
in debian/rules seems manageable.

Please, consider it.

regards
Georgios Zarkadas
diff --git a/debian/rules b/debian/rules
index 254dd84..11476dc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -67,6 +67,21 @@ override_dh_install:
 	# FIX CImg.h file name to avoid problems with cimg-dev
 	sed -i 's,CImg.h,gmic_CImg.h,g' debian/libgmic-dev/usr/include/gmic.h
 	mv debian/libgmic-dev/usr/include/CImg.h debian/libgmic-dev/usr/include/gmic_CImg.h
+	# convert bash-completion code to load dynamically and also reduce its size
+	mkdir -p debian/gmic/usr/share/bash-completion/completions
+	sed -z -e 's:/etc/bash_completion\.d/gmic:/usr/share/bash-completion/completions/gmic:' \
+	  -e 's/\(_gmic\)_stdlib/\1/g' \
+	  -e 's/\(\tCOMPREPLY=()\)/\t_init_completion || return\n\1/' \
+	  -e 's/)\n\t\t\(COMPREPLY=\)/) \1/g' \
+	  -e 's/)\n\t\t\(return 0\)\n\t\t;;/); \1;;/g' \
+	  -e 's/\\\n[[:space:]]*/ /g' \
+	  -e 's/\t\t"\(-[-a-zA-Z0-9_]*\)" | "\(--[-a-zA-Z0-9_]*\)")/\t\1|\2)/g' \
+	  -e 's/\t\t"/\t"/g' \
+	  -e 's/\n\topts="[^"]*"\n//' \
+	  -e 's/\n\tcase "\${prev}" in/\n\topts=\$(echo "\$coms" | sed "s: \\([^ ]\\+\\): -\\1 --\\1:g")\n\tcase \$prev in/' \
+	   debian/gmic/etc/bash_completion.d/gmic \
+	   >debian/gmic/usr/share/bash-completion/completions/gmic
+	rm -r debian/gmic/etc/bash_completion.d
 
 .PHONY: override_dh_auto_test override_dh_compress override_dh_auto_build override_dh_install
 


Bug#824977: O: dhelp -- Read all documentation with a WWW browser.

2016-05-21 Thread Georgios Zarkadas
Package: wnpp
Severity: normal

I haven't worked on dhelp for quite a long time and, most probably, I will
not
be able to do so for quite a long time also. I 'm therefore orphaning the
package.


Bug#820748: uniconvertor: ImportError: No module named sk1libs.utils.fs

2016-04-17 Thread Georgios Zarkadas
I encountered the same bug.

The missing python modules are contained at the sk1 release tarball at
sourceforge.net (https://sourceforge.net/projects/sk1/). This project is
not yet part of the distribution, although there is an unofficial deb
package provided at the http://sk1project.org/ download page.

Thus someone has to do the packaging of sk1, or the neccesary modules  must
be copied to python-uniconvertor as a patch, or a request to upstream to
fix this issue has to be made.

regards
George


Bug#803342: More info needed

2015-10-31 Thread Georgios Zarkadas
Hi Dominique,

The bug is really a swish++ bug, as I see it, and I will re-assing it
to that package, marking only that it also affects dhelp. I will also
downgrade severity to normal before re-assigning it; the re-assigned
package maintainer will decide what the severity is in that's package
context.

Meanwhile, it would be useful (and it would made the search component
of dhelp again usable for you) to pinpoint the offending file or
files. You can try this by directly calling the index++ binary with
the same options that dhelp uses to call it, splitting the lists of
files to different parts and continuing with the ones that give the
error (the others are ok and they can be removed from the test).

The command to run (as normal user) inside a directory created for
this purpose is:

for f in *.part; do
cat $f | /usr/bin/index++ \
--config-file /usr/share/dhelp/config/swish++.conf \
--index-file ./$f.index --follow-links -
done

I attach the list of files, split in 13 parts. After spotting the
problematic part(s) you can further split them to find the problematic
file(s). If you de-register the package containing them from doc-base
(see 'man install-docs'), then the index will be created with the rest
of your docs.

Please report back your findings.

regards
George


parts.tar.gz
Description: GNU Zip compressed data


Bug#779736: Converting to wishlist

2015-10-31 Thread Georgios Zarkadas
This is not a bug, rather a need to follow the documentation (cf. the
previous messages). However, it would be nice if dhelp could detect
this case before invoking the browser. Thus, instead of closing it
now, I' m converting it to a wishlist bug for the next release with
that subject.



Bug#712053: Bug 715053: root's umask is the probable cause of this

2015-10-31 Thread Georgios Zarkadas
Hi Yaroslav,

This seems to be the effect of a restrictive umask (0077,
specifically) to user root, either through explicitly setting it at
your startup files, or through pam settings.

Dhelp code does not set permissions for the created files, rather
assumes the customary 0022 umask for user root. There is a *lot* of
code out there that does this assumption, so I would not consider this
a bug.

Although it is quite some time since the original report, if you could
confirm whether that was the case then it would be useful.

regards
George



Bug#696338: Bug confirmed

2015-10-31 Thread Georgios Zarkadas
dhelp_fetcher does not handle well a uri that is not a file but a
directory (it should either search for an index.html file there or
complain loudly). As a result, it tries to read the directory,
resulting in an empty page. Will fix in the upcoming release.



Bug#679691: Patch is available

2015-10-31 Thread Georgios Zarkadas
tags +confirmed +patch
thanks

A patch is available for this bug from July 28, 2012 at the project's
git repository
at alioth (cf. 
http://anonscm.debian.org/cgit/collab-maint/dhelp.git/commit/?id=ad359ad1d540aef66690ce60d4fe2e54f15b767f).

Will be fixed in the upcoming release.



Bug#730148: Probably, install-docs is needed

2015-10-31 Thread Georgios Zarkadas
tags 730148 +moreinfo
thanks

Hi,

>From the wording of the report, I assume that you have tried to
manually register the documentation package, due to its
discontinuation in Debian. If this is the case, then dhelp is simply
not the tool to do this. The package must be registered with doc-base,
ie the command 'install-docs' must be used.

Please confirm whether this is the case, or the problem appeared in a
normal package installation procedure.

regards
George



Bug#779736: dhelp: The requested URL /doc/HTML/index.html was not found on this server

2015-06-09 Thread Georgios Zarkadas
Hi Giacomo,

The apache browser does not enable anymore the /doc alias by default.
This is a change made as a response to the CVE-2012-0216 vulnerability
report. As a consequence, dhelp does not enable it either during its
installation, since that may create a security hole depending on the
system's configuration and usage patterns.

Thus, it has to be manually configured by the system administrator.
This is stated in detail both in /usr/share/doc/dhelp/README.Debian.gz
and in /etc/apache2/conf-available/dhelp.conf (the dhelp's apache2
configuration file).

In order for this to happen, the relevant Alias ... line(s) in the dhelp's
configuration file must be uncommented, the configuration must be enabled
with a2enconf and the web server instructed to reload its configuration.

If the above steps were not performed, then this is not a bug; it is
the intended behaviour. Only if the above steps were performed, and the
command still did not work it would be a bug.

Tagging it moreinfo. If the error persists after enabling the /doc alias
please report; else no action is required, and I will close this bug at
the next release of the package.

Cheers,
George


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org