Re: [arch-general] [arch-dev-public] Changing compilation flags

[Evangelos Foutras via arch-general]

On 7 July 2017 at 19:17, Jordan Glover 
wrote:

> I'm surprised as it seemed to me that Daniel took it for granted that
> patch like that will get accepted. Anyway it's hard for an outsider to
> successfully submit anything to big upstream project. I hope you'll be more
> lucky if/when you decide to upstream your pie/ssp patches.
>

The SSP/PIE patch is a bit of a hack and is specific to Arch and the
architectures we support. As mentioned in the commit message, it's a
temporary fix until upstream makes those parameters configurable at
compile-time (or a better solution is found). This means it's not
upstreamable.


> It would be nice if makepkg have some conditionals i.e. :
>
> if cc=clang then
> cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack
> -fsanitize=cfi -fvisibility=hidden
>
> if cc=gcc then
> cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check
>

There are multiple ways the compiler can be selected; two of them are: 1)
exporting CC/CXX in the PKGBUILD and 2) the project's configure script
picking one of the available compilers. makepkg can't realistically know
which compiler is going to be used and thus must have only one set of flags
that is supported by both GCC and Clang.

On 7 July 2017 at 19:17, Jordan Glover 
wrote:

> I'm surprised as it seemed to me that Daniel took it for granted that
> patch like that will get accepted. Anyway it's hard for an outsider to
> successfully submit anything to big upstream project. I hope you'll be more
> lucky if/when you decide to upstream your pie/ssp patches.
>
> It would be nice if makepkg have some conditionals i.e. :
>
> if cc=clang then
> cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack
> -fsanitize=cfi -fvisibility=hidden
>
> if cc=gcc then
> cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check
>
>  Original Message 
> Subject: Re: [arch-dev-public] Changing compilation flags
> From: evange...@foutrelis.com
> To: Jordan Glover 
> arch-general@archlinux.org , Daniel Micay <
> danielmi...@gmail.com>, Public mailing list for Arch Linux development <
> arch-dev-pub...@archlinux.org>, jo...@netbsd.org
>
> Thanks for trying to push the change upstream. I"m sorry they weren"t
> very receptive of it; your responses were on point and further
> clarified our intended use case.
>
> I"m not sure what Joerg meant by saying "Arch Linux can"t do
> compiler-specific flag definitions". He could be thinking of a regular
> project that can check for supported compiler flags, but AFAIK that
> concept is not readily transferable to distro-wide flags. (Even if it
> was, it would also apply to stack-check and friends so it"s a weak
> argument in my opinion.)
>
> At the end of the day, it"s not an issue to carry this patch
> downstream in Arch. :-)
>
>
>

Re: [arch-general] Poor performance wifi BCM4331 - MacBookPro

[Bradley Klee via arch-general]

Hi Maykel,

Don't confuse me for an expert, but I have been dealing with Broadcom issue on 
a recycled dell laptop.

According to the wiki, Broadcom devices have been historically difficult for 
Linux developers to work with. Replacement hardware could be a better option, 
but in the meantime wireless seems to work in my case using the "dkms" package. 

If Installing this you should read the following:

https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support

Adding a dkms package will change your update procedure, sometimes making 
additional work for pacman. 

In case you didn't find the MacBook-specific wiki page, which also mentions 
Broadcom issues, try looking around here:

https://wiki.archlinux.org/index.php/MacBookPro11,x
https://wiki.archlinux.org/index.php/MacBookPro7,1

Also, this topic is on numerous BBS threads, so you may want to try a google 
search, such as: "broadcom macbook 4331 site:bbs.archlinux.org" .

Hope this helps,

Brad




On Jul 7, 2017, at 2:34 PM, Maykel Franco via arch-general 
 wrote:

> Hi, I have install archlinux in my MacBookPro with this wifi hardware:
> 
> Broadcom Limited BCM4331 802.11a/b/g/n
> 
> In the wiki arch:
> 
> https://wiki.archlinux.org/index.php/broadcom_wireless
> 
> BCM4331 noticed to have problems with b43-firmware-classic. Use
> b43-firmware for this card instead.
> 
> I probed with b43-firmware-classic community and b43-firmware yaourt
> and both poor performance... 900k bandwith and microcuts.
> 
> I will try broadcom-wl because I see in this link:
> 
> https://www.reddit.com/r/archlinux/comments/5qlyfm/cant_get_wifi_with_broadcom_bcm4331_chip/
> 
> Too I see broadcom-wl-dkms but I have the default kernel no dkms.
> 
> Somebody with the same problem??

