Re: [arch-general] Cups upgrade leaves broken link in multi-user.target.wants: cups.path -> /usr/lib/systemd/system/cups.path

2016-10-08 Thread Sebastiaan Lokhorst via arch-general
That was over 2 years ago, and it was mentioned in an upgrade message
(although it does not specifically mention the .path file).[1]

Anyway, it can't really hurt to have a broken file there. Just remove the
link and all will be fine.

[1]
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/cups=ed9718c7a3c8b2e67be1e71d7a04cbbb2ec57020


Re: [arch-general] how to restore root and boot directory

2016-09-23 Thread Sebastiaan Lokhorst via arch-general
2016-09-23 19:59 GMT+02:00 Sebastiaan Lokhorst <sebastiaanlokho...@gmail.com
>:

> If you are using a Raspberry Pi, you can just download the image[1], and
> extract the /boot and /root directories to your SD card.
>
> [1] https://archlinuxarm.org/platforms/armv6/raspberry-pi
>

Oops, misread. I thought you had bricked the Raspberry instead of your
laptop. Sorry!


Re: [arch-general] how to restore root and boot directory

2016-09-23 Thread Sebastiaan Lokhorst via arch-general
If you are using a Raspberry Pi, you can just download the image[1], and
extract the /boot and /root directories to your SD card.

[1] https://archlinuxarm.org/platforms/armv6/raspberry-pi


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

2016-09-19 Thread Sebastiaan Lokhorst via arch-general
2016-09-19 12:22 GMT+02:00 Florian Pritz via arch-dev-public <
arch-dev-pub...@archlinux.org>:
>
> I'm not really sure why we want to even invest time in making all i686
> packages use more features. Most of our users run x86_64 already so maybe
> we
> should think about increasing feature support there since that will have a
> bigger impact.


This is an excellent point. Be it i686, i686+SSE2, i786, or whatever, they
are all legacy platforms. You cannot seriously say "optimised for modern
processors" and "i686" in the same sentence. I don't see how there is much
gain from optimising them, especially since most users are using x86_64
anyway.

In my opinion, we should keep i686 as it is, as a legacy platform, until it
is used so little that we drop it completely. Anyone who is concerned about
performance has moved to x86_64 a long time ago.


Sebastiaan


Re: [arch-general] Not being able to upgrade system because of catalyst-hook

2016-09-13 Thread Sebastiaan Lokhorst via arch-general
By the way, how did you install Catalyst? From the AUR or from Vi0L0's
repositories?

If you did it from the AUR, you should already know all this.

If you installed it from Vi0L0's repositories, I think something else is
going on, and you can ignore most of what was said in this thread.
Is it[1] still in your pacman.conf? If it is, also note that you should
upgrade with # pacman -Syu, not # pacman -Su.

Good luck,
Sebastiaan

[1]
https://wiki.archlinux.org/index.php/Unofficial_user_repositories#catalyst


Re: [arch-general] Not being able to upgrade system because of catalyst-hook

2016-09-13 Thread Sebastiaan Lokhorst via arch-general
You don't need to manually apply the patch, just download, build and
install the new package:

$ git clone https://aur.archlinux.org/catalyst-hook.git
$ cd catalyst-hook
$ makepkg -si


Re: [arch-general] Not being able to upgrade system because of catalyst-hook

2016-09-13 Thread Sebastiaan Lokhorst via arch-general
2016-09-13 10:39 GMT+02:00 G. Schlisio :

> > You should update the catalyst-hook package manually. The latest version
> > supports Linux 4.7.
>
> this is misleading, as there is no upgrade.
>

What about version 15.9-12? It adds a patch to make it compatible with
Linux 4.7

[1]
https://aur.archlinux.org/cgit/aur.git/commit/?h=catalyst-hook=1ed0d7e92f486d3b1bae49b9c43b34b29585d1c0


Re: [arch-general] Not being able to upgrade system because of catalyst-hook

2016-09-13 Thread Sebastiaan Lokhorst via arch-general
Hi,

