- Pacman-dev - lists.archlinux.org

Re: [pacman-dev] libalpm issues (was: alpm_removedeps bug+fix && alpm_depcmp-discussion)
by Dan McGee 19 Jun '07

19 Jun '07

On 6/18/07, Xavier <shiningxc(a)gmail.com> wrote: > 2007/6/18, Dan McGee <dpmcgee(a)gmail.com>: > > On 6/18/07, ngaba(a)petra.hos.u-szeged.hu <ngaba(a)petra.hos.u-szeged.hu> wrote: > > > Hi! > > > > > > I attached the pactest file and my patch. I also made some > > > modifications in alpm_removedeps' args, because the old one was a bit > > > messy for me. And I think that my version is faster. > > > > > > can_remove_package is a bit stupid (compared to alpm_checkdeps), but I > > > leave it untouched, because speed is more important here than > > > "perfection". > > > > IMO, doing things right is what we want to do in 99% of the cases this > > speed vs. perfection issue comes up, so I'm going to disagree with you > > here. > > > > It looks like checkdeps could indeed be used here. > There is also the install reason which comes into play here though. > This problem was mentioned here : > http://bugs.archlinux.org/task/3241 > > Aaron didn't see any reason for checking that the packages removed by > -Rs are only dependencies, but I believe there is one, as I tried to > explain in my comment. > > > In addition, to assume anything only makes an ass out of u (you) and > > me. I don't want to introduce any functions that depend on a > > particular quirk of our list implementation, especially since this is > > one of the things we have considered changing. > > > > What about just renaming alpm_list_add to alpm_list_add_last ? > That way, there isn't any assumption, it's explicit :) This isn't a bad idea, but I'm thinking of changes on a much larger scale. Read here for details: http://isis.poly.edu/kulesh/stuff/src/klist/ > > I feel that if we look at the bigger picture and stop thinking of add, > > remove, and sync as isolated actions, then we could get some HUGE > > refactoring and code reduction going on with cases like this. However, > > this will be one large undertaking. > > > > There are often several ways to do things right, and we probably don't > all see the same, so it would help if it was a bit more concrete :) > You are probably the only one who can get things exactly like you > want, unless maybe you explain it in details. I agree- and part of this is me NOT trying to enforce my 'right' way on everyone else. Here is how I see our operations-based thinking being reformed a bit. There are two baseline operations- install (add) and remove. upgrade is a combination of an add and remove, and sync is a combination of install, remove, upgrade, and a little extra sugar on the side. Instead of having duplicated code everywhere, we should be able to build up a set of functions that are used by the base operations, then use these base operations to build an upgrade, then use those to build a sync. By the time we get to a sync operation, we really shouldn't have much left to code at a low level, unlike the current code base. -Dan

2 1

[pacman-dev] turkish locale problem, bug left in pacman 3.0 branch
by Xavier 19 Jun '07

19 Jun '07

http://bugs.archlinux.org/task/7235?histring=turkish http://bbs.archlinux.org/viewtopic.php?id=34301 Maybe this should be fixed there too ?

2 1

[pacman-dev] [patch] I. deps.c/checkdeps bugfix + upgrade059.py
by Nagy Gabor 18 Jun '07

18 Jun '07

