Re: [arch-general] community/NUT access cgi in /usr/share/nut/cgi without FollowSymLinks?

[Maxime Gauduin via arch-general]

June 3, 2020 8:24 AM, "David C. Rankin"  wrote:

> All / Maxime,
> 
> With the nut build option setting:
> 
> --with-cgipath=/usr/share/nut/cgi \
> 
> when using apache with the default /srv/http/cgi-bin location, how
> are you
> supposed to access the cgi files in /usr/share/nut/cgi "Safely"?
> 
> I have the entire /usr/share/nut/html directory protected by a dbm
> database
> file manipulated with dbmmanage, so to reach the  you must
> authenticate. That said, the only way I can make the cgi scripts work
> is by
> setting Options FollowSymLinks in the  for "/srv/http/cgi-
> bin"
> after symlinking (e.g. ln -s /usr/share/nut/cgi /srv/http/cgi-
> bin/nut)
> 
> Is this safe? Is this intended way to provide access to the cgi
> scripts?
> 
> -- 
> David C. Rankin, J.D.,P.E.

Hi David,

I haven't used apache in years so please take this with a grain of
salt. On nginx I'm using the alias directive, restricting access to
the upsset.cgi to my local network [0], as suggested by the nut
documentation in /etc/upsset.conf. It seems apache has a similar alias 
directive so you may be able to achieve the same without using any symlink [1].

[0] https://paste.xinu.at/BNUJFeuBycXUw8fB/
[1] https://httpd.apache.org/docs/2.4/mod/mod_alias.html#alias

Cheers,
-- 
Maxime

Re: [arch-general] community/NUT replacing Network-UPS-Tools -- won't start.

[Maxime Gauduin via arch-general]

On Fri, 2020-05-29 at 04:25 -0500, David C. Rankin wrote:
> On upgrade I agreed to:
> 
> :: Replace network-ups-tools with community/nut? [Y/n]
> 
> network-ups-tools-2.7.4-5 [removal]  nut-2.7.4-1
> 
> (both same version of package)
> 
> However, after install, the nut-server.service would not start. Here
> are the
> logs for the last start before update and then the failure after the
> update:
> 
> -- Reboot --
> May 23 03:00:55 2pi systemd[1]: Starting Network UPS Tools - power
> devices
> information server...
> May 23 03:00:56 2pi upsd[474]: fopen /var/state/ups/upsd.pid: No such
> file or
> directory
> May 23 03:00:56 2pi upsd[474]: listening on 127.0.0.1 port 3493
> May 23 03:00:56 2pi upsd[474]: listening on 127.0.0.1 port 3493
> May 23 03:00:56 2pi upsd[474]: listening on ::1 port 3493
> May 23 03:00:56 2pi upsd[474]: listening on ::1 port 3493
> May 23 03:00:56 2pi upsd[474]: Connected to UPS [stp_ups]: usbhid-
> ups-stp_ups
> May 23 03:00:56 2pi upsd[474]: Connected to UPS [stp_ups]: usbhid-
> ups-stp_ups
> May 23 03:00:56 2pi upsd[475]: Startup successful
> May 23 03:00:56 2pi systemd[1]: Started Network UPS Tools - power
> devices
> information server.
> May 29 03:55:42 2pi upsd[475]: mainloop: Interrupted system call
> May 29 03:55:42 2pi upsd[475]: Signal 15: exiting
> May 29 03:55:42 2pi systemd[1]: Stopping Network UPS Tools - power
> devices
> information server...
> May 29 03:55:42 2pi systemd[1]: nut-server.service: Succeeded.
> May 29 03:55:42 2pi systemd[1]: Stopped Network UPS Tools - power
> devices
> information server.
> -- Reboot --
> May 29 03:58:08 2pi systemd[1]: Starting Network UPS Tools - power
> devices
> information server...
> May 29 03:58:08 2pi upsd[480]: fopen /run/nut/upsd.pid: No such file
> or directory
> May 29 03:58:08 2pi upsd[480]: /etc/nut/upsd.conf is world readable
> May 29 03:58:08 2pi upsd[480]: /etc/nut/upsd.conf is world readable
> May 29 03:58:08 2pi upsd[480]: listening on 127.0.0.1 port 3493
> May 29 03:58:08 2pi upsd[480]: listening on ::1 port 3493
> May 29 03:58:08 2pi upsd[480]: listening on 127.0.0.1 port 3493
> May 29 03:58:08 2pi upsd[480]: listening on ::1 port 3493
> May 29 03:58:08 2pi upsd[480]: Warning: no UPS definitions in
> ups.conf
> May 29 03:58:08 2pi upsd[480]: Fatal error: at least one UPS must be
> defined
> in ups.conf
> May 29 03:58:08 2pi upsd[480]: Network UPS Tools upsd 2.7.4
> May 29 03:58:08 2pi upsd[480]: Warning: no UPS definitions in
> ups.conf
> May 29 03:58:08 2pi upsd[480]: Fatal error: at least one UPS must be
> defined
> in ups.conf
> May 29 03:58:08 2pi systemd[1]: nut-server.service: Control process
> exited,
> code=exited, status=1/FAILURE
> May 29 03:58:08 2pi systemd[1]: nut-server.service: Failed with
> result
> 'exit-code'.
> May 29 03:58:08 2pi systemd[1]: Failed to start Network UPS Tools -
> power
> devices information server.
> May 29 04:09:14 2pi systemd[1]: Starting Network UPS Tools - power
> devices
> information server...
> May 29 04:09:14 2pi systemd[1]: nut-server.service: Control process
> exited,
> code=exited, status=1/FAILURE
> May 29 04:09:14 2pi systemd[1]: nut-server.service: Failed with
> result
> 'exit-code'.
> May 29 04:09:14 2pi systemd[1]: Failed to start Network UPS Tools -
> power
> devices information server.
> 
> There is the very same definition of the ups in ups.conf, e,g,
> 
> [stp_ups]
> driver = usbhid-ups
> port = auto
> desc = "stp CP825 UPS"
> 
> 
> Removing the community package and reinstalling the old package works
> fine, e,g,
> 
> 04:16 2pi:~/.../pkg/x86_64/nut> sc restart nut-server
> 04:17 2pi:~/.../pkg/x86_64/nut> upsc stp_ups
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 20
> battery.mfr.date: CPS
> battery.runtime: 3180
> battery.runtime.low: 300
> battery.type: PbAcid
> battery.voltage: 13.4
> battery.voltage.nominal: 12
> device.mfr: CPS
> device.model: UPS CP825
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.synchronous: no
> driver.version: 2.7.4
> driver.version.data: CyberPower HID 0.4
> driver.version.internal: 0.41
> input.transfer.high: 140
> input.transfer.low: 100
> input.voltage: 122.0
> input.voltage.nominal: 120
> output.voltage: 122.0
> ups.beeper.status: enabled
> ups.delay.shutdown: 20
> ups.delay.start: 30
> ups.load: 15
> ups.mfr: CPS
> ups.model: UPS CP825
> ups.productid: 0501
> ups.realpower.nominal: 450
> ups.status: OL
> ups.test.result: Done and passed
> ups.timer.shutdown: -60
> ups.timer.start: 0
> ups.vendorid: 0764
> 
> Why doesn't the new nut from community work?
> 

Hi David,

