Re: [arch-general] Increase console size regardless of screen size

[Mauro Santos via arch-general]

On 27-08-2017 17:28, Storm Dragon via arch-general wrote:
> I am using an Odroid XU4 with which is an ARM machine. So it uses uboot.
> I did uncomment a larger screen setting in the boot.txt file and did
> mkscr to compile it. Here is the line from boot.txt:

You are using Arch Linux ARM, which is a separate distribution and you
want to ask on their support channels.

This mailing list is for Arch Linux which supports only x86-64 (and i686
for a little while longer) and uses different methods to boot (different
bootloaders or by using EFISTUB on UEFI systems) so I suspect not many
people here will know how to make uboot do what you want.

-- 
Mauro Santos

Re: [arch-general] kernel-install in archlinux

[Mauro Santos via arch-general]

On 22-06-2017 15:20, Damjan Georgievski wrote:
> Unfortunately that's not enough, other hooks (which are unknown) can
> update the initramfs, and I can't hook on /boot/initramfs-* since it's
> not part of any package.

I suppose the question is if any of the official packages provide a hook
that does changes the initramfs.

You can probably trigger your hook on a kernel update and give it a name
that will make it run _after_ the stock initramfs update hook and any
other hooks that change the initramfs. That said I have never played
with custom hooks so I'm going by what the man page says.

If there are some hooks which do not play well with what you want to do
then maybe you can ask the maintainer/dev to make it run in a
predictable way. I guess no one has looked into automating/integrating
secure boot into arch but it would be a cool thing to have, even if not
in the official repos (read: even if it is provided by a package on the
AUR and there are some instruction/general guidelines on how to make it
work).

-- 
Mauro Santos

Re: [arch-general] kernel-install in archlinux

[Mauro Santos via arch-general]

On 22-06-2017 12:58, Damjan Georgievski via arch-general wrote:
> Is there any plan for moving ArchLinux to the kernel-install infrastructure[1]
> 
> I've seen some talk about it from a year ago, but the discussion seems
> to have died off.
> 
> My personal use case is to have a hook that self-signs
> kernel+initramfs+cmdline images for secure boot (using my own keys),
> and currently I have to do that manually whenever the initramfs is
> updated.
> 
> 
> 
> 
> [1]
> https://www.freedesktop.org/software/systemd/man/kernel-install.html
> [2]
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-May/028014.html
> 

You may want to check 'man alpm-hooks'. You should be able to automate
what you want to do.

-- 
Mauro Santos

Re: [arch-general] Samsung NVMe set up

[Mauro Santos via arch-general]

On 21-06-2017 19:51, Alan E. Davis via arch-general wrote:
> For the NVMe drive, I see that it is *up to* 3.2 GB/s, or 3200MB/s, and
> this may be "up-to" that speed..

You should always be aware of the up to claims but it should be
achievable, even if it is only for large sequential reads.