You should update the catalyst-hook package manually. The latest version
supports Linux 4.7.

Note that catalyst-hook is an AUR package, and those don't get updated
automatically with pacman. If you want to want to automatically update your
AUR packages, you should use an AUR helper. (search the Wiki)

Regards,
Sebastiaan


Re: [arch-general] Opinions on PowerShell?

2016-08-19 Thread Sebastiaan Lokhorst via arch-general
2016-08-19 17:36 GMT+02:00 Jayesh Badwaik :
>
> The point was patents.
>

A company can give out licenses to use a patent. If Microsoft would have
patented stuff in PowerShell, but then releases them with the following
license included:

> Permission is hereby granted, free of charge, to any person obtaining a
copy
> of this software and associated documentation files (the "Software"), to
deal
> in the Software without restriction, including without limitation the
rights
> to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> copies of the Software ...

Then Microsoft has given you a license to use that patent under the
conditions listed above, and they cannot sue you.

Please correct me if I'm mistaken.


Re: [arch-general] Opinions on PowerShell?

2016-08-19 Thread Sebastiaan Lokhorst via arch-general
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.


Re: [arch-general] Eclipse-java and java7

2016-06-25 Thread Sebastiaan Lokhorst via arch-general
You seem to be right:
https://wiki.eclipse.org/Eclipse/Installation/Java8Required


Re: [arch-general] Problem with pacman hooks, alphabetic order.

2016-05-15 Thread Sebastiaan Lokhorst
2016-05-14 1:15 GMT+02:00 Carsten Feuls :
>
> I have tested to rename the etckeeper-post-install.hook to
> "99-etckeeper-post-
> install.hook" but it does not help, because numbers run before characters.
>

Well, the obvious solution is to rename it to "zz-etckeeper..", but of
course that also isn't a great long-term solution.

I think you should file a bug report. Maybe the package maintainer can come
up with a better fix, and otherwise they can get in touch with the Pacman
developers for an upstream enhancement.


Re: [arch-general] terminal

2016-03-18 Thread Sebastiaan Lokhorst
This is a known bug in Linux 4.4.[1]
It should be fixed in 4.5, which is in [testing] now, so you can try it out.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=93483


Re: [arch-general] Missing Dependency virtualbox-host-dkms

2016-03-07 Thread Sebastiaan Lokhorst
2016-03-08 0:10 GMT+01:00 Jack O'Connor :
>
> Would it be possible to depend on a "Provides" that all the different
> kernel header packages share? Similar to how nvidia-libgl,
> catalyst-libgl, and mesa-libgl all provide the "libgl" dependency.
> That would solve the presumably-very-common case where users initially
> installed virtualbox without any host headers at all, and are now
> landing in a broken state by default. (Or would that mean that the
> different header packages conflict where they didn't before?)


Yes, I think that would be the best solution. Each '*-headers' package
could provide 'kernel-headers' (or something like that).
Provides does not imply conflict, so that wouldn't be a problem.

Note that a user could still install a certain 'x-headers' which does not
match their 'y' kernel, since the headers do not depend on the kernel or
vice versa. (in the libgl case this is not a problem, since the libgl
packages depend on the matching driver)

But I think most users who use the regular kernel and are not familiar with
other kernels would install the plain 'linux-headers' package when
prompted, and not the 'linux-lts-headers' package or something else.


Re: [arch-general] How much people use Arch Linux

2016-02-18 Thread Sebastiaan Lokhorst
2016-02-18 21:42 GMT+01:00 Tim Ohliger :

> I do not know about a download counter, but maybe distrowatch.com is what
> you are looking for.
>

DistroWatch itself says:
>The DistroWatch Page Hit Ranking statistics (...) correlate neither to
usage nor to quality and should not be used to measure the market share of
distributions.

So that's not a good measure.

The only statistics I know about are at [1], but those are opt-in. So
probably not a good measure either.

Regards,
Sebastiaan

[1] https://www.archlinux.de/?page=Statistics


Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

2016-02-01 Thread Sebastiaan Lokhorst
2016-02-01 23:29 GMT+01:00 Leonid Isaev :

> On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
> > Tomasz Kramkowski wrote:
> > * Use legacy BIOS.  There is nothing wrong with it.
> Exactly, I really don't understand this interest to UEFI (and don't mention
> secureboot).
>

