Re: [pacman-dev] [PATCH v2] Swap alpm_db_update() implementation to multiplexed version
Hi Allan, Hi Anatol, I was looking to this new multiplexed implementation and I found some problems: 1) This implementation can lead to download databases from different servers, I think it can't be a problem if they are not synced 2) Differents download payloads are created for databases and its signature files, this can this time lead to download the database and its signature from differents server, I'm sure it's not wanted. 3) Because signature files have their own download payloads, if the signature is missing on a the first server (e.g. database signature is optional), all next servers will be tried and all will give the same error. I really wanted to suggest a patch but I didn't find a easy way (understand a small patch) to fix it and I would like your opinion on point 1) first. Regards, Guillaume.
Re: [pacman-dev] download interrupt mechanism
Le 25/08/2015 23:34, Dave Reisner a écrit : On Tue, Aug 25, 2015 at 09:21:50PM +0200, Guillaume wrote: To not block the GUI, I run trans_commit function in a g_thread and I can't use SIGINT signal. I have no way to correctly stop curl process. I propose to look for a particular value to do it as transaction functions do with TRANS_STATE_INTERRUPTED.Dave Reisner d...@falconindy.com a écrit :On Aug 25, 2015 7:04 AM, Guillaume Benoit guilla...@manjaro.org wrote: Please don't top post. Presumably, you can't use SIGINT because you can't guarantee which thread the signal is delivered to. You need to properly guard against this situation by blocking SIGINT on threads which aren't the caller of trans_commit. With only 1 thread not masking SIGINT, the linux kernel will guarantee delivery to this thread. http://stackoverflow.com/a/11679770 Is this correct? Or is there some other reason that you can't rely on signal delivery as an interrupt mechanism? d Yes, maybe I can do that but won't it be better for a library to not have to use signals ? Knowing that alpm_trans_commit function runs download then packages transaction, won't it be clearer to have a unique function to cancel the process ? alpm_trans_interrupt function can already be used to cancel package transaction, my idea is to complete it to also cancel downloads. Guillaume.
Re: [pacman-dev] download interrupt mechanism
To not block the GUI, I run trans_commit function in a g_thread and I can't use SIGINT signal. I have no way to correctly stop curl process. I propose to look for a particular value to do it as transaction functions do with TRANS_STATE_INTERRUPTED.Dave Reisner d...@falconindy.com a écrit :On Aug 25, 2015 7:04 AM, Guillaume Benoit guilla...@manjaro.org wrote: Hi, working on a GUI frontend for libalpm, I noticed that download process lakes for an internal interrupt mechanism. Download cancellation is only handled by catching SIGINT signal. I think it would be a benefit for libalpm to have more correct download interrupt mechanism like trans_interrupt handle package transaction cancellation. Could you explain more about why signal handling is non-ideal? What would trans_interrupt do differently? What problems does this solve? I'm already working on a patch and I would like to know if you would interested in adding this feature to libalpm. Regards. Without knowing more details on what you're proposing, its hard to say.
[pacman-dev] download interrupt mechanism
Hi, working on a GUI frontend for libalpm, I noticed that download process lakes for an internal interrupt mechanism. Download cancellation is only handled by catching SIGINT signal. I think it would be a benefit for libalpm to have more correct download interrupt mechanism like trans_interrupt handle package transaction cancellation. I'm already working on a patch and I would like to know if you would interested in adding this feature to libalpm. Regards.
[pacman-dev] [PATCH] Verbose package list now show if packages are explicit or dependencies
When verbose package is activated, the table is displayed two times,
once for explicit packages and a second time for dependencies.
This helps understanding the upgrade process. You can focus on on
explicit package and gives less attention to dependencies.
Design choices:
-- If a table does not fit in terminal width, it fallbacks to traditional
compact display, but this fallback can happen on none, one or both
tables
-- The header name stay short, Package and Dependancies. This is to
avoid too long column name, but i think it is enough explicit as is.
---
src/pacman/util.c | 59 +++
1 file changed, 46 insertions(+), 13 deletions(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c
index d42e27b..864b7a3 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -774,12 +774,12 @@ void signature_display(const char *title, alpm_siglist_t
*siglist,
}
/* creates a header row for use with table_display */
-static alpm_list_t *create_verbose_header(size_t count)
+static alpm_list_t *create_verbose_header(size_t count, int is_explicit)
{
alpm_list_t *ret = NULL;
char *header;
- pm_asprintf(header, %s (%zd), _(Package), count);
+ pm_asprintf(header, %s (%zd), (is_explicit ? _(Package) :
_(Dependency)), count);
add_table_cell(ret, header, CELL_TITLE | CELL_FREE);
add_table_cell(ret, _(Old Version), CELL_TITLE);
@@ -846,7 +846,11 @@ static void _display_targets(alpm_list_t *targets, int
verbose)
char *str;
off_t isize = 0, rsize = 0, dlsize = 0;
unsigned short cols;
- alpm_list_t *i, *names = NULL, *header = NULL, *rows = NULL;
+ alpm_list_t *i,
+ *names = NULL, *names_explicit = NULL,
*names_deps = NULL,
+ *header_explicit = NULL, *header_deps = NULL,
+ *rows = NULL, *explicit = NULL, *deps = NULL;
+ size_t count_explicit = 0, count_deps = 0;
if(!targets) {
return;
@@ -870,10 +874,6 @@ static void _display_targets(alpm_list_t *targets, int
verbose)
for(i = targets; i; i = alpm_list_next(i)) {
pm_target_t *target = i-data;
- if(verbose) {
- rows = alpm_list_add(rows, create_verbose_row(target));
- }
-
if(target-install) {
pm_asprintf(str, %s-%s,
alpm_pkg_get_name(target-install),
alpm_pkg_get_version(target-install));
@@ -885,27 +885,60 @@ static void _display_targets(alpm_list_t *targets, int
verbose)
alpm_pkg_get_version(target-remove),
_(removal));
}
names = alpm_list_add(names, str);
+
+ if(verbose) {
+ // Check if package is installed as a explicit or as a
dependency
+ // and store it in associated lists
+ if(alpm_pkg_get_reason(target-remove ? target-remove
: target-install) == ALPM_PKG_REASON_DEPEND) {
+ deps = alpm_list_add(deps,
create_verbose_row(target));
+ names_explicit =
alpm_list_add(names_explicit, str);
+ count_deps += 1;
+ } else {
+ explicit = alpm_list_add(explicit,
create_verbose_row(target));
+ names_deps = alpm_list_add(names_deps,
str);
+ count_explicit += 1;
+ }
+ }
+
}
/* print to screen */
- pm_asprintf(str, %s (%zd), _(Packages), alpm_list_count(targets));
printf(\n);
cols = getcols(fileno(stdout));
if(verbose) {
- header = create_verbose_header(alpm_list_count(targets));
- if(table_display(header, rows, cols) != 0) {
+ header_explicit = create_verbose_header(count_explicit, 1);
+ if(table_display(header_explicit, explicit, cols) != 0) {
+ /* fallback to list display if table wouldn't fit */
+ pm_asprintf(str, %s (%zd), _(Packages),
count_explicit);
+ list_display(str, names_explicit, cols);
+ free(str);
+ }
+ printf(\n);
+ header_deps = create_verbose_header(count_deps, 0);
+ if(table_display(header_deps, deps, cols) != 0) {
/* fallback to list display if table wouldn't fit */
- list_display(str, names, cols);
+ pm_asprintf(str, %s (%zd), _(Dependencies),
count_deps);
+ list_display(str, names_deps, cols);
+ free(str);
}
+
} else {
+
Re: [pacman-dev] [PATCH] Verbose package list now show if packages are explicit or dependencies
Hello,
I'm reopening this discussion. A few time ago, I proposed to grey
explicit package name. Finally it was judged as confusing.
Instead I propose to display only the package type during verbose
package listing. To achieve this, I splitted the packages table into
two tables, the one for explicit packages, and the other for
dependencies, examples:
$ pacman -S epiphany
[sudo] password for guillaume:
resolving dependencies...
looking for conflicting packages...
Package (1) New Version Net Change Download Size
extra/epiphany 3.12.0-1 6.89 MiB 1.48 MiB
Dependency (3) New Version Net Change Download Size
extra/gcr 3.12.0-1 5.42 MiB 0.77 MiB
extra/libwnck3 3.4.7-12.85 MiB
extra/libxres 1.0.7-10.02 MiB
Total Download Size:2.25 MiB
Total Installed Size: 15.17 MiB
$ pacman -Rs gitg
checking dependencies...
Package (1) Old Version Net Change
gitg 0.3.2-1 -1.41 MiB
Dependency (8) Old Version Net Change
geoclue 0.12.99-1 -1.02 MiB
gtksourceview3 3.12.1-1 -6.78 MiB
...
Feedback needed ;)
--
G
On Sat, May 10, 2014 at 4:48 PM, Guillaume Bouchard
guillaum.bouch...@gmail.com wrote:
When verbose package is activated, the table is displayed two times,
once for explicit packages and a second time for dependencies.
This helps understanding the upgrade process. You can focus on on
explicit package and gives less attention to dependencies.
Design choices:
-- If a table does not fit in terminal width, it fallbacks to traditional
compact display, but this fallback can happen on none, one or both
tables
-- The header name stay short, Package and Dependancies. This is to
avoid too long column name, but i think it is enough explicit as is.
---
src/pacman/util.c | 59
+++
1 file changed, 46 insertions(+), 13 deletions(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c
index d42e27b..864b7a3 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -774,12 +774,12 @@ void signature_display(const char *title,
alpm_siglist_t *siglist,
}
/* creates a header row for use with table_display */
-static alpm_list_t *create_verbose_header(size_t count)
+static alpm_list_t *create_verbose_header(size_t count, int is_explicit)
{
alpm_list_t *ret = NULL;
char *header;
- pm_asprintf(header, %s (%zd), _(Package), count);
+ pm_asprintf(header, %s (%zd), (is_explicit ? _(Package) :
_(Dependency)), count);
add_table_cell(ret, header, CELL_TITLE | CELL_FREE);
add_table_cell(ret, _(Old Version), CELL_TITLE);
@@ -846,7 +846,11 @@ static void _display_targets(alpm_list_t *targets, int
verbose)
char *str;
off_t isize = 0, rsize = 0, dlsize = 0;
unsigned short cols;
- alpm_list_t *i, *names = NULL, *header = NULL, *rows = NULL;
+ alpm_list_t *i,
+ *names = NULL, *names_explicit = NULL,
*names_deps = NULL,
+ *header_explicit = NULL, *header_deps = NULL,
+ *rows = NULL, *explicit = NULL, *deps = NULL;
+ size_t count_explicit = 0, count_deps = 0;
if(!targets) {
return;
@@ -870,10 +874,6 @@ static void _display_targets(alpm_list_t *targets, int
verbose)
for(i = targets; i; i = alpm_list_next(i)) {
pm_target_t *target = i-data;
- if(verbose) {
- rows = alpm_list_add(rows,
create_verbose_row(target));
- }
-
if(target-install) {
pm_asprintf(str, %s-%s,
alpm_pkg_get_name(target-install),
alpm_pkg_get_version(target-install));
@@ -885,27 +885,60 @@ static void _display_targets(alpm_list_t *targets, int
verbose)
alpm_pkg_get_version(target-remove),
_(removal));
}
names = alpm_list_add(names, str);
+
+ if(verbose) {
+ // Check if package is installed as a explicit or as
a dependency
+ // and store it in associated lists
+ if(alpm_pkg_get_reason(target-remove ?
target-remove : target-install) == ALPM_PKG_REASON_DEPEND) {
+ deps = alpm_list_add(deps,
create_verbose_row(target));
+ names_explicit =
alpm_list_add(names_explicit, str);
+ count_deps += 1;
+ } else {
+ explicit = alpm_list_add(explicit,
create_verbose_row(target));
+ names_deps =
alpm_list_add(names_deps, str);
+ count_explicit += 1
Re: [pacman-dev] [PATCH] Put not explicitly installed packages in grey during update/install/removall
1.) have a column title of Explicitly Installed? with a yes or no label for each package, optionally coloring the yes or no text for easy reading 2.) like the first way, but put an asterisk if the package is explicitly installed and leave it blank if the package is a dependency 3.) have a column title of Installed... with labels of explicitly or as a dependency Of those three, I think I prefer the second method. I like the second method, but it is still not really explicit for users. I'll wait for a few other feedbacks and I'll update the patch to add an asterix after the package name. -- Guillaume
Re: [pacman-dev] [PATCH] Put not explicitly installed packages in greyduring update/install/removall
Of the two options, I would prefer the dependencies to be shown in grey instead of having explicitly installed packages typeset in bold. I don't feel too strongly about this though, so I won't complain if everyone else prefers bold. There is a second option. Instead of just flaging deps OR explicit and associating a color with both, we can flag both and associate a color with both, and let this color be changed by configuration (i.e., the line in conf.c/enable_color) so everybody will be happy... -- G.
Re: [pacman-dev] [PATCH] Put not explicitly installed packages in grey during update/install/removall
That colour cases the dependencies to stand out more on a terminal with a white background. I'd say bold would be better... ;) I agree on that part. I guess the best idea must be to create a color class for depend and for explicit so that changing it latter may be easier. However, the colour coding really is unclear. How do people come into the knowledge of what it means? For example, during an update I might think that a new package being pulled in as a dependency so it is highlighted. Or is it entirely obvious and I am thinking too hard? You are right. Perhaps a caption, like: --- $ sudo pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Packages (21): **(Explict packages appears in bold)** Name Old Version New Version Net Change Download Size ... Total Download Size:154.72 MiB Total Installed Size: 491.30 MiB Net Upgrade Size: -1.28 MiB :: Proceed with installation? [Y/n] - ? (I had never though a *so simple* hack would generate so much discussion ;) -- Guillaume
Re: [pacman-dev] [PATCH] Put not explicitly installed packages in grey during update/install/removal
Any feedbacks on that patch ? Must I change something ?
On Fri, Jan 24, 2014 at 5:22 PM, Guillaume Bouchard
guillaum.bouch...@gmail.com wrote:
In extended table view, packages which are not explicitly installed are
displayed in grey. This helps understanding why
packages are updated.
This helps the package managment workflow. During update, we can
quickly have a look at why packages are updated and easilly track and
remove the explicit packages which are not longer required. During
remove, it shows all the explicit packages which are also removed by a
cascade removal. During install, it provides a feedback on how your
action will affect the database.
This patch created a new colstr setting and associate it with BOLDBLACK
(i.e. grey).
Signed-off-by: Guillaume Bouchard guillaum.bouch...@gmail.com
---
src/pacman/conf.c | 1 +
src/pacman/conf.h | 1 +
src/pacman/util.c | 13 ++---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c
index 5450f3b..785061b 100644
--- a/src/pacman/conf.c
+++ b/src/pacman/conf.c
@@ -76,6 +76,7 @@ void enable_colors(int colors)
colstr-warn= BOLDYELLOW;
colstr-err = BOLDRED;
colstr-nocolor = NOCOLOR;
+ colstr-depend = BOLDBLACK;
}
}
diff --git a/src/pacman/conf.h b/src/pacman/conf.h
index 9faf5de..2edbe16 100644
--- a/src/pacman/conf.h
+++ b/src/pacman/conf.h
@@ -32,6 +32,7 @@ typedef struct __colstr_t {
const char *warn;
const char *err;
const char *nocolor;
+ const char *depend;
} colstr_t;
typedef struct __config_t {
diff --git a/src/pacman/util.c b/src/pacman/util.c
index 58b0cec..7cbbd33 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -57,7 +57,8 @@ enum {
CELL_NORMAL = 0,
CELL_TITLE = (1 0),
CELL_RIGHT_ALIGN = (1 1),
- CELL_FREE = (1 3)
+ CELL_FREE = (1 3),
+ CELL_DEPEND = (1 4)
};
int trans_init(alpm_transflag_t flags, int check_valid)
@@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line,
short col_padding,
if(cell-mode CELL_TITLE) {
printf(%s%*s%s, config-colstr.title, cell_width,
str, config-colstr.nocolor);
- } else {
+ } else if(cell-mode CELL_DEPEND) {
+ printf(%s%*s%s, config-colstr.depend, cell_width,
str, config-colstr.nocolor);
+} else {
printf(%*s, cell_width, str);
}
need_padding = 1;
@@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t
*target)
} else {
pm_asprintf(str, %s, alpm_pkg_get_name(target-remove));
}
- add_table_cell(ret, str, CELL_NORMAL);
+ if(alpm_pkg_get_reason(target-remove ? target-remove :
target-install) == ALPM_PKG_REASON_DEPEND) {
+ add_table_cell(ret, str, CELL_DEPEND);
+ } else {
+ add_table_cell(ret, str, CELL_NORMAL);
+ }
/* old and new versions */
pm_asprintf(str, %s,
--
1.8.5.2
[pacman-dev] [PATCH] Put explicitly installed packages in bold during update/install/removal
Hello.
A really small change in pacman which, I hope, improves the feedback
about explicit packages on install/removal/update.
Have a nice day.
Output of git format-patch origin:
From bd5c3aa7826c3c073cca691f0e30b5363487cd6f Mon Sep 17 00:00:00 2001
From: Guillaume Bouchard guillaum.bouch...@gmail.com
Date: Fri, 24 Jan 2014 12:20:16 +0100
Subject: [PATCH] Put explicitly installed packages in bold during
update/install/removal
In extended table view, packages which are explicitly installed are
displayed as CELL_TITLE (i.e. in bold). This helps understanding why
packages are updated.
This helps the package managment workflow. During update, we can
quickly have a look at why packages are updated and easilly track and
remove the explicit packages which are not longer required. During
remove, it shows all the explicit packages which are also removed by a
cascade removal. During install, it provides a feedback on how your
action will affect the database.
This only affects VerbosePkgLists output. Patching the un-verbose
output appears more difficult and I think this information is only
interesting during verbose output.
Signed-off-by: Guillaume Bouchard guillaum.bouch...@gmail.com
---
src/pacman/util.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c
index 58b0cec..a3ee5ee 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -808,7 +808,12 @@ static alpm_list_t *create_verbose_row(pm_target_t *target)
} else {
pm_asprintf(str, %s, alpm_pkg_get_name(target-remove));
}
-add_table_cell(ret, str, CELL_NORMAL);
+if(alpm_pkg_get_reason(target-remove ? target-remove :
target-install) == ALPM_PKG_REASON_EXPLICIT) {
+/* put emphasis on the package name if it is an explicitly
installed package */
+add_table_cell(ret, str, CELL_TITLE);
+} else {
+add_table_cell(ret, str, CELL_NORMAL);
+}
/* old and new versions */
pm_asprintf(str, %s,
--
1.8.5.2
--
Guillaume
[pacman-dev] [PATCH] Put explicitly installed packages in bold during update/install/removal
In extended table view, packages which are explicitly installed are
displayed as CELL_TITLE (i.e. in bold). This helps understanding why
packages are updated.
This helps the package managment workflow. During update, we can
quickly have a look at why packages are updated and easilly track and
remove the explicit packages which are not longer required. During
remove, it shows all the explicit packages which are also removed by a
cascade removal. During install, it provides a feedback on how your
action will affect the database.
Signed-off-by: Guillaume Bouchard guillaum.bouch...@gmail.com
---
src/pacman/util.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/pacman/util.c b/src/pacman/util.c
index 58b0cec..a3ee5ee 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -808,7 +808,12 @@ static alpm_list_t *create_verbose_row(pm_target_t *target)
} else {
pm_asprintf(str, %s, alpm_pkg_get_name(target-remove));
}
- add_table_cell(ret, str, CELL_NORMAL);
+ if(alpm_pkg_get_reason(target-remove ? target-remove :
target-install) == ALPM_PKG_REASON_EXPLICIT) {
+ /* put emphasis on the package name if it is an explicitly
installed package */
+ add_table_cell(ret, str, CELL_TITLE);
+ } else {
+ add_table_cell(ret, str, CELL_NORMAL);
+ }
/* old and new versions */
pm_asprintf(str, %s,
--
1.8.5.2
[pacman-dev] [PATCH] Put not explicitly installed packages in grey during update/install/removal
In extended table view, packages which are not explicitly installed are
displayed in grey. This helps understanding why
packages are updated.
This helps the package managment workflow. During update, we can
quickly have a look at why packages are updated and easilly track and
remove the explicit packages which are not longer required. During
remove, it shows all the explicit packages which are also removed by a
cascade removal. During install, it provides a feedback on how your
action will affect the database.
This patch created a new colstr setting and associate it with BOLDBLACK
(i.e. grey).
Signed-off-by: Guillaume Bouchard guillaum.bouch...@gmail.com
---
src/pacman/conf.c | 1 +
src/pacman/conf.h | 1 +
src/pacman/util.c | 13 ++---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/src/pacman/conf.c b/src/pacman/conf.c
index 5450f3b..785061b 100644
--- a/src/pacman/conf.c
+++ b/src/pacman/conf.c
@@ -76,6 +76,7 @@ void enable_colors(int colors)
colstr-warn= BOLDYELLOW;
colstr-err = BOLDRED;
colstr-nocolor = NOCOLOR;
+ colstr-depend = BOLDBLACK;
}
}
diff --git a/src/pacman/conf.h b/src/pacman/conf.h
index 9faf5de..2edbe16 100644
--- a/src/pacman/conf.h
+++ b/src/pacman/conf.h
@@ -32,6 +32,7 @@ typedef struct __colstr_t {
const char *warn;
const char *err;
const char *nocolor;
+ const char *depend;
} colstr_t;
typedef struct __config_t {
diff --git a/src/pacman/util.c b/src/pacman/util.c
index 58b0cec..7cbbd33 100644
--- a/src/pacman/util.c
+++ b/src/pacman/util.c
@@ -57,7 +57,8 @@ enum {
CELL_NORMAL = 0,
CELL_TITLE = (1 0),
CELL_RIGHT_ALIGN = (1 1),
- CELL_FREE = (1 3)
+ CELL_FREE = (1 3),
+ CELL_DEPEND = (1 4)
};
int trans_init(alpm_transflag_t flags, int check_valid)
@@ -488,7 +489,9 @@ static void table_print_line(const alpm_list_t *line, short
col_padding,
if(cell-mode CELL_TITLE) {
printf(%s%*s%s, config-colstr.title, cell_width,
str, config-colstr.nocolor);
- } else {
+ } else if(cell-mode CELL_DEPEND) {
+ printf(%s%*s%s, config-colstr.depend, cell_width,
str, config-colstr.nocolor);
+} else {
printf(%*s, cell_width, str);
}
need_padding = 1;
@@ -808,7 +811,11 @@ static alpm_list_t *create_verbose_row(pm_target_t *target)
} else {
pm_asprintf(str, %s, alpm_pkg_get_name(target-remove));
}
- add_table_cell(ret, str, CELL_NORMAL);
+ if(alpm_pkg_get_reason(target-remove ? target-remove :
target-install) == ALPM_PKG_REASON_DEPEND) {
+ add_table_cell(ret, str, CELL_DEPEND);
+ } else {
+ add_table_cell(ret, str, CELL_NORMAL);
+ }
/* old and new versions */
pm_asprintf(str, %s,
--
1.8.5.2
Re: [pacman-dev] [PATCH] Put explicitly installed packages in bold during update/install/removal
On Fri, Jan 24, 2014 at 4:24 PM, Jerome Leclanche adys...@gmail.com wrote: On Fri, Jan 24, 2014 at 2:17 PM, Guillaume Bouchard guillaum.bouch...@gmail.com wrote: In extended table view, packages which are explicitly installed are displayed as CELL_TITLE (i.e. in bold). This helps understanding why packages are updated. This helps the package managment workflow. During update, we can quickly have a look at why packages are updated and easilly track and remove the explicit packages which are not longer required. During remove, it shows all the explicit packages which are also removed by a cascade removal. During install, it provides a feedback on how your action will affect the database. 2¢ for the bikeshed: have you tried putting non-explicitly installed packages in grey instead? It might make more sense. Patch sent (However, I may have failed the Message-Id because it does not appears as a child of this discussion. I'm not really convinced with the Grey results. And for the grey I was forced to add a new colstr category which linked to BOLDBLACK. -- Guillaume
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
On 20 September 2010 13:58, Allan McRae al...@archlinux.org wrote:
Hi,
FYI, it is much easier to comment (and separate comments from the patch) if
things are posted inline. Here goes some brief comments in cut paste sort
of format... hopefully you can follow them.
Anyway, overall this looks quite good. Make these small adjustments it is
basically good to go. Even better if you submit as a patch with the
necessary autotools changes, but I can handle those if not.
Description
---
The script *pacman-key* manage *pacman*'s keyring, ie the keyring of GnuPG
keys used to sign packages.
It enables to import, export and fetch keys from keyservers as well as
update the key trust database.
Hmm... how about something like:
The script *pacman-key* manage *pacman*'s keyring, which is the collection
of GnuPG keys used to check signed packages.
It provides the ability to import and export keys, fetch keys from
keyservers and update the key trust database.
*\--config* 'file'::
Set an alternative configuration file to use (default is
/etc/pacman.conf)
you should use {sysconfdir}/pacman.conf instead so we can adjust this based
on the configure output.
*-l*, *\--list*::
List keys and signatures in pacman's keyring. Same as option
\--list-sigs of GnuPG. See GnuPG's man pages for flag significations
Equivalent to --list-sigs from GnuPG. (?)
*-u*, *\--updatedb*::
Update the trustdb of pacman. Same as option \--check-trustdb of
GnuPG.
Equivalent to \--check-trustdb in GnuPG
Allan
Hello,
it is much easier to comment if things are posted inline
OK I hadn't think about it !
Make these small adjustments it is basically good to go
They also look OK to me, I will change that.
Even better if you submit as a patch with the necessary autotools changes
Will try to :)
--
Guillaume
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
On 20 September 2010 14:06, Guillaume ALAUX guilla...@alaux.net wrote:
On 20 September 2010 13:58, Allan McRae al...@archlinux.org wrote:
Hi,
FYI, it is much easier to comment (and separate comments from the patch) if
things are posted inline. Here goes some brief comments in cut paste sort
of format... hopefully you can follow them.
Anyway, overall this looks quite good. Make these small adjustments it is
basically good to go. Even better if you submit as a patch with the
necessary autotools changes, but I can handle those if not.
Description
---
The script *pacman-key* manage *pacman*'s keyring, ie the keyring of GnuPG
keys used to sign packages.
It enables to import, export and fetch keys from keyservers as well as
update the key trust database.
Hmm... how about something like:
The script *pacman-key* manage *pacman*'s keyring, which is the collection
of GnuPG keys used to check signed packages.
It provides the ability to import and export keys, fetch keys from
keyservers and update the key trust database.
*\--config* 'file'::
Set an alternative configuration file to use (default is
/etc/pacman.conf)
you should use {sysconfdir}/pacman.conf instead so we can adjust this based
on the configure output.
*-l*, *\--list*::
List keys and signatures in pacman's keyring. Same as option
\--list-sigs of GnuPG. See GnuPG's man pages for flag significations
Equivalent to --list-sigs from GnuPG. (?)
*-u*, *\--updatedb*::
Update the trustdb of pacman. Same as option \--check-trustdb of
GnuPG.
Equivalent to \--check-trustdb in GnuPG
Allan
Hello,
it is much easier to comment if things are posted inline
OK I hadn't think about it !
Make these small adjustments it is basically good to go
They also look OK to me, I will change that.
Even better if you submit as a patch with the necessary autotools changes
Will try to :)
--
Guillaume
OK, how about that?
=== PATCH ===
diff --git a/doc/.gitignore b/doc/.gitignore
index f047aaa..aebf7a0 100644
--- a/doc/.gitignore
+++ b/doc/.gitignore
@@ -3,6 +3,7 @@ libalpm.3
makepkg.8
makepkg.conf.5
pacman.8
+pacman-key.8
pacman.conf.5
repo-add.8
repo-remove.8
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 2e656f6..5c84234 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -7,6 +7,7 @@ ASCIIDOC_MANS = \
pacman.8 \
makepkg.8 \
repo-add.8 \
+ pacman-key.8 \
PKGBUILD.5 \
makepkg.conf.5 \
pacman.conf.5 \
@@ -18,6 +19,7 @@ HTML_MANPAGES = \
pacman.8.html \
makepkg.8.html \
repo-add.8.html \
+ pacman-key.8.html \
PKGBUILD.5.html \
makepkg.conf.5.html \
pacman.conf.5.html \
@@ -38,6 +40,7 @@ EXTRA_DIST = \
pacman.8.txt \
makepkg.8.txt \
repo-add.8.txt \
+ pacman-key.8.txt \
PKGBUILD.5.txt \
PKGBUILD-example.txt \
makepkg.conf.5.txt \
@@ -128,6 +131,7 @@ $(HTML_OTHER): asciidoc.conf
pacman.8 pacman.8.html: pacman.8.txt
makepkg.8 makepkg.8.html: makepkg.8.txt
repo-add.8 repo-add.8.html: repo-add.8.txt
+pacman-key.8 pacman-key.8.html: pacman-key.8.txt
PKGBUILD.5 PKGBUILD.5.html: PKGBUILD.5.txt PKGBUILD-example.txt
makepkg.conf.5 makepkg.conf.5.html: makepkg.conf.5.txt
pacman.conf.5 pacman.conf.5.html: pacman.conf.5.txt
diff --git a/doc/pacman-key.8.txt b/doc/pacman-key.8.txt
new file mode 100644
index 000..6b70f80
--- /dev/null
+++ b/doc/pacman-key.8.txt
@@ -0,0 +1,76 @@
+/
+vim:set ts=4 sw=4 syntax=asciidoc noet:
+/
+pacman-key(8)
+=
+
+
+Name
+
+pacman-key - manage pacman's list of trusted keys
+
+
+Synopsis
+
+*pacman-key* [options] *command* ['arguments']
+
+
+Description
+---
+The script *pacman-key* manage *pacman*'s keyring, which is the
collection of GnuPG keys used to check signed packages.
+It provides the ability to import and export keys, fetch keys from
keyservers and update the key trust database.
+
+
+Options
+---
+*\--config* 'file'::
+ Set an alternative configuration file to use (default is
{sysconfdir}/pacman.conf)
+
+*\--gpgdir* 'directory'::
+ Set an alternative home directory for GnuPG (default is set in
{sysconfdir}/pacman.conf)
+
+
+Commands
+---
+*-a*, *\--add* 'file ...'::
+ Add the key(s) contained in 'file'(s) to pacman's keyring. If a key
already exists, update it.
+
+*\--adv* 'param ...'::
+ Use this option to issue particular GnuPG actions to pacman's
keyring. This option should be used with care as it can modify
pacman's trust in packages' signatures.
+
+*-d*, *\--del* 'keyid ...'::
+ Remove the key(s) identified by 'keyid'(s) from pacman's keyring
+
+*-e*, *\--export* ['keyid ...']::
+ Export key(s) identified by 'keyid'(s) to STDOUT or all keys if no
'keyid' is specified
+
+*-f*, *\--finger* ['keyid ...']::
+ List fingerprint(s) for specified 'keyid'(s) or for all if none is
specified
+
+*\--help
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
OK so hopefully this one will work nicely...
=== PATCH ===
diff --git a/doc/.gitignore b/doc/.gitignore
index f047aaa..aebf7a0 100644
--- a/doc/.gitignore
+++ b/doc/.gitignore
@@ -3,6 +3,7 @@ libalpm.3
makepkg.8
makepkg.conf.5
pacman.8
+pacman-key.8
pacman.conf.5
repo-add.8
repo-remove.8
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 2e656f6..5c84234 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -7,6 +7,7 @@ ASCIIDOC_MANS = \
pacman.8 \
makepkg.8 \
repo-add.8 \
+ pacman-key.8 \
PKGBUILD.5 \
makepkg.conf.5 \
pacman.conf.5 \
@@ -18,6 +19,7 @@ HTML_MANPAGES = \
pacman.8.html \
makepkg.8.html \
repo-add.8.html \
+ pacman-key.8.html \
PKGBUILD.5.html \
makepkg.conf.5.html \
pacman.conf.5.html \
@@ -38,6 +40,7 @@ EXTRA_DIST = \
pacman.8.txt \
makepkg.8.txt \
repo-add.8.txt \
+ pacman-key.8.txt \
PKGBUILD.5.txt \
PKGBUILD-example.txt \
makepkg.conf.5.txt \
@@ -128,6 +131,7 @@ $(HTML_OTHER): asciidoc.conf
pacman.8 pacman.8.html: pacman.8.txt
makepkg.8 makepkg.8.html: makepkg.8.txt
repo-add.8 repo-add.8.html: repo-add.8.txt
+pacman-key.8 pacman-key.8.html: pacman-key.8.txt
PKGBUILD.5 PKGBUILD.5.html: PKGBUILD.5.txt PKGBUILD-example.txt
makepkg.conf.5 makepkg.conf.5.html: makepkg.conf.5.txt
pacman.conf.5 pacman.conf.5.html: pacman.conf.5.txt
diff --git a/doc/pacman-key.8.txt b/doc/pacman-key.8.txt
new file mode 100644
index 000..6b70f80
--- /dev/null
+++ b/doc/pacman-key.8.txt
@@ -0,0 +1,76 @@
+/
+vim:set ts=4 sw=4 syntax=asciidoc noet:
+/
+pacman-key(8)
+=
+
+
+Name
+
+pacman-key - manage pacman's list of trusted keys
+
+
+Synopsis
+
+*pacman-key* [options] *command* ['arguments']
+
+
+Description
+---
+The script *pacman-key* manage *pacman*'s keyring, which is the collection of
GnuPG keys used to check signed packages.
+It provides the ability to import and export keys, fetch keys from keyservers
and update the key trust database.
+
+
+Options
+---
+*\--config* 'file'::
+ Set an alternative configuration file to use (default is
{sysconfdir}/pacman.conf)
+
+*\--gpgdir* 'directory'::
+ Set an alternative home directory for GnuPG (default is set in
{sysconfdir}/pacman.conf)
+
+
+Commands
+---
+*-a*, *\--add* 'file ...'::
+ Add the key(s) contained in 'file'(s) to pacman's keyring. If a key
already exists, update it.
+
+*\--adv* 'param ...'::
+ Use this option to issue particular GnuPG actions to pacman's keyring.
This option should be used with care as it can modify pacman's trust in
packages' signatures.
+
+*-d*, *\--del* 'keyid ...'::
+ Remove the key(s) identified by 'keyid'(s) from pacman's keyring
+
+*-e*, *\--export* ['keyid ...']::
+ Export key(s) identified by 'keyid'(s) to STDOUT or all keys if no
'keyid' is specified
+
+*-f*, *\--finger* ['keyid ...']::
+ List fingerprint(s) for specified 'keyid'(s) or for all if none is
specified
+
+*\--help*::
+ Displays this message
+
+*-l*, *\--list*::
+ Equivalent to --list-sigs from GnuPG
+
+*-r*, *\--receive* 'keyserver' 'keyid ...'::
+ Fetch the 'keyid'(s) from the specified 'keyserver' URL
+
+*\--reload*::
+ Reloads the keys from the keyring package
+
+*-t*, *\--trust* 'keyid'::
+ Set the trust level of the given key
+
+*-u*, *\--updatedb*::
+ Equivalent to \--check-trustdb in GnuPG
+
+*-v*, *\--version*::
+ Displays the current version
+
+
+See Also
+
+linkman:pacman.conf[5]
+
+include::footer.txt[]
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
On 16 September 2010 17:58, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: On Thu, Sep 16, 2010 at 4:37 AM, Guillaume ALAUX guilla...@archlinux.org wrote: Hi Denis, Hi everyone, I'm really pleased to see you're back on track. Hi and thanks for the support :) If any of the collaborators want to help, this is the time I would be glad to. I see you need help to write the man right? Is this the number one task? Because I could also help with some more technical things if needed. Just let me know. Yeah, right now the man page for pacman-key is the work that needs to be done. The script is not very complex, but 1) English is not my mother language and 2) I don't have lots of time. My wife is doing an internship and my daughter is consuming almost all my free time. But if you want to start a draft, I can surely help to develop it. If you want to discuss the script itself, you are also welcome. When the developers start to comment on the other patches, you can also help. Or you can start commenting on them right now. Don't be shy :) -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto --- Denis, Silly question: what is the format for source man pages for pacman? Pacman man page has a comment saying it was generated by DocBook XSL Stylesheets but I can't find SGML (nor XML file). Are they plain text? AsciiDoc? -- Guillaume
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
On 18 September 2010 22:05, Guillaume ALAUX guilla...@alaux.net wrote: On 16 September 2010 17:58, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: On Thu, Sep 16, 2010 at 4:37 AM, Guillaume ALAUX guilla...@archlinux.org wrote: Hi Denis, Hi everyone, I'm really pleased to see you're back on track. Hi and thanks for the support :) If any of the collaborators want to help, this is the time I would be glad to. I see you need help to write the man right? Is this the number one task? Because I could also help with some more technical things if needed. Just let me know. Yeah, right now the man page for pacman-key is the work that needs to be done. The script is not very complex, but 1) English is not my mother language and 2) I don't have lots of time. My wife is doing an internship and my daughter is consuming almost all my free time. But if you want to start a draft, I can surely help to develop it. If you want to discuss the script itself, you are also welcome. When the developers start to comment on the other patches, you can also help. Or you can start commenting on them right now. Don't be shy :) -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto --- Denis, Silly question: what is the format for source man pages for pacman? Pacman man page has a comment saying it was generated by DocBook XSL Stylesheets but I can't find SGML (nor XML file). Are they plain text? AsciiDoc? -- Guillaume Here is a TXT version of the usage of pacman-key. Nothing more from now on but that is a starter. Anyone willing to check my English or add things is welcome. Footer.txt is the one from pacman/doc folder. I may dig a bit further into the script to elaborate the man. As I'm completely new to writing man pages, here is how I get HTML and man page from this: Generate HTML from TXT asciidoc pacman-key.8.txt Generate XML from TXT asciidoc -b docbook -d manpage pacman-key.8.txt Generate man from XML docbook2man pacman-key.8.xml Let me know if that looks useful. -- Guillaume / vim:set ts=4 sw=4 syntax=asciidoc noet: / pacman-key(8) = Name pacman-key - manage pacman's list of trusted keys Synopsis 'pacman-key' [options] command [arguments] Description --- The script pacman-key manage pacman's keyring. It imports, exports, fetches from keyservers, helps in the process of trusting and updates the trust database. Options --- *\--config*:: Set an alternative configuration file to use. Default is /etc/pacman.conf *\--gpg-dir*:: Set an alternative home directory for GnuPG. Default is set in /etc/pacman.conf Commands --- *-a, \--add [file] ...*:: Add the key contained in file (empty for stdin) *-d, \--del keyid ...*:: Remove the key keyid *-e, \--export keyid ...*:: Output the key keyid *-r, \--receive keyserver keyid ...*:: Fetch the keyids from the specified keyserver URL *-t, \--trust keyid ...*:: Set the trust level of the given key *-u, \--updatedb*:: Update the trustdb of pacman *\--reload*:: Reloads the keys from the keyring package *-l, \--list*:: List keys *-f, \--finger [keyid] ...*:: List fingerprint for specified keyids (or for all, if none is specified *\--adv params*:: Use pacman's keyring as target for advanced commands *-h, \--help*:: Displays this message *-v, \--version*:: Displays the current version See Also linkman:pacman.conf[5] include::footer.txt[]
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
On 18 September 2010 23:40, Guillaume ALAUX guilla...@alaux.net wrote: On 18 September 2010 22:05, Guillaume ALAUX guilla...@alaux.net wrote: On 16 September 2010 17:58, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: On Thu, Sep 16, 2010 at 4:37 AM, Guillaume ALAUX guilla...@archlinux.org wrote: Hi Denis, Hi everyone, I'm really pleased to see you're back on track. Hi and thanks for the support :) If any of the collaborators want to help, this is the time I would be glad to. I see you need help to write the man right? Is this the number one task? Because I could also help with some more technical things if needed. Just let me know. Yeah, right now the man page for pacman-key is the work that needs to be done. The script is not very complex, but 1) English is not my mother language and 2) I don't have lots of time. My wife is doing an internship and my daughter is consuming almost all my free time. But if you want to start a draft, I can surely help to develop it. If you want to discuss the script itself, you are also welcome. When the developers start to comment on the other patches, you can also help. Or you can start commenting on them right now. Don't be shy :) -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto --- Denis, Silly question: what is the format for source man pages for pacman? Pacman man page has a comment saying it was generated by DocBook XSL Stylesheets but I can't find SGML (nor XML file). Are they plain text? AsciiDoc? -- Guillaume Here is a TXT version of the usage of pacman-key. Nothing more from now on but that is a starter. Anyone willing to check my English or add things is welcome. Footer.txt is the one from pacman/doc folder. I may dig a bit further into the script to elaborate the man. As I'm completely new to writing man pages, here is how I get HTML and man page from this: Generate HTML from TXT asciidoc pacman-key.8.txt Generate XML from TXT asciidoc -b docbook -d manpage pacman-key.8.txt Generate man from XML docbook2man pacman-key.8.xml Let me know if that looks useful. -- Guillaume Denis, Here is already an other version that is a bit more verbose. Please correct it if I misunderstood some options. BTW: usage says: pacman-key -a | --add [file] ...- add the key contained in file (empty for stdin)) But I guess it won't go without a file (I'm talking about the stdin feature). So I removed it from the man. You may want to fix the usage (or implement the feature :) ) I haven't actually tested it but command --trust sets the user on an interactive gpg dialogue right? Then we should document this a bit and maybe tell user to read man gpg if needed. -- Guillaume / vim:set ts=4 sw=4 syntax=asciidoc noet: / pacman-key(8) = Name pacman-key - manage pacman's list of trusted keys Synopsis *pacman-key* [options] *command* ['arguments'] Description --- The script *pacman-key* manage *pacman*'s keyring, ie the keyring of GnuPG keys used to sign packages. It enables to import, export and fetch keys from keyservers as well as update the key trust database. Options --- *\--config* 'file':: Set an alternative configuration file to use (default is /etc/pacman.conf) *\--gpgdir* 'directory':: Set an alternative home directory for GnuPG (default is set in /etc/pacman.conf) Commands --- *-a*, *\--add* 'file ...':: Add the key(s) contained in 'file'(s) to pacman's keyring. If a key already exists, update it. *\--adv* 'param ...':: Use this option to issue particular GnuPG actions to pacman's keyring. This option should be used with care as it can modify pacman's trust in packages' signatures. *-d*, *\--del* 'keyid ...':: Remove the key(s) identified by 'keyid'(s) from pacman's keyring *-e*, *\--export* ['keyid ...']:: Export key(s) identified by 'keyid'(s) to STDOUT or all keys if no 'keyid' is specified *-f*, *\--finger* ['keyid ...']:: List fingerprint(s) for specified 'keyid'(s) or for all if none is specified *\--help*:: Displays this message *-l*, *\--list*:: List keys and signatures in pacman's keyring. Same as option \--list-sigs of GnuPG. See GnuPG's man pages for flag significations *-r*, *\--receive* 'keyserver' 'keyid ...':: Fetch the 'keyid'(s) from the specified 'keyserver' URL *\--reload*:: Reloads the keys from the keyring package *-t*, *\--trust* 'keyid':: Set the trust level of the given key *-u*, *\--updatedb*:: Update the trustdb of pacman. Same as option \--check-trustdb of GnuPG. *-v*, *\--version*:: Displays the current version See Also linkman:pacman.conf[5] include::footer.txt[]
Re: [pacman-dev] [PATCH 1/5] pacman-key: keyring management tool
+ ;;
+ -d|--del)
+ if (( $# == 0 )); then
+ error $(gettext You need to specify at least one
key identifier)
+ usage
+ exit 1
+ fi
+ while (( $# 0 )); do
+ ${GPG_PACMAN} --quiet --batch --delete-key --yes $1
+ shift
+ done
+ ;;
+ -u|--updatedb)
+ ${GPG_PACMAN} --batch --check-trustdb
+ ;;
+ --reload)
+ reload_keyring
+ ;;
+ -l|--list)
+ ${GPG_PACMAN} --batch --list-sigs
+ ;;
+ -f|--finger)
+ ${GPG_PACMAN} --batch --fingerprint $*
+ ;;
+ -e|--export)
+ if (( $# == 0 )); then
+ ${GPG_PACMAN} --armor --export
+ else
+ while (( $# 0 )); do
+ ${GPG_PACMAN} --armor --export $1
+ shift
+ done
+ fi
+ ;;
+ -r|--receive)
+ if (( $# 2 )); then
+ error $(gettext You need to specify the keyserver
and at least one key identifier)
+ usage
+ exit 1
+ fi
+ keyserver=$1
+ shift
+ ${GPG_PACMAN} --keyserver ${keyserver} --recv-keys $*
+ ;;
+ -t|--trust)
+ if (( $# == 0 )); then
+ error $(gettext You need to specify at least one
key identifier)
+ usage
+ exit 1
+ fi
+ while (( $# 0 )); do
+ # Verify if the key exists in pacman's keyring
+ if ${GPG_PACMAN} --list-keys $1 /dev/null 21;
then
+ ${GPG_PACMAN} --edit-key $1
+ else
+ error $(gettext The key identified by %s
doesn't exist) $1
+ exit 1
+ fi
+ shift
+ done
+ ;;
+ --adv)
+ msg $(gettext Executing: %s )$* ${GPG_PACMAN}
+ ${GPG_PACMAN} $* || ret=$?
+ exit $ret
+ ;;
+ --help)
+ usage
+ ;;
+ --version)
+ version
+ exit 0
+ ;;
+ *)
+ usage
+ exit 1
+ ;;
+esac
+
--
1.7.2.3
Hi Denis, Hi everyone,
I'm really pleased to see you're back on track.
If any of the collaborators want to help, this is the time
I would be glad to.
I see you need help to write the man right? Is this the number one
task? Because I could also help with some more technical things if
needed.
Just let me know.
--
Guillaume