The configuration for nut is now in `/etc/nut` as it should be, instead
of `/etc/ups`. You will need to migrate your previous configuration.
Modified the wiki to reflect that.

Cheers,
-- 
Maxime

Re: [arch-general] PC build for hardware video acceleration

[Maxime Gauduin via arch-general]

On Fri, 2019-07-19 at 13:00 +0300, L. Rose wrote:
> Dear community,
> 
> I want to build a new CPU-focused Arch Linux PC. No requirements for
> GPU, except for H.265 4K decode, in decent profiles (whatever that
> means).
> 
> What hardware is best supported by libraries like VA-API and VDPAU?
> Are there other relevant libraries? Which libraries are still
> maintained and up-to-date, which are open source?
> 
> I see three options right now:
> 
> 1. High-end Intel CPU (e.g. i9-9900K) w/ integrated HD 630 GPU, or
> 2. CPU w/o iGPU (e.g. AMD Ryzen Threadripper 2920X) + dedicated, low-
> end AMD GPU (e.g. Radeon RX 560)
> 3. CPU w/o iGPU and low-end NVidia GPU (e.g. GTX 1050)
> 
> I couldn't find out which setup works best using the wiki and other
> sources. Maybe anyone could point me to the right direction? What
> hardware is recommended for good H.265 4K playback on GPU?
> 
> Thanks in advance, kind regards,
> 
> L.

Hi there,

I can vouch for option 3, and am pretty confident option 1 will do as
well. I only used AMD at a time where their driver was absolutely
terrible so I can't say for option 2.

Got a Xeon paired with a 1050 which does x265 4K HDR effortlessly,
you'll want to use the binary blob paired with NVDEC if you go that
route.

For option 1 you'll want to use VAAPI paired with the recent intel-
media-driver, should tackle the workload just fine as well.

FYI VDPAU is pretty much dead, you can forget about it.

Cheers,
-- 
Maxime

Re: [arch-general] mythtv

[Maxime Gauduin via arch-general]

On Mon, Jan 8, 2018 at 05:48 PM, Giancarlo Razzolini via arch-general  wrote:
Em janeiro 8, 2018 12:53 Jameson via arch-general escreveu:
With the mythtv packages being dropped to the AUR, are there any remaining
options for DVR software in the official repos?

=-Jameson

Hi Jameson,

I might be wrong, but I think the only other option is kodi.

Regards,
Giancarlo Razzolini
Hi Jameson,

I've never used that functionality, but emby-server supports DVR as well.

Cheers,
-- 
Maxime

Re: [arch-general] Why isn't RetroArch in the Arch repos?

[Maxime Gauduin]

On Sun, May 1, 2016 at 9:33 PM, Rob Miller <docro...@riseup.net> wrote:

> On Sun, May 01, 2016 at 09:26:20PM +0200, Maxime Gauduin wrote:
> > On Sun, May 1, 2016 at 9:07 PM, Rob Miller <docro...@riseup.net> wrote:
> >
> > > On Sun, May 01, 2016 at 03:40:39PM -0300, Diego Viola wrote:
> > > > Any reasons?
> > >
> > > Probably due to not enough interest in the package. Also, despite the
> > > name, RetroArch has nothing whatsoever to do with the Arch Linux
> > > project. Just thought this might bear mentioning.
> > >
> >
> > Just a heads up, I am and have been interested in bringing retroarch into
> > [community] and have had nightly builds going around for a while.
> Hopefully
> > I'll have the time to do so in a not so distant future.
> >
> > Cheers,
> > --
> > Maxime
>
> Is it only a matter of time, or are there other things in the way?
> Anything that people can help with?
>

Time only, the build issues I had when I first got into it were fixed in
the 1.3 release.

Cheers,
--
Maxime

Re: [arch-general] Why isn't RetroArch in the Arch repos?

[Maxime Gauduin]

On Sun, May 1, 2016 at 9:07 PM, Rob Miller  wrote:

> On Sun, May 01, 2016 at 03:40:39PM -0300, Diego Viola wrote:
> > Any reasons?
>
> Probably due to not enough interest in the package. Also, despite the
> name, RetroArch has nothing whatsoever to do with the Arch Linux
> project. Just thought this might bear mentioning.
>

Just a heads up, I am and have been interested in bringing retroarch into
[community] and have had nightly builds going around for a while. Hopefully
I'll have the time to do so in a not so distant future.

Cheers,
--
Maxime

Re: [arch-general] Mkvtoolnix-gui/cli

[Maxime Gauduin]

On Sun, Oct 4, 2015 at 11:33 AM, Vladimir Nikšić  wrote:

> Thanks, I understand now, I'll look into it!
> On Oct 4, 2015 10:13 AM, "Moritz Bunkus"  wrote:
>
> > Hey,
> >
> > > After the latest "pacman -Syu" I'm having a weird issue, I've upgraded
> > > the mkvtoolnix package, and I seem to have lost the "mmg" program.
> >
> > mmg (the old GUI) has been superseded by the new GUI (MKVToolNix
> > GUI) which in turn has been part of official MKVToolNix releases since
> > 8.0.0. The old one's been removed in 8.4.0.
> >
> > Now about Arch packaging: there are four open bugs already for this[1]
> > as the Arch package doesn't include the new GUI yet. Additionally there
> > has been a thread about this on this very mailing list a couple of days
> > ago[2]. That thread includes proposed PKGBUILDs that include the new
> > GUI. You can give those a try.
> >
> > Kind regards,
> > mosu
> >
> > [1]
> >
> https://bugs.archlinux.org/index.php?string=mkvtoolnix=0_name=%5B%5D=%5B%5D=%5B%5D=%5B%5D=%5B%5D=%5B%5D=%5B%5D=open%5B%5D=index
> > [2]  http://thread.gmane.org/gmane.linux.arch.general/54718
> >
>

This will be fixed sometimes during the week, I currently have no internet
connection except at work. I will push updated packages as soon as I have
working internet at home.

Cheers,
--
Maxime

Re: [arch-general] asd

[Maxime Gauduin]

On Wed, Sep 30, 2015 at 9:26 AM, Moritz Bunkus  wrote:

> Hey,
>
> the MKVToolNix author here. First of all I appreciate all the effort of
> packaging MKVToolNix for Arch. Thanks for that.
>
> The orignal PKGBUILD in the repositories builds the whole of MKVToolNix
> twice, once configured with GUI support, once configured without
> it. However, this is not really necessary.
>
> Being configured with and without GUI support only affects two programs:
> mkvinfo and mkvtoolnix-gui. If configured with GUI support then mkvinfo
> will be built including a Qt-based GUI in addition to the
> always-included text mode interface, and mkvtoolnix-gui will be built in
> the first place. If configured without GUI support then mkvinfo will
> only include that text mode interface and mkvtoolnix-gui will not be
> built at all.
>
> Therefore the PKGBUILD in the pastebin cuts down on compilation time by
> only compiling the whole of MKVToolNix once when it's configured with
> GUI support. For the text-mode only version of mkvinfo you only have to
> configure MKVToolNix and build mkvinfo (and then preserve that binary
> over the »drake clean«, of course); nothing else has to be built. Hence
> the pastebin'ed PKGBUILD being a lot faster.
>
> There's only one version of mkvinfo's man page in my upstream MKVToolNix
> source, and the installed version is identical in both cases (configured
> with/without GUI). Therefore including it in each Arch package is indeed
> wasting space.
>
> The mkvtoolnix-gui (and therefore the Arch mkvtoolnix-qt package) cannot
> work without the mkvmerge executable as the GUI uses the CLI-only
> mkvmerge for all of its actual work. Therefore the mkvtoolnix-qt package
> must depend on the mkvtoolnix package, and preferably of the same
> version: I only guarantee that mkvtoolnix-gui version a.b.c will work
> with mkvmerge version a.b.c, nothing else. The GUI will even emit
> warnings if the mkvmerge executable's version differs. Therefore
> upgrading the mkvtoolnix-qt package without upgrading the mkvtoolnix
> package should ideally not be possible.
>
> If you don't want to include mkvinfo's Qt GUI then you still have to do
> both builds. Well, you could leave out mkvinfo during the with-GUI-
> configured build, but that wouldn't cut down on compilation time a lot
> as mkvinfo only consists of three source files on top of the common
> library.
>
> I don't particularly care whether or not mkvinfo's GUI is included in
> the mkvtoolnix-qt package. I've created it mostly for Windows users as
> those are pretty resilient to the advice of using the command line
> version ;) On the other hand I can really understand them when I think
> of cmd.exe…
>
> Kind regards,
> mosu
>