Many new (OEM) machines do not support legacy BIOS.


Re: [arch-general] opinion request about Firefox add-ons

2016-01-31 Thread Sebastiaan Lokhorst
I think everyone is missing the point: the firefox-adblock-plus package[1]
is broken since it does not work with the latest version of Firefox.
It should probably be dropped from the repositories. I've opened a bug
report.[1]

[1] https://bugs.archlinux.org/task/47970


Re: [arch-general] Removal of php-pear, what provides functionality

2016-01-07 Thread Sebastiaan Lokhorst
There is no change in PEAR upstream. It has not been deprecated nor is it
included with PHP.
Instead, the maintainer of the Arch Linux package decided to no longer
package it.[1]

Are you sure your GroupWare app needs PEAR? PEAR is usually only used to
install dependencies, which can also be done in some other way.

[1] https://pierre-schmitz.com/php-7-on-arch-linux/


Re: [arch-general] [arch-dev-public] PHP 7

2015-12-31 Thread Sebastiaan Lokhorst
2015-12-31 22:15 GMT+01:00 Genes Lists :

>
> I'm having trouble with nginx after this update. This is just getting the
> top level page which is simple php.
>
> 2015/12/31 16:05:01 [crit] 476#0: *5 connect() to
> unix:/run/php-fpm/php-fpm.sock failed (13: Permission denied) while
> connecting to upstream, client: xxx, server: www.sapience.com, request:
> "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/php-fpm.sock:",
> host: "www.sapience.com"
>

Make sure the following lines in /etc/php/php-fpm.d/www.conf are
uncommented and pointing to the right user/group:
 ;listen.owner = http
 ;listen.group = http


Re: [arch-general] virt-manager empty package?

2015-12-25 Thread Sebastiaan Lokhorst
2015-12-25 13:25 GMT+01:00 Sebastiaan Lokhorst <sebastiaanlokho...@gmail.com
>:

> It can't be right that this PKGBUILD[1] produces a completely empty
> package.
>

Okay, apparently it is.
*https://bugs.archlinux.org/task/43881
<https://bugs.archlinux.org/task/43881>*


Re: [arch-general] virt-manager empty package?

2015-12-25 Thread Sebastiaan Lokhorst
It can't be right that this PKGBUILD[1] produces a completely empty package.
I have filed a bug.[2]

[1]
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/virt-manager
[2] https://bugs.archlinux.org/task/47527

2015-12-25 3:49 GMT+01:00 Neven Sajko :

> virt-install is just for console usage, as is indicated in its
> package description, and virt-manager package adds and sets up
> dependencies needed for desktop parts of virt-manager.
>


Re: [arch-general] Community and TU questions

2015-12-09 Thread Sebastiaan Lokhorst
You can easily search the bug tracker[1] yourself, and help out with bugs
in packages you are familiar with.
Maintaining packages is usually not very time-intensive for the
maintainers. So I think that there is little to offer there.
Besides that, you can have a look at this page[2] for more things to do.

Basically, you don't have to be a TU to help out on most tasks.

Good luck and thanks in advance,
Sebastiaan

[1] https://bugs.archlinux.org/
[2] https://wiki.archlinux.org/index.php/Getting_involved


Re: [arch-general] Linux still at 4.2, but nvidia and virtualbox compiled for 4.3?

2015-11-24 Thread Sebastiaan Lokhorst
2015-11-24 18:42 GMT+01:00 João Miguel :
>
> Boy, I wish I was as cautious as you before updating... I was about to
> post that after updating nvidia drivers, trying to start the X will get
> you a black screen. I had assumed it was related to the custom kernel
> and/or DKMS, but the problem appears with the regular nvidia package and
> kernel. Well, I guess I can always downgrade.
>
> Thanks for the post, I must remember to check my email more often
>