Another thing you should check is how many lanes are actually connected
or being used to communicate with the nvme ssd. I remember seeing (I
think it was on anandtech but can't find the article) that for some nucs
intel's firmware was not activating all lanes or was operating the lanes
at reduced speed (can't recall exactly), so you might be hitting
something similar.

-- 
Mauro Santos

Re: [arch-general] xfce4-notifyd issues

[Mauro Santos via arch-general]

On 21-06-2017 20:16, David Rosenstrauch wrote:
> On 06/21/2017 03:07 PM, Bjoern Franke wrote:
>> Am 21.06.2017 um 14:17 schrieb David Barri via arch-general:
>>> Broke for me recently too. I had to add this to my .xinitrc:
>>>
>>> systemctl --user start xfce4-notifyd.service
>>>
>>
>> Which DE are you using? With XFCE, it's autostarted here, not need for
>> systemctl --user.
>>
>> Regards
>> Bjoern
> 
> I (the original reporter) am running XFCE.
> 
> I've done a bit of research on the issue.  Seems like what's happening is:
> 
> a) Apparently xfce4-notifyd intentionally (!) shuts itself down after 10
> mins of inactivity (see
> https://bugzilla.xfce.org/show_bug.cgi?id=12754).  However, it's had
> this behavior for quite some time (since v0.3.0 - we're now at 0.3.6),
> so I don't think this is the source of the issue.
> 
> b) It looks like what changed recently is that for some reason dbus is
> no longer able to automatically restart xfce4-notifyd when a
> notification happens.  See what I get when I issue "notify-send 'test'":
> 
> Jun 21 15:08:16 darosedm dbus-daemon[628]: Activating service
> name='org.freedesktop.Notifications'
> Jun 21 15:09:16 darosedm plasma_waitforname[7097]:
> org.kde.knotifications: WaitForName: Service was not registered within
> timeout
> Jun 21 15:09:16 darosedm dbus-daemon[628]: Activated service
> 'org.freedesktop.Notifications' failed: Process
> org.freedesktop.Notifications exited with status 1
> 
> I haven't quite pinned down what's causing the restart to fail yet.  If
> anyone has any relevant info, please do share.
> 

It's working fine here.

I don't use a login manager, I login from a tty and I haven't changed
any configuration in a long while. I also don't do anything special to
launch xfce or anything else.

my .xinitrc has:

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
[ -x "$f" ] && . "$f"
  done
  unset f
fi
exec startxfce4

and that's all.

-- 
Mauro Santos

Re: [arch-general] arch health

[Mauro Santos via arch-general]

On 20-04-2017 23:37, Carsten Mattner wrote:
> Bug has been reported in Arch's tracker and there's a companion
> bug from someone else about ffmpeg2.8. It makes sense to report
> in Arch first because arch has published 3.3 in testing and maybe
> ffmpeg's version scheme is just convoluted and 3.3 is unstable
> while 2.8 and 3.2 (even numbers) were stable branches. ffmpeg.org
> doesn't label 3.3 as a dev branch so I don't blame arch for
> picking ffmpeg3.3. In fact it says 3.3 is a stable release.

In case of doubt you should ask upstream, doesn't mean it has to be a
bug report right away, you can start by asking in a mailing list. If it
turns out it really is a nasty bug then opening a bug in arch's bug
tracker for the current affected version is the way to go to get the
attention of the maintainer. Obviously you should provide links to
upstream's bug report or mailing list thread.

> The corruption is easy to reproduce and so obvious that I didn't
> consider reporting it to ffmpeg.org. It looks impossible to slip
> their tests.

I haven't used ffmpeg directly very much so I don't know if there are
any ways to shoot yourself in the foot, but you should consider that
what is broken and easy to reproduce for you might just work™ for
someone else. If upstream didn't catch it and no one else is complaining
you have to consider the problem _could_ be in your setup.

> I'm using ffmpeg 2.8.11 now, but since it's dangerous for other
> users to have their files corrupted, I think an official downgrade
> to 3.2.4 is in order.

If you've reported the bug both upstream and in arch's bug tracker and
it turns out it really is a nasty bug it will most probably either get a
downgrade or will be patched quickly (after upstream fixes it).

-- 
Mauro Santos

Re: [arch-general] arch health

[Mauro Santos via arch-general]

On 20-04-2017 20:21, Ralf Mardorf wrote:
>> Have you reported the bug? If yes and the dev decides that it should be
>> reverted to a previous version there is a way to do it, see:
>> man pacman | grep -A1 epoch
> 
> For the sake of completeness:
> 
> "Upstream or Arch?
> [snip]
> If Arch is not responsible for a bug, the problem
> will not be solved by reporting the bug to Arch developers." -
> https://wiki.archlinux.org/index.php/Reporting_bug_guidelines#Upstream_or_Arch.3F
> 
> This policy isn't always pleasant ;), but the Arch developers sometimes
> are willing to balance pros and cons, so sometimes they fix such
> issues ;).
> 

Maybe I should have been more specific, I was talking about
downgrading/reverting an update. That is why the epoch field exists and
it has been used before. Ffmpeg does have the mark of shame already so I
suppose sometime in the past it has been necessary to do a downgrade.

In the case where the bug comes from upstream one should report it
upstream, but if it is something "serious" you have to report it in
Arch's bug tracker, the maintainer does not have a crystal ball to know
some nasty bug reared its head.

-- 
Mauro Santos

Re: [arch-general] arch health

[Mauro Santos via arch-general]

On 20-04-2017 18:56, Carsten Mattner via arch-general wrote:
> If I may suggest a pain point: arch needs good support for
> revoking packages and replacing with the previous version
> if regressions are encountered. Case in point ffmpeg 3.3.
> 3.2.4 was fine and 2.8.11 is also fine but 3.3's muxer
> corrupts files. It's not the first instance where I wished
> for official revoke and replace in the index instead of
> manual user intervention.
> 

Have you reported the bug? If yes and the dev decides that it should be
reverted to a previous version there is a way to do it, see:
man pacman | grep -A1 epoch

-- 
Mauro Santos

Re: [arch-general] Update to Linux 4.10.1-1 Broke Bind9 /etc/named.conf never reached on startup

[Mauro Santos via arch-general]

On 12-03-2017 14:00, David C. Rankin wrote:
> All,
> 
>   After update to Linux 4.10.1-1, Bind9 cannot connect to 127.0.0.1#953. This
> server has been flawless with Bind for 4 years. Now, for example attempting to
> sync zones:


It seems other people also have noticed problems:
https://bbs.archlinux.org/viewtopic.php?id=224028

I guess the quick "fix" would be to downgrade the kernel or maybe try
the lts kernel.

-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)

[Mauro Santos via arch-general]

On 06-03-2017 12:45, Henrik Danielsson via arch-general wrote:
> 2017-03-06 12:53 GMT+01:00 Mauro Santos via arch-general <
> arch-general@archlinux.org>:
> 
>> On 06-03-2017 11:20, Henrik Danielsson via arch-general wrote:
>>> 2017-03-06 11:18 GMT+01:00 Ralf Mardorf <silver.bul...@zoho.com>:
>>>>
>>>> Privacy is a principle. You seem not to understand the difference
>>>> between giving somebody data with the formal permission to use this data
>>>> and data that simply is available for everybody, but not explicitly
>>>> handed over to somebody. Paranoia isn't involved in my concern.
>>>>
>>> My standpoint is that privacy does not apply to this kind of public
>>> information, simply because it's not private and by no means sensitive
>>> (people freely chose the username and other visible info they posted,
>> no?).
>>> Thus, no, I see no difference and really no point in even considering
>>> trying to keep such information private.
>>>
>>> What anyone does with the freely available information posted in the AUR
>> is
>>> up to them ("mining" it or handing it over to someone else included), we
>>> could not do anything about it anyway, nor would I even care if I was in
>>> that list or not, since there seems to be no ToS between the one
>> submitting
>>> that information and the one publishing it. Since it was freely submitted
>>> without any terms, I can simply not find any restrictions on its usage.
>>>
>>> Yes, we should have a ToS to at least keep the principle of privacy
>> alive.
>>> But let's face it, real privacy online has been dead for long, if it ever
>>> existed.
>>>
>>> If there was a ToS, the situation would perhaps have been different, at
>>> least legally. I'm no legal expert of course, but to me it makes perfect
>>> sense that if you posted something on the internet, in a very public
>> space,
>>> you can have no expectations of keeping any of that information private
>> in
>>> any way, nor any information easily associated with.
>>> No, I don't see that as a problem, at least not if you never explicitly
>>> agreed that information would not be shared. What I really want to keep
>>> private I don't post anywhere.
>>>
>>
>> I think the point here is not so much privacy, as I believe everyone
>> recognizes that the information that was asked for (the full list of
>> usernames) is public and can be scraped.
>>
>> The point here is handing over the full list of usernames on request. Do
>> note that in their research proposal[1] they specifically mention
>> scraping information from github. That information is public, github
>> does have an API to query that information, but they still have to
>> scrape it, I suppose that implies github does not hand it over wholesale
>> on request, why should we? This might be due to their ToS or they know
>> something we don't.
>>
> It would be rather interesting to see what they could come up with from
> that correlation.

Probably nothing meaningful. As I've said before you have no way of
knowing if user foo on github is the same as user foo on the AUR.