Hi Moritz,

Thanks for the explanation. I keep thinking that we don't need the mkvinfo
GUI.

I tried to use apps:mkvtoolnix-gui to build only that one the second time
around. While it works in build(), invoking drake install in install()
seems to ignore the argument and goes on to build everything else before
installing. Is that expected behavior or am I doing something wrong? Either
way, my CPU has seen worse, building the whole thing twice isn't that big
of a deal.

Cheers,
--
Maxime

Re: [arch-general] mkvtoolnix-gtk: The new GUI is missing

[Maxime Gauduin]

On Tue, Sep 29, 2015 at 12:01 AM, Benjamin Robin  wrote:

> There is a problem with your PKGBUILD. The build performances set aside.
> The PKGBUILD [1] provided in the bug report is built much faster.
>
>
There's no difference here, and there shouldn't be anyway, drake can be
multithreaded make-style with the -j flag or by setting the env variable
like it's currently done. Make-style happens to look neater, and the number
of threads is configured by the user instead of being hardcoded in the
PKGBUILD.


> You try to be able to install mkvtoolnix-qt alone without the
> mkvtoolnix-cli package, right ?
>

Hmm, no?


> Well this cannot work since mkvtoolnix-qt needs the locale/translation.
>
>
You don't say. Read the depends array once more.


> And since mkvtoolnix-cli *must* be a dependency of mkvtoolnix-qt,
> there is no point to have the manual mkvinfo-gui.1 which is identical
> to mkvinfo.1. You can if you want create a symbolic link.


Indeed, in that case I'd rather get rid of the duplicates. If it were up to
me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring
anyhting more compared to the CLI tool, and if people need a GUI, I would
highly recommend MediaInfo instead.


>
> [1] http://pastebin.com/rtguGrbR
>
> > @Benjamin: Feel free to give the diff a spin before we push it, it's
> working
> > fine here, the only gripe I have with the new GUI is that the left
> toolbar
> > is completely black, but that may just be because my desktop is powered
> by
> > GNOME.
>

--
Maxime

Re: [arch-general] mkvtoolnix-gtk: The new GUI is missing

[Maxime Gauduin]

On Tue, Sep 29, 2015, 9:52 PM Benjamin Robin  wrote:

> There's no difference here, and there shouldn't be anyway

In the PKGBUILD the first "drake" doesn't build everything:
./drake apps:mkvinfo  != ./drake


>> You try to be able to install mkvtoolnix-qt alone without the
>> mkvtoolnix-cli package, right ?
>
> Hmm, no?
> You don't say. Read the depends array once more.

Oops, sorry, I should have read the PKGBUILD more than once.

> Indeed, in that case I'd rather get rid of the duplicates. If it were up
to
> me, I wouldn't even package the Qt-enabled mkvinfo, the GUI doesn't bring
> anyhting more compared to the CLI tool, and if people need a GUI, I would
> highly recommend MediaInfo instead.

I cannot say that I am not agree :-)

Benjamin


Oh, I thought you were talking about the multithreading. I guess that trick
can be used to do things the other way around and build only mkvtoolnix-gui
in the second build folder. I'll have a look tomorrow and remove
mkvinfo-gui, I guess most people will agree that it's unnecessary to
package it.


Cheers,
--
Maxime

Re: [arch-general] mkvtoolnix-gtk: The new GUI is missing

[Maxime Gauduin]

On Mon, Sep 28, 2015 at 6:20 PM, Benjamin Robin  wrote:

> Hello Giovanni Scafora,
>
> I am trying to contact you about the bug reports opened about the
> mkvtoolnix package. Please see the email below posted on the mailing list.
>
> Thank you,
> Benjamin
>
> >> Hi,
> >>
> >> We do have trouble with some bug reports [1], [2] and [3].
> >> The maintainer (Giovanni Scafora) does not answer, nor update the
> >> PKGBUILD. In the last bug report [3] we kindly offer a working example
> of
> >> PKGBUILD which fix the problem : bring back the GUI (Qt5 instead of Gtk)
> >> The first bug report [1] is more than 4 years old without any respond...
> >>
> >> What do we need to do to resolve this issue ?
> >>
> >> [1] https://bugs.archlinux.org/task/24532
> >> [2] https://bugs.archlinux.org/task/44948
> >> [3] https://bugs.archlinux.org/task/45439
>
>
> > Antonio Rojas wrote:
> > Have you tried directly emailing the maintainer?
>

Hi all,

@Giovanni: being a somewhat heavy user of mkvtoolnix myself I'd like to
co-maintain mkvtoolnix with you. I rewrote most of the PKGBUILD, here are
the changes I'd iike to push [1], I chose to name the Qt-enabled mkvinfo
binary mkvinfo-gui to mirror how the main GUI is named. Also, as Moritz
Bunkus pointed out, it appears all current workarounds can be removed.
Please let me know what you think.

@Benjamin: Feel free to give the diff a spin before we push it, it's
working fine here, the only gripe I have with the new GUI is that the left
toolbar is completely black, but that may just be because my desktop is
powered by GNOME.

[1] https://paste.xinu.at/oX2o/

Cheers,
--
Maxime

Re: [arch-general] TLP ac/batt auto switch

[Maxime Gauduin]

On Wed, Jul 8, 2015 at 10:44 PM, Maxime Gauduin aluc...@archlinux.org
wrote:



 On Wed, Jul 8, 2015 at 9:42 PM, Giuseppe Turrisi 
 giuseppeturr...@gmail.com wrote:

 Hi guys,

 from about a week on my notebook tlp do not auto recognize ac/batt state
 and it don't auto load the config. If i restart the daemon manually
 after an ac/batt switch it will work well.

 Any idea to fix it?
 I'm on a Lenovo G50-70

 Greetings,
 Giuseppe

 --
 * Giuseppe Turrisi giuseppeturr...@gmail.com GPG Key: 0x64CC9BD9 *
 * Questo messaggio contiene firma GPG ed e' autentico *
 * http://it.wikipedia.org/wiki/GNU_Privacy_Guard *


 There's already a bug report about it [1]. I'm going to see to that
 tomorrow. Note that, for the same reason, tlp-rdw doesn't work as intended
 either.

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

 Cheers,
 --
 Maxime