Did you update today? Laurent fixed the nvidia package the same day (22
Nov.), which is in [extra] now. There shouldn't be any problems with the
current package.


[arch-general] Linux still at 4.2, but nvidia and virtualbox compiled for 4.3?

2015-11-22 Thread Sebastiaan Lokhorst
So I just did an update and got the following messages:

(16/24) upgrading nvidia
[--] 100%
cat: /usr/lib/modules/extramodules-4.3-ARCH/version: No such file or
directory

(20/24) upgrading virtualbox-host-modules
 [--] 100%
cat: /usr/lib/modules/extramodules-4.3-ARCH/version: No such file or
directory

It seems like these are looking for Linux 4.3, but the linux package in
[core] is still at 4.2.

I'm afraid if I'll reboot, there will be problems with the graphics driver.
Why wasn't the linux package updated alongside these others?

Or am I wrong, and is this harmless?


Re: [arch-general] Linux still at 4.2, but nvidia and virtualbox compiled for 4.3?

2015-11-22 Thread Sebastiaan Lokhorst
2015-11-22 11:30 GMT+01:00 Laurent Carlier :
>
> This should be fixed with 5.0.10-2.1 version
>

Thanks, it is!

What about the nvidia package? Should I file a bug?


Re: [arch-general] Linux still at 4.2, but nvidia and virtualbox compiled for 4.3?

2015-11-22 Thread Sebastiaan Lokhorst
2015-11-22 12:35 GMT+01:00 Laurent Carlier <lordhea...@gmail.com>:

> Le dimanche 22 novembre 2015, 12:08:28 CET Sebastiaan Lokhorst a écrit :
> > 2015-11-22 11:30 GMT+01:00 Laurent Carlier <lordhea...@gmail.com>:
> > > This should be fixed with 5.0.10-2.1 version
> >
> > Thanks, it is!
> >
> > What about the nvidia package? Should I file a bug?
>
> Should be fixed also with 358.16-2.1 version :)
>
> --
> Laurent Carlier
> http://www.archlinux.org
>

Great! Thanks again for the fast response! :)


Re: [arch-general] Any ETA on the Tex Live 2015 update?

2015-08-24 Thread Sebastiaan Lokhorst
2015-08-22 21:27 GMT+02:00 Mohammad_AlSaleh ce.mohammad.alsa...@gmail.com:

 I'm wondering if there is any reason for the hold-up. Other than
 the maintainers(s) being busy of course.


I'm also curious about this. It seems like the maintainer hasn't been
active for the past 5 months.[1]
What is the normal course of action in such a case? For instance, how could
I contact the maintainer?

Thanks,
Sebastiaan

[1] https://www.archlinux.org/packages/?maintainer=remy


Re: [arch-general] filezilla won't start

2015-08-23 Thread Sebastiaan Lokhorst
2015-08-24 0:37 GMT+02:00 James bjloc...@lockie.ca:

 I did a fresh install of filezilla and tried to start it but it didn't
 start.
 filezilla-3.12.0.2-1
 Here's a picture:
 http://lockie.ca/test/filezilla_017.png


This is a bug that has been fixed:
https://trac.filezilla-project.org/ticket/10598
I'm not sure why there hasn't been a new release yet though...

By the way, you can just click 'continue' and keep using the program.

Sebastiaan


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Sebastiaan Lokhorst
It is very simple. The bare minimum Arch install consist of the base
https://www.archlinux.org/groups/x86_64/base/ group.

The user *must* install this group. If they don't, they no longer have a
minimal Arch install, so developers cannot help them. It is the *base* and
everything else builds on it.
It would make no sense to replace the *linux*, *filesystem* or *pacman*
package with something incompatible and expect everything to keep working.

