[arch-general] PHP 7.1.0 not compatible with latest stable ownCloud in [community]

[Chi-Hsuan Yen via arch-general]

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

Re: [arch-general] valgrind - memory exclusion files on the fritz?

[Chi-Hsuan Yen via arch-general]

On Thu, Nov 24, 2016 at 8:45 AM, David C. Rankin
<drankina...@suddenlinkmail.com> 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

Re: [arch-general] valgrind - memory exclusion files on the fritz?

[Chi-Hsuan Yen via arch-general]

On Wed, Nov 23, 2016 at 2:46 PM, David C. Rankin
<drankina...@suddenlinkmail.com> 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?

[Chi-Hsuan Yen via arch-general]

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] Cannot no longer resolve local hostname with the new nsswitch.conf

[Chi-Hsuan Yen via arch-general]

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] Cannot no longer resolve local hostname with the new nsswitch.conf

[Chi-Hsuan Yen via arch-general]

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
> <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:
>
> 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

[Chi-Hsuan Yen via arch-general]

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=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

[Chi-Hsuan Yen via arch-general]

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=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a
>

Sorry, the title should be: "Can no longer resolve local hostname with the
new nsswitch.conf"

[arch-general] Cannot no longer resolve local hostname with the new nsswitch.conf

[Chi-Hsuan Yen via arch-general]

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=f1cd9f7fb4cdf7617a1b875e14be212733f9c67a

Re: [arch-general] Implement sql/sqlite database for pacman local database

[Chi-Hsuan Yen via arch-general]

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

Re: [arch-general] bitcoin-qt out-of-date

[Chi Hsuan Yen via arch-general]

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] bitcoin-qt out-of-date

[Chi Hsuan Yen via arch-general]

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] Is ncurses in Arch Linux out-dated?

[Chi Hsuan Yen via arch-general]

Thanks Maarten, now I know my next step :)

On Sun, Aug 21, 2016 at 10:14 PM, Maarten de Vries <maar...@de-vri.es>
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
>
>