Status update: The issue is caused by a change in udevd v221 making forked
subshells unusable. Udev rules will need a non-trivial rewrite to work
again. Thomas Koch (the author) has already made good progress, and
restored correct behavior on battery events. However, there are still some
issues with USB autosuspend and the exclusion of the usbhid driver, which
could result in some unresponsive input devices.

You can use tlp-git from AUR [1] until a fully working fix is available but
beware of the aforementioned issues. In case you run into them, consider
disabling USB autosuspend in TLP's configuration.

Also forget about what I said about tlp-rdw, it is unaffected by the udevd
changes, it was my mistake.

[1] https://aur4.archlinux.org/packages/tlp-git

Cheers,
--
Maxime

Re: [arch-general] TLP ac/batt auto switch

[Maxime Gauduin]

On Wed, Jul 8, 2015 at 9:42 PM, Giuseppe Turrisi giuseppeturr...@gmail.com
wrote:

 Hi guys,

 from about a week on my notebook tlp do not auto recognize ac/batt state
 and it don't auto load the config. If i restart the daemon manually
 after an ac/batt switch it will work well.

 Any idea to fix it?
 I'm on a Lenovo G50-70

 Greetings,
 Giuseppe

 --
 * Giuseppe Turrisi giuseppeturr...@gmail.com GPG Key: 0x64CC9BD9 *
 * Questo messaggio contiene firma GPG ed e' autentico *
 * http://it.wikipedia.org/wiki/GNU_Privacy_Guard *


There's already a bug report about it [1]. I'm going to see to that
tomorrow. Note that, for the same reason, tlp-rdw doesn't work as intended
either.

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

Cheers,
--
Maxime

Re: [arch-general] LightDM GTK+ Greeter 2.0.0

[Maxime Gauduin]