> I think, perhaps a bit cynically, the reason github may not hand over that
> data directly is likely that they don't want to do some of the work of the
> researchers for them. As you said, the data is there, the format matters
> less if they're going to massage it into something else later anyway, so
> why bother with the effort of compiling it on their [github] own time?
> 
> We could simply deny the AUR username request it for the same reason, or no
> reason at all. Since some people seem uncomfortable about what could be
> derived from a potential correlation of publicly available data, that's
> most likely the safest way to go.
> 


-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)

[Mauro Santos via arch-general]

On 06-03-2017 12:13, Ralf Mardorf wrote:
> On Mon, 6 Mar 2017 11:53:34 +0000, Mauro Santos via arch-general wrote:
>> I think the point here is not so much privacy, as I believe everyone
>> recognizes that the information that was asked for (the full list of
>> usernames) is public
> 
> It's not per se forbidden to take a photo of a public location, it's
> even allowed to take the photo and to publish the photo, if a girl
> randomly is on that photo, too. It is forbidden to provide a collection
> of such photos to somebody else, who needs such photos for a porn
> website. Now "research" isn't "porn", but subtleties could make it hard
> to decide how to handle something like this. That something is public,
> doesn't mean that privacy could be ignored.
> .
> 

I'm not saying privacy doesn't matter, it does. The usernames are there
for everyone to see, there is no expectation of privacy on that, or the
comments on packages.

What I feel is the crux of the problem here is handing the list (or
database) of users wholesale. I believe you have framed the main
question better than I have in one of your replies :)

-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)

[Mauro Santos via arch-general]

On 06-03-2017 11:20, Henrik Danielsson via arch-general wrote:
> 2017-03-06 11:18 GMT+01:00 Ralf Mardorf :
>>
>> Privacy is a principle. You seem not to understand the difference
>> between giving somebody data with the formal permission to use this data
>> and data that simply is available for everybody, but not explicitly
>> handed over to somebody. Paranoia isn't involved in my concern.
>>
> My standpoint is that privacy does not apply to this kind of public
> information, simply because it's not private and by no means sensitive
> (people freely chose the username and other visible info they posted, no?).
> Thus, no, I see no difference and really no point in even considering
> trying to keep such information private.
> 
> What anyone does with the freely available information posted in the AUR is
> up to them ("mining" it or handing it over to someone else included), we
> could not do anything about it anyway, nor would I even care if I was in
> that list or not, since there seems to be no ToS between the one submitting
> that information and the one publishing it. Since it was freely submitted
> without any terms, I can simply not find any restrictions on its usage.
> 
> Yes, we should have a ToS to at least keep the principle of privacy alive.
> But let's face it, real privacy online has been dead for long, if it ever
> existed.
> 
> If there was a ToS, the situation would perhaps have been different, at
> least legally. I'm no legal expert of course, but to me it makes perfect
> sense that if you posted something on the internet, in a very public space,
> you can have no expectations of keeping any of that information private in
> any way, nor any information easily associated with.
> No, I don't see that as a problem, at least not if you never explicitly
> agreed that information would not be shared. What I really want to keep
> private I don't post anywhere.
> 

I think the point here is not so much privacy, as I believe everyone
recognizes that the information that was asked for (the full list of
usernames) is public and can be scraped.

The point here is handing over the full list of usernames on request. Do
note that in their research proposal[1] they specifically mention
scraping information from github. That information is public, github
does have an API to query that information, but they still have to
scrape it, I suppose that implies github does not hand it over wholesale
on request, why should we? This might be due to their ToS or they know
something we don't.

[1]
https://ncn.gov.pl/sites/default/files/listy-rankingowe/2016-03-15/streszczenia/337724-en.pdf

-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)

[Mauro Santos via arch-general]

On 05-03-2017 13:35, Lukas Fleischer wrote:
> Hi,
> 
> I was recently contacted by a Polish researcher asking for a list of AUR
> account names. I did not expect this to be controversial but a couple of
> Trusted Users raised concerns on IRC, so I decided to move this to the
> public mailing list and discuss the whole topic in generality. I would
> like to head more opinions but please read the whole email and give it a
> second thought before simply bringing up the usual privacy arguments
> mentioned below.
> 
> My original questions was: Are we fine with sharing the list of AUR
> accounts names (only user names, no real names or email addresses) with
> a researcher that seems trustworthy and agrees to not share the data in
> any form other than the resulting anonymized statistics?
> 
> In this particular case, we are talking about Dorota Celinska [1] from
> the University of Warsaw, Faculty of Economic Sciences [2], see [3] for
> a list of her publications and [4] for a summary of her research project
> funded recently by the Polish National Science Centre. She needs the
> list of user names to perform a segmentation analysis, including users
> which were active on the older AUR releases both do not show any
> activity on AUR 4. She would also like to use the user names as
> identifiers to establish connections with other platforms, such as
> GitHub.
> 
> The next question is: Would it make sense to even make this data
> publicly available? Would it make sense to extend our RPC interface such
> that one can search for users names? GitHub, for example, already
> provides such an interface [5]. Let me quickly summarize some arguments
> for this idea which came up on IRC:
> 
> * User names are mostly identifiers. It is questionable whether they
>   can/should be considered personal/private information. Maybe this can
>   only be answered by a lawyer, though.
> 
> * The user names of all accounts with any kind of public activity, like
>   uploading a package, filing a request, writing a comment, are public
>   already.
> 
> * After logging into the aurweb interface, you can already check whether
>   an account with a given user name exists because the account details
>   page URIs have the form https://aur.archlinux.org/account/$username.
>   This means that for any platform providing a list of user names (such
>   as GitHub), you can "establish connections" with the AUR already.
> 
> Now the arguments against:
> 
> * Principle of data economy: We should not share any kind of information
>   we do not need to share.
> 
> * Sharing user names lowers the threshold for sharing other information
>   which is considered more confidential.
> 
> * Users can (and should) already use crawlers to fetch the user names.
>   For example, the user names of all package maintainers and comment
>   authors appear on the package details pages. The names of all users
>   filing package requests appear in the mailing list archives etc.
> 
> * We do not have ToS so we better not share anything.
> 
> I, personally, find the second last argument a very weak one. Telling
> users to build crawlers scraping an brute-forcing our HTML pages makes
> life difficult for both them and us. What do you think?
> 
> On the other side of the coin, the last argument is a very good one and
> it brings me to my last point. Independently of the outcome of this
> discussion, I think we should add some ToS that users need to agree upon
> when registering. It should contain information on liability and on
> privacy. Is anybody willing to write a draft? Do we need the support of
> a lawyer here?
> 
> Thank you for your time and have a nice Sunday!
> 
> Regards,
> Lukas
> 
> [1] http://coin.wne.uw.edu.pl/dcelinska/en/
> [2] https://www.wne.uw.edu.pl/index.php/en/
> [3] http://coin.wne.uw.edu.pl/dcelinska/en/pages/publications.html
> [4] 
> https://ncn.gov.pl/sites/default/files/listy-rankingowe/2016-03-15/streszczenia/337724-en.pdf
> [5] https://developer.github.com/v3/users/
> 

