- Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.4.3-6-g23451e7
by dan＠archlinux.org 28 Feb '11

28 Feb '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, maint has been updated via 23451e7fa4302092153b4c760561d0f134b4077a (commit) via 2d25993d2d2c14214bd64bcd28b7cf1ab904c1ff (commit) from e17c4fe6115fb7b0f58540c8f825267688fa81b6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: .tx/config | 13 ++++++++++++ doc/translation-help.txt | 50 +++++++++++++++++++++++----------------------- 2 files changed, 38 insertions(+), 25 deletions(-) create mode 100644 .tx/config hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.4.3-373-gaafb387
by dan＠archlinux.org 28 Feb '11

28 Feb '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via aafb3874558b03e0d3720f35e27ca43f2ac735d6 (commit) via 23451e7fa4302092153b4c760561d0f134b4077a (commit) via dcd234ea278357f2ab71f20326ba37d89a5335c1 (commit) via 1a524fa8b80c147c0ad2c26797e75f76c0f1d2fe (commit) via f45369800abdeb54847d9ea6a326eb613f30cd3b (commit) via 5ea4706f57e15de23a5fd36eff3bc4619aeac224 (commit) via 1eccae3d9349a4366f511910f64870027a7fd2d7 (commit) via 2d25993d2d2c14214bd64bcd28b7cf1ab904c1ff (commit) via acd9269478dbc40f1dac64d8f6ddfbb5f562ad09 (commit) via e8f799ba83904db2a347e7d37fe217216a0faf90 (commit) from 3149a45bfbf05a02155f17bbd10fa58ec24f5655 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit aafb3874558b03e0d3720f35e27ca43f2ac735d6 Merge: dcd234e 23451e7 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 28 11:08:08 2011 -0600 Merge branch 'maint' commit dcd234ea278357f2ab71f20326ba37d89a5335c1 Author: Jakob Gruber <jakob.gruber(a)gmail.com> Date: Mon Feb 21 14:21:40 2011 +0100 --print-format displays size in bytes Printing the exact size seems to make more sense for scripting contexts. Signed-off-by: Jakob Gruber <jakob.gruber(a)gmail.com> [Dan: adjust for master before VerbosePkgLists patches, fix type] Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 1a524fa8b80c147c0ad2c26797e75f76c0f1d2fe Author: Jakob Gruber <jakob.gruber(a)gmail.com> Date: Sun Feb 20 20:34:32 2011 +0100 A couple of minor manpage adjustments Signed-off-by: Jakob Gruber <jakob.gruber(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f45369800abdeb54847d9ea6a326eb613f30cd3b Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 28 10:46:00 2011 -0600 Check local DB version before continuing transaction Ensure we have a local DB version that is up to par with what we expect before we go down any road that might modify it. This should prevent stupid mistakes with the 3.5.X upgrade and people not running pacman-db-upgrade after the transaction as they will need to. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 5ea4706f57e15de23a5fd36eff3bc4619aeac224 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 28 10:43:36 2011 -0600 Move locking functions to where they are needed We only call these from the transaction init and teardown, so move them to that file, mark them static, and push more of the logic of handle manipulation into these functions. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 1eccae3d9349a4366f511910f64870027a7fd2d7 Author: Dan McGee <dan(a)archlinux.org> Date: Mon Feb 28 10:34:00 2011 -0600 Fix trans no-argument function definitions Signed-off-by: Dan McGee <dan(a)archlinux.org> commit acd9269478dbc40f1dac64d8f6ddfbb5f562ad09 Author: Jonathan Conder <jonno.conder(a)gmail.com> Date: Sat Feb 5 13:39:37 2011 +1300 Fix double close of the lock file According to FOPEN(3), using fclose on an fdopen'd file stream also closes the underlying file descriptor. This happened in _alpm_lckmk (util.c), which meant that when alpm_trans_release closed it again, the log file (which reused the original file descriptor) was closed instead. Signed-off-by: Jonathan Conder <jonno.conder(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit e8f799ba83904db2a347e7d37fe217216a0faf90 Author: Allan McRae <allan(a)archlinux.org> Date: Sun Feb 27 22:20:23 2011 +1000 pactest for removing a required empty directory Signed-off-by: Allan McRae <allan(a)archlinux.org> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: .tx/config | 13 +++++++ doc/pacman.8.txt | 45 ++++++++++------------- doc/translation-help.txt | 50 +++++++++++++------------- lib/libalpm/alpm.c | 2 + lib/libalpm/alpm.h | 1 + lib/libalpm/be_local.c | 53 +++++++++++++++++++++++++++ lib/libalpm/be_sync.c | 6 +++ lib/libalpm/db.c | 8 ++++ lib/libalpm/db.h | 4 ++- lib/libalpm/error.c | 2 + lib/libalpm/handle.c | 1 - lib/libalpm/handle.h | 2 +- lib/libalpm/trans.c | 79 ++++++++++++++++++++++++++++++++-------- lib/libalpm/util.c | 41 --------------------- lib/libalpm/util.h | 2 - src/pacman/util.c | 8 +++- test/pacman/tests/remove070.py | 21 +++++++++++ 17 files changed, 225 insertions(+), 113 deletions(-) create mode 100644 .tx/config create mode 100644 test/pacman/tests/remove070.py hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] 3.5.0 release planning
by Dan McGee 28 Feb '11