On Thu, Feb 26, 2015 at 7:15 AM, Pablo Lezaeta Reyes prfl...@gmail.com
wrote:

 On 02/25/2015 04:33 PM, Pablo Lezaeta Reyes wrote:
 * Hi all,
 ** Version 2.0.0 of the LightDM GTK greeter was released about week
 ago.
 ** This release drops GTK2 support.
 ** That's ironic, Xfce recommend lightdm as DM for the gtk2 theme,
 and the
 ** upcomimng xfce-gtk-engine 3.1 drop gtk3 support.
 **
 *
 From what I saw, it didn't drop it. It just disabled it by default, which
 makes sense given that the desktop is GTK+2 only and they don't want to
 unnecessary pull in the gtk+3 dep only for the engine.
 
 3.1.0 taged http://git.xfce.org/xfce/gtk-xfce-engine/tree/NEWS

 verbatim from the news: Gtk+-3 support has been stopped

 I asume they keep it but they stop supporting so I think unles a patch
 that fix all the themes emerge wldly, will be better drop xfce3-gtk-engine
 or the entire xfce-gtk-engine, but that mostly prove that they not
 support gtk3, drop gtk2-greeter will render without a wai to use a gtk2
 only
 environment since lxdm is mostly no-more-maintained and is better have a
 greeter
 than a binary unsupported.

 Also xfce4 recomend greybird as theme for xfce if someone need a gtk2-gtk3
 theme


 * Therefore I propose to rename the current lightdm-gtk3-greeter into
 ** lightdm-gtk-greeter and drop the legacy lightdm-gtk2-greeter to
 AUR.
 ** looking oxygen keep the gtk3 in AUR gtk3 only themes tend to use gtk3
 and
 ** gtk2 only thend to use gtk or gtk2, I will preffer keep the 3 in the
 name.
 ** I could keep lightdm-gtk2-greeter around for a while in
 [community] if
 ** some people want me to (I'm thinking people using MATE for example,
 ** but it's going towards GTK3 anyway), but keep in mind that you can
 use
 ** LXDM instead if you really need a GTK2 display manager.
 ** Or Xfce4 users, the upcoming xfce4 release is gtk2, and only after
 that the
 ** migration to gtk3 will start.
 ** so a gtk2-greeter will be apreciated until xfce drop gtk2, and dont
 forget
 ** that LXDM is now presumably unmaintained or in low maintainance since
 they
 ** migrate to QT
 ** If there aren't any objections by the end of the week, I'll
 proceed with my
 ** proposal.
 ** Me
 **
 ** Cheers,
 *

 tldr; I will go for keep gtk2-greeter for  xfce4 user since lxdm is
 semi-unmaintained and better a unmaintained theme that a
 binary.
 someone know if slim keep working with systemd, last time was buggy
 or not start or not let thing start at all (like logind)

 --
 *Pablo Lezaeta*


LXDM is a different story because AFAIK it hasn't been officially
abandonned, whereas the LightDM GTK2 greeter has, meaning I essentially
become upstream if I continue to package it. Anyone is free to keep
maintining it in AUR though, it won't be lost into oblivion. Also, as Ralf
mentioned, even for a GTK2 desktop, the GTK3 greeter will work just fine if
you can live with a few more megabytes.

As for the change of name, we always try to follow upstream's naming, the
GTK2 drop is a good opportunity to abide by that. FTR nearly all other
distros have had a single lightdm-gtk-greeter package for a while now,
providing only the GTK3 greeter even when GTK2 was still an option.

Since a lot less people than I expected seem to object, I pushed 2.0.0 in
[community-testing] for now, please give it a spin.

Cheers,
--
Maxime

[arch-general] LightDM GTK+ Greeter 2.0.0

[Maxime Gauduin]

Hi all,

Version 2.0.0 of the LightDM GTK greeter was released about week ago. This
release drops GTK2 support.

Therefore I propose to rename the current lightdm-gtk3-greeter into
lightdm-gtk-greeter and drop the legacy lightdm-gtk2-greeter to AUR.
I could keep lightdm-gtk2-greeter around for a while in [community] if
some people want me to (I'm thinking people using MATE for example, but
it's going towards GTK3 anyway), but keep in mind that you can use LXDM
instead if you really need a GTK2 display manager.

If there aren't any objections by the end of the week, I'll proceed with my
proposal.

Cheers,
--
Maxime

Re: [arch-general] Geary

[Maxime Gauduin]

On Mon, Oct 20, 2014 at 9:54 PM, Bjoern Franke b...@nord-west.org wrote:

 Am Montag, den 20.10.2014, 21:25 +0200 schrieb
 frank.zimmermann.ber...@freenet.de:
  Hi there,
 
  I'm running Openbox and use Geary as mail client. Since the appearance
 of Gnome 3.14 in stable Geary remains blank. I don't see my mail folder or
 mails at all. Not sure if Geary is connecting to the mail server at all
 since there is no feedback.
 

 What happens if you use another theme?

 --
 xmpp b...@schafweide.org
 bjo.nord-west.org | nord-west.org


Geary wouldn't even launch at all for me this morning, rebuilding it fixed
that. I just pushed 0.8.1-2 in [community], I'm not sure if it was the same
issue, but can you try again (also the theme thing Bjoern suggested)?

Cheers,
--
Maxime

Re: [arch-general] Dependency Hell

[Maxime Gauduin]

On Tue, Jul 15, 2014 at 3:27 PM, Chris Tonkinson ch...@tonkinson.com
wrote:

 Hi all,

   I have ZFS (from AUR) and VirtualBox (from Community) installed. The
 problem is that these both dependend typically on very specific kernel
 versions, and usually (usually being a subjective and ill-defined term
 slanted by when and how often I update my system; at least once per day)
 cause dependency failures which prevent *ANY* upgrades from being
 processed.

   As such, my /etc/pacman.conf contains an ignore declaration:

 IgnorePkg = linux zfs-git spl-git virtualbox virtualbox-host-dkms
 virtualbox-host-modules


Looking at your IgnorePkg line, I assume you have both
virtualbox-host-{dkms,modules} installed. Why? In the end they both provide
the modules, only one is needed.


   So once in a while, I'll comment out my IgnorePkg and attempt a system
 update and expect it to fail because getting the kernel, ZFS, and
 VirtualBox all to line up at the same time feels like, to quote Scotty,
 trying to hit a bullet with a smaller bullet, whilst wearing a
 blindfold, riding a horse.

   Is there any graceful solution here? Clearly the three won't (can't)
 ALL be bleeding edge simultaneously, but is there a sane workaround to
 keep them as-current-as-possible without pacman barfing on everything
 else. It's not immediately obvious to me how to combine IgnorePkg,
 HoldPkg, and NoUpgrade to achieve the desired result.


Yes they can, just install virtualbox-host-dkms and zfs-dkms-git, and build
the modules via dkms. No need for ugly workarounds.


 Thanks,
 -Chris

 --
 Chris Tonkinson
 610.425.7807

   Lead, follow, or get out of the way.
   -Thomas Paine


Cheers,

-- 
Maxime

Re: [arch-general] Xsession inconsitencies in login managers

[Maxime Gauduin]

On Wed, Jun 18, 2014 at 7:40 PM, Damjan Georgievski gdam...@gmail.com
wrote:

 I've checked xdm, kdm and lightdm only for now, but all use different
 Xsession scripts to start the user session. Not that they are just
 different scripts/files, they behave completely differently.

 Should we strive for some consitency here?

 --
 damjan


The Xsession scripts in kdm and xdm come from upstream, they work for us
with minimal patching (to source our xinitrc scripts), I don't think
radically changing them is useful. As for the scrips in lxdm and lightdm,
they're essentially the same already (note that lightdm doesn't come with
one at all, I shamelessly copied gentoo's script).

Of course I'm open to suggestions to improve the lightdm script as there is
no upstream there.

Cheers,
-- 
Maxime

Re: [arch-general] evolution-ews, does it work?

[Maxime Gauduin]

I've been using it at work for a couple years now. The OAB URL is
incorrectly detected (it picks up our external domain name), but it
works without a hitch after I modify that URL to use the local server
IP.

Did you try to delete ~/.config/evolution to start fresh? Is there
anything at all in there, especially the sources folder, after you've
tried to create an account?

Cheers,

On Wed, 2014-06-04 at 09:42 +0200, Magnus Therning wrote:
 I'm seeing strange behaviour in evolution when adding an EWS account,
 so I'm wondering if others are having problems with it, or if the
 blame falls squarely on the exchange server I'm trying to connect to.
 
 My system is up-to-date:
 
 % pacman -Q|grep evolution
 evolution 3.12.2-1
 evolution-data-server 3.12.2-1
 evolution-ews 3.12.2-1
 
 I can, seemingly successfully, configure an EWS account.  During
 config I can fetch the OAB URL, which ought to indicate that at least
 something's working as it's supposed to.  However, once I finish the
 account is nowhere to be found.  Indeed, when I restart evolution I
 get thrown back into configuring an account again.
 
 It would be great to hear if anyone is using the standard Arch package
 of evolutin-ews successfully.  Then I can be pretty sure that my
 problems are caused by our (rather clueless) sysadmins.
 
 /M
 

-- 
Maxime


signature.asc
Description: This is a digitally signed message part

Re: [arch-general] python-dbus upgrade 1.20-2 fails

[Maxime Gauduin]

On Tue, Jan 21, 2014 at 1:30 PM, Mark Lee m...@markelee.com wrote:

 Salutations,

 Upgrading from python-dbus-1.20-1 to 1.20-2 on Arch Linux 64 bit fails
 with the following error:
 --
 error: failed to commit transaction (conflicting files)
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/__init__.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/_compat.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/_dbus.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/_expat_introspect_parser.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/_version.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/bus.cpython-33.pyc exists
 in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/connection.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/decorators.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/exceptions.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/lowlevel.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/proxies.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/service.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/__pycache__/types.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/__init__.cpython-33.pyc
 exists in filesystem
 python-dbus:
 /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/glib.cpython-33.pyc
 exists in filesystem
 Errors occurred, no packages were upgraded.
 --

 Regards,
 Mark

 --
 Mark Lee m...@markelee.com


Same here, they were probably missing from the previous python-dbus package
and were generated afterwards. These are now part of python-dbus, you can
safely force the install: sudo pacman -S --force python-dbus.

Cheers,
-- 
Maxime

Re: [arch-general] Is out of source building still recommended with cmake in PKGBUILD scripts

[Maxime Gauduin]

On Tue, Jan 14, 2014 at 10:58 PM, David C. Rankin 
drankina...@suddenlinkmail.com wrote:

 On 01/14/2014 03:26 PM, David C. Rankin wrote:
Am I reading this correctly to say - creating a separate
 out-of-source build
  directory is no longer required -- even for cmake built packages? Or am
 I just
  confused again...

 WOW,

   I confirmed on a smaller build that with VCS packages no longer require
 an
 out-of-source build with cmake.

   What about normal packages built with cmake. Is an out-of-source build
 directory still required?

 --
 David C. Rankin, J.D.,P.E.


It is indeed no longer required with VCS sources, and has never been with
tarballs since those are extracted every time you run makepkg so files you
might have changed are overwritten anyway. However I sometimes find useful
to keep doing that with cmake when you need to figure out why sth won't
build, because that way files generated by cmake at build time are in a
separate dir.

Cheers,
-- 
Maxime

Re: [arch-general] Ruby gem packages in Arch

[Maxime Gauduin]

On Tue, Jan 14, 2014 at 11:04 AM, Paul Gideon Dann pdgid...@gmail.comwrote:

 On Monday 13 Jan 2014 17:58:59 Maxime Gauduin wrote:
  I only use a few ruby packages. However, you said it yourself, ruby and
  pacman both have different uses, my point was: do not change the content
 of
  a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't
 ever
  use both. In the end, we're free to do anything we want, I just think it
 is
  bad practice to mix things up like described above. In extreme cases,
 just
  have a look at Windows, where anybody can install anything anywhere, we
 all
  know what it ends up like :P

 What worries me about this is that you're making a clear distinction
 between users and
 developers.  I'm not convinced that is really consistent with the Arch
 Way, which I have
 always admired because it expects that the line between users and
 developers is blurry,
 and actively encourages users to experiment and cross over.  The idea of
 needing to
 switch to ruby's (purpose-built) method of handling gems when a user
 wants to achieve
 developer status seems wrong to me.

 The Arch Way is not about encouraging you to be a developer, it is about
leaving all the tools in your hands so that you can decide what you want to
do with them. I don't have a problem making a distinction between users and
developers, and clearly you are not dealing with users on a daily basis if
you can't do the same :P I don't consider myself a developer, but I still
make the most out of Arch Linux in my own way, which is, the Arch Way.
There is no typical Arch user/developer, each person uses it differently
for their own purpose, be it a server, home media center, gaming rig or a
ruby hacking machine.


 And for what?

 sudo pacman -S ruby-json
 sudo pacman -R ruby-json

 instead of:

 sudo gem install json
 sudo gem uninstall json

 It doesn't seem worth it to me.  The commands can easily be documented in
 the wiki, and
 then the bar is lowered that tiny bit more for hacking something together
 in Ruby.  Bear in
 mind that rubygems doesn't spread files all over the system, either.
  They're kept neatly
 tucked out of the way in /usr/lib/ruby, except for a few wrappers that end
 up in /usr/bin so
 that they're in the PATH.

 Paul


It seems to me (maybe I'm wrong, but that's how it feels) you wish to force
people to use rubygem instead of pacman, but I say it is not necessary if
pacman is sufficient for their need. If you feel the need to do so, and I'm
sure other people do, I'm just stating that in my opinion it is bad
practice to interfere with pacman's ecosystem via another package manager,
all the more if you give it root permissions. Now I understand you have a
need for root permissions, and I won't insist , but keep in mind that gems
can be installed anywhere outside pacman's jurisdiction and still be run as
root. I know rubygem is not messy at all, I'm using it to repackage gems
for pacman, still I think it is a good idea for most people to point it to
a safe directory, and you always have the possibility to add the relevant
dir to your PATH.

As for multiple versions, the root of all evil is that there are too many
gems that are not updated to support the latest version of a gem. Pacman
does not have to deal with that because we make sure packages are always
compatible with the latest and greatest, by submitting patches and/or bug
reports upstream. That's one of the 2 reasons why rubygem can be a better
choice for advanced ruby users, the other being the effort needed to
repackage gems (which is not much, unless you have hundreds of them).

Now I feel this discussion has dragged out for too long, and I believe I've
made my point several times already, so I will take my leave and go back to
my cave to geek to my heart's content :P

Cheers,
-- 
Maxime

Re: [arch-general] Ruby gem packages in Arch

[Maxime Gauduin]

On Mon, Jan 13, 2014 at 11:52 AM, Paul Gideon Dann pdgid...@gmail.comwrote:

 On Monday 13 Jan 2014 11:38:57 Alfredo Palhares wrote:
  I agree with you, some ruby-packages just are a royal pain in the arse to
  maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I
  still have some packages that use the old naming convention.
 
  But like you said the worst scenerio is to deal with multiple versions,
 like
  one fact you need to update an gem, but packages that depend on it need
 an
  older version of it, so now you have to have 2 versions of that gem.
 
  It can be done, we just need more man power to put quality packages.

 Forgive me: I'm a little unclear on why it's better to have the packages
 available via
 pacman?  I do development in Rails and am personally perfectly happy to use
 rubygems (and rbenv, for larger projects) for gem management.  I suppose
 it does
 mean there are files installed on the system that pacman can't identify,
 but personally I
 use rubygems enough that I have no problem handling the concept of two
 package
 managers that operate in different domains...

 I'm not trying to dismiss your effort, I'm just concerned that this seems
 a little like
 duplication.

 Paul


IMHO, the reason why you would choose to use rubygem over pacman depends of
how extensive a ruby user you are. I like to have gems handled by pacman,
but I only use a few of them and don't need to have several versions of the
same gem. Having them installed system-wise also makes them easily
available to all users. That being said, you can achieve the same with
rubygem by sharing a common ruby home between your users. As for the files
not handled by pacman, home dirs are not referenced anyway so having gems
in it really doesn't hurt.

Regarding naming convention, ultimately, I believe the decision is up to
the maintainer, not to some script. I have a few ruby packages in
[community], some of them containing executables in /usr/bin. I still chose
to keep the ruby prefix for 2 of them (namely ruby-term-ansicolor and
ruby-treetop) because as Anatol pointed out, they are also libs. I did not
for rubyripper and taskjuggler3 though, and I won't change that.
ruby-rubyripper would just be silly, and taskjuggler3 is a fairly big piece
of software, and it's pretty obvious it's written in ruby, there is no need
for a prefix. You can find the rubygem prefix on some other distros, but I
don't really see the point.

Now, about versioning: Arch is all about bleeding edge, keeping previous
versions in our repo is against our policy. There are only a few special
cases and we avoid to do that unless half the world still lives on the
previous version. Keeping only the latest not only greatly simplifies our
packaging life, but it also encourages devs to always keep their code up to
date with the latest and greatest. Sure, ruby deps may be more flexible,
but there's no harm in having the latest release, even if it works with an
older one.

Ultimately, I'd say rubygem is best for extensive ruby user, unless you
have a lot of time and really want to have pacman handle them. Still if you
need more than 2 versions of the same gem, rubygem is the way to go.

Cheers,
-- 
Maxime

Re: [arch-general] Ruby gem packages in Arch

[Maxime Gauduin]

On Mon, Jan 13, 2014 at 1:33 PM, Paul Gideon Dann pdgid...@gmail.comwrote:

 On Monday 13 Jan 2014 12:59:28 Maxime Gauduin wrote:
  IMHO, the reason why you would choose to use rubygem over pacman depends
 of
  how extensive a ruby user you are. I like to have gems handled by pacman,
  but I only use a few of them and don't need to have several versions of
 the
  same gem. Having them installed system-wise also makes them easily
  available to all users. That being said, you can achieve the same with
  rubygem by sharing a common ruby home between your users. As for the
 files
  not handled by pacman, home dirs are not referenced anyway so having gems
  in it really doesn't hurt.

 For system-wide gems, I do sudo gem install gem.  That works because
 I've restored
 /etc/gemrc so that it reads simply gem:, instead of gem:
 --user-install.  I'm still not clear
 on why this configuration file is altered in the Arch package.  I think
 it's because there's a
 feeling that system-wide gems should be handled by pacman, which I
 personally find weird.


That is not a feeling, gemrc is removed on purpose so that you _don't_ run
sudo gem. Your whole system is managed by pacman except for some dirs,
why wreak havok in it by using some other package manager? I'm exagerating
on purpose, I know rubygem does its job well and there shouldn't be
conflicts bewteen the two, but it just doesn't feel right.


 I get that people may be afraid of using a second package manager, but
 Rubygems is
 incredibly easy to use, and handles gems much more effectively than can be
 achieved in
 pacman, because Rubygems is domain-specific.  A quick command reference on
 the Ruby
 page on the Wiki should be enough.


Yes, gem is easy to use, so is pacman. You can achieve the same results
with pacman-handled ruby packages given some effort on the maintainer's
part (apart maybe for the, imho unneeded, complexity of having multiple
versions of the same gem, but that is another story).


 When you start doing Ruby development, you quickly come to rely on
 Bundler, which relies
 on Rubygems.  Throwing Pacman into the mix would cause a big mess, at
 least until you
 learn to use rbenv or something similar.

 Paul


As I mentioned above, you can easily reverse that statement. Why throw
Bundler and Rubygems in the mix when you have pacman? I personally think
that having pacman-managed dirs tinkered with by another package manager is
heresy :P I have no problem using one in ~ or any other dir that pacman
does not manage though, and as Rashif said, all in all it's just a matter
of options and preferences.

Cheers,
-- 
Maxime

Re: [arch-general] Ruby gem packages in Arch

[Maxime Gauduin]

On Mon, Jan 13, 2014 at 5:32 PM, Paul Gideon Dann pdgid...@gmail.comwrote:

 On Monday 13 Jan 2014 16:35:16 Maxime Gauduin wrote:
   For system-wide gems, I do sudo gem install gem.  That works
 because
   I've restored
   /etc/gemrc so that it reads simply gem:, instead of gem:
   --user-install.  I'm still not clear
   on why this configuration file is altered in the Arch package.  I think
   it's because there's a
   feeling that system-wide gems should be handled by pacman, which I
   personally find weird.
 
  That is not a feeling, gemrc is removed on purpose so that you _don't_
 run
  sudo gem. Your whole system is managed by pacman except for some dirs,
  why wreak havok in it by using some other package manager? I'm
 exagerating
  on purpose, I know rubygem does its job well and there shouldn't be
  conflicts bewteen the two, but it just doesn't feel right.

 We're talking about two completely different domains that both happen to
 use the
 filesystem for storage.  Ruby gems are not packages in the same sense that
 Firefox is a
 package.  It's a different concept, and although I agree that Pacman could
 do an acceptable
 job of managing Ruby gems insofar as both systems bundle files for
 installation, it is not
 possible to map the two systems completely.  They are built for different
 purposes, and
 have different semantics.

 Agreed.


  Yes, gem is easy to use, so is pacman. You can achieve the same results
  with pacman-handled ruby packages given some effort on the maintainer's
  part (apart maybe for the, imho unneeded, complexity of having multiple
  versions of the same gem, but that is another story).

 To some extent, yes.  You end up with a lowest-common-denominator
 situation.  It's
 acceptable for casual use, I'm sure.

 Yep, and that is sufficient for a lot of people. Developers are better off
using rubygem/bundler/rbenv, I agree too.


When you start doing Ruby development, you quickly come to rely on
   Bundler, which relies
   on Rubygems.  Throwing Pacman into the mix would cause a big mess, at
   least until you
   learn to use rbenv or something similar.
 
  As I mentioned above, you can easily reverse that statement. Why throw
  Bundler and Rubygems in the mix when you have pacman? I personally think
  that having pacman-managed dirs tinkered with by another package manager
 is
  heresy :P I have no problem using one in ~ or any other dir that pacman
  does not manage though, and as Rashif said, all in all it's just a matter
  of options and preferences.

 Based on that paragraph, I'd be surprised if you had undertaken any
 serious development in
 Ruby.  Many Rails developers work on Macs (not to mention other flavours
 of Linux), and
 Rubygems and Bundler are cross-platform tools.  Relying on Pacman for Ruby
 development
 would render a project pointlessly platform-dependent.

 I have indeed never undertaken development in ruby, and as I said before,
I only use a few ruby packages. However, you said it yourself, ruby and
pacman both have different uses, my point was: do not change the content of
a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever
use both. In the end, we're free to do anything we want, I just think it is
bad practice to mix things up like described above. In extreme cases, just
have a look at Windows, where anybody can install anything anywhere, we all
know what it ends up like :P


 Paul


Cheers,
-- 
Maxime

Re: [arch-general] OpenNTPd not correcting time on boot

[Maxime GAUDUIN]

On Tue, Jul 2, 2013 at 11:37 PM, Joe Eaves ji...@alluha.net wrote:

 Hi,

 First time posting so forgive me if I get it wrong. (This is already a
 resend because I used the wrong email previously!)

 I'm using OpenNTPd as a time server for my local network, but I have a
 slight issue. I run it on my Raspberry Pi which lacks a hardware clock, so
 every time I boot it, it thinks the time is 1970.

 In the systemd init file, openntpd.service, it runs the ntpd daemon with
 the '-s' option, which tell it that if the time is really far out of sync,
 just update it straight to the time that the server has. The problem is,
 this doesn't happen after boot.

 If I manually set the time with 'date -s @00' and then restart the
 openntpd service it will work, but not automatically after boot up.

 I suspect it might be that it's not able to talk to a server because it's
 starting the service before the network is ready or something, but I'm
 using a static IP and have told openntpd.service that wants and after
 both == network.target.

 Any ideas?

 Joe

 --
 *:wq!*


Hi,

I did not test this, but you may want to make it want
network-online.target instead of network.target.

Cheers,

-- 
Maxime

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

[Maxime Gauduin]

On Fri, 2013-03-08 at 13:34 +0100, Ralf Mardorf wrote:
 Hi :)
 
 dkms can't rebuild deleted vbox modules for the linux kernel
 
   # dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed 
 's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
   Module vboxhost/4.2.8 already installed on kernel 3.7.10-1-ARCH/x86_64
 
   # ls /usr/lib/modules/extramodules-3.7-ARCH/
   version
 
 and for linux-rt I get the same error
 
   # dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed 
 's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
   Module vboxhost/4.2.8 already installed on kernel 3.6.11-rt30-1-rt/x86_64
 
 but there never were modules installed for the kernel-rt.
 
 
 Regards,
 Ralf
 