I'd say err on the caution side and don't share, even though the
usernames are public and easy to find by scraping them from the
website/mailing list/etc, handing the whole database of usernames in a
silver platter is a whole different story, which is what is being asked.
Is there any community/website that provides a full list of registered
usernames on request?

There is also the question of how useful that data would be, without any
other data such as email the username list is useless, you have no
guarantee that user foo on github is the same person as user foo on the
AUR/Wiki/Forum or user foo somewhere else. In this case I'd also have to
agree that sharing usernames lowers the threshold for sharing other
information.

It also doesn't fit with their stated research goals, only github and
projects associated with scraping data from github are mentioned, why
would they want to throw the AUR usernames in the mix?

-- 
Mauro Santos

Re: [arch-general] NILFS: A filesystem designed to minimize the likelyhood of data loss

[Mauro Santos via arch-general]

On 09-01-2017 15:39, Alexander Rath wrote:
> Hello!
> 
> I'd like to share a link to this description/tutorial about NILFS2:
> https://forum.manjaro.org/t/nilfs-a-filesystem-designed-to-minimize-the-likelyhood-of-data-loss/15091
> 
> Did anybody try to install Arch on a NILFS2-formatted partition?
> 
> Best regards,
> Alexander
> 

Try it yourself and see how it works. Make sure you use it until you
write enough data to disk/partition that it would fill it if data did
not get overwritten (I'm thinking system updates).

I think I've tried it a few years back in a usb drive, didn't like it.
Can't comment on data loss, I don't remember if it ever imploded.

-- 
Mauro Santos

Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Mauro Santos via arch-general]

On 26-12-2016 02:54, Eli Schwartz via arch-general wrote:
> On 12/24/2016 10:33 AM, Mauro Santos via arch-general wrote:
>> What other distros do is recommend a 1GB /boot or changing the
>> configuration to reduce the number of older kernels installed[1]. People
>> have complained about small libraries needing to be installed as being
>> wasteful, at a grand total 100MiB+ for each kernel that would start a
>> nice flamewar.
> 
> Well, we already expect people to take care of orphans themselves, and
> nobody is suggesting old kernels *must* be kept around forever.
> 
>>>> There is also the matter of automagic bootloader configuration change to
>>>> support that, not to mention people that use efistub to boot their
>>>> system, how do you propose to handle that?
> 
> The blatantly obvious way would be with a dummy kernel package
> containing a symlink to the vmlinuz/initramfs of the latest versioned
> package. Old bootloader configurations don't care about how many new and
> irrelevant files aren't being looked at.
> 
> If you want new bootloader entries to be automatically added in grub.cfg
> then simply use a pacman hook to re-run grub-mkconfig -- I am sure
> something similar can be easily done for syslinux/EFI.
> You can also edit the boot cmdline from grub itself...
> 

Automagic updates? No thank you. Stay away from my configuration files
and efi variables.

>>> If you have installed archlinux, it's reasonable to expect that one knows
>>> how to configure this.
>>
>> It is you who said "I wish arch would (like other distros) keep 2 or
>> three old kernel versions around" not me. Other distributions
>> automagically take care of updating the bootloader configuration, as
>> much would be expected of arch.
>> Some people already have trouble managing to update one kernel properly,
>> imagine the chaos it would be with more than one if manual steps were
>> involved, not to mention old kernels have _known_ security issues and
>> having old stuff around is not the Arch way.
> 
> What problems are people having with updating one kernel? Please
> elaborate on your vagueness.
> 

Forgetting to reboot, which you address below and I have to agree that
as things are now they are not optimal. Forgetting to mount /boot and
all the "fun" stuff that every once in a while pops up in the forum.

> As for known security issues and keeping old stuff around, I could care
> less about offering all kernels in the repos -- I just don't want my old
> kernel to be uninstalled until I say so.
> 
> See http://bugs.archlinux.org/task/16702 for more details, but the basic
> gist is that versioned kernel installs are a *good* thing, as opposed to
> being forced to reboot every time your --sysupgrade includes the kernel
> (which is what *I* would call not-very-Arch-way), and it is intended
> that we will eventually get versioned kernels, and the fact that we
> don't have that today is simply because it is low-priority and tpowa
> hasn't gotten around to it yet.
> 
> (I am not entirely sure what the holdup is, though.)
> 


-- 
Mauro Santos

Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Mauro Santos via arch-general]