Now, it would be technically possible to replace *systemd* in base with a
generic init-system which could be provided by both *systemd* and *openrc*,
but that would make things much more complicated and *much* more effort to
maintain.

Regards,
Sebastiaan


Re: [arch-general] core/linux provides kernel*26*, not kernel4

2015-05-03 Thread Sebastiaan Lokhorst
2015-05-03 15:10 GMT+02:00 Doug Newgard scim...@archlinux.info:

 It's left over from when the package was named differently.


So they serve no purpose anymore, right?

I have opened a bug report asking for them to be removed:
https://bugs.archlinux.org/task/44826

Thanks,
Sebastiaan


Re: [arch-general] core/linux provides kernel*26*, not kernel4

2015-05-03 Thread Sebastiaan Lokhorst
2015-05-03 18:29 GMT+02:00 Doug Newgard scim...@archlinux.info:

 The only purpose they would serve would be someone running extremely out of
 date packages or trying to upgrade an extremely out of date system.


I don't think a system running a 2.6 kernel would be salvageable anyway.
The many filesystem, systemd, etc upgrades would make this a horrible job.
;)

2015-05-03 18:29 GMT+02:00 Doug Newgard scim...@archlinux.info:

 Of course, they also don't hurt anything.


That's also true, but we like to Keep It Simple, right. ;) (although this
might be a bit overly obsessive)

Sebastiaan


Re: [arch-general] Post-packaging modification tool

2015-04-28 Thread Sebastiaan Lokhorst
2015-04-28 18:50 GMT+02:00 Magnus Therning mag...@therning.org:

 I have a large set of already packages (300+) that I'd like to make
 some minor modifications to the meta data in.  Since it takes a few
 hours to build them all I'd prefer to avoid dong that.  So, is there
 a tool out there that allows me to make some minor changes to the meta
 data of a package?


A package is just a tar.xz, so you can simply unzip it, edit the .PKGINFO
file, and zip it again. (I think)


Re: [arch-general] fdisk vs. gdisk for GPT partitioning

2015-02-11 Thread Sebastiaan Lokhorst
2015-02-11 19:13 GMT+01:00 Jude DaShiell jdash...@shellworld.net:

 Yes, I couldn't create an ef02 partition using fdisk.  I ended up using
 gdisk and the job got done with no problem at all.


You can create a BIOS boot partition (ef02 in gdisk) in fdisk:
Press p to change partition type, press L to list partition types, and
look for BIOS boot partition:
4 BIOS boot ...
type 4

done!

Or did you mean something else?


Re: [arch-general] broken locale after glibc upgrade

2015-02-11 Thread Sebastiaan Lokhorst
2015-02-11 10:47 GMT+01:00 arnaud gaboury arnaud.gabo...@gmail.com:

 I had to manually edit /etc/locale.gen, uncomment the needed locales,
 then run locale-gen to fix this issue.


You likely overwrote locale.gen with locale.gen.pacnew and forgot to
uncomment any locales.


Re: [arch-general] fdisk vs. gdisk for GPT partitioning

2014-12-21 Thread Sebastiaan Lokhorst
Thanks everyone for your responses! It seems that gdisk is still favorable
for advanced tasks, but fdisk is can be used for basic tasks, as are
usually required by beginners.

2014-12-17 5:43 GMT+01:00 Stefan Höck efascken...@gmail.com:

 However, I think we still should consider having only UEFI in the
 beginners guide and link to a separate wiki entry if somebody needs an
 MBR partition.


I really like this idea but I think it is not quite the time yet. We're
trying to simplify everything else though, so I hope that the Beginners'
guide will be clearer anyway.

2014-12-21 20:54 GMT+01:00 Leonid Isaev lis...@umail.iu.edu:

 Yes. The age of a machine has no relevance for deciding whether to use GPT
 (or
 UEFI in general).


This is not true. Some low-end modern machines completely drop legacy BIOS
boot. So booting via UEFI is required, and thus GPT is required.

Thanks,
Sebastiaan


Re: [arch-general] fdisk vs. gdisk for GPT partitioning