Try 'dkms remove vboxhost/4.2.8 --all' and attempt to build again ('dkms
autoinstall' should do the trick for this).

-- 
Maxime


signature.asc
Description: This is a digitally signed message part

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

[Maxime Gauduin]

On Fri, 2013-03-08 at 13:34 +0100, Ralf Mardorf wrote:
 Hi :)
 
 dkms can't rebuild deleted vbox modules for the linux kernel
 
   # dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed 
 's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')
   Module vboxhost/4.2.8 already installed on kernel 3.7.10-1-ARCH/x86_64
 
   # ls /usr/lib/modules/extramodules-3.7-ARCH/
   version
 
 and for linux-rt I get the same error
 
   # dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed 
 's/\-.\+//') -k 3.6.11-rt30-1-rt/x86_64
   Module vboxhost/4.2.8 already installed on kernel 3.6.11-rt30-1-rt/x86_64
 
 but there never were modules installed for the kernel-rt.
 
 
 Regards,
 Ralf
 

Also, modules are not in extramodules anymore, they are in
'/usr/lib/modules/your kernel/kernel/misc/' now.

-- 
Maxime


signature.asc
Description: This is a digitally signed message part

Re: [arch-general] makechrootpkg vs. namcap

[Maxime GAUDUIN]

Just put the dep in makedepends, namcap only checks for runtime deps, can't
detect build dep AFAIK.