Re: [arch-general] Poor performance wifi BCM4331 - MacBookPro

[ProgAndy]

Am 07.07.2017 um 21:34 schrieb Maykel Franco via arch-general:

[...]

I will try broadcom-wl because I see in this link:

https://www.reddit.com/r/archlinux/comments/5qlyfm/cant_get_wifi_with_broadcom_bcm4331_chip/

Too I see broadcom-wl-dkms but I have the default kernel no dkms.

Somebody with the same problem??


Hi,

DKMS is not a kernel version, but a method to install kernel modules 
from source code


https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support

[arch-general] Poor performance wifi BCM4331 - MacBookPro

[Maykel Franco via arch-general]

Hi, I have install archlinux in my MacBookPro with this wifi hardware:

Broadcom Limited BCM4331 802.11a/b/g/n

In the wiki arch:

https://wiki.archlinux.org/index.php/broadcom_wireless

BCM4331 noticed to have problems with b43-firmware-classic. Use
b43-firmware for this card instead.

I probed with b43-firmware-classic community and b43-firmware yaourt
and both poor performance... 900k bandwith and microcuts.

I will try broadcom-wl because I see in this link:

https://www.reddit.com/r/archlinux/comments/5qlyfm/cant_get_wifi_with_broadcom_bcm4331_chip/

Too I see broadcom-wl-dkms but I have the default kernel no dkms.

Somebody with the same problem??

Re: [arch-general] [arch-dev-public] Changing compilation flags

[Jordan Glover via arch-general]

I'm surprised as it seemed to me that Daniel took it for granted that patch 
like that will get accepted. Anyway it's hard for an outsider to successfully 
submit anything to big upstream project. I hope you'll be more lucky if/when 
you decide to upstream your pie/ssp patches.
It would be nice if makepkg have some conditionals i.e. :
if cc=clang then
cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack 
-fsanitize=cfi -fvisibility=hidden
if cc=gcc then
cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check

>  Original Message 
> Subject: Re: [arch-dev-public] Changing compilation flags
> From: evange...@foutrelis.com
> To: Jordan Glover 
> arch-general@archlinux.org , Daniel Micay 
> , Public mailing list for Arch Linux development 
> , jo...@netbsd.org
> Thanks for trying to push the change upstream. I"m sorry they weren"t
> very receptive of it; your responses were on point and further
> clarified our intended use case.
> I"m not sure what Joerg meant by saying "Arch Linux can"t do
> compiler-specific flag definitions". He could be thinking of a regular
> project that can check for supported compiler flags, but AFAIK that
> concept is not readily transferable to distro-wide flags. (Even if it
> was, it would also apply to stack-check and friends so it"s a weak
> argument in my opinion.)
> At the end of the day, it"s not an issue to carry this patch
> downstream in Arch. :-)

Re: [arch-general] [arch-dev-public] Changing compilation flags

[Evangelos Foutras via arch-general]

On 7 July 2017 at 16:39, Jordan Glover  wrote:
> FYI clang devs don't want to take 1 line patch adding another no-op flag
> upstream.
> https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html

Thanks for trying to push the change upstream. I'm sorry they weren't
very receptive of it; your responses were on point and further
clarified our intended use case.

I'm not sure what Joerg meant by saying "Arch Linux can't do
compiler-specific flag definitions". He could be thinking of a regular
project that can check for supported compiler flags, but AFAIK that
concept is not readily transferable to distro-wide flags. (Even if it
was, it would also apply to stack-check and friends so it's a weak
argument in my opinion.)

At the end of the day, it's not an issue to carry this patch
downstream in Arch. :-)

Re: [arch-general] tmux/systemd: tmux user service exits on detach/logout

[David Runge]

Hey Andre Vitor,

On 2017-07-07 10:53:32 (-0300), André Vitor de Lima Matos wrote:
> Not sure if related, but try setting KillUserProcesses=no in
> /etc/systemd/logind.conf
> 
> https://askubuntu.com/questions/802189/how-to-run-tmux-screen-with-systemd-230
That is an Arch default setting (commented variables in the systemd
config files reflect compile-time defaults).

