[arch-general] Is ncurses in Arch Linux out-dated?
Hi Archers, ncurses 6.0 is released in 2015/08/08. It has some bugs and part of them are fixed. For example, I was just hit by http://bugs.python.org/issue27323. On bug-ncurses mailing list there are some patch versions. The latest one is 6.0-20160820: http://lists.gnu.org/archive/html/bug-ncurses/2016-08/msg00010.html. If I want to fix the aforementioned Python issue, should Arch Linux 1) Bump the ncurses package to 6.0-20160820, or 2) Just backport the relevant patch For 1), I just need to flag to package out-of-date, for 2), I have to submit a bug and request backporting. Any similar cases in other packages? Best, Yen Chi Hsuan
Re: [arch-general] Is ncurses in Arch Linux out-dated?
Thanks Maarten, now I know my next step :) On Sun, Aug 21, 2016 at 10:14 PM, Maarten de Vries wrote: > > > On 21 August 2016 at 15:40, Chi Hsuan Yen via arch-general < > arch-general@archlinux.org> wrote: > >> Hi Archers, >> >> ncurses 6.0 is released in 2015/08/08. It has some bugs and part of them >> are fixed. For example, I was just hit by http://bugs.python.org/issue27 >> 323. >> On bug-ncurses mailing list there are some patch versions. The latest one >> is 6.0-20160820: >> http://lists.gnu.org/archive/html/bug-ncurses/2016-08/msg00010.html. If I >> want to fix the aforementioned Python issue, should Arch Linux >> >> 1) Bump the ncurses package to 6.0-20160820, or >> 2) Just backport the relevant patch >> >> For 1), I just need to flag to package out-of-date, for 2), I have to >> submit a bug and request backporting. >> > > In general Arch Linux packagers don't really do back porting. They try to > stay as close to upstream releases as possible. So the best thing you can > do is flag the package as out-of-date. If you don't want to wait for the > packagers, you can use ABS [1] to download the PKGBUILD and modify it to to > your need in the mean time. > > [1] https://wiki.archlinux.org/index.php/Arch_Build_System > > Hope this helps, > Maarten de Vries > >
Re: [arch-general] bitcoin-qt out-of-date
On Fri, Sep 2, 2016 at 12:06 AM, Jeroen Mathon via arch-general < arch-general@archlinux.org> wrote: > Some people have projects, or other things that take priority, if you have > a problem then get the git version from the AUR > > On Thu, 1 Sep 2016, 18:01 Diego Viola via arch-general, < > arch-general@archlinux.org> wrote: > > > On Thu, Sep 1, 2016 at 12:53 PM, Doug Newgard > > wrote: > > > On Thu, 1 Sep 2016 12:42:24 -0300 > > > Diego Viola via arch-general wrote: > > > > > >> Hello, > > >> > > >> I flagged this package 10 days ago as out of date and I've been trying > > >> to contact the maintainer about it, with no response. > > >> > > >> https://www.archlinux.org/packages/community/x86_64/bitcoin-qt/ > > >> > > >> Is there any problem with updating this? Any reasons for the delay or > > >> lack of response? > > >> > > >> Thanks, > > >> Diego > > > > > > Oh no, 10 days. > > > > > > Seriously? > > > > Other packages get updated much quicker, are you just going to put the > > blame the users on this one too? > > > > Diego > > > I have a similar question. If I have a working PKGBUILD for an out-dated package, and I have tested all other packages that depends on it, can I open "pull requests" to get the updated PKGBUILD into Arch Linux? To be more specific, I'm talking about youtube-dl. I'm currently one of youtube-dl maintainers, and I hope Arch users can always get the latest version with pacman. Unfortunately, the package in [community] gets updates slow in comparison with how youtube-dl releases new versions. AUR works, while it's not an ideal solution, as VCS packages are not updated automatically. (I guess there are some helpers for that, but still not ideal for this case) Best, Yen Chi Hsuan
Re: [arch-general] bitcoin-qt out-of-date
On Fri, Sep 2, 2016 at 12:32 AM, Antonio Rojas wrote: > Chi Hsuan Yen via arch-general wrote: > > > To be more specific, I'm talking about youtube-dl. I'm currently one of > > youtube-dl maintainers, and I hope Arch users can always get the latest > > version with pacman. Unfortunately, the package in [community] gets > > updates slow in comparison with how youtube-dl releases new versions. AUR > > works, while it's not an ideal solution, as VCS packages are not updated > > automatically. (I guess there are some helpers for that, but still not > > ideal for this case) > > > > Best, > > > > Yen Chi Hsuan > > youtube-dl gets a new release every two days, I hope you're not expecting > packagers to keep up with that. Current package is one month old, that > doesn't look too bad to me, especially considering that its maintainer is > currently inactive. > Yep that's my expectation. There were several times, that a new version with important fixes (fix for YouTube downloading, etc.) was released, and lots of people came to our issue tracker for "broken" YouTube downloading because the Arch version was not updated yet. As a result, I hope Arch can keep it updated. Of course users can also use our own updater or AUR. I just feel the official package integrates with the system better. For example it updates with `pacman -Syu`. *NOTE* I'm not blaming anyone. I just hope that I can contribute something to Arch, so I'm asking possible approaches here. I know it's a burden to update a package so often, so I'm not requesting anything, just discussing. Best, Yen Chi Hsuan
Re: [arch-general] bitcoin-qt out-of-date
On Fri, Sep 2, 2016 at 2:39 AM, Kwang Moo Yi via arch-general < arch-general@archlinux.org> wrote: > On 01/09/16 20:32, Chi Hsuan Yen via arch-general wrote: > >> Yep that's my expectation. There were several times, that a new version >> with important fixes (fix for YouTube downloading, etc.) was released, and >> lots of people came to our issue tracker for "broken" YouTube downloading >> because the Arch version was not updated yet. >> > > In this case, wouldn't it suite better to be in the AUR always? >From "Rules of submission" section on Arch Wiki: [1] Check the official package database <https://www.archlinux.org/packages/> for the package. If *any version* of it exists, *do not* submit the package. If the official package is out-of-date, flag it as such. I'm not sure whether my case is an exception to this rule or not. > It would be practically impossible that a package to be reviewed and > signed so often. Also, my personal expectation on the official packages is > to be more stable than that. > Unlike other programs, most new youtube-dl bugs come from changed websites, not changes in youtube-dl itself. For example if YouTube changes how videos are delivered, we have to update relevant codes and ask users to update as soon as possible. > > Cheers, > Kwang > [1] https://wiki.archlinux.org/index.php/Arch_User_Repository
Re: [arch-general] Implement sql/sqlite database for pacman local database
On Sat, Oct 22, 2016 at 1:54 AM, Robin via arch-general < arch-general@archlinux.org> wrote: > Hi, > > > I was curious why does 'pacman -Q' operations took longer than 'apt' > > counterparts. > Sounds interesting but I have a few question about how did you measure > this and how big the difference is. (Shouldn't be that big). Would be great > if you provide more information on the comparability of you systems and the > tools you used for tracing. > Maybe there are other reasons why it is slow on your installation ? > > > For long term pacman development road map, it would be better to use > > single sql based database for tracking locally installed packages > > instead of keeping directories of every installed packages. > I am not sure if a sql based database would be a good solution if you > where right. It adds much more complexity and also a dependencies on $SQL > backend. For me as a semi-professional arch user this would be worse than a > maybe "not that fast" package dB querying. > > Regards, > Robin Sometimes I have a similar problem, too. When the system just boots up, or I just exploits my disk (for example building Firefox), pacman-related files are moved out of the disk cache, so it needs some time to read them all from the disk. Here's a simple performance test: $ sudo -v && time pacman -Q linux && sudo sync && sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches && time pacman -Q linux [sudo] password for yen: linux 4.8.3-1 pacman --color=auto -Q linux 0.00s user 0.00s system 2% cpu 0.121 total 3 linux 4.8.3-1 pacman --color=auto -Q linux 0.00s user 0.01s system 0% cpu 1.229 total The difference is more than 10 times. I use a 5-year-old HDD. I guess on even older machines things are worse. Regards, Yen Chi Hsuan
[arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf
Hi Arch enthuasiasts, With testing/filesystem 2016.11-2, I can no longer use my local hostname to acess services on the local machine. For example: $ hostname PC12574 $ ping PC12574 ping: PC12574: Name or service not known Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: line in nsswitch.conf back to the old configuration "files resolve mymachines myhostname", or remove the [!UNAVAIL=return] part from this line, ping works fine: $ ping PC12574 PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 ttl=64 time=0.025 ms 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 ttl=64 time=0.078 ms Is it a bug? Or such a usage is just a non-standard coincidence? Thanks for any help. Yen Chi Hsuan [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/filesystem&id=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a
Re: [arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf
On Tue, Nov 8, 2016 at 8:37 PM, Chi-Hsuan Yen wrote: > Hi Arch enthuasiasts, > > With testing/filesystem 2016.11-2, I can no longer use my local hostname > to acess services on the local machine. For example: > > $ hostname > PC12574 > > $ ping PC12574 > ping: PC12574: Name or service not known > > Seems changes in nsswitch.conf [1] does the effect. If I change the hosts: > line in nsswitch.conf back to the old configuration "files resolve > mymachines myhostname", or remove the [!UNAVAIL=return] part from this > line, ping works fine: > > $ ping PC12574 > PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes > 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 > ttl=64 time=0.025 ms > 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 > ttl=64 time=0.078 ms > > Is it a bug? Or such a usage is just a non-standard coincidence? > > Thanks for any help. > > Yen Chi Hsuan > > [1] https://git.archlinux.org/svntogit/packages.git/commit/ > trunk?h=packages/filesystem&id=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a > Sorry, the title should be: "Can no longer resolve local hostname with the new nsswitch.conf"
Re: [arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf
On Tue, Nov 8, 2016 at 9:11 PM, Jan Alexander Steffens via arch-general < arch-general@archlinux.org> wrote: > On Tue, Nov 8, 2016 at 1:37 PM Chi-Hsuan Yen via arch-general < > arch-general@archlinux.org> wrote: > > > Hi Arch enthuasiasts, > > > > With testing/filesystem 2016.11-2, I can no longer use my local hostname > to > > acess services on the local machine. For example: > > > > $ hostname > > PC12574 > > > > $ ping PC12574 > > ping: PC12574: Name or service not known > > > > Seems changes in nsswitch.conf [1] does the effect. If I change the > hosts: > > line in nsswitch.conf back to the old configuration "files resolve > > mymachines myhostname", or remove the [!UNAVAIL=return] part from this > > line, ping works fine: > > > > $ ping PC12574 > > PING PC12574(PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0)) 56 data bytes > > 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=1 > ttl=64 > > time=0.025 ms > > 64 bytes from PC12574 (fe80::ae22:bff:fe77:e20b%enp3s0): icmp_seq=2 > ttl=64 > > time=0.078 ms > > > > Is it a bug? Or such a usage is just a non-standard coincidence? > > > > Thanks for any help. > > > > Yen Chi Hsuan > > > > [1] > > > > https://git.archlinux.org/svntogit/packages.git/commit/ > trunk?h=packages/filesystem&id=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a > > > This is an effect of putting "myhostname" at the end of the list. If you > don't want your network to be able to override lookup for your hostname > move "myhostname" to after "files". > > Thanks for the solution! Maybe it should be the default? I see https://bugs.archlinux.org/task/51709 changed nsswitch.conf to the current settings. > It seems this only happens when you're part of a domain. AFAICT resolve/dns > won't ask upstream for unqualified names. > How to check whether I'm in a domain or not? Here's my /etc/resolv.conf: $ cat /etc/resolv.conf # Generated by resolvconf nameserver 8.8.8.8 And another seemingly related command: $ hostname --domain (none) Best, Yen Chi Hsuan
Re: [arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf
On Tue, Nov 8, 2016 at 10:02 PM, Damjan Georgievski via arch-general <
arch-general@archlinux.org> wrote:
> On 8 November 2016 at 13:37, Chi-Hsuan Yen via arch-general
> wrote:
> > Hi Arch enthuasiasts,
> >
> > With testing/filesystem 2016.11-2, I can no longer use my local hostname
> to
> > acess services on the local machine. For example:
> >
> > $ hostname
> > PC12574
> >
> > $ ping PC12574
> > ping: PC12574: Name or service not known
> >
> > Seems changes in nsswitch.conf [1] does the effect. If I change the
> hosts:
> > line in nsswitch.conf back to the old configuration "files resolve
> > mymachines myhostname", or remove the [!UNAVAIL=return] part from this
> > line, ping works fine:
>
> do you have systemd-resolved running?
> what does `getent -s resolve hosts ` return?
>
> --
> damjan
>
Here it is:
$ getent -s resolve hosts $(hostname)
[2] $ systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service;
disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
http://www.freedesktop.org/wiki/Software/systemd/resolved
http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
The getent command prints nothing and exits with 2. And from strace, it
asks Google DNS, which is set in my /etc/resolv.conf:
$ strace -f getent -s resolve hosts "$(hostname)" |& grep recvfrom
recvfrom(6, "^\236\201\203\0\1\0\0\0\1\0\0\17PC12574\0\0\34\0"..., 1024, 0,
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")},
[28->16]) = 108
recvfrom(6, "\314d\201\203\0\1\0\0\0\1\0\0\17PC12574\0\0\1\0"..., 1024, 0,
{sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")},
[28->16]) = 108
Is it normal?
Best,
Yen Chi Hsuan
Re: [arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf
On Wed, Nov 9, 2016 at 1:53 AM, Damjan Georgievski via arch-general < arch-general@archlinux.org> wrote: > On 8 November 2016 at 18:43, Patrick Burroughs (Celti) via > arch-general wrote: > > On Tue, 8 Nov 2016 18:01:32 +0100 > > Damjan Georgievski via arch-general wrote: > > > >> > $ getent -s resolve hosts $(hostname) > >> > >> this should fail since you don't have the resolved service running. > > > > nss-resolve will chainload nss-dns when systemd-resolved is not running > > (see `man 8 nss-resolve`). > > ah right, that fallback should be removed *in the future* and I was > under the impression it already happened > > https://github.com/systemd/systemd/commit/344874fcd0a3fc1f9bc6cdf34ecaf5 > 37c10a3ad3 > > > > > -- > damjan > getent -s dns hosts $(hostname) also returns 2 getent -s myhostname hosts $(hostname) gives reasonable results: fe80::ae22:bff:fe77:e20b NEWSLAB-PC12574 fe80::800:27ff:fe00:0 NEWSLAB-PC12574 The package testing/systemd is the latest r232. My machine has been online for half a month. Should I reboot to use the latest systemd? By the way, from your commit, seems r232 has fixed it? Many thanks, Yen Chi Hsuan
Re: [arch-general] valgrind - memory exclusion files on the fritz?
On Wed, Nov 23, 2016 at 2:26 PM, David C. Rankin
wrote:
> All,
>
> valgrind is reporting an additional allocation and free along with and
> additional 1M of memory used. Below, 11 bytes should be allocated and freed.
> Instead valgrind reports 1035 bytes. (it's worse if you use strdup). For
> example:
>
> #include
> #include
> #include
>
> enum { MAXC = 16 };
>
> int main (void) {
>
> char buf[] = "0123456789";
> size_t len = strlen (buf);
> char *s = NULL;
>
> s = malloc (len + 1);
> snprintf (s, len + 1, "%s", buf);
>
> printf (" s : %s\n", s);
>
> free (s);
>
> return 0;
> }
>
> The report from valgrind:
>
> valgrind ./bin/valgrindchk
> ==3917== Memcheck, a memory error detector
> ==3917== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==3917== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==3917== Command: ./bin/valgrindchk
> ==3917==
> s : 0123456789
> ==3917==
> ==3917== HEAP SUMMARY:
> ==3917== in use at exit: 0 bytes in 0 blocks
> ==3917== total heap usage: 2 allocs, 2 frees, 1,035 bytes allocated
> ==3917==
> ==3917== All heap blocks were freed -- no leaks are possible
> ==3917==
> ==3917== For counts of detected and suppressed errors, rerun with: -v
> ==3917== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> Anybody else experience this problem? Anybody got a fix? I don't find
> anything valgrind related with a cursory search, did a patch get missed with
> the latest build?
>
> --
> David C. Rankin, J.D.,P.E.
In glibc, printf calls malloc. See
http://stackoverflow.com/questions/6743034/does-fprintf-use-malloc-under-the-hood
Re: [arch-general] valgrind - memory exclusion files on the fritz?
On Wed, Nov 23, 2016 at 2:46 PM, David C. Rankin wrote: > On 11/23/2016 12:31 AM, Chi-Hsuan Yen via arch-general wrote: >> In glibc, printf calls malloc. See >> http://stackoverflow.com/questions/6743034/does-fprintf-use-malloc-under-the-hood > > Yes, > > That's not the point. There is generally a know exclusion file that covers > the memory used by fprintf, etc.. The reporting of the allocation and free by > fprintf (if that is indeed the case here) should not be reported by valgrind. > > The same code run on 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET > 2016 x86_64 GNU/Linux and on SuSE: > > > valgrind ./bin/valgrindchk > ==1974== Memcheck, a memory error detector > ==1974== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==1974== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info > ==1974== Command: ./bin/valgrindchk > ==1974== > s : 0123456789 > ==1974== > ==1974== HEAP SUMMARY: > ==1974== in use at exit: 0 bytes in 0 blocks > ==1974== total heap usage: 1 allocs, 1 frees, 11 bytes allocated > ==1974== > ==1974== All heap blocks were freed -- no leaks are possible > ==1974== > ==1974== For counts of detected and suppressed errors, rerun with: -v > ==1974== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) > > Something is wrong with the Arch package. > > -- > David C. Rankin, J.D.,P.E. As far as I know it's impossible (yet) to skip specific functions in memory usage counters. Only memory leak reports can be filtered. And things may be different on SuSE and Arch as they ship with different glibc versions and/or patches. Best, Yen, Chi-Hsuan
Re: [arch-general] valgrind - memory exclusion files on the fritz?
On Thu, Nov 24, 2016 at 8:45 AM, David C. Rankin wrote: > On 11/23/2016 08:49 AM, Chi-Hsuan Yen via arch-general wrote: >> As far as I know it's impossible (yet) to skip specific functions in >> memory usage counters. Only memory leak reports can be filtered. And >> things may be different on SuSE and Arch as they ship with different >> glibc versions and/or patches. >> >> Best, >> >> Yen, Chi-Hsuan > > I have a couple of old arch boxes I cranked up just to test: > > $ uname -a > Linux providence 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 08:15:06 UTC 2012 i686 > GNU/Linux > > $ valgrind ./bin/valgrindchk > ==7060== Memcheck, a memory error detector > ==7060== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==7060== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==7060== Command: ./bin/valgrindchk > ==7060== > s : 0123456789 > ==7060== > ==7060== HEAP SUMMARY: > ==7060== in use at exit: 0 bytes in 0 blocks > ==7060== total heap usage: 1 allocs, 1 frees, 11 bytes allocated > ==7060== > ==7060== All heap blocks were freed -- no leaks are possible > ==7060== > ==7060== For counts of detected and suppressed errors, rerun with: -v > ==7060== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > and a second old arch box: > > $ uname -a > Linux nirvana 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 > GNU/Linux > > $ valgrind ./bin/valgrindchk > ==3481== Memcheck, a memory error detector > ==3481== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==3481== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==3481== Command: ./bin/valgrindchk > ==3481== > s : 0123456789 > ==3481== > ==3481== HEAP SUMMARY: > ==3481== in use at exit: 0 bytes in 0 blocks > ==3481== total heap usage: 1 allocs, 1 frees, 11 bytes allocated > ==3481== > ==3481== All heap blocks were freed -- no leaks are possible > ==3481== > ==3481== For counts of detected and suppressed errors, rerun with: -v > ==3481== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) > > Both boxes show the correct valgrind behavior. So sometime (I don't know > when), something has changed in the way valgrind is packaged or patched. I > have some old ABS backups I'll take a look at and see if anything is apparent. > > The whole reason this jumped out at me is I know this used to work correctly > on Arch which incorporated the proper exclusion files up to at least valgrind > 3.10-0 as shown above. > > -- > David C. Rankin, J.D.,P.E. OK I found the cause of the extra malloc() call. Since glibc 2.23 printf uses malloc instead of mmap to allocate file buffers. If you want to keep the old behavior, keep the old glibc. See https://sourceware.org/bugzilla/show_bug.cgi?id=16734 Best, Yen, Chi-Hsuan
[arch-general] PHP 7.1.0 not compatible with latest stable ownCloud in [community]
Hi Arch enthusiasts, I've just upgraded to testing/php 7.1.0-2. Now my ownCloud installation only displays a short notice on its index.php: This version of ownCloud is not compatible with PHP 7.1. You are currently running 7.1.0. Please use at least ownCloud 9.2.0. However, seems ownCloud 9.2 is still far away to go: https://github.com/owncloud/core/milestone/76, and php 7.1 is not yet fully supported: https://github.com/owncloud/core/issues/26764. I guess I need to leave a loud message to Arch developers and prevent php 7.1.0 from entering [extra]. What's the best way? Open a bug on Flyspray? Thanks for any input! Best, Yen, Chi-Hsuan
