> Just checking the sanity of an idea here:
>
> What do you all think of supporting wildcards for version comparisons?
> I was thinking fnmatch could almost be dropped in directly to
> alpm_pkg_vercmp in place of the initial strcmp.
>
> Use case:
> readline version 6.0.003
> bash depends readline
Idézet Xavier :
On Fri, Jul 25, 2008 at 2:11 PM, Nagy Gabor wrote:
> If you want to restore our old negligent "eye-candy" behaviour, you
> can do the following (pseudo-code):
> if(isdir(local_conflicting_stuff) &&
> alpm_list_find_str(oldpkg->files,local_confl
Special thanks to my mail client for formatting this. See my git repo
for the applicable patch.
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://www.archlinux.org/mailman/listinfo/pacman-dev
>From e9d1686e5e54bff2aad12820e335c10603b307db Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Wed, 15 Jul 2009 17:08:28 +0200
Subject: [PATCH] API changes between 3.2 and 3.3
Signed-off-by: Nagy Gabor
---
README | 50 ++
1 files changed,
> On Sat, Jul 11, 2009 at 2:32 PM, Nagy Gabor wrote:
> >> we had a section in the README about API CHANGES BETWEEN 3.1 AND 3.2
> >> do we need the same for 3.2 -> 3.3?
> >> As you can see in the attached diff, there were quite a few changes as
> >> we
> we had a section in the README about API CHANGES BETWEEN 3.1 AND 3.2
> do we need the same for 3.2 -> 3.3?
> As you can see in the attached diff, there were quite a few changes as well :P
I will send a patch for this when we are in "patch freeze". (I have 4
pending patches, all of them change AP
> On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor wrote:
> >> > This pactest currently fails. It shows that the current "sync
> >> > addtarget" is quite messy. Most of the work (search for provision,
> >> > install group) is done in the front-end, some o
> > This pactest currently fails. It shows that the current "sync
> > addtarget" is quite messy. Most of the work (search for provision,
> > install group) is done in the front-end, some of the work done in the
> > back-end (interpret '/', avoid duplicated targets, and the
> > "conversion" from pmp
Did you try with pacman-git? This should be fixed, see FS#12059.
Haha, of course not. I probably should have dug a bit first, whoops. I
just built pacman-git on that box and it seems to have done what I
expected now, so thanks for letting me know I don't even know what
we've done in 3.3.
It is
So I tried to install base-devel on my slice today so I could build
a package:
$ pacS base-devel
Password:
base-devel package not found, searching for group...
:: group base-devel (including ignored packages):
autoconf automake bin86 bison ed fakeroot flex gcc libtool
m4 make pa
>From c62951e21bd61982be4bae2dc5bdbd0651ab53f9 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Tue, 16 Jun 2009 12:34:16 +0200
Subject: [PATCH] Document the .pacnew extension with NoUpgrade
See FS#13832.
Signed-off-by: Nagy Gabor
---
doc/pacman.conf.5.txt |3 ++-
1 files changed
>From 26a3d52910e8c04794789bf2da7855a056a5886f Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sun, 14 Jun 2009 21:00:07 +0200
Subject: [PATCH] Update the documentation of -Qs and -Ss
It was undocumented that multiple regexps are interpreted using logical AND.
Thanks to recurs...@#archlinux
> Nagy Gabor wrote:
> > Hi!
> >
> > http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/universal
> >
> > I've managed to implement some nice features for -U by "moving"
> > upgrade_prepare to sync.c.
> >
> > 1. Conflict
>From 0880c6a0f60e8377197f00bd5fab3652a3e40f39 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Wed, 10 Jun 2009 20:22:04 +0200
Subject: [PATCH] Enable remove progressbar with -S (conflict resolving)
$ sudo pacman -S mc
Old output:
***
:: mc conflicts with mc-mp. Remove mc-mp? [Y/n
Hi!
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/universal
I've managed to implement some nice features for -U by "moving"
upgrade_prepare to sync.c.
1. Conflict resolving should now work (upgrade051.py now passes),
FS#3492 implemented. (This was my main motivation.)
2. -U --syncdep
> Hi!
>
> After killing pmsyncpkg_t, there is not much difference between -S and
> -U transactions. The only difference is that trans->packages come from
> pkgcache (-S) or they are loaded from file (-U). And of course, with -S
> we have an extra step, we have to actually download the packages.
>
Hi!
IMHO the default no answer is better. If pacman is invoked with
--noconfirm (see scripts), it is unpredictable what will happen. By the
way, I _want_ to install the specified packages, so by default, I would
say no.
However, then it is not possible to test the remove_unresolvable feature
with
Hi!
After killing pmsyncpkg_t, there is not much difference between -S and
-U transactions. The only difference is that trans->packages come from
pkgcache (-S) or they are loaded from file (-U). And of course, with -S
we have an extra step, we have to actually download the packages.
However, -U i
The main purpose of this function to make our code more readable.
It frees transaction specific fields of pmpkg_t. (It is used when a package
is removed from the target list.)
Signed-off-by: Nagy Gabor
---
lib/libalpm/package.c | 13 +
lib/libalpm/package.h |1 +
lib/libalpm
> > IMHO we should print all error messages to stderr. (This can be
> > done easily in callback functions.) I am sure that it would be
> > better with -Sp (-Sp users usually do pacman -Sup > foo.txt), and I
> > don't see any drawbacks in other cases. (What about our scripts?)
> > See also: FS#12101
> This fixes FS#14899. When running an -Sp operation without servers
> configured for a repository, we would segfault, so add an assert to
> the backend method returning the first server preventing a null
> pointer dereference.
>
> In addition, add a new error code to libalpm that indicates we hav
See FS#14833.
Signed-off-by: Nagy Gabor
---
doc/pacman.8.txt |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt
index 195135b..0d86bad 100644
--- a/doc/pacman.8.txt
+++ b/doc/pacman.8.txt
@@ -80,6 +80,13 @@ to determine which
> Nagy Gabor wrote:
> > I thought -Suf cannot hurt anything, so I just did -Suf.
>
> I still can't believe you did that! I always say the guideline is to
> only use -f for one package at a time.
Yes, I always say that, too (on #archlinux.hu irc channel). At least no
> ... (probably due to the symlink bug) ...
>
> I guess, I've just run into the file relocation bug (otherwise, we have
> a more serious bug here), showed by upgrade046.py. Briefly, the file
> relocation check is hacked into the fileconflict check, which is omitted
> with -f.
Even if -f checked f
Hi!
I think this bug has just hurted my system today. Since I have no net in
my sublet, I do -Su very rarely, so today's sysupgrade upgraded 415
packages (my system was ~0.7 year-old).
I got lots of false fileconflict errors first (probably due to the
symlink bug). I was lazy to resolve all of th
>From 2f51241a85f1df7219ae0649bff9a0de369a8c84 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Fri, 22 May 2009 01:06:33 +0200
Subject: [PATCH] Change package to package(s) and file to file(s) in
documentation
The pacman --help pages and the manual suggested that only one package can
> >From d20f84a86432bee553abdc2c485d953dc9ec6b3f Mon Sep 17 00:00:00
> >2001
> From: Nagy Gabor
> Date: Wed, 20 May 2009 21:46:23 +0200
> Subject: [PATCH] Introduce -D, --database
>
> The request of FS#12950 is implemented.
>
> On the backend
>From d20f84a86432bee553abdc2c485d953dc9ec6b3f Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Wed, 20 May 2009 21:46:23 +0200
Subject: [PATCH] Introduce -D, --database
The request of FS#12950 is implemented.
On the backend side, I introduced a new function, alpm_db_set_pkgreason(),
to mod
>From 4531be12ace34a952e5d84e70f464f4643957793 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sat, 16 May 2009 17:59:45 +0200
Subject: [PATCH 2/2] We don't need root with -Sp
FS#8905 is fixed. The front-end passes PM_TRANS_FLAG_NOLOCK to the back-end,
so it doesn't lock the databas
>From afa07db77af2896b407b24c6ef69bb19f6b80417 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sat, 16 May 2009 16:54:21 +0200
Subject: [PATCH 1/2] Introduce PM_TRANS_FLAG_NOLOCK
This flag indicates that the front-end will not call alpm_trans_commit(),
so the database needn't be locked.
> >From 449d53df4a41f3856a5dba967e2eb186aa64914a Mon Sep 17 00:00:00 2001
> From: Nagy Gabor
> Date: Thu, 14 May 2009 18:25:16 +0200
> Subject: [PATCH] Introduce -Suu
>
> If the user switches from unstable repo to a stable one, it is quite hard to
> sync its system wit
>From 449d53df4a41f3856a5dba967e2eb186aa64914a Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Thu, 14 May 2009 18:25:16 +0200
Subject: [PATCH] Introduce -Suu
If the user switches from unstable repo to a stable one, it is quite hard to
sync its system with the new repo (the user will see m
>From 8f675582f8f0098ec524fa702c38058c687e53fd Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Thu, 14 May 2009 16:15:20 +0200
Subject: [PATCH] Query documentation updates
The old documentation didn't emphasize our filtering options at all, and it
was a bit misleading. ("List ALL
On Sun, May 10, 2009 at 3:04 PM, Nagy Gabor wrote:
>From 054eae27537989dee76a06fac882fb38702144d5 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sun, 10 May 2009 22:41:29 +0200
Subject: [PATCH] Introduce -Qlq
With --quiet flag, -Ql doesn't print the package name only lists files
>From 054eae27537989dee76a06fac882fb38702144d5 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sun, 10 May 2009 22:41:29 +0200
Subject: [PATCH] Introduce -Qlq
With --quiet flag, -Ql doesn't print the package name only lists files.
I made --quiet documentation up-to-date (I also added -
>From 1572535efe01dfae1f28b74862dec21f2102f165 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sun, 10 May 2009 14:08:04 +0200
Subject: [PATCH] Don't print "local/" with -Qs
See FS#14642.
Signed-off-by: Nagy Gabor
---
src/pacman/query.c |2 +-
1 files changed, 1 insertio
> > > dmc...@galway /home/makepkg/packages
> > > $ pacS ../valgrind-3.4.1-1-x86_64.pkg.tar.gz
> > > error: repository '..' not found
> > > error: '../valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
>
> Wow, this is ugly. The problem with PM_ERR_PKG_REPO_NOT_FOUND error
> code, that it need
> > dmc...@galway /home/makepkg/packages
> > $ pacS ../valgrind-3.4.1-1-x86_64.pkg.tar.gz
> > error: repository '..' not found
> > error: '../valgrind-3.4.1-1-x86_64.pkg.tar.gz': no such repository
Wow, this is ugly. The problem with PM_ERR_PKG_REPO_NOT_FOUND error
code, that it needs a param (whi
From 88c26a6e5902875f07ca7c842971619530fa5aa9 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sat, 18 Apr 2009 17:35:08 +0200
Subject: [PATCH] Remove unused error codes and handle
PM_ERR_RETRIEVE by alpm_strerror()
Signed-off-by: Nagy Gabor
---
First I started to work on http
>From 88c26a6e5902875f07ca7c842971619530fa5aa9 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sat, 18 Apr 2009 17:35:08 +0200
Subject: [PATCH] Remove unused error codes and handle PM_ERR_RETRIEVE by
alpm_strerror()
Signed-off-by: Nagy Gabor
---
lib/libalpm/alpm.h |9 -
As usual, I modified the patch slightly in my git repo (I added a
missing '\n'), so review it instead of ML's one.
One more thing, that I didn't emphasize earlier, but I should have:
When I finally voted to this implemented behavior of replacements, I
kept in mind that many users have testing
>From bf937acf544b836fd322a94cbf9e41bc7f609284 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Mon, 13 Apr 2009 15:08:38 +0200
Subject: [PATCH] Remove find_replacements().
"Foo replaces bar" simply means that "foo is a new version of bar".
So this patch refactors the
> Nagy Gabor wrote:
> >
> > Bump on these. As I see, 1-2 are fixed now (mentioned in the first
> > mail of this thread). But the "duplicated messages/data-list" issue
> > is still here. After my "Print warning in _alpm_resolvedep() if a
> > satisfier
> > -- new suggestions :) [optional] --
> >
> > 3. Now it can happen, that a missing dependency is added to the
> > *data list many times. For example, if there is a popular
> > unresolvable package in our repo, let's say gtk2, and we have 10
> > packages in the target list depend on that, then we
> On Sat, Mar 7, 2009 at 8:29 PM, Nagy Gabor
> wrote:
> > Hi!
> >
> > Since the patch is quite long and it depends on my working branch, I
> > don't send it here directly. It can be found in my repo (it is a new
> > branch): http://repo.or.cz/w/pac
> 2009/3/27 Dario Freddi :
> > Not really a bump. I just wanted to know if this patch will ever be
> > in, no matter when.
> >
> > To talk bluntly: if you assure me this patch is going to make it in
> > the main pacman tree, and you simply don't know when, I'll apply it
> > in my local copy and sta
>From c121fa3c9ad702f4daa0f1156869573673d749c7 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sun, 22 Mar 2009 17:13:29 +0100
Subject: [PATCH] Document --debug
After some irc/forum experiences, I decided to document this option.
However, I left the debug-level undocumented (--debug=2).
Sig
> Sebastian Nowicki wrote:
> >
> > On 12/03/2009, at 7:18 PM, Xavier wrote:
> >
> >> Otherwise, go go sqlite :)
> >
> > Wasn't there a (set of) patch(es) for a "packed" format for the
> > databases (tar-like, iirc)? From what I remember there was a
> > performance improvement.
>
> There was talk
> I just found a funny test case on my first try. Funny because besides
> the same missing dependency message being printed many times, there is
> also a "provider package was selected" printed multiple times, which
> makes the whole thing worse.
> If I understood you correctly, all these missing d
> >> sync993 does not exist in the pacman sources. If it did, I would have
> >> seen this problem and addressed it.
> >>
> >
> > That's why I posted it here :) I've just created it to show the problem.
> > (I like pactests, because we can test our patches easily with them.)
> >
>
> Oh, I
Hi!
Since the patch is quite long and it depends on my working branch, I
don't send it here directly. It can be found in my repo (it is a new
branch): http://repo.or.cz/w/pacman-ng.git
---quote---
Remove pmsyncpkg_t
pmsyncpkg_t data sructure was removed:
1. pmpkg_t.reason is used instead of pmsy
>From 9cfe60f495dfabe29d92e426f9c823fedd315ca6 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sat, 7 Mar 2009 16:25:29 +0100
Subject: [PATCH] Free *data list when user removes unresolvable packages
Resolvedeps reports error when it cannot resolve some dependencies, puts
them into the *data l
> > Nagy Gabor wrote:
> > > Hi!
> > >
> > > I know that I speak too late, but I haven't time/motivation to review
> > > this patch nowadays.
> > >
> > > 1. See alpm/sync.c/sync_prepare(). When user decides to remove
> > &g
> +
> + /* Destroy all packages which are in trans->packages but not in
> +newpkgs before replacing trans->packages with newpkgs */
> + for(i = trans->packages; i; i = i->next) {
> + pmsyncpkg_t *spkg = (pmsyncpkg_t *) i->data;
> +
> Nagy Gabor wrote:
> > Hi!
> >
> > I know that I speak too late, but I haven't time/motivation to review
> > this patch nowadays.
> >
> > 1. See alpm/sync.c/sync_prepare(). When user decides to remove
> > unresolvable targets from the list, o
I know that I speak too late, but I haven't time/motivation to review
this patch nowadays.
I forgot to say that I think Bryan did a great work: The
implementation is much simpler than I expected.
Bye
--
SZTE Egyetemi Konyvtar - http://www
Hi!
I know that I speak too late, but I haven't time/motivation to review
this patch nowadays.
1. See alpm/sync.c/sync_prepare(). When user decides to remove
unresolvable targets from the list, our code doesn't remove any targets
from target->packages, just adds the pulled dependencies. The actua
>From 816e0ec31278ff9e94b0d8dcdea24dadb5e4fa1b Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Fri, 6 Mar 2009 17:02:19 +0100
Subject: [PATCH] Fix error handling in _alpm_resolvedeps
Now resolvedeps is just a helper function for sync_prepare, so we set
pm_errno in sync_prepare. We free *d
[Xav, sorry for my direct reply.]
I generated deltas for the last 20 updates on my system. The total
delta size is 12M, while the total package size is 73M. So the overall
ratio is pretty good imo.
Afaik, only one delta on the 20 didn't reach the 0.7 ratio : attr
The ghostscript one is unbelieva
2009. 03. 4, szerda keltezéssel 20.51-kor Nagy Gabor ezt írta:
> >From fe694f5e78a93284a28c4afd1a9272dac565b29b Mon Sep 17 00:00:00 2001
> From: Nagy Gabor
> Date: Wed, 4 Mar 2009 20:34:06 +0100
> Subject: [PATCH] Print warning in _alpm_resolvedep() if a satisfier package
>
>From fe694f5e78a93284a28c4afd1a9272dac565b29b Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Wed, 4 Mar 2009 20:34:06 +0100
Subject: [PATCH] Print warning in _alpm_resolvedep() if a satisfier package is
ignored without QUESTION
After commit f57f8d33862050acc8d131710c100ba47877e675 pac
> On Mon, Mar 2, 2009 at 2:33 PM, Allan McRae wrote:
> > Nagy Gabor wrote:
> >>>
> >>> Redux:
> >>> /usr/lib/zomg.so is not owned by any package. Allow foobar-1.0-2 to
> >>> overwrite this file? [y/N]
> >>>
> >>>
> Nagy Gabor wrote:
> >> Redux:
> >> /usr/lib/zomg.so is not owned by any package. Allow foobar-1.0-2 to
> >> overwrite this file? [y/N]
> >>
> >> Optional:
> >> s/overwrite/claim ownership of/
> >>
> >
> > In thi
> Redux:
> /usr/lib/zomg.so is not owned by any package. Allow foobar-1.0-2 to
> overwrite this file? [y/N]
>
> Optional:
> s/overwrite/claim ownership of/
In this case we don't need overwrite option at all, right? (This can be
detected automatically. However, this detection is slow.)
_
> hi all!
>
> i wanted to ignore a pkg in a group but i can with this:
> pacman -S gnome-extra --ignore orca
>
> Pacman after i say yes to install all the packages but then ask me if i want
> to install orcad that's insidce ignorePkg/ignoreGroup, i say no but then
> pacman exit saying that it can
> These db_open and db_close looked quite useless. And they caused the db
> directory to be opened on a simple registering of a database. This is
> totally unneeded, this opening can be delayed to when we actually need it.
>
> Signed-off-by: Xavier Chantry
After this patch, we don't need db->han
>From 884155e03bf20f1cca880f39848423091729f6cd Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Mon, 19 Jan 2009 00:35:45 +0100
Subject: [PATCH] db_register: Unlink DbPath/database, if it is not a directory
We had a check for this case, but we didn't handle it at all (neither error,
nor
>From 2b1a58bda8318b7d0c70a4cfc161a82a156b199b Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sun, 18 Jan 2009 20:03:56 +0100
Subject: [PATCH] Use archive_entry_set_perm instead of archive_entry_set_mode
This patch fixes FS#12148 ('unstable' regular file).
I also chan
This discussion is motivated by FS#11737.
A replacement is nothing more than a simple upgrade with package name
change. (This is plausible, but we don't really follow this principle
atm.) So if we moved our find_replacments code to sync_newversion our
code would be more readable [1].
Benefits:
-
> It sounds good, but isn't it a bit a step backward after this :
> http://projects.archlinux.org/?p=pacman.git;a=commit;h=72c0ab5c51d5119b6f81c768b1a0f6ff499df292
> However, we were not considering this new behavior in case of
> unresolvable dependency back then.
We should decide, whether we want
> Hey all. I've been thinking about my patches and the concerns that
> list members have had about them and I've come up with a different
> way of accomplishing the same thing that may be more palatable:
>
> - Modify the signature of deps.c:_alpm_resolvedeps so that it takes,
> instead of a list
No. pkg->depends or alpm_pkg_get_depends(pkg) is used to get the
dependency list of pkg. In the old code it was easy to determine if a
dependency is broken. If we couldn't find a satisfier package in the
target list or in the local database (which won't be upgraded), we
simply detected that this d
[Bryan, sorry for my previous direct reply.]
In terms of a warning, pacman already prints out lines like this:
warning: kernel26: ignoring package upgrade (2.6.27.8-1 => 2.6.27.10-1)
warning: pacman: ignoring package upgrade (3.2.1FIXBUG9395-1 => 3.2.1-2)
warning: pango: ignoring package upgrad
Hi!
Some comments/suggestions. (Note: First wait for Dan's response, whether
he can support your concept (behavior change) or not. I would be sad, if
you did useless work because of me.)
I must repeat some of my earlier suggestions.
We prefer shorter patches. I can fully support in your patch: d
>From e00884ab554562fa5e6ac601aa99477e0f70cd75 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Sat, 10 Jan 2009 16:25:03 +0100
Subject: [PATCH] db->pkgcache_loaded and db->grpcache_loaded
Clearly the old code was more elegant (NULL cache indicated "not loaded"),
but it had
Translation is attached.
pacman-hu.tar.gz
Description: GNU Zip compressed data
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
> >From 01ba4fce1e7bf2c6058074c583e5db5147d31f02 Mon Sep 17 00:00:00
> >2001
> From: Nagy Gabor
> Date: Fri, 2 Jan 2009 17:43:05 +0100
> Subject: [PATCH] Fix for trans001.py (FS#9088)
>
> >From now on _alpm_db_find_fileconflicts() works with upgrade and
> >r
>From 01ba4fce1e7bf2c6058074c583e5db5147d31f02 Mon Sep 17 00:00:00 2001
From: Nagy Gabor
Date: Fri, 2 Jan 2009 17:43:05 +0100
Subject: [PATCH] Fix for trans001.py (FS#9088)
>From now on _alpm_db_find_fileconflicts() works with upgrade and remove
target lists (like checkdeps), which ma
> > 2. A new list for pkginfos looks ugly imho.
> >
>
> What do you mean by 'ugly'? Is it redundant given other data
> structures in libalpm? If so, I will be happy to switch to another
> data structure. Xavier already pointed out that pmgraph_t may fit
> the bill. I'll definitely look into
> Hi, attached is a patch to fix bug 9395, against the current git tree
> for pacman, as described in an earlier email to this list. You may
> find a description of the changes I made in the Arch bug database for
> bug 9395. Please let me know if there are any questions.
>
> Thank you, and best
> This is an attempt to add a one-file-per-database backend. This leads to
> significatly faster loading of the database when the database is not
> cached. As you can see from the patch minimal changes to the rest of
> ALPM was needed. The only change was to make reading of the changelog
> files ha
> I'd like to do a 3.2.2 release sometime soon (this week, more than
> likely). Let me know if there are any outstanding patches for this
> release that aren't already in the maint branch as of tonight. I will
> put a call for updated translations out in the coming few days.
>
I have some pending
> Looks good outside of my main "cleanup" naming comment. I'll pull this
> into maint once that gets addressed, thanks for the quick fix to the
> missing message and Flyspray bug.
>
OK. Fixed in my repo. (In fact I used clean_up label because we already
have a cleanup function in pacman.c.)
Bye
Omg, you can find my patch here: http://repo.or.cz/w/pacman-ng.git
Bye
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
> From 8e11e0c7198f7c7bdeb6ca76d647d4831593b965 Mon Sep 17 00:00:00 2001
> From: Nagy Gabor <[EMAIL PROTECTED]>
> Date: Mon, 17 Nov 2008 17:02:43 +0100
> Subject: [PATCH] Give an error message on alpm_db_register_sync() error
>
> This patch slightly modifies pacman.c/_pa
Idézet Xavier <[EMAIL PROTECTED]>:
On Fri, Nov 14, 2008 at 1:02 PM, Nagy Gabor <[EMAIL PROTECTED]> wrote:
I guess I spoke to soon. I was right concerning xdelta3 using gzip for
handling gzipped files, however it doesn't use the -n flag. This gives
us the same behaviour as
I guess I spoke to soon. I was right concerning xdelta3 using gzip for
handling gzipped files, however it doesn't use the -n flag. This gives
us the same behaviour as xdelta1, with one minor difference: Method 1.
stops working.
Wait. I don't understand something. If it doesn't use the -n flag,
: http://horde.org/imp/
>From 962ccd09c7afc59a19045e353b4fbd4711414720 Mon Sep 17 00:00:00 2001
From: Nagy Gabor <[EMAIL PROTECTED]>
Date: Sun, 9 Nov 2008 17:34:49 +0100
Subject: [PATCH] New error type: PM_ERR_PKG_IGNORED
This patch fixes FS#12059.
Now sync_addtarget can re
Hi,
I have been looking through the current delta implementation in
libalpm and have put some thought into changing makepkg/repo-add to
support delta creation. However, I'm running into some problems,
mostly due to md5sums and gzip.
The current implementation works as follows. On a sync operatio
Hi all,
Im trying to add some downgradability magic into pacman .Being quite
new to pacman code, i need your help to identify the possible
pitfalls of my approach before trying something.
What i plan to do is..
In libalpm/remove.c unlink_file() [ I guess remove.c is the only
place where we ar
> > There is something I don't understand:
> > We have trans->state and handle->trans->state. This is intentional?
> > Probably you wanted to set handle->trans->state.
> No, if things are sane, I want to abort the *current* transaction. We
> are looking at that one's packages. In this case, because
Sat, 1 Nov 2008 08:19:51 -0500 -n
"Dan McGee" <[EMAIL PROTECTED]> írta:
> On Sat, Nov 1, 2008 at 8:16 AM, Nagy Gabor <[EMAIL PROTECTED]>
> wrote:
> >> Hmm, this isn't quite what I expected either. Can we clean up this
> >> garbage in any way?
>
> Hmm, this isn't quite what I expected either. Can we clean up this
> garbage in any way?
>
> $ ./src/pacman/pacman -Qu
> warning: alsa-lib: local (1.0.17a-2) is newer than extra (1.0.17a-1)
> warning: gvim: local (7.2.25-1) is newer than extra (7.1.330-1)
> warning: namcap: local (2.1-2) is newe
> Hey guys,
>
> I would *love* it if someone could take this patch and run with it. I
> really just wanted to hash out a possible fix, but unfortunately it
> isn't easy for two reasons: our code structure is a bit rough, and we
> really don't have a hard-and-fast set of rules for continuing or
> f
> On Fri, Oct 24, 2008 at 12:53 AM, Xavier <[EMAIL PROTECTED]> wrote:
> > On Fri, Oct 24, 2008 at 2:09 AM, Nagy Gabor
> > <[EMAIL PROTECTED]> wrote:
> >> See:
> >> http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
> >>
> &
> On Thu, Oct 30, 2008 at 2:17 AM, Hugo Doria <[EMAIL PROTECTED]>
> wrote:
> >
> > http://bugs.archlinux.org/task/11846
> >
>
> I have nothing to add to what Nagy said there. He gave the link to a
> discussion on the ML about how to implement this differently, in a
> better way, which would also f
On Fri, Oct 24, 2008 at 12:00 PM, Nagy Gabor <[EMAIL PROTECTED]> wrote:
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
I know you may not like this way (free functions public), but IMHO the
result is not so ugly ;-)
Can we just expose something more like "free_c
http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
I know you may not like this way (free functions public), but IMHO the
result is not so ugly ;-)
Off-topic: A small thing. During working on this patch I realized,
that "\nerrors occurred, no packages were upgraded.\n" messag
See: http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/working
This is a big behavior change (iirc it restores the old behavior). Opinions?
--
SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu
This message was sent using IMP: http://
This seems more like an issue with dependency resolution than anything
else. Assuming this is all based on issues with optdepends, like so:
$ pacman -S foobar
Optional dependencies for foobar:
baz
$ pacman -S --asdep baz
What we have here is 'baz' indicated as an orphan, but what we *want*
is
101 - 200 of 359 matches
Mail list logo
