Re: [arch-general] efibootmgr doesn't change boot order!

[Maarten de Vries via arch-general]

Hey,

On 28-12-2020 12:12, Peter K Haokip wrote:

thanks for the reply,
I am able to change the boot order from the BIOS menu.  It works 
A-okay from there, I am trying to accomplish that with efibootmgr.


If you're unlucky, maybe the motherboard firmware prevents you from 
doing that. You could fall back to adding chain-load entries for grub in 
that case, to have grub start the next bootloader.



could you cite any link where I could read about it in details ? where 
the bootx64.efi file will be stored if I install it in NOT IN PORTABLE 
mode(?)?  cuz that would help me know whether the grub is installed in 
portable or none portable mode.


You can add boot entries for any EFI executable on the EFI system 
partition, regardless of the name. These boot entries are stored on 
non-volatile storage on the motherboard. Normally, grub-install takes 
care of this, and the binary is installed as `efi/grub/grub.efi`. All 
you need to do is not pass `--removable` to grub-install.


You would install a bootloader as `efi/boot/bootx64.efi` only if you 
want to create a bootable USB stick, or if your motherboards UEFI 
implementation is so broken that that's the only thing that works.


Also, would be nice if you could provide  any source where I can read 
about how I make my motherboard detect regular boot entries (instead 
of the /Efi/boot/bootx64.efi)



You can find everything in the specifications if you dig deep enough:

https://uefi.org/specifications

See in particular section 3.5.1.1 on "Removable Media Boot Behavior" of 
the "UEFI Specification Version 2.8":


https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf


Regards,

-- Maarten



thanks,


On Mon, 28 Dec 2020, 15:45 Maarten de Vries, > wrote:


On 28-12-2020 10:42, Peter K Haokip via arch-general wrote:
> I read an forum entry from nearly 6 years ago about am
efibootmgr bug that
> Doesn't let you change the boot order on a multi OS system if
you have arch
> linux as the default OS.  Had some users report this as well in
other
> forums.
> Now i am facing the that problem in my system with arch ubuntu
and windows.
>
> when i change the boot order , it shows the change 'temporarily'
but when i
> restart it boots the default (Arch linux Grub ) and the change
disappears.
>
> I faced this issue last month and gave up on it since I couldn't
find any
> detailed resource on this on the net.
> This list may be my last hope.
>
> If anybody could give some direction , would be much appreciated.
>
> regards,
> khaithang39

Hey,

It could be a motherboard problem. Sadly I've seen more motherboards
with weird bugs in their UEFI implementation than without. You
could try
to change the boot order through the motherboard firmware interface
(often called "the BIOS" even if that isn't technically correct
anymore)
and see if that helps.

Another thing that may have happened is that you installed grub as
portable bootloader. It will be called `efi/boot/bootx64.efi` on
the EFI
system partition if that happened. A bootloader under that name is
auto-detected by the motherboard, even if you didn't add a boot entry
for it manually. Perhaps your motherboard always favors such
bootloaders
over the normal boot entries.

If this is the case, you could install grub as non-portable
bootloader
by not passing `--removable` to `grub-install`, and then delete
`efi/boot/bootx64.efi`. Alternatively, you might also be able to
configure your motherboard to prefer regular boot entries before
running
`bootx64.efi` from that partition.

I hope this helps,

-- Maarten

Re: [arch-general] efibootmgr doesn't change boot order!

[Maarten de Vries via arch-general]

On 28-12-2020 10:42, Peter K Haokip via arch-general wrote:

I read an forum entry from nearly 6 years ago about am efibootmgr bug that
Doesn't let you change the boot order on a multi OS system if you have arch
linux as the default OS.  Had some users report this as well in other
forums.
Now i am facing the that problem in my system with arch ubuntu and windows.

when i change the boot order , it shows the change 'temporarily' but when i
restart it boots the default (Arch linux Grub ) and the  change disappears.