Hi! I started to work on deps.c. I send smaller patches instead of a big one. At first I rewrite alpm_*deps functions (implement topological sort...); I merge them later (which would be the most optimal imho) after testing. I found a bug: ---upgrade059.py--- self.description = "Try to upgrade packages which would break a multiple-depend" lp1 = pmpkg("pkg1") lp1.depends = ["imaginary"] self.addpkg2db("local", lp1) lp2 = pmpkg("pkg2", "1.0-1") lp2.provides = ["imaginary"] lp2.requiredby = [ "pkg1" ] self.addpkg2db("local", lp2) lp3 = pmpkg("pkg3", "1.0-1") lp3.provides = ["imaginary"] lp3.requiredby = [ "pkg1" ] self.addpkg2db("local", lp3) p2 = pmpkg("pkg2", "1.0-2") self.addpkg(p2) p3 = pmpkg("pkg3", "1.0-2") self.addpkg(p3) self.args = "-U %s" % " ".join([p.filename() for p in p2, p3]) self.addrule("PACMAN_RETCODE=1") self.addrule("PKG_EXIST=pkg1") self.addrule("PKG_VERSION=pkg2|1.0-1") self.addrule("PKG_VERSION=pkg3|1.0-1") ------------------- Here is my patch (WARNING: with large targetlist this may cause notable slowdown). ------------------- diff -Naur pacman-lib/lib/libalpm/deps.c pacman-lib.new/lib/libalpm/deps.c --- pacman-lib/lib/libalpm/deps.c 2007-03-19 05:23:45.000000000 +0100 +++ pacman-lib.new/lib/libalpm/deps.c 2007-04-21 16:42:29.000000000 +0200 @@ -271,8 +271,9 @@ for(l = _alpm_db_get_pkgcache(db); l; l = l->next) { pmpkg_t *pkg = l->data; - if(strcmp(alpm_pkg_get_name(pkg), alpm_pkg_get_name(oldpkg)) == 0) { - /* well, we know this one succeeds, but we're removing it... skip it */ + if(_alpm_pkg_find(alpm_pkg_get_name(pkg), packages)) { + /* we ignore packages that will be updated because we know that + updated ones don't satisfy depend.*/ continue; } ------------------ Bye, ngaba

6 32

[pacman-dev] CVS update of pacman-lib (17 files)
by Dan McGee 18 Jun '07

18 Jun '07

Date: Sunday, June 17, 2007 @ 20:15:37 Author: dan Path: /home/cvs-pacman/pacman-lib Modified: NEWS (1.15 -> 1.16) configure.ac (1.41 -> 1.42) etc/makepkg.conf.in (1.17 -> 1.18) etc/pacman.d/mirrorlist.in (1.11 -> 1.12) lib/libalpm/po/de.po (1.20 -> 1.21) lib/libalpm/po/en_GB.po (1.6 -> 1.7) lib/libalpm/po/es.po (1.2 -> 1.3) lib/libalpm/po/fr.po (1.13 -> 1.14) lib/libalpm/po/hu.po (1.13 -> 1.14) lib/libalpm/po/it.po (1.23 -> 1.24) lib/libalpm/po/libalpm.pot (1.11 -> 1.12) lib/libalpm/po/pl_PL.po (1.2 -> 1.3) lib/libalpm/po/pt_BR.po (1.12 -> 1.13) lib/libalpm/po/ru_RU.po (1.4 -> 1.5) scripts/repo-add (1.10 -> 1.11) src/pacman/po/de.po (1.24 -> 1.25) src/pacman/po/pl_PL.po (1.2 -> 1.3) Check in changes for 3.0.5 release (mostly backports) * Update the mirrorlist * Fix FS7338- the previous repo-add fix didn't quite do the job, but it should be fixed now. * Small updates to translations files * Add -mtune=generic to default CFLAGS (req'd by GCC 4.2) ----------------------------+ NEWS | 6 +++++ configure.ac | 2 - etc/makepkg.conf.in | 4 +-- etc/pacman.d/mirrorlist.in | 8 +++++++ lib/libalpm/po/de.po | 26 +++++++++++----------- lib/libalpm/po/en_GB.po | 26 +++++++++++----------- lib/libalpm/po/es.po | 26 +++++++++++----------- lib/libalpm/po/fr.po | 26 +++++++++++----------- lib/libalpm/po/hu.po | 26 +++++++++++----------- lib/libalpm/po/it.po | 26 +++++++++++----------- lib/libalpm/po/libalpm.pot | 26 +++++++++++----------- lib/libalpm/po/pl_PL.po | 34 ++++++++++++++--------------- lib/libalpm/po/pt_BR.po | 26 +++++++++++----------- lib/libalpm/po/ru_RU.po | 26 +++++++++++----------- scripts/repo-add | 2 - src/pacman/po/de.po | 49 ++++++++++++++++++++++++++++--------------- src/pacman/po/pl_PL.po | 10 ++++---- 17 files changed, 189 insertions(+), 160 deletions(-) The diff is longer than the limit of 39KB.

1 0

Re: [pacman-dev] How does pacman interact with a package's INSTALL script
by Andrew Fyfe 17 Jun '07

17 Jun '07

lordbad wrote: > In the documentation I have read the following: > > There are also install files. This PKGBUILD specifies 'foo.install' as the > package's install file. Here is an example install file: > > post_install() { > /bin/true > } > > post_upgrade() { > /bin/true > } > > pre_remove() { > /bin/true > } > > op=$1 > shift > > $op "$@" > > Here are the function explainations : > > * post_install : this script is run right after files are installed, it > takes one argument : > o the package version > * post_upgrade : this script is run after all files have been upgraded, > it takes two arguments : > o the new package version > o the old package version > * pre_remove : this script is run right before files are removed (stop a > daemon for example) and takes one argument : > o the package version > > The three lines at the bottom are needed in every install file so that they > run properly. > > But I do not understand how does pacman handle these scripts. Does it source the > scripts first and then call the shell functions defined in them with some C > function like "system" for example? But if it does so why are the last 3 lines > needed - I see little if any need for them. So if anyone can give me some hints > on the subject and maybe even mention which of pacman's source files implements > this functionality I'd be very grateful. Thanks in advance for your help. > > Best Regards, > Bozhidar > > > _____________________ > http://www.e-card.bg/ > > > _______________________________________________ > pacman-dev mailing list > pacman-dev(a)archlinux.org > http://archlinux.org/mailman/listinfo/pacman-dev The function your looking for is _alpm_runscriptlet() (lib/libalpm/trans.c:567) http://projects.archlinux.org/git/?p=pacman.git;a=blob;f=lib/libalpm/trans.… Pacman runs 'source <path to file>/.INSTALL <function name> <old ver> <new ver>', the last 3 lines of .INSTALL are needed to get the function name and call it. Andrew

4 6

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-235-gcacf968
by Dan McGee 17 Jun '07

17 Jun '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via cacf968970bbc63e8eb519e40194e6c083ba6a06 (commit) via 2ab320a3885226ce28da0f2f2bc84b5f2d0f0539 (commit) via 520841ee8a82460e0abb2a9a44c857556604cf56 (commit) via a486fec3c48d57d48c7d871161c1510be10e0924 (commit) from 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc (commit) - Log ----------------------------------------------------------------- commit cacf968970bbc63e8eb519e40194e6c083ba6a06 Author: Dan McGee <dan(a)archlinux.org> Date: Thu Jun 14 11:12:21 2007 -0400 Update Doxyfile and add a few missing parts of documentation Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 2ab320a3885226ce28da0f2f2bc84b5f2d0f0539 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 11:33:45 2007 -0400 Remove some use of goto in the pacman frontend Refactor the goto cleanup; statements out of add.c and remove.c, and move what the cleanup: label did into a function. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 520841ee8a82460e0abb2a9a44c857556604cf56 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Jun 13 10:36:33 2007 -0400 Quick updates to the bash completion script Signed-off-by: Dan McGee <dan(a)archlinux.org> commit a486fec3c48d57d48c7d871161c1510be10e0924 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Jun 17 18:57:15 2007 +0200 FS7338: Fix conflicts typo totally this time. The last typo fix for conflicts wasn't complete, it only fixed one occurence of the conflicts variable, instead of the two : http://www.archlinux.org/pipermail/pacman-dev/2007-May/008222.html This caused all conflicts statement to be ignored, so all databases will need to be rebuilt with a fixed repo-add. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Diffstat: contrib/bash_completion | 25 +++++++++---------------- lib/libalpm/Doxyfile | 16 +++++++++++++++- lib/libalpm/db.c | 11 +++++++++++ scripts/repo-add.in | 2 +- src/pacman/add.c | 37 ++++++++++++++++++++++--------------- src/pacman/remove.c | 41 ++++++++++++++++++++++++++--------------- 6 files changed, 84 insertions(+), 48 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc \ cacf968970bbc63e8eb519e40194e6c083ba6a06

1 0

[pacman-dev] How does pacman interact with a package's INSTALL script
by lordbad 16 Jun '07

16 Jun '07

In the documentation I have read the following: There are also install files. This PKGBUILD specifies 'foo.install' as the package's install file. Here is an example install file: post_install() { /bin/true } post_upgrade() { /bin/true } pre_remove() { /bin/true } op=$1 shift $op "$@" Here are the function explainations : * post_install : this script is run right after files are installed, it takes one argument : o the package version * post_upgrade : this script is run after all files have been upgraded, it takes two arguments : o the new package version o the old package version * pre_remove : this script is run right before files are removed (stop a daemon for example) and takes one argument : o the package version The three lines at the bottom are needed in every install file so that they run properly. But I do not understand how does pacman handle these scripts. Does it source the scripts first and then call the shell functions defined in them with some C function like "system" for example? But if it does so why are the last 3 lines needed - I see little if any need for them. So if anyone can give me some hints on the subject and maybe even mention which of pacman's source files implements this functionality I'd be very grateful. Thanks in advance for your help. Best Regards, Bozhidar _____________________ http://www.e-card.bg/

1 0

Re: [pacman-dev] [arch] Plans for switching to new package naming format (name-ver-rel -> name-ver-rel-arch)
by Dan McGee 15 Jun '07

15 Jun '07

On 6/13/07, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On 6/13/07, Johan Grahn <johan(a)cgeek.net> wrote: > > On Wed, 2007-06-13 at 22:43 +0100, Andrew Fyfe wrote: > > > Are there any plans (if so when) to switch the official repositories > > > over to the new package naming format? > > > > > > Current/Old: name-ver-rel.pkg.tar.gz > > > New: name-ver-rel-arch.pkg.tar.gz > > > > Why do you wanna do this? I'm just curios... > > > > Is it not better to just have separate repos because they are compiled > > differently and better to maintain. > > > > I'm not saying that is it a bad idea, I just wanna know how you think > > No body "wants" to do it - it's already done, and part of pacman 3.0. > The rationalization is simple: the majority of the time you don't > touch real package files... it's pacman -S, done. There is really > nothing lost from adding the suffix - what is gained is clarity in > looking at the filename. > > To respond to Andrew: there actually is no real "plan" at the > moment... but we want to make sure pacman2 users have sufficient time > to make the switch before we kill their packages. This drifts into something that should be on the pacman ML, so I'm moving it there. Is there any reason for pacman to enforce a naming convention at all when it comes to the packages? We should do any information gathering from the .PKGINFO file in the package itself rather than the name, shouldn't we? I also might be way off here- maybe pacman doesn't care. If so, let me know- I haven't dug into the code yet on this issue. -Dan

5 4

[pacman-dev] [patch] patch IV rewritten for git
by Nagy Gabor 13 Jun '07

13 Jun '07

Hi! Some comments: 1. This is a simple topological sort algorithm, based on the "depth first search" algorithm, for more info plz visit: http://en.wikipedia.org/wiki/Topological_sorting (An alternative algorithm for...) Usually this is done by a recursive way but I not prefer that, because this version is more expressive to me (however this looks more difficult, because we need some extra variables to precisely store the current state). 2. As I noted in the patch (TODO), the most CPU-cost part of the algorithm is to build the graph, so this should somehow combined with depcheck (because that function does this too...) So, here is the patch: ---------------------- diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 29a2f02..afbfed0 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -43,7 +43,7 @@ libalpm_la_SOURCES = \ versioncmp.h versioncmp.c libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -libalpm_la_LIBADD = -larchive -ldownload -lm +libalpm_la_LIBADD = -larchive -ldownload if HAS_DOXYGEN all: doxygen.in diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index d4c584f..e6c905f 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -50,6 +50,7 @@ typedef struct __pmsyncpkg_t pmsyncpkg_t; typedef struct __pmdepend_t pmdepend_t; typedef struct __pmdepmissing_t pmdepmissing_t; typedef struct __pmconflict_t pmconflict_t; +typedef struct __pmgraph_t pmgraph_t; /* * Library diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index b6f8cc8..ceee5c1 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -29,7 +29,6 @@ #ifdef __sun__ #include <strings.h> #endif -#include <math.h> /* libalpm */ #include "deps.h" @@ -46,6 +45,27 @@ extern pmhandle_t *handle; +pmgraph_t *_alpm_graph_new(void) +{ + pmgraph_t *graph = NULL; + + graph = (pmgraph_t *)malloc(sizeof(pmgraph_t)); + if(graph) { + graph->state = 0; + graph->data = NULL; + graph->father = NULL; + graph->sons = NULL; + graph->sonptr = NULL; + } + return(graph); +} + +void _alpm_graph_free(pmgraph_t *graph) +{ + alpm_list_free(graph->sons); + free(graph); +} + pmdepmissing_t *_alpm_depmiss_new(const char *target, pmdeptype_t type, pmdepmod_t depmod, const char *depname, const char *depversion) @@ -108,11 +128,10 @@ int _alpm_depmiss_isin(pmdepmissing_t *needle, alpm_list_t *haystack) alpm_list_t *_alpm_sortbydeps(alpm_list_t *targets, pmtranstype_t mode) { alpm_list_t *newtargs = NULL; - alpm_list_t *i, *j, *k, *l; - int change = 1; - int numscans = 0; - int numtargs = 0; - int maxscans; + alpm_list_t *i, *j, *k; + alpm_list_t *vertices = NULL; + alpm_list_t *vptr; + pmgraph_t *vertex; ALPM_LOG_FUNC; @@ -120,65 +139,64 @@ alpm_list_t *_alpm_sortbydeps(alpm_list_t *targets, pmtranstype_t mode) return(NULL); } + _alpm_log(PM_LOG_DEBUG, _("started sorting dependencies")); + + /* We create the vertices */ for(i = targets; i; i = i->next) { - newtargs = alpm_list_add(newtargs, i->data); - numtargs++; + pmgraph_t *vertex = _alpm_graph_new(); + vertex->data = (void *)i->data; + vertices = alpm_list_add(vertices, vertex); } - maxscans = (int)sqrt(numtargs); + /* We compute the edges */ + for(i = vertices; i; i = i->next) { + pmgraph_t *vertex_i = i->data; + pmpkg_t *p_i = vertex_i->data; + //TODO: this should be somehow combined with _alpm_checkdeps + for(j = vertices; j; j = j->next) { + pmgraph_t *vertex_j = j->data; + pmpkg_t *p_j = vertex_j->data; + int son=0; + for(k = alpm_pkg_get_depends(p_i); k && !son; k = k->next) { + pmdepend_t *depend = alpm_splitdep(k->data); + son = alpm_depcmp(p_j, depend); + free(depend); + } + if(son) vertex_i->sons=alpm_list_add(vertex_i->sons, vertex_j); + } + vertex_i->sonptr=vertex_i->sons; + } - _alpm_log(PM_LOG_DEBUG, _("started sorting dependencies")); - while(change) { - alpm_list_t *tmptargs = NULL; - change = 0; - if(numscans > maxscans) { - _alpm_log(PM_LOG_DEBUG, _("possible dependency cycle detected")); - continue; + vptr = vertices; + vertex = vertices->data; + while(vptr) { + vertex->state = -1; // we touched this vertex + int found = 0; + while(vertex->sonptr && !found) { + pmgraph_t *nextson = (vertex->sonptr)->data; + vertex->sonptr = (vertex->sonptr)->next; + if (nextson->state == 0) { + found = 1; + nextson->father = vertex; + vertex = nextson; + } + else if(nextson->state == -1) { + _alpm_log(PM_LOG_WARNING, _("dependency cycle detected\n")); + } } - numscans++; - /* run thru targets, moving up packages as necessary */ - for(i = newtargs; i; i = i->next) { - pmpkg_t *p = i->data; - _alpm_log(PM_LOG_DEBUG, " sorting %s", alpm_pkg_get_name(p)); - for(j = alpm_pkg_get_depends(p); j; j = j->next) { - pmdepend_t *depend = alpm_splitdep(j->data); - pmpkg_t *q = NULL; - if(depend == NULL) { - continue; - } - /* look for depend->name -- if it's farther down in the list, then - * move it up above p - */ - for(k = i->next; k; k = k->next) { - q = k->data; - const char *qname = alpm_pkg_get_name(q); - if(!strcmp(depend->name, qname)) { - if(!_alpm_pkg_find(qname, tmptargs)) { - change = 1; - tmptargs = alpm_list_add(tmptargs, q); - } - break; - } - for(l = alpm_pkg_get_provides(q); l; l = l->next) { - const char *provname = l->data; - if(!strcmp(depend->name, provname)) { - if(!_alpm_pkg_find(qname, tmptargs)) { - change = 1; - tmptargs = alpm_list_add(tmptargs, q); - } - break; - } - } + if(!found) { + newtargs = alpm_list_add(newtargs, vertex->data); + vertex->state = 1; //we leave this vertex + vertex = vertex->father; + if(!vertex) { + while(vptr = vptr->next) { + vertex = vptr->data; + if (vertex->state == 0) break; } - free(depend); - } - if(!_alpm_pkg_find(alpm_pkg_get_name(p), tmptargs)) { - tmptargs = alpm_list_add(tmptargs, p); } } - alpm_list_free(newtargs); - newtargs = tmptargs; } + _alpm_log(PM_LOG_DEBUG, _("sorting dependencies finished")); if(mode == PM_TRANS_TYPE_REMOVE) { @@ -189,6 +207,8 @@ alpm_list_t *_alpm_sortbydeps(alpm_list_t *targets, pmtranstype_t mode) newtargs = tmptargs; } + alpm_list_free_inner(vertices, _alpm_graph_free); + return(newtargs); } diff --git a/lib/libalpm/deps.h b/lib/libalpm/deps.h index 8f3a9b9..56028a4 100644 --- a/lib/libalpm/deps.h +++ b/lib/libalpm/deps.h @@ -42,6 +42,18 @@ struct __pmdepmissing_t { pmdepend_t depend; }; +/* Graphs */ +struct __pmgraph_t { + int state; //0: untouched, -1: entered, other: leaving time + void *data; + struct __pmgraph_t *father; //where did we come from? + alpm_list_t *sons; + alpm_list_t *sonptr; // points to a son in the sons list +}; + +pmgraph_t *_alpm_graph_new(void); +void _alpm_graph_free(pmgraph_t *graph); + pmdepmissing_t *_alpm_depmiss_new(const char *target, pmdeptype_t type, pmdepmod_t depmod, const char *depname, const char *depversion); diff --git a/src/pacman/Makefile.am b/src/pacman/Makefile.am index 6a7f4e4..1ab5916 100644 --- a/src/pacman/Makefile.am +++ b/src/pacman/Makefile.am @@ -26,11 +26,11 @@ pacman_SOURCES = \ util.h util.c pacman_LDADD = $(top_builddir)/lib/libalpm/.libs/libalpm.la \ - -ldownload + -ldownload -lm pacman_static_SOURCES = $(pacman_SOURCES) pacman_static_LDFLAGS = $(LDFLAGS) -all-static pacman_static_LDADD = $(top_builddir)/lib/libalpm/.libs/libalpm.la \ - -ldownload + -ldownload -lm # vim:set ts=2 sw=2 noet:

4 6

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-231-g7bd4486
by Dan McGee 13 Jun '07

13 Jun '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc (commit) from af813a8badd71c591a8c29d9bad1710ae3b2e945 (commit) - Log ----------------------------------------------------------------- commit 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc Author: Andrew Fyfe <andrew(a)neptune-one.net> Date: Wed Jun 13 10:48:22 2007 +0100 scripts/makepkg.in: Forgot the fakeroot switch when changing to GNU getopt. Signed-off-by: Andrew Fyfe <andrew(a)neptune-one.net> ----------------------------------------------------------------------- Diffstat: scripts/makepkg.in | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ af813a8badd71c591a8c29d9bad1710ae3b2e945 \ 7bd4486ebd15ba9cca0ee3e6a2c2ddc88ff104dc

1 0