On 24-12-2016 14:14, Carsten Mattner wrote:
> On Fri, Dec 23, 2016 at 3:17 PM, Mauro Santos via arch-general
> <arch-general@archlinux.org> wrote:
>> On 23-12-2016 13:58, Carsten Mattner via arch-general wrote:
>>> On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
>>> <arch-general@archlinux.org> wrote:
>>>> Hello.
>>>>
>>>> I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years
>>>> old Toshiba Laptop. When I try to make it boot on with linux 4.9-1
>>>> kernel, it freeze right after loading initramfs.
>>>>
>>>> 4.8.xx kernel was working flawlessly. My eeePC (nearly 9 years old)
>>>> and my desktop computer (which is AMD based) are both starting with
>>>> linux 4.9.
>>>>
>>>> I opened a bug : https://bugs.archlinux.org/task/52246
>>>>
>>>> Here is my lspci. If someone can help me finding what is happening,
>>>> I'll be very happy :
>>>>
>>>> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
>>>> Controller Hub (rev 07)
>>>> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
>>>> Chipset Integrated Graphics Controller (rev 07)
>>>> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
>>>> Integrated Graphics Controller (rev 07)
>>>> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>> UHCI Controller #4 (rev 03)
>>>> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>> UHCI Controller #5 (rev 03)
>>>> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>>> EHCI Controller #2 (rev 03)
>>>> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
>>>> Controller (rev 03)
>>>> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>>> Port 1 (rev 03)
>>>> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>>> Port 2 (rev 03)
>>>> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>>>> Port 5 (rev 03)
>>>> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>> UHCI Controller #1 (rev 03)
>>>> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>> UHCI Controller #2 (rev 03)
>>>> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>> UHCI Controller #3 (rev 03)
>>>> 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>>>> UHCI Controller #6 (rev 03)
>>>> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>>>> EHCI Controller #1 (rev 03)
>>>> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
>>>> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 
>>>> 03)
>>>> 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM
>>>> (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
>>>> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
>>>> (rev 03)
>>>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>>> RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02)
>>>> 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless
>>>> Network Adapter (PCI-Express) (rev 01)
>>>
>>> Does the fallback boot entry work?
>>>
>>> Have you tried reinstalling the kernel?
>>>
>>> I wish arch would (like other distros) keep 2 or three old kernel
>>> versions around because it doesn't take any space to do so
>>> and works around boot bugs in new kernels.
>>>
>>
>> Care to explain how "doesn't take any space" works? Last time I checked
>> files do take up space. There is an LTS kernel in the repos, which you
>> can have installed exactly for things like this.
> 
> While writing that I knew somebody would read it in strict interpretation 
> mode.
> s/no space/not enough space in \/boot to matter/ 

The kernel only might not take much space but you have to take into
account the initramfs images and kernel modules too. All together it
should amount to over 100MiB per kernel.

What other distros do is recommend a 1GB /boot or changing the
configuration to reduce the number of older kernels installed[1]. People
have complained about small libraries needing to be installed as being
wasteful, at a grand total 100MiB+

Re: [arch-general] Getting freeze on early start with linux 4.9-1 kernel.

[Mauro Santos via arch-general]

On 23-12-2016 13:58, Carsten Mattner via arch-general wrote:
> On Fri, Dec 23, 2016 at 1:59 PM, fredbezies via arch-general
>  wrote:
>> Hello.
>>
>> I'm facing an annoying bug with linux 4.9-1 kernel on my 6 or 7 years
>> old Toshiba Laptop. When I try to make it boot on with linux 4.9-1
>> kernel, it freeze right after loading initramfs.
>>
>> 4.8.xx kernel was working flawlessly. My eeePC (nearly 9 years old)
>> and my desktop computer (which is AMD based) are both starting with
>> linux 4.9.
>>
>> I opened a bug : https://bugs.archlinux.org/task/52246
>>
>> Here is my lspci. If someone can help me finding what is happening,
>> I'll be very happy :
>>
>> 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory
>> Controller Hub (rev 07)
>> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
>> Chipset Integrated Graphics Controller (rev 07)
>> 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
>> Integrated Graphics Controller (rev 07)
>> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>> UHCI Controller #4 (rev 03)
>> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>> UHCI Controller #5 (rev 03)
>> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>> EHCI Controller #2 (rev 03)
>> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
>> Controller (rev 03)
>> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>> Port 1 (rev 03)
>> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>> Port 2 (rev 03)
>> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express
>> Port 5 (rev 03)
>> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>> UHCI Controller #1 (rev 03)
>> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>> UHCI Controller #2 (rev 03)
>> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>> UHCI Controller #3 (rev 03)
>> 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB
>> UHCI Controller #6 (rev 03)
>> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2
>> EHCI Controller #1 (rev 03)
>> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
>> 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
>> 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM
>> (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
>> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 
>> 03)
>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 02)
>> 03:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless
>> Network Adapter (PCI-Express) (rev 01)
> 
> Does the fallback boot entry work?
> 
> Have you tried reinstalling the kernel?
> 
> I wish arch would (like other distros) keep 2 or three old kernel
> versions around because it doesn't take any space to do so
> and works around boot bugs in new kernels.
> 

Care to explain how "doesn't take any space" works? Last time I checked
files do take up space. There is an LTS kernel in the repos, which you
can have installed exactly for things like this.

There is also the matter of automagic bootloader configuration change to
support that, not to mention people that use efistub to boot their
system, how do you propose to handle that?

> If this is a regression you will have to post dmesg. If you don't see
> errors/warnings, then kernel developers would usually ask to enable
> debug flags for printing more information during boot.
> 
> That said, I have one old machine with a Core2Duo and GM4xx and
> ever since DRM's atomic modesetting was introduced in 4.2, I can
> only use 4.1 warning free. Regressions do happen but you had no
> warnings or errors in 4.8 so yours looks like a different regression.
> 

If you don't report the bugs upstream they don't get fixed, if you have
reported it and no one got around to take a look at it then fine,
otherwise don't be lazy and report those bugs and help get them fixed.

-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes

[Mauro Santos via arch-general]

On 29-11-2016 17:00, Giancarlo Razzolini wrote:
> Em novembro 29, 2016 14:38 Christian Hesse escreveu:
>>
>> We need root privileges at initialization phase, no? Privileges are
>> dropped
>> to nobody/nobody when initialization sequence completed.
>>
>> If we can make things work with non-root system user... Let me know
>> how to do
>> that. :D
>>
> 
> We just need root for creating the tun devices and destroying them.
> I managed to make an entire unprivileged deployment.
> 
> Basically all I need is this:
> 
> [Service]
> User=openvpn
> Group=openvpn
> PermissionsStartOnly=true
> ExecStartPre=-/usr/bin/openvpn --rmtun --dev tun0
> ExecStartPre=/usr/bin/openvpn --mktun --dev tun0 --dev-type tun --user
> openvpn --group openvpn
> ExecStart=
> ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config %i.conf --daemon
> openvpn@%i --writepid /run/openvpn/openvpn@%i.pid --status-version 2
> PIDFile=/run/openvpn/openvpn@%i.pid
> 

I see a problem with this, the configuration file is not hard coded
(good) but the tun device is hardcoded (bad).