Check with:
$ loginctl show-session|grep Kill

Also: The issue at hand is not a logind problem (at least not a
login/logout issue), as far as I can see, as it happens on detach from
tmux (but only sometimes).
That one often times disconnects from the machine after a tmux detach
doesn't help to figure out why it happens unfortunately :>

Thanks anyhow!

Best,
David


-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [arch-general] tmux/systemd: tmux user service exits on detach/logout

[André Vitor de Lima Matos via arch-general]

Not sure if related, but try setting KillUserProcesses=no in
/etc/systemd/logind.conf

https://askubuntu.com/questions/802189/how-to-run-tmux-screen-with-systemd-230

-- 
André Vitor de Lima Matos



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] Changing compilation flags

[Jordan Glover via arch-general]

FYI clang devs don't want to take 1 line patch adding another no-op flag 
upstream.
https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html

>  Original Message 
> Subject: Re: [arch-dev-public] Changing compilation flags
> From: arch-dev-pub...@archlinux.org
> To: Evangelos Foutras 
> Daniel Micay , Public mailing list for Arch Linux 
> development 
> On 5 July 2017 at 19:51, Daniel Micay  wrote:
> So I think it would be a good idea to flip the default to -z,now in the
> linker if we"re going to use -fno-plt. I think they"d take a patch for
> that upstream. Clang issue could be avoided with a 1 line patch adding
> another no-op flag and they"d take that upstream. It"s harmless to use
> the slower lazy linking calling convention when -fno-plt is passed.

[arch-general] tmux/systemd: tmux user service exits on detach/logout

[David Runge]

Hey all,

I got a very strange behavior with tmux and systemd on my server and
maybe someone knows a way around it.

The way I start tmux is as follows:
Setting TMUX_TMPDIR to my user's XDG_RUNTIME_DIR and starting tmux in a
systemd user service [1]. I do the same for other things, such as
weechat [2]. They both use the same tmux.conf [3].
Lingering is activated for my user, so the enabled user services will
start with the system and stay running, even when it's disconnected...
in theory (and this used to work very well, without a problem for
years).

With some changes in systemd however, this seems to fail now, and I
can't seem to find the reason why. Tmux just exits with "server lost"
once I do a detach.
At first I could only observe this behavior when I had a shared ssh
session to the server (so I thought), that I then quit, or when I
attached and detached the tmux session quickly.
Now I'm getting this nearly every time I detach from the tmux session!

I tried several things by now, and it doesn't seem to make any
difference:
- using legacy cgroups [4], because of maybe being affected by this [5]
- switching to single connections instead of shared connections for ssh
  (lowered the amount of random tmux quits!)
- using hardened kernel (just to try another one)
- logging a tmux session, without getting any output, that would
  explain, why this happens
- crossing fingers (actually helps, because the bug seems completely
  random ;/ )
- using a system scope unit (tmux@username) [6], getting the same results
- downgrading tmux to >=2.3 (no difference)
- downgrading systemd to <=233-7 (seems to happen less frequently)

For some awkward reason, it seems to have worked again for a short time,
when Arch first switched to systemd 233 a few days back [6], but ever
since it moved to systemd-stable [7], the problem is back (and even
worse than before). Me thinking that might only be due to a "less
frequent occurence" though.

I'm just wondering, how to solve this. Maybe someone has a great idea to
share? It's getting beyond annoying by now and I can't seem to find out,
if it's tmux, systemd or some kernel problem... or all of them together.

David


P.S.: Doesn't seem to happen with screen. I don't want to adapt
everything to screen now though ;)


[1] https://git.sleepmap.de/software/uenv.git/tree/user/tmux.service
[2] https://git.sleepmap.de/software/uenv.git/tree/user/weechat.service
[3] https://git.sleepmap.de/config/dotfiles.git/tree/.tmux.conf
[4] 
https://www.freedesktop.org/software/systemd/man/systemd.html#systemd.legacy_systemd_cgroup_controller
[5] https://github.com/systemd/systemd/issues/3388
[6] https://wiki.archlinux.org/index.php/Tmux#Autostart_with_systemd
[7] 
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd=e0ee38b0c90d0a0da7baad4f472f38dd451326a6
[8] https://github.com/systemd/systemd-stable


-- 
https://sleepmap.de


signature.asc
Description: PGP signature