2014-12-21 Thread Sebastiaan Lokhorst
2014-12-21 22:48 GMT+01:00 Leonid Isaev lis...@umail.iu.edu:

  This is not true. Some low-end modern machines completely drop legacy
 BIOS
  boot. So booting via UEFI is required, and thus GPT is required.

 I really doubt this. Are you saying that some vendors on purpose break such
 things as booting from an external USB key?


USB keys can also boot in UEFI mode, see for instance the Arch install
medium. But only if the creator of the key included an UEFI boot file of
course.

An example of newer laptops not having legacy BIOS (or at least disabling
it): [1]. An explanation that legacy BIOS is optional: [2].

Thanks,
Sebastiaan

[1]
http://h30434.www3.hp.com/t5/Notebook-Operating-Systems-and-Software/Pavilion-11-x2-no-legacy-option-in-bios-settings/td-p/3756368
[2]
https://embedded.communities.intel.com/servlet/JiveServlet/previewBody/6775-102-1-1846/AMI_Intro_to_UEFI_PUB.pdf
(see page 8-9)


[arch-general] fdisk vs. gdisk for GPT partitioning

2014-12-16 Thread Sebastiaan Lokhorst
Hello everyone,

Since more than a year now, fdisk (provided by util-linux) has had GPT
support. This theoretically makes gdisk a duplicate of fdisk, and we could
replace gdisk with fdisk.

Now, I'm not asking to drop gdisk or anything like that, but in an effort
to clean up the Beginners' guide of the Arch Wiki, we want to use a single
partitioning tool for both MBR and GPT partitioning instructions.[1]
util-linux fdisk is able to provide this functionality, but we are not
completely sure if it is stable by now (it should be, I think).

So, now my question: is there anyone who has had bad experiences with fdisk
and GPT partitions, where gdisk was superior? Or any other objections why
we should keep gdisk instructions in the Beginners' guide?

Thanks!
Sebastiaan

[1]
https://wiki.archlinux.org/index.php/Talk:Beginners%27_guide#remove_gdisk_instructions_for_install_medium_2013-11


Re: [arch-general] Netflix in Arch?

2014-10-14 Thread Sebastiaan Lokhorst
2014-10-14 8:13 GMT+02:00 Hugo Osvaldo Barrera h...@barrera.io:

 There would be little point in getting it to work with Chromium anyway. Why
 would you care if you're using an open source browser if you're gonna add a
 propietary DRM plugin onto it?
 Just pick Chrome and avoid the hastle. That is, after all, what Chrome is:
 Chromium + propietary addons (+ some rebranding).


A proprietary plugin can be sandboxed, to be sure it doesn't do anything
it's not supposed to do. That's at least the idea that the Firefox people
want to implement.

Besides that, just using Chrome is indeed the easiest solution right now.
The only problem is that it is not in the official Arch repositories,
leading to more hassle.

Would it be possible to move it there from the AUR? We have lots of
closed-source software in the official repositories, and I think Chrome
(with EME and Flash Player built in!) would be very useful for people. We
already have the old NPAPI Flash Player, so I don't see why this would be a
problem.

Sebastiaan


Re: [arch-general] Netflix in Arch?

2014-10-14 Thread Sebastiaan Lokhorst
2014-10-14 8:40 GMT+02:00 Doug Newgard scim...@archlinux.info:

 On Tue, 14 Oct 2014 08:28:46 +0200
 Sebastiaan Lokhorst sebastiaanlokho...@gmail.com wrote:

  2014-10-14 8:13 GMT+02:00 Hugo Osvaldo Barrera h...@barrera.io:
 
   There would be little point in getting it to work with Chromium
   anyway. Why would you care if you're using an open source browser
   if you're gonna add a propietary DRM plugin onto it?
   Just pick Chrome and avoid the hastle. That is, after all, what
   Chrome is: Chromium + propietary addons (+ some rebranding).
  
 
  A proprietary plugin can be sandboxed, to be sure it doesn't do
  anything it's not supposed to do. That's at least the idea that the
  Firefox people want to implement.
 
  Besides that, just using Chrome is indeed the easiest solution right
  now. The only problem is that it is not in the official Arch
  repositories, leading to more hassle.
 
  Would it be possible to move it there from the AUR? We have lots of
  closed-source software in the official repositories, and I think
  Chrome (with EME and Flash Player built in!) would be very useful for
  people. We already have the old NPAPI Flash Player, so I don't see
  why this would be a problem.
 
  Sebastiaan

 I believe the closed source portions are non-redistributable.