--
Maxime
On Mar 9, 2013 12:28 AM, Lieven Moors lievenmo...@gmail.com wrote:

 Hi,

 I was building a package using makechrootpkg, and the build was
 failing because a mandatory dependency was missing. But when I add
 the dependency, namcap complains that it is not needed.

 I was wondering how namcap checks dependencies, and what the particular
 shortcommings are of namcap when detecting dependencies.
 I was also wondering if there could be a possibility that namcap is right,
 and that something else goes wrong while doing the chroot-build.

 I would be grateful if somebody could enlighten me a little in this...

 Greetings,

 lieven

Re: [arch-general] makechrootpkg vs. namcap

[Maxime GAUDUIN]

On Mar 9, 2013 1:16 AM, Maxime GAUDUIN aluc...@gmail.com wrote:

 Just put the dep in makedepends, namcap only checks for runtime deps,
can't detect build dep AFAIK.

 --
 Maxime

 On Mar 9, 2013 12:28 AM, Lieven Moors lievenmo...@gmail.com wrote:

 Hi,

 I was building a package using makechrootpkg, and the build was
 failing because a mandatory dependency was missing. But when I add
 the dependency, namcap complains that it is not needed.

 I was wondering how namcap checks dependencies, and what the particular
 shortcommings are of namcap when detecting dependencies.
 I was also wondering if there could be a possibility that namcap is