I faced this issue last month and gave up on it since I couldn't find any
detailed resource on this on the net.
This list may be my last hope.

If anybody could give some direction , would be much appreciated.

regards,
khaithang39


Hey,

It could be a motherboard problem. Sadly I've seen more motherboards 
with weird bugs in their UEFI implementation than without. You could try 
to change the boot order through the motherboard firmware interface 
(often called "the BIOS" even if that isn't technically correct anymore) 
and see if that helps.


Another thing that may have happened is that you installed grub as 
portable bootloader. It will be called `efi/boot/bootx64.efi` on the EFI 
system partition if that happened. A bootloader under that name is 
auto-detected by the motherboard, even if you didn't add a boot entry 
for it manually. Perhaps your motherboard always favors such bootloaders 
over the normal boot entries.


If this is the case, you could install grub as non-portable bootloader 
by not passing `--removable` to `grub-install`, and then delete 
`efi/boot/bootx64.efi`. Alternatively, you might also be able to 
configure your motherboard to prefer regular boot entries before running 
`bootx64.efi` from that partition.


I hope this helps,

-- Maarten

Re: [arch-general] Bug with CIFS mount

[Maarten de Vries via arch-general]

On 16-12-2020 14:09, Tasnad Kernetzky via arch-general wrote:

Hi All,

Hi,


I suppose I hit this bug: https://bugs.archlinux.org/task/68963 and it 
seems it is not fully resolved. I didn't request to reopen the bug, 
because I'm not 100% sure it is really the same thing.



The bug you're linking is marked as duplicate of this one: 
https://bugs.archlinux.org/task/68666


That one has been re-opened yesterday, so it seems likely that the 
problem is not solved yet. But you also shouldn't re-open the duplicate 
issue. Judging from the comments on the re-opened issue, an additional 
patch has been sent upstream already.


I hope this helps :)

-- Maarten

Re: [arch-general] "npm" package issues

[Maarten de Vries via arch-general]

On Wed, 4 Nov 2020 at 15:17, Nick Shvelidze via arch-general <
arch-general@archlinux.org> wrote:

> I think running `pacman -Syu --overwrite '/usr/lib/node_modules/*'` is
> safe.
> I have no idea how those files would end up there without using `sudo
> npm install -g`
>

It would be good to also explicitly delete everything not owned by pacman
in /usr/lib/node_modules. Otherwise you run the risk that some old (deleted
upstream) files stick around and possibly cause weird issues.

-- Maarten

Re: [arch-general] Thunderbird 78

[Maarten de Vries via arch-general]

On Tue, 27 Oct 2020 at 23:26, Bjoern Franke via arch-general <
arch-general@archlinux.org> wrote:

> Am 27.10.20 um 23:12 schrieb Javier via arch-general:
> > I really hope not, I prefer to wait than having to build TB on every
> release.  Besides, current version works just fine...
> >
>
> There are also bin-packages so you don't have build it really.
>

True, but it still won't update automatically with `pacman -Syu`. For an
email client, automatic security updates are quite important. Having to
update manually from the AUR would certainly be a downgrade in user
experience.

Anyway, I can't imagine that not a single Arch packager or TU is using
thunderbird.

-- Maarten

Re: [arch-general] Can anyone share experience with "preloader" on Arch (UEFI secure boot)?

[Maarten de Vries via arch-general]

On Thu, 24 Sep 2020 at 14:18, Manuel Reimer 
wrote:

> Hello,
>
> I want to occasionally run Linux on a system which was set up with
> Windows 10 with Bitlocker enabled.
>
> Disabling secure boot for Linux and reenabling it when booting into
> Windows starts to get annoying.
>
> So my idea was to just use "preloader" and add it to the chain of EFI
> binaries to execute. But as Arch gets kernel updates pretty often I am a
> bit worried about getting my MokList corrupted at some time as described
> here:
>
>
> http://blog.rootserverexperiment.de/2013/06/02/moklist-gesemmelt-boot-unmoglich-moklist-corruptet-boot-impossible/
>
> Has anyone ever noticed this problem? How are the hashes stored? If I
> update the kernel, will preloader *replace* the hash in MokList or add a
> new one? How is this MokList stored? Is this flash memory with limited
> write cycles?
>