Unfortunately, you seem to be right...
From https://www.google.com/intl/en/chrome/browser/privacy/eula_text.html :

5.3 Unless you have been specifically permitted to do so in a separate
agreement with Google, you agree that you will not reproduce, duplicate,
copy, sell, trade or resell the Services for any purpose.

Thanks for the quick reply anyway! :)
Sebastiaan


Re: [arch-general] Netflix in Arch?

2014-10-11 Thread Sebastiaan Lokhorst
Just because there still seems to be some confusion:

Plugin-free Netflix requires Embedded Media Extensions (EME).[1] This is
supported by all major closed-source browsers: Internet Explorer, Safari
and Chrome.
This includes Chrome on Arch (available in the AUR), without the need for
any user-agent hacking or plugins.

EME however requires a closed source component, therefore it is NOT
available in open-source browsers, such as Chromium and Firefox, and likely
_never_ will be.
In the future, it might be possible to use some kind of closed-source
plugin to support this in open-source browsers, but there is none at the
moment. (there was some discussion about this with Firefox, see [1] for
more details)

So basically, at the moment you have two options to use Netflix on Arch:
(1) install a closed-source browser (i.e. Chrome) with EME, where it will
work out-of-the-box, or (2) install a open-source browser with all kinds of
hackery such as Pipelight.

I hope that this clears things up.
Sebastiaan

[1] https://en.wikipedia.org/wiki/Encrypted_Media_Extensions


Re: [arch-general] [aur-general] lists.archlinux.org mailing list memberships reminder

2014-10-01 Thread Sebastiaan Lokhorst
2014-10-01 14:24 GMT+02:00 Marcel Korpel marcel.kor...@gmail.com:

 Even if it's removed, it means that mailman stores passwords in plain
 text, which is a bad thing.

 Regards,
 Marcel


From the mailman page:

You may enter a privacy password below. This provides only mild security,
but should prevent others from messing with your subscription. *Do not use
a valuable password* as it will occasionally be emailed back to you in
cleartext.


Re: [arch-general] Gnome extensions and the extension site

2014-09-03 Thread Sebastiaan Lokhorst
What browser are you using?
If it is Chromium/Google Chrome, they dropped support for NPAPI plugins, so
this will not work in Chromium anymore.
If your using Firefox, do you see Gnome Shell Integration in about:addons
in the Plugins tab?


Re: [arch-general] LibreOffice update

2014-08-23 Thread Sebastiaan Lokhorst
2014-08-23 20:20 GMT+02:00 Andreas Radke andy...@archlinux.org:

 We dropped the app splitting because they are of small size and sometimes
 upstream broken the
 dependencies between the parts.