28 Feb '11

It is time for a major release; we've had a bunch of stuff baking in master for a while that should get out to the masses. https://wiki.archlinux.org/index.php/Pacman_Roadmap Open/pending release blockers: * Local database sanity check- ensure we are operating on an updated pacman database. I will have a potential patch for this shortly. * Allan's pkghash branch and work. This should be good to go, we were just sorting out a few lingering issues. * soprovides/sodeps. This may/may not make it, depending upon how fast we can reach consensus and compromise. I'm hopeful. * Translation doings. We need to get Transifex updated a tad now that they have changed the way things work on their end, and make sure we can handle everything through their interface. If anyone wants to head this up, please let me know. This is *not* a call for translations. * Just *one* person to step up and not be lazy: https://bugs.archlinux.org/task/19735#comment70672 Let me know if you think there are additional items I have left off this list. Not on this list on purpose: hooks, package signing, libcurl. -Dan

5 8

Re: [pacman-dev] License for new contributions?
by edmeister46＠hushmail.com 28 Feb '11

28 Feb '11

On Sat, 26 Feb 2011 13:55:27 -0400 Xavier Chantry <chantry.xavier(a)gmail.com> wrote: >On Sat, Feb 26, 2011 at 6:42 PM, <edmeister46(a)hushmail.com> >wrote: >> Hello pacman team! >> >> I've been following development for quite some time, and would >like >> to submit my package signing patches for review. >> > >Out of curiosity, what do these patches accomplish exactly ? Bindings for openssl implemented in the backend (alpm). > >> However, since some of the files are entirely new, they would >have >> a license header. I would like to know under what license should >I >> release my work. >> >> I bring this up because during this time I overlooked the >inclusion >> of the rankmirrors script, which I've now noticed to be GPL v3 >code. >> >> Should my files be GPL v2 or v3? >> > >Why don't you use the same header that all C files in pacman have, >which is "gpl v2 or later" ? You see, "or later" includes v3. And since I want to keep up to date with RMS' licenses, I prefer v3. Because of this, I'd like to know if v3 is acceptable before releasing my work. Some of v2 is sadly susceptible to loopholes.

3 2

[pacman-dev] Draft pacman-3.5.0 NEWS
by Allan McRae 27 Feb '11

27 Feb '11