What happens if one wants more than one server or client instances? What
if the user wants to use tap instead of tun devices? It will also not
respect the naming configured in the configuration file, or at least it
will have to match tun0.

Trying to ship more secure unit files/configuration is good but it seems
this would probably be best described in the wiki and let the user
implement it if desired.

> The config file doesn't need any actual user/group configuration, because
> it is already started with the right user/group. It needs to use a
> different
> iproute binary (which in my case is a script) that has sudo permissions
> for the openvpn user to run the ip command as root.
> 
>>
>> The new systemd units create this automatically. (Well,
>> actually /run/openvpn-client and /run/openvpn-server.)
> 
> Nice to hear this.
> 
>>
>> Just followed the link from our wiki [2]. Probably you can make this
>> work,
>> but I am not convinced this can be packaged to work smoothly.
>> Dynamic device naming, up/route-up/... scripts, ... There is lot of stuff
>> that can and will break.
>>
>> Still, if you have some clues on how to package this...
>>
> 
> I never meant for you (us) to package such setup. I was
> just making the case for a dedicated openvpn system user
> and it's run directories. At least one of those is already
> taken care of. If we can deploy such unprivileged systemd
> units, alongside upstream official ones, it's another matter.
> 
> Personally I'm okay with all of this and I'll accommodate my
> setup, no matter how openvpn gets packaged. I had to compile
> openvpn for at least two release cycles because of a bug on it[0].
> I think you'll probably remember that one.
> 
> Cheers,
> Giancarlo Razzolini
> 
> [0] https://bugs.archlinux.org/task/50090


-- 
Mauro Santos

Re: [arch-general] Supermicro cd/dvd inst error: ARCH_201603 device did not show up after 30 seconds

[Mauro Santos via arch-general]

On 10-10-2016 23:49, David C. Rankin wrote:
> On 10/10/2016 03:26 PM, LoneVVolf wrote:
>> Check these 2 options in the AMI Bios :
>>
>> Advanced Chipset Control > Northbridge
>> Set IOMMU MODE to 1 GB
>> (unless you have an agp videocard in this system, then it should be set to 
>> "AGP
>> present" )
>>
>>
>> Processor & Clock Options
>> Set   Secure Virtual Machine Mode to Enabled
>>
>>
>> Without those settings in my experience linux 64-bit kernel is  very 
>> unreliable
>> on this system.
>> With those settings it's been running rock steady for 7 years now.
>> (it's my main workstation pc ).
>>
>> LW
> 
> Got both set, thanks!  I think there is something funny with the arch install
> iso. For some reason, I'm getting a failure waiting on the install to be 
> mounted
> at /run/archiso/bootmnt
> 
> The strange things is it says:
> 
> Waiting 30 seconds
> Error: '/dev/disk/by-label/ARCH_201603' device did not show up after 30 
> seconds.
> 
> WTF?? 201603, this is the 201610 install medial
> 
> Sure enough
> 
> # ls -al /dev/disk/by-label
> 
> ARCHISO_EFI -> ../../sdb2
> ARCH_201610 -> ../../sdb1
> 
> Why the hell is it trying to mount 'ARCH_201603' when 'ARCH_201610' is the
> actual label? I can manually mount /dev/disk/by-label/ARCH_201610 to
> /run/archiso/bootmnt but I don't know how to make the install continue from 
> that
> point??
> 
> This was with the USB installer. Funny, the arch iso from both 20160903 and
> 20161001 both fail looking for the 'ARCH_201603' (this was a fresh USB drive
> too, no prior iso on it)
> 
> "get a rope... somebody done screwed something up..."
> 

You could try to inspect the boot entry. If I recall correctly the
install iso uses grub so you can check and edit the entry before booting.

If indeed the boot entries are not correct then you should file a bug
report.

-- 
Mauro Santos

Re: [arch-general] How to set up a virtual network / NAT for libvirt?

[Mauro Santos via arch-general]

On 09-10-2016 18:38, Peter Nabbefeld wrote:
> 
> Hello,
> 
> I've been told that I cannot bridge multiple networks using WLAN (as WDS
> would not have been implemented correctly on all devices), but I've to
> use a virtual network, brobably with NAT, but I cannot find sufficient
> advice, neither in the arch wiki nor on the internet - probably just my
> search terms are incorrect, I don't know.
> 
> Could You give me advice, what I've to do to get internet access on my
> QEMU/Windows VM? Default networking does'nt work.
> 
> Kind regards
> Peter
> 

Have you seen this: https://wiki.archlinux.org/index.php/QEMU#Networking

-- 
Mauro Santos

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Mauro Santos via arch-general]

On 23-09-2016 01:06, Francis Gerund via arch-general wrote:
> Hi Maurio,
> 
> Thank you for your opinion.  In regard to your postulate, if my freedom
> ends where the others starts, then it would seem that the reverse is also
> true, that the freedom of others ends where my freedom starts.
> 

Yes that is true, I never said it wasn't. Yet you conveniently ignore
what I have written below that. Arch is not yours, you don't make it or
run/manage the infrastructure, to use the same analogy as before, this
is not your house so either you abide by the rules of the house or you
get reprimanded or kicked out.

-- 
Mauro Santos

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Mauro Santos via arch-general]

On 22-09-2016 23:10, Francis Gerund via arch-general wrote:
> Hi D C,
> 
> Freedom of speech means being able to say whatever you want to say, without
> interference from sel-appointed sidewalk supervisors or other members of
> the Peanut Gallery.
> 
> HTH.
> .
> 

All nice and well, but don't forget your freedom ends where the freedom
of others start.

When you go to someone's house either you abide by their rules or you
get reprimanded or kicked out. The same logic applies in the ML and the
forums.

When you decide to run a forum or ML providing support for whatever you
fancy then you can manage it any way you like, here you have to abide by
the rules put in place by the people running the forums/ML/IRC.

-- 
Mauro Santos

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Mauro Santos via arch-general]

On 22-09-2016 17:26, Zachary Kline wrote:
> 
> How does one define “third-party installer?” By my reading, the TalkingArch 
> project, which makes the installation process accessible to the visually 
> impaired, could qualify, as it isn’t released by the official Arch 
> maintainers. This would be deeply upsetting to me, as I am only able to use 
> Arch at all thanks to this project.