Depending on how much you actually value the security of secure boot, you
could just add your own DB key (so not a MOK) and sign grub with that key
directly rather than using shim. Grub will then happily load any unsigned
linux kernel. This is a bug in the shim_lock grub module, but even when it
is fixed, you can get grub to ignore secure boot as long as you don't use
the shim_lock module.

If you actually want to prevent unsigned code from running, you should use
shim with a MOK. You only need a single key that you can use to sign your
bootloader and kernel images. By using a key for signing, you don't have to
add any hashes to the MOK database. So there also shouldn't be much risk of
corrupting your MOK database.

-- Maarten

>

Re: [arch-general] dash as default shell?

[Maarten de Vries via arch-general]

On Wed, 17 Jun 2020 at 20:37, David Rosenstrauch  wrote:

>
>
> On 6/17/20 2:18 PM, Piscium via arch-general wrote:
> > Today I set dash as my default shell [1] on two PCs. We will see if I
> > get into trouble.
> >
> > This question was asked years ago but maybe good to ask again. Could
> > dash be made the default shell in Arch?
>
>
> Couldn't you just set it as the default for your user using chsh?
>

I don't think many people will want to use dash as interactive shell. It's
more about running shell scripts with a #!/bin/sh shebang. It is still
possible to do that system wide of course, with a symlink in /usr/local/bin
.

The question whether it makes sense as default /bin/sh on Arch Linux
remains valid though. I personally would be positive towards that change.

-- Maarten

Re: [arch-general] (no subject)

[Maarten de Vries via arch-general]

On Tue, 24 Mar 2020 at 23:51, Robin Martijn  wrote:

> Update: Thanks everyone for helping me think! Finally, I discovered that
> all three of my USB devices were broken. A fourth one finally connected.
> I should've known when dmesg did not see anything at all, that they were
> broken.
>
>
What are the odds.. :) Glad to hear you found the issue though.

-- Maarten

Re: [arch-general] (no subject)

[Maarten de Vries via arch-general]

On Tue, 24 Mar 2020 at 22:57, Andy Pieters 
wrote:

> On Tue, 24 Mar 2020 at 21:38, mick howe via arch-general <
> arch-general@archlinux.org> wrote:
>
> > you have rebooted since update? Every time updates generate a new
> startup?
> >
> >
> I concur: in many cases you need to reboot after doing a kernel update in
> order to recognise devices that were not plugged in before the update
>

Indeed.

To also explain why this happens: the relevant kernal modules hadn't been
loaded yet, and the modules on disk are for the newly upgraded kernel while
you're still running an older kernel. In that case, `pacman -Qi linux` and
`uname -r` will also show different version information.

-- Maarten

Re: [arch-general] Many timers now running at boot. How to make them run later?

[Maarten de Vries via arch-general]

On Thu, 21 Nov 2019 at 21:02, NTS  wrote:

> On Thu, 21 Nov 2019 at 18:13, David C. Rankin
>  wrote:
> >
> > On 11/21/2019 05:53 AM, Christian Hesse wrote:
> > > I've created systemd configuration overlay snippets for this, for
> example
> > > /etc/systemd/system/man-db.timer.d/RandomizedDelaySec.conf:
> > >
> > > [Timer]
> > > RandomizedDelaySec=30min
> > >
> > > Create a file for every timer you want to delay.
> >
> > Thank you Ralph & Christian,
> >
> >   I'll do that. Something to just keep them all from firing when I boot
> would
> > be nice.
>
> Can't you make these services depend on another one which you write to
> start a certain number of minutes after boot?
>
> Regards,
> NTS
>