right,
 and that something else goes wrong while doing the chroot-build.

 I would be grateful if somebody could enlighten me a little in this...

 Greetings,

 lieven

Sorry I answered above, still getting used to android :P

--
Maxime

Re: [arch-general] UEFI madness

[Maxime GAUDUIN]

Oh thx for the link! I didn't bother because I had already installed refind
last week, plus previous isos booted fine without further tweaking.
Gummiboot started acting funny recently.

--
Maxime
On Mar 3, 2013 11:32 AM, Mike Cloaked mike.cloa...@gmail.com wrote:

 On Sat, Mar 2, 2013 at 2:25 PM, Maxime Gauduin aluc...@gmail.com wrote:

 
  I have been succesfully using a GRUB2 based UEFI system for the past
  year, but it died on me a week ago. Didn't want to load any kernel
  anymore...
  I switched to refind and it works beautiffuly, just follow the wiki
  here: https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd
  and set your ESP partition like Mike suggested.
  The tricky part is to boot the iso into efi mode, it complains about it
  having no loader config (at least for me). You can work around that if
  you already have refind on the ESP partition, if you don't, install it
  in EFI/Boot/ and name the efi file bootx64.efi (be sure that it scans
  externals, or optical if you're using a CD). You can then load refind by
  going into your EFI bios and choosing Load EFI Shell (note that not
  all EFI bioses have that option).
 

 I followed the following to make a uefi bootable iso on a usbkey:


 https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Create_UEFI_bootable_USB_from_ISO



 --
 mike c

Re: [arch-general] UEFI madness

[Maxime Gauduin]

On Fri, 2013-03-01 at 22:44 -0800, David Benfell wrote:
 Hi all,
 
 So far, my attempt to install Arch Linux on a UEFI system is a total
 facepalm moment. The problem is in booting post-install.
 
 So, first, does anyone have actual--and successful--experience
 installing Arch on a UEFI system? Yes, I went to the Arch Wiki, which
 initially pointed me at GummiBoot. There are actually two sets of
 instructions, one given where I looked first, for the UEFI entry, and
 another under the entry for GummiBoot. Neither succeeds, but I wound up
 following the latter set of instructions (and cleaning up extra entries
 with efibootmgr, which fortunately makes this relatively easy).
 
 GummiBoot says it can't find /vmlinuz-linux. I tried modifying the
 configuration to say /boot/vmlinuz-linux, but no joy. Apparently, I'm
 really supposed to copy this file and the initrd image to the EFI
 partition, but nobody says where in the EFI partition, so I have no idea.
 
 I also tried following the instructions for grub-efi. I'm just
 mystified. I managed to install the right package, but from there I just
 wasn't understanding a thing. I've been using linux since 1999 so this
 shouldn't be so completely mystifying.
 
 I tried installing rEFInd (from sourceforge). As near as I can tell, it
 does indeed detect all the possible boot options on the system. But when
 I try booting the Arch installation, it says it can't find the root
 partition. It also detects the GummiBoot option, but that leads the same
 place as before. Finally, it detects the Windows option, which I hope
 still works (unfortunately I do need this).
 
 I guess getting something that just works--like it did with BIOS
 systems--is not in the cards. What do I do now?
 
 Thanks!
 
 

I have been succesfully using a GRUB2 based UEFI system for the past
year, but it died on me a week ago. Didn't want to load any kernel
anymore...
I switched to refind and it works beautiffuly, just follow the wiki
here: https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd
and set your ESP partition like Mike suggested.
The tricky part is to boot the iso into efi mode, it complains about it
having no loader config (at least for me). You can work around that if
you already have refind on the ESP partition, if you don't, install it
in EFI/Boot/ and name the efi file bootx64.efi (be sure that it scans
externals, or optical if you're using a CD). You can then load refind by
going into your EFI bios and choosing Load EFI Shell (note that not
all EFI bioses have that option).

--
Maxime
timeout 20
#hideui singleuser
#icons_dir myicons
#banner mybanner.png
#selection_big   selection-big.bmp
#selection_small selection-small.bmp
#font myfont.png
textonly
#textmode 2
#resolution 1920 1080
#resolution 3
#use_graphics_for linux
showtools shell, reboot, shutdown
#scan_driver_dirs drivers
scanfor external,manual
#also_scan_dirs boot
#dont_scan_volumes Recovery HD
#dont_scan_dirs ESP:/EFI/Boot
#dont_scan_files shim.efi,MokManager.efi
scan_all_linux_kernels
default_selection Arch Linux ck kernel
#include manual.conf

menuentry Arch Linux core kernel {
  ostype Linux
  icon EFI/refind/icons/os_arch.icns
  volume ARCH_BOOT
  loader vmlinuz-linux
  initrd initramfs-linux.img
  options root=PARTUUID=a18ed687-42d0-44e4-a8bf-689457b9ea17 rootfstype=btrfs 
ro nomodeset quiet
  submenuentry Terminal Mode {
add_options systemd.unit=terminal.target
  }
}

menuentry Arch Linux ck kernel {
  ostype Linux
  icon EFI/refind/icons/os_arch.icns
  volume ARCH_BOOT
  loader vmlinuz-linux-ck
  initrd initramfs-linux-ck.img
  options root=PARTUUID=a18ed687-42d0-44e4-a8bf-689457b9ea17 rootfstype=btrfs 
ro nomodeset quiet
  submenuentry Terminal Mode {
add_options systemd.unit=terminal.target
  }
}

menuentry elementaryOS generic kernel 3.5.0-18 {
  ostype Linux
  volume EOS_BOOT
  loader vmlinuz-3.5.0-18-generic
  initrd initrd.img-3.5.0-18-generic
  options root=PARTUUID=be8dea17-6e9b-416c-94e9-93cb135053e4 rootfstype=btrfs 
ro nomodeset quiet splash
  submenuentry Recovery Mode {
add_options recovery
  }
}

menuentry Windows 7 {
  ostype Windows
  icon EFI/rEFInd/icons/os_win.icns
  loader \EFI\Microsoft\Boot\bootmgfw.efi
}


signature.asc
Description: This is a digitally signed message part

Re: [arch-general] Default directory for extra modules

[Maxime Gauduin]

On Tue, 2013-02-19 at 09:41 +0100, Sergi Pons Freixes wrote:
 Hi All,
 
 I have the vanilla and the PAE kernels installed, and I use latter as my
 default for booting. I installed tp_smapi, and the modules are placed on
 /usr/lib/modules/extramodules-3.7-ARCH/ instead of
 /usr/lib/modules/extramodules-3.7-pae/, so they are not found.
 
 Is there anyway to set where the modules should be installed by default
 (which should be the current running kernel, resulting from uname). Or do I
 have to work with the PKGBUILD?
 
 Cheers,
 Sergi

Hi,

The tp_smapi modules are built for the vanilla kernel, they won't work
with the PAE even if you move them. You need to install tp_smapi-dkms
from the AUR and build the modules using DKMS (this should be done by
the install file upon installation, be sure to be running the PAE kernel
when you do this).

Regards,

--
Maxime


signature.asc
Description: This is a digitally signed message part