If I understand correctly, from what the description on the TalkingArch
project webpage says, it is the Arch iso with a few added packages to
help the visually impaired install Arch. I suppose that by this it means
the user is responsible for doing all the steps described in the wiki to
install Arch. I don't see any problem with this.

What I meant before is curses/graphical/one click installers that do
everything automagically. The user will be clueless as to what is
installed and how it is configured, and will waste everyone's time
playing a game of twenty questions to solve a trivial problem when the
solution is many of the times in a wiki page.

-- 
Mauro Santos

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Mauro Santos via arch-general]

On 22-09-2016 16:47, Francis Gerund via arch-general wrote:
> Note that all of these are regarded as separate distros and will NOT be
>> supported by Arch in the forums, mailing lists, or IRC.
>>
> 
> 
> While Antergos is indeed a separate distribution (but very close to raw
> Arch), the Archtect Arch Installer and Arch-Anywhere are not distributions,
> they are just installers for Arch.
> 
> And I do believe there are quite a few friendly, helpful people in the Arch
> community that will be happy to help, without questioning the pedigree of
> the user's installation.
> 

Third party installers are not supported in any shape or form. Threads
asking for support about derivative distros or third party installers on
the forums will be closed and binned on sight.

-- 
Mauro Santos

Re: [arch-general] Supermicro cd/dvd inst error: ARCH_201603 device did not show up after 30 seconds

[Mauro Santos via arch-general]

Have you tried with the latest install ISO?

You also seem to have physical access to the hardware, any special
reason why you have to use optical media instead of a usb flash drive?

-- 
Mauro Santos

Re: [arch-general] [arch-dev-public] i686 and SSE2

[Mauro Santos via arch-general]

I'm not sure enforcing sse3 or later for AMD64 hardware is the best
course of action.

> egrep "^model name|^flags" /proc/cpuinfo
model name  : AMD Athlon(tm) 64 Processor 3000+
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm
3dnowext 3dnow rep_good nopl eagerfpu pni lahf_lm 3dnowprefetch vmmcall

This machine is still able to run Arch just fine, and has saved the day
when the laptop I used day to day broke down. As others have said, AMD
cpus might not have sse4 unless they are quite recent.

Requiring sse2 might be a reasonable cutoff, but I'm sure there will be
people still using older machines that will complain if sse2 is
mandatory, as I can reasonably see late pentium 3 machines still being
usable for office, email or light browsing applications.

-- 
Mauro Santos

Re: [arch-general] Opinions on PowerShell?

[Mauro Santos via arch-general]

On 19-08-2016 16:05, Sebastiaan Lokhorst via arch-general wrote:
> 2016-08-19 16:28 GMT+02:00 Mauro Santos via arch-general <
> arch-general@archlinux.org>:
>>
>> Make no mistake, they are after profits and do whatever it takes to keep
>> the money flowing
>>
> 
> So do Red Hat and Google. But does that keep us from using systemd or
> Chromium?
> 
> Please stop this unfounded, tinfoil hat "Micro$oft sucks!!11" whining.
> If there is an actual reason why you shouldn't use a product, please say
> so, but this "don't use it because Microsoft made it" nonsense is
> ridiculous.
> 

I'm not saying powershell doesn't have merit, and you are free to use it
as much as you want, but just like you have stated your opinion, I was
stating mine and as such it can be biased.

However, as others have pointed out, Microsoft has a very bad track
record, unlike Red Hat and Google. If Microsoft wants to be trusted they
will have to earn it.

-- 
Mauro Santos

Re: [arch-general] Opinions on PowerShell?

[Mauro Santos via arch-general]

On 19-08-2016 15:58, Lee Fuller via arch-general wrote:
> Mauro - Could I please quote you verbatim in a post on my personal website?
> It' gets very little traffic and so there's nothing really for you to gain,
> but I simply couldn't write anything better and feel that your quote
> summarises my own view on the news. The address is https://leefuller.io -
> please let me know if it's okay and whether you have a website address or
> any specific information you'd like me to include. I'd typically link to
> the mailman archive page for this thread.
> 
> Thanks very much, sorry if I've drawn your attention away from something
> more important.
> 
> Regards

I don't mind, and this is a public post I can't stop anyone from using it ;)

> 
> 
> 
> 
> 
> *Kind Regards,Lee Fuller*
> 
> *PGP Fingerprint <https://leefuller.io/pgp/>: *
> 4ACAEBA4B9EE1B3A075034302D5C3D050E6ED55A
> 
> On 19 August 2016 at 15:28, Mauro Santos via arch-general <
> arch-general@archlinux.org> wrote:
> 
>> On 19-08-2016 14:27, Stephen E. Baker via arch-general wrote:
>>> As a PowerShell user, it certainly has it's place, but it's place is
>>> pretty niche in the linux world, so +1 for the AUR.
>>
>> Given that it comes from Microsoft they must have some agenda to
>> fulfill, I'd rather not touch this even with a 10 foot pole, just like I
>> try to stay away for other MS products as much as I can. The AUR is
>> where it should stay, but even then they can spin it as PR fodder just
>> like canonical spun snappy coming to Arch Linux.
>>
>> Make no mistake, they are after profits and do whatever it takes to keep
>> the money flowing, all their friendliness to linux and open source is
>> tainted with patent attacks behind the curtain. The next time the
>> leadership changes there is no guarantee that this new found
>> friendliness isn't going to change.
>>
>> --
>> Mauro Santos
>>
> 


-- 
Mauro Santos

Re: [arch-general] Opinions on PowerShell?

[Mauro Santos via arch-general]

On 19-08-2016 14:27, Stephen E. Baker via arch-general wrote:
> As a PowerShell user, it certainly has it's place, but it's place is
> pretty niche in the linux world, so +1 for the AUR.

Given that it comes from Microsoft they must have some agenda to
fulfill, I'd rather not touch this even with a 10 foot pole, just like I
try to stay away for other MS products as much as I can. The AUR is
where it should stay, but even then they can spin it as PR fodder just
like canonical spun snappy coming to Arch Linux.