For comment. I have not written the epoch stuff yet... VERSION DESCRIPTION ----------------------------------------------------------------------------- 3.5.0 - database format changes - sync databases are read directly from the repo database tarball (FS#8586, FS#20233) - local database "depends" files have been merged into the "desc" file - pacman-db-upgrade script provided to update the local database format - sync database extension is .db (without compression suffix) - requires repo-add from pacman-3.4+ - epoch - TODO!!! - disk space checking - check available space before installing packages (FS#11639) - enabled by the "CheckSpace" option in pacman.conf - attempt to stop install if we hit an extraction issue (FS#7692, FS#22034) - improved groups/providers selction dialog (FS#19704, FS#19853) - more fine grained controll of ignorine dependency resolution - -Sd to ignore dependency versions only - -Sdd to ignore all dependency information - clean-up of --help output (FS#19526) - CleanMethod for package cache cleaning can use both KeepInstalled and KeepCurrent simultaneously - various speed-ups: - improved internal storage of the package cache - faster pkgname/depends searches - use openssl crypto functions if available - makepkg: - add support for running testsuites in a check() function (FS#15145) - controlled by BUILDENV option 'check' in makepkg.conf which may be overridden by --check/--nocheck on the commandline - extract any file bsdtar recognizes - STRIP_DIRS has been removed in favour of stripping all recognized files - improve $srcdir/$pkgdir check to reduce false positives - $pkgname can be used in split package() functions (FS#22174) - added '!buildflags' option to allow unsetting CFLAGS/LDFLAGS/etc - repo-add: - added -f/--files to create files database (FS#11302) - pactree: rewritten in C using libalpm

2 1

[pacman-dev] Removing empty directories
by Allan McRae 27 Feb '11

27 Feb '11

I just noticed this: > pacman -Qk | grep "^warning" warning: filesystem: /opt/ (No such file or directory) warning: hal: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hal-info: /usr/share/hal/fdi/information/20thirdparty/ (No such file or directory) warning: hicolor-icon-theme: /usr/share/icons/hicolor/256x256/apps/ (No such file or directory) warning: network-manager-applet: /etc/gconf/schemas/ (No such file or directory) All these directories are empty in their package. They appear to have been removed when I uninstalled a different package that had files in that directory. Maybe we need some more checking before removing an empty directory. Allan

4 8

[pacman-dev] [PATCH 1/2] pactest for removing a required empty directory
by Allan McRae 27 Feb '11

27 Feb '11

Signed-off-by: Allan McRae <allan(a)archlinux.org> --- test/pacman/tests/remove070.py | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 test/pacman/tests/remove070.py diff --git a/test/pacman/tests/remove070.py b/test/pacman/tests/remove070.py new file mode 100644 index 0000000..e0587e1 --- /dev/null +++ b/test/pacman/tests/remove070.py @@ -0,0 +1,21 @@ +self.description = "Remove a package with an empty directory needed by another package" + +p1 = pmpkg("pkg1") +p1.files = ["bin/pkg1", "opt/"] + +p2 = pmpkg("pkg2") +p2.files = ["bin/pkg2", "opt/"] + +for p in p1, p2: + self.addpkg2db("local", p) + +self.args = "-R %s" % p1.name + +self.addrule("PACMAN_RETCODE=0") +self.addrule("!PKG_EXIST=pkg1") +self.addrule("PKG_EXIST=pkg2") +self.addrule("!FILE_EXIST=bin/pkg1") +self.addrule("FILE_EXIST=bin/pkg2") +self.addrule("FILE_EXIST=opt/") + +self.expectfailure = True -- 1.7.4.1

1 0

[pacman-dev] [PATCH] Fix double close of the lock file
by Jonathan Conder 27 Feb '11

27 Feb '11

According to FOPEN(3), using fclose on an fdopen'd file stream also closes the underlying file descriptor. This happened in _alpm_lckmk (util.c), which meant that when alpm_trans_release closed it again, the log file (which reused the original file descriptor) was closed instead. Signed-off-by: Jonathan Conder <jonno.conder(a)gmail.com> --- lib/libalpm/handle.c | 1 - lib/libalpm/handle.h | 2 +- lib/libalpm/trans.c | 13 +++++-------- lib/libalpm/util.c | 7 +++---- lib/libalpm/util.h | 2 +- 5 files changed, 10 insertions(+), 15 deletions(-) diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c index aa34cf4..8f44e94 100644 --- a/lib/libalpm/handle.c +++ b/lib/libalpm/handle.c @@ -49,7 +49,6 @@ pmhandle_t *_alpm_handle_new() ALPM_LOG_FUNC; CALLOC(handle, 1, sizeof(pmhandle_t), RET_ERR(PM_ERR_MEMORY, NULL)); - handle->lckfd = -1; return(handle); } diff --git a/lib/libalpm/handle.h b/lib/libalpm/handle.h index 1834994..6884666 100644 --- a/lib/libalpm/handle.h +++ b/lib/libalpm/handle.h @@ -34,7 +34,7 @@ typedef struct _pmhandle_t { pmdb_t *db_local; /* local db pointer */ alpm_list_t *dbs_sync; /* List of (pmdb_t *) */ FILE *logstream; /* log file stream pointer */ - int lckfd; /* lock file descriptor if one exists */ + FILE *lckstream; /* lock file stream pointer if one exists */ pmtrans_t *trans; /* callback functions */ diff --git a/lib/libalpm/trans.c b/lib/libalpm/trans.c index 02612ec..e13a7b2 100644 --- a/lib/libalpm/trans.c +++ b/lib/libalpm/trans.c @@ -73,8 +73,8 @@ int SYMEXPORT alpm_trans_init(pmtransflag_t flags, /* lock db */ if(!(flags & PM_TRANS_FLAG_NOLOCK)) { - handle->lckfd = _alpm_lckmk(); - if(handle->lckfd == -1) { + handle->lckstream = _alpm_lckmk(); + if(handle->lckstream == NULL) { RET_ERR(PM_ERR_HANDLE_LOCK, -1); } } @@ -260,12 +260,9 @@ int SYMEXPORT alpm_trans_release() /* unlock db */ if(!nolock_flag) { - if(handle->lckfd != -1) { - int fd; - do { - fd = close(handle->lckfd); - } while(fd == -1 && errno == EINTR); - handle->lckfd = -1; + if(handle->lckstream != NULL) { + fclose(handle->lckstream); + handle->lckstream = NULL; } if(_alpm_lckrm()) { _alpm_log(PM_LOG_WARNING, _("could not remove lock file %s\n"), diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 32eaa44..4d152ee 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -197,7 +197,7 @@ char *_alpm_strtrim(char *str) } /* Create a lock file */ -int _alpm_lckmk() +FILE *_alpm_lckmk() { int fd; char *dir, *ptr; @@ -220,10 +220,9 @@ int _alpm_lckmk() fprintf(f, "%ld\n", (long)getpid()); fflush(f); fsync(fd); - fclose(f); - return(fd); + return(f); } - return(-1); + return(NULL); } /* Remove a lock file */ diff --git a/lib/libalpm/util.h b/lib/libalpm/util.h index 8a3154a..edd51d5 100644 --- a/lib/libalpm/util.h +++ b/lib/libalpm/util.h @@ -62,7 +62,7 @@ int _alpm_makepath(const char *path); int _alpm_makepath_mode(const char *path, mode_t mode); int _alpm_copyfile(const char *src, const char *dest); char *_alpm_strtrim(char *str); -int _alpm_lckmk(); +FILE *_alpm_lckmk(); int _alpm_lckrm(); int _alpm_unpack_single(const char *archive, const char *prefix, const char *fn); int _alpm_unpack(const char *archive, const char *prefix, alpm_list_t *list, int breakfirst); -- 1.7.4

3 6

[pacman-dev] Style questions and concerns
by Dan McGee 27 Feb '11

27 Feb '11

I've noticed these things a lot in recent patches, so let the discussion commence. 1) typedef-ed structs. This is just a "copy the rest of them" habit, but I really feel we should stop doing this, only typedef-ing when we are making a public-facing type that we don't want to expose the internal contents of. Everything else should remain a struct type, and referred to as such, no typedef and no confusion that the fields are accessible. 2) return(value) style. This is a rule set in stone in the coding style doc but people are continuously breaking it. To be fair, it is silly, but mixing styles sucks way worse. I propose switching this, *BUT* all current patches need to follow current style, and if we switch, it should happen post-3.5.0 and in one commit, not this piecemeal junk. 3) C99. Several patches are introducing things that go further down this road. I don't think they should all be avoided but I'm not sure GCC 3.X (Cygwin is still on this?) supports all of these. * Variable declarations not at the start of a block. I'm not a huge fan of this, as I think having them at the start of the block helps clarify scope a lot better. * Dynamically sized array declarations, e.g. data[numcpus]. I think this needs to be avoided, unfortunately, but it isn't hard to just use MALLOC/FREE in this case. * C99 structure initialization (saw it in the parallelize patches). Please chip in and discuss. -Dan

5 5

[pacman-dev] Paralellising integrity checks
by Tavian Barnes 26 Feb '11

26 Feb '11

Integrity checking in pacman seems to be a CPU-bound embarrassingly parallel task, so I'd like to spread it out over every available core to speed it up. To me it looks like both the delta and regular package integrity checking loops in lib/libalpm/sync.c could be parallelised. But I've never messed with the pacman code before, so I have a couple questions about your best practices: - There doesn't seem to be any threading code in pacman/libalpm currently; would using pthreads directly be okay, or should a threading abstraction layer be created? - There's no portable way to get the number of available cores. Where does platform-specific code go in libalpm? The way to do it on Linux is with sched_getaffinity(); sysconf(_SC_NPROCESSORS_ONLN) is almost as good and works on BSD too I believe. Also, I guess a major question would be: would this be likely to be merged? It's not a major issue, but it's also not a very large change. Every time there's a KDE update or something similarly large I find myself wishing that all 2/4/24 of my cores were being used for the the integrity checks. -- Tavian Barnes

4 10