Hello,
It seems I found a bug in pacman. Some information first:
version: pacman 4.1.2-5 prebuilt from official repo
system: Linux 3.12.7-2-ARCH i686
So it happened when I tried to remove alex package.
$ sudo pacman -R alex
[sudo] password for michael:
checking
Hi!
I've run into the following bug:
$ df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 44G 30G 13G 71% /
/dev501M 0 501M 0% /dev
/run503M 276K 503M 1% /run
/dev/sda344G 30G 13G 71% /
none503M 0 503M 0%
Well, I did some good old printf debugging:
pacman simply thinks that /etc/... files will be installed to /e.
I think there is a string comparison bug somewhere in the code, but I am
too tired to find it now (and fully read diskspace.c).
NG
This has outlived its usefulness and causes more problems than it
solves.
Signed-off-by: Dan McGee d...@archlinux.org
---
This is an RFC first of all, so please feel free to comment.
Pros:
1. Removes complexity and a fair amount of code.
2. Removes the hack necesary for download-only and print
() to indicate giving up),
this ugliness cannot be eliminated.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/dload.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
index 97778c2..9b57b97 100644
--- a/lib/libalpm
In the download code a successful package-download could reset the previously
set pm_errno to 0, which is unwanted.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/dload.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/dload.c b/lib/libalpm
In the download code a successful package-download could reset the previously
set pm_errno to 0, which is unwanted.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
This patch needs testing. Btw, I can see more pm_errno = 0 line in the
code, which is not a good practice...
NG
On Wed, Feb 8, 2012 at 11:06 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote:
In the download code a successful package-download could reset the
previously
set pm_errno to 0, which is unwanted.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
This patch needs testing. Btw, I can see
For example:
allan@mugen ~
sudo touch /var/lib/pacman/db.lck
Password:
allan@mugen ~
pacman -Syu
:: Synchronizing package databases...
error: failed to update allanbrokeit (unable to lock database)
error: failed to update kernel64 (unable to lock database)
error: failed to update
Patch looks fine to me but some minor comments :
1) just a matter of taste, I would reduce the number of levels with
if (prompt download)
install = 1
else if prompt
...
else
...
2) can we have downloadonly and prompt=0 ? do we want to print the warning in
that case ?
3) that patch
2011/3/6 Nagy Gabor ng...@bibl.u-szeged.hu:
We're using transifex this time around, and going cold turkey, so I
won't even look at translations submitted here.
http://projects.archlinux.org/pacman.git/tree/doc/translation-help.txt
Hi, I cannot get msgid_plurals to work:
I tried
2011/3/7 Nagy Gabor ng...@bibl.u-szeged.hu:
2011/3/6 Nagy Gabor ng...@bibl.u-szeged.hu:
We're using transifex this time around, and going cold turkey, so I
won't even look at translations submitted here.
http://projects.archlinux.org/pacman.git/tree/doc/translation-help.txt
Hi
Yes, this is correct (both sentence).
For testing the non-plural case, pick a sync package which is not
installed on your system (some KDE stuff, for example), and put one of
its (pulled) depends to IgnorePkg. For example, sudo pacman -S gimp
--ignore libwmf is good for testing here, and I
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
src/pacman/callback.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/pacman/callback.c b/src/pacman/callback.c
index a80172b..8a1c947 100644
--- a/src/pacman/callback.c
+++ b/src/pacman/callback.c
@@ -285,7 +285,7
On 08/03/11 07:00, Nagy Gabor wrote:
Yes, this is correct (both sentence).
For testing the non-plural case, pick a sync package which is not
installed on your system (some KDE stuff, for example), and put one of
its (pulled) depends to IgnorePkg. For example, sudo pacman -S gimp
We're using transifex this time around, and going cold turkey, so I
won't even look at translations submitted here.
http://projects.archlinux.org/pacman.git/tree/doc/translation-help.txt
Hi, I cannot get msgid_plurals to work:
I tried to copy the French .po file, so I did the following:
On Tue, Dec 7, 2010 at 11:44 PM, Dan McGee dpmc...@gmail.com wrote:
On Tue, Dec 7, 2010 at 4:55 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote:
In fact I don't like neither force nor epoch. Epoch is just a version
prefix, why don't we let the packager to workaround this (KISS)? We can
$ sudo pacman -Su
warning: supertuxkart: local (0.6.2a-2) is newer than community (0.7rc1-1)
What? First I thought that our vercmp code is buggy, but vercmp
binary worked as expected. Then I figured out that my local package has
epoch=1, but the epoch is unset on the community package (so this
In fact I don't like neither force nor epoch. Epoch is just a version
prefix, why don't we let the packager to workaround this (KISS)? We can
introduce a new separator (now we have one: '.'), for example '#', and
let the packager define his favourite pkgversion (maybe epoch in mind),
like
This should hopefully reduce local db corruption issues.
Signed-off-by: Allan McRae al...@archlinux.org
---
lib/libalpm/be_local.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/be_local.c b/lib/libalpm/be_local.c
index 4574bd4..cb12abb 100644
Nagy and I discussed a bit that topic.
Don't we already read all local depends file for conflict and/or dep
checking ?
So this means we'll now read all local depends + all desc files ?
Why not put epoch stuff in the local depends file then ?
IIRC there has been a plan for years to move
$ pacman -Uh
options:
-b, --dbpath path set an alternate database location
-d, --nodeps skip dependency checks
-f, --force force install, overwrite conflicting files
-k, --dbonly only modify database entries, not package files
-r, --root pathset an
Updates for README file.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
README | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/README b/README
index b9eb399..1276eaa 100644
--- a/README
+++ b/README
@@ -295,3 +295,36 @@ API CHANGES
The Hungarian translation is attached.
I have one minor comment.
What is this in pacman/*.po?:
#, c-format
msgid [%s: %s]
msgstr [%s: %s]
Is this intended? If it is, then this is a good place to explain what
is expected from translators here. :-) See pacman/sync.c, line 292.
NG
On Fri, Jun 4, 2010 at 6:03 PM, Nagy Gabor ng...@bibl.u-szeged.hu
wrote:
OK, here we go again. All files (po and pot) are available here:
http://dev.archlinux.org/~dan/po_files/
What about the -S group regression? Won't we fix it? (That
probably needs some string modification.) /me
On Sun, May 16, 2010 at 7:33 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote:
This patch fixes the phonon/qt issue, if all to-be-upgraded packages are
explicit targets (ie. only not-yet-installed packages are pulled by
resolvedeps). This condition covers the most common situations, for example
If there is an unresolvable target in the target list
(including -Su), the new issue can be interpreted as pacman is too
safe, it won't install any targets depending on the problematic targets.
A little correction: Pacman will search for other problematic target
satisfiers, which is unwanted
To test the regression of commit a4084b91.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
pactest/tests/unresolvable001.py | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 pactest/tests/unresolvable001.py
diff --git a/pactest/tests
If there is an unresolvable target in the target list
(including -Su), the new issue can be interpreted as pacman is too
safe, it won't install any targets depending on the problematic targets.
A little correction: Pacman will search for other problematic target
satisfiers, which is
On Mon, May 17, 2010 at 2:41 PM, Nagy Gabor ng...@bibl.u-szeged.hu wrote:
To test the regression of commit a4084b91.
This might not be the ID on the main branch so that might not work.
But with that said, I thought you said forget about it completely in
that other email? What is the plan
Signed-off-by: Jonathan Conder j...@skurvy.no-ip.org
---
lib/libalpm/sync.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
index d9f4c28..9e140dc 100644
--- a/lib/libalpm/sync.c
+++ b/lib/libalpm/sync.c
@@
Hi
On Sun, 2010-05-16 at 14:54 +0200, Nagy Gabor wrote:
The spirit of this patch is better, but it is still not perfect, because
of the -Sw (PM_TRANS_FLAG_DOWNLOADONLY) case. That return(0) can also be
changed to goto error, and I can see one more RET_ERR in the function.
See my other
, but sync406.py doesn't.
The work is inspired by the patch of Henning Garus, thanks for his work:
http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010429.html
(I moved the alpm_list_diff computation to sync.c in order to compute it
only once.)
Signed-off-by: Nagy Gabor ng...@bibl.u
.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/sync.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
index 6bc0b37..6b625ed 100644
--- a/lib/libalpm/sync.c
+++ b/lib/libalpm/sync.c
@@ -857,12 +857,6
Thanks to Dan for pointing out a mistake I made.
Personally I prefer the old patch over this. If I read this patch
correctly, you have completely removed the on-demand computation from
current pacman GUI. The old patch was better for -Sp for example...
I think we should catch the
Any other points/concerns people want to mention?
Allan
One more thing I want to mention: pacman -S group interactive versus
non-interactive behaviour. Details:
http://mailman.archlinux.org/pipermail/pacman-dev/2010-March/010516.html
Bye
Original work by: Xavier Chantry shinin...@gmail.com
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
pactest/tests/sync405.py | 26 ++
pactest/tests/sync406.py | 31 +++
2 files changed, 57 insertions(+), 0 deletions(-)
create mode
On 24/04/10 02:04, Nagy Gabor wrote:
Any other points/concerns people want to mention?
The phonon/qt issue:
http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010429.html
And I revoke my reply. :-) Xavier and I discussed this issue on irc,
and neither of us could come
Any other points/concerns people want to mention?
The phonon/qt issue:
http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010429.html
And I revoke my reply. :-) Xavier and I discussed this issue on irc,
and neither of us could come up with a perfect solution. So we should
discuss
I was going to use alpm_list_remove_dups instead of testing for a
strings presence before adding it but I find that function quite
impractical...
I wonder if any other frontend is using it and whether we could change
it to actually removing the duplicates from a list. i.e. return the
same list
In addition, I permuted shortopts to make it more readable.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
src/pacman/pacman.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index 750afca..7fe8514 100644
--- a/src/pacman
I have a minor comment on pacman --print:
pacman -Q --print is the same as pacman -Qp, so the result of pacman
-Qi evince --print is 'error: package evince not found', because
pacman searches for 'evince' package file. Clearly, it is stupid to use
--print with -Q, but pacman shows that option with
http://mailman.archlinux.org/pipermail/pacman-dev/2010-March/010519.html
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
src/pacman/pacman.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c
index 6778ea2..fdc53db
Idézet Henning Garus henning.ga...@googlemail.com:
Don't use packages which are updated during the current transaction as
dependency providers, when computing needed dependencies in resolvedeps.
This could lead to new dependencies not being pulled in, in situations
like:
foo-1 provides bar
baz
1) I'd prefer just using a single depends array rather than an
additional sodepends array. A version of pacman's -d ignoring
dependency versioning would not require a separate array and would be
far more useful than one that ignored sodepends. I think that should be
implemented in
Finally, this would prevent proper upgrades to partially complete
rebuilds. That is fine for some users who would like such things, but
the people doing and testing a rebuild would have issues. I upgraded
the libpng/libjpeg rebuild packages while there were still several
packages needing to be
On 02/02/2010 09:13 PM, Nagy Gabor wrote:
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)
I've repacked core and the results are quite good
On 02/02/2010 09:13 PM, Nagy Gabor wrote:
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)
I've repacked core and the results
This patch was inspired by FS#17859. (That is not a bug atm due to target
loading-interface change.)
From now on, with empty transactions (e.g. -Ru needed_pkg) pacman prints
a there is nothing to do message. The local database is up to date
message is kept for -Su.
Signed-off-by: Nagy Gabor ng
The local database is up to date message has been replaced with there
is nothing to do message. This used with empty -S, -R, -U operations too.
(Examples: pacman -S ignored_pkg, pacman -Ru needed_pkg.)
See FS#17859.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
src/pacman/remove.c
On Fri, 11 Dec 2009, Nagy Gabor wrote:
depends files are read in order to ensure that the upgraded package
won't break any old dependencies.
Example: local foo requires bar=2.0 (which is installed)
Then pacman -S bar is not allowed (if bar in sync has different
version).
I just
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
P.S. Is there some option --pretend I might have missed? What I
need is to get exactly the same actions of pacman -S blah or
pacman -Su until the Y/N prompt, as non-root user.
Regarding this issue, it's the first I tried to fix since I
On Sat, 12 Dec 2009, Dimitrios Apostolou wrote:
Hello list,
I have been investigating the slow performance of pacman regarding
the cold caches scenario and I'm trying to write some proof of
concept code that improves things a lot for some cases. However I
need your help regarding some
Hello list,
I have been investigating the slow performance of pacman regarding
the cold caches scenario and I'm trying to write some proof of
concept code that improves things a lot for some cases. However I
need your help regarding some facts I might have misunderstood, and
any pointers
Dan McGee wrote:
On Fri, Nov 13, 2009 at 11:33 PM, Allan McRae al...@archlinux.org wrote:
Nagy Gabor wrote:
Some users reported duplicated database entries in /var/lib/pacman/local/,
for example, both foo-1.0-1 and foo-2.0-1 subdirectories existed. (Bogus
3rd-party scripts, backup
and prints an error message.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/be_files.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/be_files.c b/lib/libalpm/be_files.c
index ffbaa8d..feb71f8 100644
--- a/lib/libalpm/be_files.c
+++ b/lib
Just as we do in -Qi, we can compute required by information for sync
database packages. The behavior seems sane; for a given package, the -Si
required by will show all packages in *any* sync database that require it.
Implements FS#16244.
Signed-off-by: Dan McGee d...@archlinux.org
---
Dan McGee schrieb:
Just as we do in -Qi, we can compute required by information for sync
database packages. The behavior seems sane; for a given package, the -Si
required by will show all packages in *any* sync database that require it.
Implements FS#16244.
I was wondering about
The translation is attached.
pacman-hu.tar.gz
Description: GNU Zip compressed data
Hi!
This discussion is motivated by FS#16117.
First of all, I know that pacman -Sy foo is not recommended, only
pacman -Syu foo (see commit f53d9ba), but it is still allowed by
pacman (which is distro independent), so I must mention the following
situation:
---sync405.py---
self.description =
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/remove.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c
index af2ce94..15ea069 100644
--- a/lib/libalpm/remove.c
+++ b/lib/libalpm/remove.c
@@ -136,7 +136,7
2009. 09. 15, kedd keltezéssel 21.18-kor James Rayner ezt írta:
On Tue, Sep 15, 2009 at 9:14 PM, James Rayner iphi...@iphitus.org wrote:
On Tue, Sep 15, 2009 at 11:20 AM, Dan McGee dpmc...@gmail.com wrote:
I don't really know what to think here. I had looked at that messages
one for a
in sync_prepare:
* preferred list is not needed anymore
* I removed a needless alpm_list_remove_dupes line (the target list should
not contain dupes at all)
* I moved alpm_list_free(remove); to cleanup part to eliminate a possible
memleak
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
After commit 774c252 the --debug output shows 5-6 syntax error... lines
for each package. After this patch pacman recognizes makepkgopt as a valid
key, but doesn't do anything.
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/be_package.c |2 ++
1 files changed, 2 insertions
On Tue, Sep 8, 2009 at 10:30 PM, Dan McGeed...@archlinux.org wrote:
From: Nagy Gabor ng...@bibl.u-szeged.hu
The request of FS#12950 is implemented.
On the backend side, I introduced a new function, alpm_db_set_pkgreason(),
to modify the install reason of a package in the local
Here are some output of the patch just sent to the ML.
$ pacman -Sp --print-format %r/%n-%v : %l [%s] kdelibs
extra/qt-4.5.2-6 :
http://mir1.archlinuxfr.org/archlinux/extra/os/i686/qt-4.5.2-6-i686.pkg.tar.gz
[28914122]
extra/ilmbase-1.0.1-1 :
On Thursday, September 3, 2009, Laszlo Papp djsza...@gmail.com wrote:
From: root r...@djszapi.localdomain
To get feedback while searching instead of using another utility for
this purpose, whether the desired packages are installed. You can see
example for it in case of yaourt.
On Thu, Sep 3, 2009 at 9:54 PM, Nagy Gaborng...@bibl.u-szeged.hu wrote:
What is wrong with printf(_( [installed]));?
For my taste, printing [installed] when I have _older version_
installed, a bit strange. In this case [installed: 2.0-1] would be
better (but harder to parser).
From 841439f2d5d8c8e750d7abe186a22f53f7f87729 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
Date: Mon, 31 Aug 2009 16:20:18 +0200
Subject: [PATCH] Add a new reason field to pmconflict_t struct
Sometimes foo conflicts with bar information is not enough, see this
thread: http
From 66cb7b5d48ae173944531318022d351f4e503172 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
Date: Mon, 31 Aug 2009 23:54:51 +0200
Subject: [PATCH] Do not remove conflict by default
When a conflict is detected, pacman asks if the user wants to remove
the conflicting package
Hm. The concept is wrong, sorry. alpm/conflict.c may swap the
conflicting targets, so it can happen that this prints foo conflicts
with bar (bar), which is odd. I will rework this soon (if I can), atm
this patch is revoked.
typo: foo conflicts with bar (foo)
When a conflict is detected, pacman asks if the user wants to remove
the conflicting package. In many cases this is a bad idea. e.g.
udev conflicts with initscripts. Remove initscripts [Y/n]
util-linux-ng conflicts with e2fsprogs. Remove e2fsprogs? [Y/n]
This changes the query to [y/N].
+ if ((config-op_s_printuris = 2) !alpm_pkg_download_size(pkg)) {
+ continue;
+}
This means that -Sp prints everything, -Spp prints only the
to-be-download URIs. This is good for backward compatibility, but for
my taste -Sp should print only the to-be-download URIs, and -Spp all.
Hi!
I think the problem is known for everyone, if a user upgrades a package
(without -Su), he can easily get error while loading shared libraries.
The most perfect (but maybe overkill) solution is Florian's one:
http://www.archlinux.org/pipermail/pacman-dev/2009-August/009158.html
(that patch
Hi!
Since bugs.archlinux.org is off-line, I send my problem here. When I
want to compile pacman, I get the following error:
dload.c: In function ‘download_internal’:
dload.c:107: error: ‘struct url’ has no member named ‘last_modified’
dload.c:145: error: ‘FETCH_UNCHANGED’ undeclared (first use
On Wed, Jul 22, 2009 at 8:35 PM, Dan McGeedpmc...@gmail.com wrote:
OK, here we go.
A call for translation updates will come in 2 or 3 days time when we
have all messages finalized. You are welcome to start before then, but
please do not submit anything until all strings are final.
Translation
Maybe instead of trying to remove the directory, it should check all
existing packages to see if there is one owning this directory.
But this will slow down the -R operation, for each directory inside
a package.
-1. This would induce a memory usage boost for fixing a minor issue.
Pacman
OK, here we go.
We have two basic lists to chop through. One is here:
http://wiki.archlinux.org/index.php/Pacman_Roadmap#3.3_Final_Release_Plans.
Of course, Xavier blew my (short) list away and tried to sneak in a
much longer list. Sorry, but this is not all getting in if we are
releasing before
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=6.0.*
From 5979ea01d2f4217c1b199c675a7a3d4c728da9fa Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
Date: Tue, 21 Jul 2009 15:50:08 +0200
Subject: [PATCH] Fix a minor memleak
Signed-off-by: Nagy Gabor ng...@bibl.u-szeged.hu
---
lib/libalpm/remove.c |1 +
1 files changed, 1
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
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 API.)
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 pmpkg_t to
On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gaborng...@bibl.u-szeged.hu 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 of the work done in the
back-end
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
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
From c62951e21bd61982be4bae2dc5bdbd0651ab53f9 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
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 ng...@bibl.u-szeged.hu
---
doc/pacman.conf
From 26a3d52910e8c04794789bf2da7855a056a5886f Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
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
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 resolving should now work (upgrade051.py now passes),
FS#3492 implemented. (This was my
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 --syncdeps
From 0880c6a0f60e8377197f00bd5fab3652a3e40f39 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
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
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
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!
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
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 ng...@bibl.u-szeged.hu
---
lib/libalpm/package.c | 13 +
lib/libalpm/package.h
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 have no
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.
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 now
I can show a concrete example
From d20f84a86432bee553abdc2c485d953dc9ec6b3f Mon Sep 17 00:00:00
2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
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
From 2f51241a85f1df7219ae0649bff9a0de369a8c84 Mon Sep 17 00:00:00 2001
From: Nagy Gabor ng...@bibl.u-szeged.hu
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
1 - 100 of 226 matches
Mail list logo
