Re: [pacman-dev] pacman sorting incompatible with 'sort' command
On Fri, May 5, 2017 at 4:06 PM, Kieran Colford wrote: > Maybe pacman should sort according to the current locale, it's all in glibc > so it should be trivial to implement. Is there a technical reason for using > the C locale or is it just a default? > Trying to pin down the impact of a call to setlocale(LC_ALL, NULL). This changes the behavior of the following functions: fprintf, fscanf, printf, scanf, snprintf, sscanf, vfprintf, vfscanf, vprintf, vscanf, vsnprintf, vsprintf, vsscanf, mblen, mbtowc, wctomb, mbstowcs, wcstombs, strtol, strtoll, strtoul, strtoull, strcoll, strftime, strxfrm, isalnum, isalpha, isblank, iscntrl, isgraph, islower, isprint, ispunct, isspace, isupper, tolower, toupper Accoring to POSIX, these have to be taken into account additionally: exec, isdigit, iswalnum, iswalpha, iswblank, iswcntrl, iswctype, iswdigit, iswgraph, iswlower, iswprint, iswpunct, iswspace, iswupper, iswxdigit, isxdigit, localeconv, nl_langinfo, setlocale, strerror, strfmon, strtod, towlower, towupper, wcscoll, wcstod, wcsxfrm I'm not sure how exec functions behave with regard to setlocale, I don't think it should have any affect and only receive whatever is in **environ. Then again, it's mentioned in [0]. cheers! mar77i [0] http://pubs.opengroup.org/onlinepubs/009695399/functions/setlocale.html
Re: [pacman-dev] [PATCH] Provide a better guess about who the packager is.
Anybody could impersonate anybody else as long as a package isn't even signed. I don't get what we are trying to accomplish here. cheers! mar77i
Re: [pacman-dev] Is there an architectural document for pacman
Your question is basically about the difference between depends and makedepends. When you installed parity, pacman just downloaded the finished package as *.pkg.tar.xz for you and installed (runtime-) dependencies as you need them. If you set up abs [0] for you, you can build the package yourself, just update the abs tree, copy /var/abs/*/parity to ~/abs/parity and type makepkg -s. if you add -i to the makepkg command, it also tries to run pacman -U the_finished_package.pkg.tar.xz as root. In that order of doing things, makepkg (as told by the -s flag) will install cargo, because it needs the (make-) dependency to build the package. So uh, yeah, read up how ABS works and how you can create, maintain and fix archlinux packages for personal use/learning experience [1]. cheers! mar77i [0] https://wiki.archlinux.org/index.php/Arch_Build_System [1] https://wiki.archlinux.org/index.php/Makepkg
Re: [pacman-dev] Potential bug in alpm-hooks; fix provided
As far as I can tell this is relevant to the other discussion in [0]. I recommend you have a look and check the code duplication, so you don't fix things that are being removed anyway. cheers! mar77i [0] https://lists.archlinux.org/pipermail/pacman-dev/2017-January/021770.html
Re: [pacman-dev] [PATCH rebased 1/1] Introduce a 'stupid-proxy' option
Without intending to come across as overly sensitive, but does it have to be called stupidproxy? cheers! mar77i
[pacman-dev] [PATCH v3] Parametrise the different ways in which the payload is reset
In FS#43434, Downloads which fail and are restarted on a different server
will resume and may display a negative download speed. The payload's progress
in libalpm was not properly reset which ultimately caused terminal noise
because the line width calculation assumes positive download speeds.
This patch fixes the incomplete reset of the payload by mimicing what
be_sync.c:alpm_db_update() does over in sync.c:download_single_file().
The new dload.c:_alpm_dload_payload_reset_for_retry() extends beyond the
current behavior by updating initial_size and prevprogress for this case.
This makes pacman reset the progress properly in the next invocation of the
callback and display positive download speeds.
Fixes FS#43434.
Signed-off-by: Martin Kühne
---
lib/libalpm/dload.c | 10 ++
lib/libalpm/dload.h | 1 +
lib/libalpm/sync.c | 4 +---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
index dc57c92..855099b 100644
--- a/lib/libalpm/dload.c
+++ b/lib/libalpm/dload.c
@@ -762,4 +762,14 @@ void _alpm_dload_payload_reset(struct dload_payload
*payload)
memset(payload, '\0', sizeof(*payload));
}
+void _alpm_dload_payload_reset_for_retry(struct dload_payload *payload)
+{
+ ASSERT(payload, return);
+
+ FREE(payload->fileurl);
+ payload->initial_size += payload->prevprogress;
+ payload->prevprogress = 0;
+ payload->unlink_on_fail = 0;
+}
+
/* vim: set noet: */
diff --git a/lib/libalpm/dload.h b/lib/libalpm/dload.h
index 427c486..3459665 100644
--- a/lib/libalpm/dload.h
+++ b/lib/libalpm/dload.h
@@ -47,6 +47,7 @@ struct dload_payload {
};
void _alpm_dload_payload_reset(struct dload_payload *payload);
+void _alpm_dload_payload_reset_for_retry(struct dload_payload *payload);
int _alpm_download(struct dload_payload *payload, const char *localpath,
char **final_file, const char **final_url);
diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c
index 00b68d0..a1f673f 100644
--- a/lib/libalpm/sync.c
+++ b/lib/libalpm/sync.c
@@ -946,9 +946,7 @@ static int download_single_file(alpm_handle_t *handle,
struct dload_payload *pay
EVENT(handle, &event);
return 0;
}
-
- FREE(payload->fileurl);
- payload->unlink_on_fail = 0;
+ _alpm_dload_payload_reset_for_retry(payload);
}
event.type = ALPM_EVENT_PKGDOWNLOAD_FAILED;
--
2.10.0
[pacman-dev] [PATCH] Resume downloads properly on another server
Package Downloads which fail for the next mirror to be used may resume and
display negative download speeds. A detailed analysis revealed that the
payload's progress in libalpm is not properly reset which ultimately leads to
this annoying terminal noise due to a negative sign on the download speeds.
This patch resets the payload's prevprogress so that the callback's state
is properly reset.
Fixes the beautifully symmetric FS#43434
Signed-off-by: Martin Kühne
---
lib/libalpm/dload.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c
index dc57c92..657f562 100644
--- a/lib/libalpm/dload.c
+++ b/lib/libalpm/dload.c
@@ -605,6 +605,9 @@ cleanup:
STRDUP(*final_file, strrchr(realname, '/') + 1,
RET_ERR(handle, ALPM_ERR_MEMORY, -1));
}
+ } else {
+ payload->initial_size += payload->prevprogress;
+ payload->prevprogress = 0;
}
if((ret == -1 || dload_interrupted) && payload->unlink_on_fail &&
--
2.10.0
[pacman-dev] [PATCH] Use f_bavail for diskspace calculations
From: Martin Kühne
This should make pacman's behavior consistent with GNU coreutils df,
as well as follow advice from affected filesystems' devs as well as
`man statvfs`.
This fixes FS#37402
Signed-off-by: Martin Kühne
---
lib/libalpm/diskspace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/libalpm/diskspace.c b/lib/libalpm/diskspace.c
index da4ad56..55343c1 100644
--- a/lib/libalpm/diskspace.c
+++ b/lib/libalpm/diskspace.c
@@ -348,11 +348,11 @@ static int check_mountpoint(alpm_handle_t *handle,
alpm_mountpoint_t *mp)
_alpm_log(handle, ALPM_LOG_DEBUG,
"partition %s, needed %jd, cushion %ju, free %ju\n",
mp->mount_dir, (intmax_t)mp->max_blocks_needed,
- (uintmax_t)cushion, (uintmax_t)mp->fsp.f_bfree);
- if(needed >= 0 && (fsblkcnt_t)needed > mp->fsp.f_bfree) {
+ (uintmax_t)cushion, (uintmax_t)mp->fsp.f_bavail);
+ if(needed >= 0 && (fsblkcnt_t)needed > mp->fsp.f_bavail) {
_alpm_log(handle, ALPM_LOG_ERROR,
_("Partition %s too full: %jd blocks needed,
%ju blocks free\n"),
- mp->mount_dir, (intmax_t)needed,
(uintmax_t)mp->fsp.f_bfree);
+ mp->mount_dir, (intmax_t)needed,
(uintmax_t)mp->fsp.f_bavail);
return 1;
}
return 0;
--
2.10.0
Re: [pacman-dev] [RFC v3 13/13] bacman: make gettext useful
Had to try this myself because I don't trust you on this for whatever reason: $ set -- -a '1 2 3' -b; printf '<%s>\n' "$@" <-a> <1 2 3> <-b> $ set -- -a '1 2 3' -b; printf '<%s>\n' "$*" <-a 1 2 3 -b> Wow uh. So. My own expectation was that "1 2 3" would be split up too instead. I'm not decided on which of these makepkg should do. I can submit the implied makepkg patch and scan the project tree for other instances of this. cheers! mar77i
Re: [pacman-dev] Fwd: [arch-general] Removing infinality
Having a mechanism to choose from past transactions and undoing them properly has to be done by hand right now and tends to be tedious and error-prone. There might be ways to mitigate that by parsing the logs and offering actions based on such data, assuming that the logs stay parseable as they are. Would that be considered eg. as a contrib script? cheers! mar77i
[pacman-dev] Fwd: [arch-general] Removing infinality
...actually, would a mechanism like beneath implemented natively in pacman be worth a feature request? cheers! mar77i -- Forwarded message -- From: Martin Kühne Date: Tue, Sep 27, 2016 at 2:46 PM Subject: Re: [arch-general] Removing infinality To: General Discussion about Arch Linux Just a thought. If you find the excerpt in the pacman logs where you did the transaction got you into this mess, you might be able to reverse just that without risking too much for the current install and save you a complete reinstall. Ignoring dependencies is then not so bad, because you then just install the packages again that were uninstalled to get you into this. cheers! mar77i
Re: [pacman-dev] [RFC, PATCHES]: Very preliminary work towards clean build with clang -Weverything
All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use. All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces. (ISO 9899:1999, 7.1.3) Don't use such identifiers. As a matter of fact, typedefs, struct names and function names fall under this terminology. Despite the fact that the compiler accepts leading underscores, per standard they are explicitly discouraged. So, what we should consider is to move _alpm_errno_t along with all other names in the source tree away from leading underscores. Their visibility should be controlled by the presence of a static keyword, -fvisibility and such instead. You might want to write a sed script for this, and it looks like a major invasion into the codebase. The last word is with the developers, though, hence I'm not sure this is going to be accepted for traditional reasons. cheers! mar77i