You could, but if you're going to modify the services anyway, then a
randomized delay seems betters. That way, they are not only delayed, they
are also spread out.

-- Maarten

Re: [arch-general] Unmaintained project with active community fork - what to do with the package?

[Maarten de Vries via arch-general]

On 01-07-2019 21:20, Danila Kiver via arch-general wrote:

Hi all,

please help me in handling the following situation.

The  bash-bats  package ( 
https://www.archlinux.org/packages/community/any/bash-bats )
uses the upstream repository ( https://github.com/sstephenson/bats ), which is 
no longer
maintained by its owner ( https://github.com/sstephenson/bats/issues/150 ).

Looks like the project moved to a community-maintained fork ( 
https://github.com/bats-core/bats-core ),
which already reached version 1.1.0 and includes crucial fixes, while the 
original project
stays untouched for a long while.

What would be the correct approach here: ask the maintainer of  bash-bats  
package to switch
to the active fork, or leave this deprecated package as it is and create an AUR 
package for the fork?

Regards,
Danila Kiver.



Open an issue on the Arch bug tracker with the suggestion to switch to 
the fork. Sounds like a switch makes sense, the maintainer will probably 
agree. If not, you can always add an AUR package anyway.


-- Maarten

Re: [arch-general] steam-native can't find libpcre.so.3, breaks embedded browser

[Maarten de Vries via arch-general]

On Thu, 4 Apr 2019 at 15:40, Giancarlo Razzolini via arch-general
 wrote:
>
> Em abril 4, 2019 0:25 Alexandre Oliveira via arch-general escreveu:
> > It seems like the steam-native package is broken as of March 21,
> > according to this bug report[1].
> >
> > Installing libselinux and pcre seems to fix the issue. I don't know if
> > it's a good idea to write about it here, but I'd like to get this patch
> > mainstreamed, instead of having to install another package to workaround
> > this bug.
> >
> > [1]
> > https://bugs.archlinux.org/task/62095?project=5&string=steam-native-runtime
> >
>
> Hi Alexandre,
>
> As I have just commented on the bug, I cannot reproduce this bug. And I use 
> steam on an
> almost daily basis.
>
> It looks like it's a bug on upstream steam and does not affect all users. 
> Even though we
> can patch things on occasion to fix broken packages, we tend to wait for 
> upstream fixes
> if the issue is not critical or a fix already exists.

Are you sure you're running steam-native? I get the exact same issue
with `steam-native`, while `steam` has a working browser (but some
games have other issues). It seems unlikely to me that steam would
require libpcre.so.3 only for some users but not for others.

While it is definitely a problem caused by upstream, they officially
only support some Ubuntu distributions. There's no guarantee that
steam will solve this on their end.

> Also, the patch you referred to, is not an actual patch, just a package that 
> creates an
> ugly fix, by creating a symlink to libpcre. That's not the right way to fix 
> this issue.

A better fix is mentioned on the steam forum [1] by a WorMzy:
> $ export LD_PRELOAD="/usr/lib/libgio-2.0.so.0:/usr/lib/libglib-2.0.so.0"
> $ steam-native

Apparently those libraries still come from the steam distribution,
even with steam-native, and those pull in libpcre.so.3 and
libselinux.so.1. Preloading the system versions avoids that.

[1] 
https://steamcommunity.com/groups/SteamClientBeta/discussions/0/1848072002764995823/#c1769259642875894556

> Regards,
> Giancarlo Razzolini

Re: [arch-general] Issue linking 32-bit GAS assembly

[Maarten de Vries via arch-general]

Why not let gcc take care of what compiler/assembler and linker to 
invoke with which precise flags:


$ gcc -m32 -o foo filename.s
$ ./foo # great success!

It will probably link to libc without you even asking for it. And if 
that works and you really want to know what linker flags you need, you 
can add -v to make gcc spam you about it.



-- Maarten

(Sent off-list by accident before, sending to the list now.)


On 10/17/18 9:36 PM, Dutch Ingraham wrote:

Hi all:

I'm having a problem linking 32-bit GAS assembly code that references external
C libraries on an up-to-date 64-bit Arch installation.

I have enabled the 32-bit repositories and installed the multilib-devel group
and lib32-glibc. I have updated the library cache with ldconfig and rebooted.

The command to assemble is: .  Assembly
succeeds.

However, when linking using the command


the command fails with:
ld: skipping incompatible /usr/lib/libc.so when searching for -lc
ld: skipping incompatible /usr/lib/libc.a when searching for -lc
ld: cannot find -lc

Note this linker command (or a hierarchy-appropriate one) seems standard, and
succeeds on a 64-bit Debian OS.

There is a fairly recent Forum question (but pre-dating the discontinuance of
i686 support) regarding the same issue at
https://bbs.archlinux.org/viewtopic.php?id=229235 which indicates the command
should be:



This command succeeds, insofar as the linker returns an exit code of 0. However,
running the program (and all other similar programs) fails with "Illegal
instruction (core dumped)." Assembling with debugging symbols and running a
backtrace didn't enlighten me.

Note that changing /lib/ld-linux to /usr/lib32/ld-linux in the command 
immediately
above produces the same result, as confirmed by the output of 

Anyone see something I've missed of have any suggestions?  Thanks.


---

Here is some simple code to test with:


# paramtest2.s - Listing system environment variables
.section .data
output:
.asciz "%s\n"
.section .text
.globl _start
_start:
movl %esp, %ebp
addl $12, %ebp
loop1:
cmpl $0, (%ebp)
je endit
pushl (%ebp)
pushl $output
call printf
addl $12, %esp
addl $4, %ebp
loop loop1
endit:
pushl $0
call exit

Re: [arch-general] libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'

[Maarten de Vries via arch-general]

On 14 February 2018 at 21:32, Kyle  wrote:

> Maarten de Vries ALIANDIKA:
> # ​pacman -Rs $(pacman -Qqdt​)
>
> Unfortunately this will break my system. It's trying to remove git for one
> thing, which is definitely something I need. Not to mention that I
> installed git explicitly, so pacman definitely shouldn't be removing it. I
> can see a whole lot of other explicitly installed packages as well as
> packages that are installed as build dependencies that would also be
> removed using this method, which is unacceptable at least on my system.
>

​This should not be the case. The -d flag to pacman -Q restricts the output
to packages installed as dependency. The -t option restricts it to packages
that are no longer needed by any other package. If that command removes a
package, pacman thinks it's an unneeded dependency.

So my guess is that either you had a typo, or the packages are currently
indeed in pacman's local database as installed as dependency. Check the
output of pacman -Qi for the packages that you think are marked as
explicitly installed (in particular "Install Reason" near the bottom).

Now, considering that this should work (if it does not there are other
problems), I think occasionally doing this manually is fine. Heck, if you
must, put it on a cronjob. But it will probably break your system from time
to time because it may turn out you were actually using packages that
happened to be installed as a dependency. That on it's own is enough reason
for me not to make pacman do it automatically. Regardless of who is lazy
and who is stupid or not.


​P.S.

The -s flag to pacman -R is just there so you get rid of packages that will
be unneeded dependencies after the removal in one go. I actually kinda like
leaving it off an running the command multiple times to see how often I
have to run it before everything is gone. Everybody needs a hobby.
​

Re: [arch-general] libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'

[Maarten de Vries via arch-general]

On 14 February 2018 at 19:35, Eduardo Machado via arch-general <
arch-general@archlinux.org> wrote:

> 2018-02-10 1:55 GMT-02:00 Doug Newgard via arch-general <
> arch-general@archlinux.org>:
>
> > Not gremlins, just an old package that never got cleaned out. Pacman
> > doesn't do
> > this automatically.
> >
>
> Sorry to hijack this trhead,
>
> but so that pacman does not clean automagically this kind of packages. What
> is the recommended way to keep a clean box?
>

​pacman -Rs $(pacman -Qqdt​)

Re: [arch-general] pavucontrol depency question

[Maarten de Vries via arch-general]

On 20 Mar 2017 10:41 a.m., "ProgAndy"  wrote:

Am 20.03.2017 um 10:06 schrieb Christoph Gysin via arch-general:

> pavucontrol works fine without pulseaudio, if you control another
> machine's pulseaudio instance over the network:
>
> $ PULSE_SERVER=another-box pavucontrol
>
> Not sure about xfce4 packages, don't use them.
>
> Hi,

You can use the pulseaudio client library to send audio to a pulseaudio
server in your network. That works only for software using libpulse,
though. It probably won't work for connections through pulseaudio-alsa.


pulseaudio-alsa works fine with a remote pulse server if you properly
configure the client library. My desktop has streamed all audio to a
different device for years without problem. And that included audio from
alsa-only applications.

-- Maarten

Re: [arch-general] URXVT background color

[Maarten de Vries via arch-general]

On 18 March 2017 at 11:51, arnaud gaboury via arch-general <
arch-general@archlinux.org> wrote:

> I run many urxvt windows on my screen. Some are for the host system and
> some are for my container (managed by systemd-nspawn).
> I am looking for a way to change color background according to hostname in
> order to quickly see which terminal I am on.
>  My idea was to test $HOST variable in my ~/.xinitrc and give a specific
> .Xressource accordingly, but it doesn't work as .xinitrc is obviously not
> invoked when I fire a new terminal window.
>
> How can I manage what I am looking for (if I can)?
> Thank you for hints.
>

​You could make a wrapper script that calls `exec urxvt -bg ` with a
color​

​based on the hostname.​ I'd recommend a wrapper script and not an alias
since the wrapper script will work everywhere, not just in your shell. Just
put the script somewhere that is accessible in the host system and the
container and set $PATH accordingly for your user.

--
​ Maarten​

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Maarten de Vries via arch-general]

On 18 December 2016 at 21:32, Leonid Isaev 
wrote:

> On Sun, Dec 18, 2016 at 02:25:00PM -0600, David C. Rankin wrote:
> >   I know this is small-potatoes stuff, but I just wonder if in these
> > instances, it may not be better to either provide pre-update notice or
> do a
> > post-install script rather than relying on a post update action by the
> user?
> > At least in the cases where you know up-front that existing
> functionality will
> > be disabled by the upgrade. (which was apparent from the comment)
>
> Hmm, what about reading /var/log/pacman.log?
>
>
​A log is great for figuring out what went happened after something broke,
but it shouldn't have to be part of a normal upgrade procedure in my
opinion. Personally I do think the provided message was enough though.

I'd be a bit scared if package maintainers would add scripts to
automatically rename files. This case might have been safe, but in general
it is impossible for package maintainers to predict what users may have
done to their system and how post-upgrade scripts would interact with that.
I'm very happy that Arch lets the user (the one who knows the system best)
deal with this type of problem.

-- Maarten

Re: [arch-general] On containers. WAS: Re: snapcraft.io ...

[Maarten de Vries via arch-general]

On 26 November 2016 at 15:08, Carsten Mattner via arch-general <
arch-general@archlinux.org> wrote:

>
> Another very useful case would be using containers as a chroot replacement
> for having clean (only what's in the recipe), reproducable build
> environments
> for building arch packages. It would also allow installing makedeps only in
> the container/chroot or make cross-compilation easier to manage.
>
> Are there plans to support this in makepkg? I believe xbps has this.
>

​To my knowledge​, makechrootpkg uses systemd-nspawn, which means it is
already using a container. Reproducible builds will need quite a bit more
work than simply using containers though.

And since this whole thread is widely off topic already, there is a totally
different approach to isolating untrusted apps: cloudabi [1]. Instead of
making isolated traditional posix environments to run untrusted
applications, cloudabi makes it impossible to access global resources such
as the filesystem and network by providing only a subset of system calls.
For example, there is no `open()` syscall, but there is `open_at()`.
Resources can be given to the process by leaving open file descriptors when
it is exec'd, or by sending file descriptors to it over a unix socket.

The biggest drawback is of course that existing software can't simply run
under cloudabi because there are syscalls and libc functions missing. Also,
controlling access to network resources is troublesome, but I like the
general idea: instead of adding complexity of multiple isolated
environments, cloudabi removes complexity by stripping system calls that
can access global resources. There is a working patchset for the Linux
kernel already, though not upstreamed yet. See [1] if you're interested.

​[1] https://nuxi.nl/​

Re: [arch-general] Is ncurses in Arch Linux out-dated?

[Maarten de Vries via arch-general]

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/
> 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.
>

​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] Pacman Hooks

[Maarten de Vries via arch-general]

On 21 August 2016 at 13:29, Jayesh Badwaik 
wrote:

> Hi,
>
> I have been trying to write some hooks for my pacman and so, I
> search the internet for it. I could not find any documentation on it,
> apart from some examples and a blog post on Allan McRae's blog. I
> was wondering if there is such a documentation or not?
>
>

​You probably want to check out the manpage for alpm-hooks.

Kind regards,
Maarten de Vries​

Re: [arch-general] SLiM DM

[Maarten de Vries via arch-general]

On 13 June 2016 at 01:31, Levente Polyak  wrote:

> On 06/13/2016 12:59 AM, David C. Rankin wrote:
> > [...] prevent whip-sawing all arch users who following the
> > recommendation in configuring their desktop from finding out their
> config is
> > broken on the first reboot after update following removal.
> >
>
> ​
>
> I don't say there may be no problems, but bashing like that statement is
> simply not fair and also not very helpful.
>

​I read his message as "we shouldn't remove it just like that because
_that_ would break peoples system/config", and not as "SLiM is broken"​.

-- Maarten

Re: [arch-general] ML is being sent to Spam by Gmail

[Maarten de Vries via arch-general]

On 8 June 2016 at 10:55, Florian Pritz via arch-general <
arch-general@archlinux.org> wrote:

> On 08.06.2016 06:26, Eli Schwartz via arch-general wrote:
> > dkim header remarks indicate either failed or missing dkim sigs for
> > those messages.
>
> That's weird. For me the signatures very just fine. Could you show me
> the exact error you get (assuming there is one)?
>
> Maybe also run the full mail (source, including headers) through
> `opendkim-testmsg` (part of the opendkim package)? If there is no error,
> the mail verifies fine.
>
> Also missing DKIM signatures are not our fault and FWIW a missing
> signature should not cause mails to go to spam. An invalid signature
> also shouldn't unless there is a DMARC policy for that domain that
> states so. archlinux.org currently doesn't publish a DMARC policy so the
> default of letting everything through applies.
>
> We do change the From address of any mail that uses DMARC though and
> resign the mail with our key so that signatures for those mails are
> valid. Since we change the From address, the DMARC policy of the
> original sender no longer matters.
>
> I don't know if gmail provides any information as to why they classify a
> specific mail as spam, but if they do, please show me. If they do not,
> please send me all the headers of one mail that has been delivered to
> spam so I can check them for possible problems.
>

​Gmail imposes more strict checks on email coming in over IPv6, with​ the
rationale that IPv6 enabled machines are more modern and thus should be
configured properly for newer verification techniques. Of course, for a
mailinglist this does not fly since it does not generate the messages
itself. See also [1], specifically "Additional guidelines for IPv6".

So... A stupid but possibly pragmatic approach is to use IPv4 when relaying
email to gmail.

[1] https://support.google.com/mail/answer/81126