Does this also mean we will stop splitting -still? It is strange to split
Still but not Fresh. (I'm all for shipping one large pkg by the way)

Thanks,
Sebastiaan


Re: [arch-general] LibreOffice update

2014-08-23 Thread Sebastiaan Lokhorst
2014-08-23 21:30 GMT+02:00 Andreas Radke andy...@archlinux.org:

 Am Sat, 23 Aug 2014 20:32:42 +0200
 schrieb Sebastiaan Lokhorst sebastiaanlokho...@gmail.com:

  2014-08-23 20:20 GMT+02:00 Andreas Radke andy...@archlinux.org:
  
   We dropped the app splitting because they are of small size and
   sometimes upstream broken the
   dependencies between the parts.
  
 
  Does this also mean we will stop splitting -still? It is strange to
  split Still but not Fresh. (I'm all for shipping one large pkg by the
  way)
 
  Thanks,
  Sebastiaan
 

 Development happens in the fresh packages. All changes will move over
 to the still package when a new major fresh release happens. Then the
 massive splitting will be dropped.

 -Andy


Ah, that makes sense. Thanks for clearing it up!

Sebastiaan


Re: [arch-general] Skype and PA

2014-06-23 Thread Sebastiaan Lokhorst
It works (the application starts and you can chat), but anything related to
audio does not work. So when you are calling someone you can't hear them
and they can't hear you.


2014-06-23 16:42 GMT+02:00 Manolo Martínez man...@austrohungaro.com:

 Hello,

 Pacman warns that Skype 4.3 only works with Pulseaudio. As far as I can
 tell, that is not true. I don't use PA, and Skype works.

 Manolo

 --



Re: [arch-general] [arch-dev-public] Upgrading Apache to 2.4

2014-03-07 Thread Sebastiaan Lokhorst
Thanks for taking the effort to finally update Apache!

When trying to start Apache with PHP, I get the same error as Rene.

Just to be clear, what is the recommended way to run Apache+PHP now? Will
mod_php5 will still be supported?

Thanks!
Sebastiaan


2014-03-07 0:52 GMT+01:00 Armin K. kre...@email.com:

 On 03/07/2014 12:39 AM, Anatol Pomozov wrote:
  Hi
 
  + php maintainer
 
  On Thu, Mar 6, 2014 at 3:05 PM, Rene Pasing r...@pasing.net wrote:
  Hi Anatol,
 
  On 03/06/2014 10:48 PM, Anatol Pomozov wrote:
  Apache 2.4 has been moved from [testing] to [extra] and now available
  for everyone. Please update your setup, follow the migration
  instructions https://httpd.apache.org/docs/trunk/upgrading.html and
  report any problems. Thanks everyone.
 
  I get the following error:
 
  Mar 06 23:59:34 VAIO-ARCH apachectl[697]: [Thu Mar 06 23:59:34.072638
  2014] [:crit] [pid 699:tid 139754760394624] Apache is running a threaded
  MPM, but your PHP Module is not compiled to be threadsafe.  You need to
  recompile PHP.
  Mar 06 23:59:34 VAIO-ARCH apachectl[697]: AH00013: Pre-configuration
 failed
  Mar 06 23:59:34 VAIO-ARCH systemd[1]: httpd.service: control process
  exited, code=exited status=1
  Mar 06 23:59:34 VAIO-ARCH systemd[1]: Failed to start Apache Web Server.
  Mar 06 23:59:34 VAIO-ARCH systemd[1]: Unit httpd.service entered failed
  state.
 
  I will switch to php-fpm soon, but nevertheless... Just wanted you to be
  aware... ;-)
 
  Sounds like a bug to me. Mind filing one at bugs.archlinux.org?
 
  Pierre, I found some information in Google+ related to apache24
  package in aur: The only thing was that I had to recompile PHP to be
  thread-safe. It was '--enable-zts' parameter, I think The flag
  sounds like a solution for this bug.
 

 Default mpm in apache is thread safe one. You need to switch to
 non-thread safe one (prefork?) in order to use mod_php5 with apache2.4

 --
 Note: My last name is not Krejzi.



[arch-general] efivars kernel module not loaded automatically in 3.10 kernel

2013-08-06 Thread Sebastiaan Lokhorst
Hello fellow Archers,

I've noticed that the efivars kernel module is no longer loaded
automatically. Previously (I believe also in 3.9), it was loaded by default
and commands like gummiboot and efibootmgr would work without any manual
loading. The wiki[1] also explains that it should be enabled in the stock
Arch kernel.

I am not sure if this is intended, but if it is, all UEFI bootloader
instructions should be updated because none of them work without efivars.

Thanks!
Sebastiaan

[1]
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_Support_in_Linux_Kernel