Make no mistake, they are after profits and do whatever it takes to keep
the money flowing, all their friendliness to linux and open source is
tainted with patent attacks behind the curtain. The next time the
leadership changes there is no guarantee that this new found
friendliness isn't going to change.

-- 
Mauro Santos

Re: [arch-general] Announcing pacpak

[Mauro Santos via arch-general]

On 10-07-2016 13:18, pelzflorian (Florian Pelz) wrote:
> Hello,
> 
> On 07/10/2016 01:59 PM, LoneVVolf wrote:
>> My personal preference though is for AL community to treat flatpak
>> similar as derivative distros.
>>
>> something like : flatpak is unsupported on Arch linux, ask the flatpak
>> creator(s) for help.
> 
> Hm… If there is not that much desire to support Flatpak “officially” as
> an Arch project, then I probably will end up setting up a mailing list
> and bug tracker on my server sometime in the coming weeks.
> 
> Regards,
> Florian Pelz
> 

Personally I'd rather keep using the good old packages _but_ it would be
nice to have an official tool to manage/run/create flatpak packages,
this just to make sure that in case one needs to use a flatpak package
nothing will screw up the filesystem and cause more trouble than it's worth.

However a big fat warning should be present somewhere that bugs/problems
with flatpak packages are the sole responsibility of upstream/the
creator as I suspect bugs and problems will be the norm.

-- 
Mauro Santos

Re: [arch-general] packer vs packer-io

[Mauro Santos via arch-general]

On 23-06-2016 15:04, Andre "Osku" Schmidt via arch-general wrote:
> Hmm,
> 
> so Archlinux has packer[0] that provides an executable named `packer` and
> now there is packer-io[1] that changes the upstream executable from
> `packer` to `packer-io`.
> 
> Now i have a Makefile that runs packer-io[1] that fails on systems where
> its executable is not renamed to `packer-io`. (eg. everything[2] else than
> Archlinux)
> 
> I would like to provide the user a single command to build "my" software
> (eg. make), but am not sure what i should do.
> 
> 1. Tell Archlinux users to manually alias/link `packer` pointing to
> `packer-io`?
> 2. Automagically try to findout the correct executable in Makefile?
> 3. Request a rename of packer[0] executable upstream?
> 4. Request a rename of packer-io[1] executable upstream?
> 
> What would you do?
> 
> Cheers
> .andre
> 
> [0] https://aur.archlinux.org/packages/packer/
> [1] https://aur.archlinux.org/packages/packer-io/
> [2] at least Debian and MS-Windows
> 

Packer and packer-io, at first glance, seem to be different projects.
Even if they aren't different projects, both packages are in the AUR and
therefore unsupported.

As far as I know the only officially supported way of building and
installing packages on Arch Linux is using makepkg and pacman.

-- 
Mauro Santos

Re: [arch-general] kudos to Arch for packing keepassx 0.4.4-2

[Mauro Santos via arch-general]

On 21-06-2016 18:28, Jérôme M. Berger wrote:
>   I was'nt aware of keepassx2 until you mentionned it, but it appears
> unable to import my keepassx db. So yay, thanks for keeping the legacy
> keepassx…

I was also unaware of keepassx2 but for me it seems to have imported my
"old" database without any problems.

-- 
Mauro Santos

Re: [arch-general] Where did the touch pad tapping go?

[Mauro Santos via arch-general]

On 17-06-2016 06:52, Javier Vasquez via arch-general wrote:
>> On Thu, Jun 16, 2016 at 7:50 PM, Kyle Terrien  wrote:
>>> Javier Vasquez via arch-general wrote:
>>> ...
>>>
>>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/xf86-input-synaptics.install?h=packages/xf86-input-synaptics
>>
>> I saw that message while upgrading a couple of days ago.
>>
>> xf86-input-synaptics driver is on maintenance mode and
>> xf86-input-libinput driver must be prefered over.
>>
>> But I didn't understand what "must be prefered over" means (grammar
>> error).
>>
>> You suggested that libinput is the default now.  That would make more
>> sense.  So is this a warning of some sort, or is it a notification to
>> try to encourage people to switch to libinput?
>>
>> Does switching break any older desktop environments?  (e.g. MATE, Window
>> Maker)
> 
> Hi Kyle,
> 
> Although stalling development (just maintenance for now) on the Xorg
> synaptics driver doesn't mean it's deprecated, I prefer the move onto
> libinput as I did some time back.  Not related to what Arch might
> encourage, but I would encourage the move.
> 
> BTW, I have a libinput config to enable tapping, without specifying
> the "Driver" since november, and if present, Xorg has always treated
> libinput as the default over Synaptics.  The thing is that now the
> Arch xorg-server package requires the libinput driver as well as the
> evdev one.  And that makes libinput the default no matter you wanted
> it (as I did by installing it) or not (you can still opt for the
> synaptics driver through config).
> 
> I use plain fluxbox WM, no DE, so I guess other more used and/or
> supported WMs/DEs might work just fine.  The support for libinput on
> Xorg by Arch is not new.  The anouncement of the availability to chose
> for it is from 2015-11-13:
> 
> https://www.archlinux.org/news/xorg-1180-enters-testing
> 
> So it might be it's been tested on different WMs/DEs by now, and by
> different users.
> 
> One can still keep using the synaptics driver if preferred as
> mentioned.  It provides more options to tweak (for those who
> understand them and care).  Its config is similar to its libinput
> counterpart (just longer), and its main requirement is to specify to
> use the synaptics "Driver" in there.  You can read the wiki for some
> synaptics config basics:
> 
> https://wiki.archlinux.org/index.php/Touchpad_Synaptics
> 
> Or use the config from Fabien on this same thread:
> 
> https://lists.archlinux.org/pipermail/arch-general/2016-June/041457.html
> 

You should also be aware that some bugs are solved in libinput and have
been closed as wontfix in other drivers [1-2]. Although this is for
evdev it can give you an idea of what will happen in the future, if any
hard to solve bugs arise (as was the case with the example I provide).

[1] https://bugs.freedesktop.org/show_bug.cgi?id=92897
[2] https://bugs.freedesktop.org/show_bug.cgi?id=92896
-- 
Mauro Santos