Re: [arch-general] Kernel 4.19 preventing Firefox from playing videos

2018-11-14 Thread LoneVVolf

On 14/11/2018 19.54, Bardur Arantsson wrote:

On 14/11/2018 17.54, Frank Zimmermann wrote:

Good evening,

I have a very strange issue with kernel 4.19.1 With this kernel Firefox
no longer plays any videos. It opens the page but the video wont play.
It gets even worse when I open another tab. This will freeze Firefox
though system load is ok. But I cannot kill Firefox, even logging off
and on will keep it running in the background. Only way to stop it is a
reboot and shutdown will take approx 10 to 15 mins for various stop
jobs running. just downgraded to Kernel 4.18.19 and things are fine.
I'm running Gnome on a Thinkpad X201.

KR Frank



Just another data point: (Might be related, might not...)

I'm seeing something similar with 4.19.1, though it doesn't completely
crash it just casues all GUI operations (even just switching windows) to
become *really* sluggish until I reboot the machine. At that point
firefox gets so slow that it's basically unusable -- this might be
experienced as it having hung on a slower machine. I am able to quit it
with regular Ctrl+Q though.

Downgrading to 4.18.19 seems to fix it for me.

(Running KDE on a Radeon GPU.)

Regards,

Archlinux stock kernel went from 4.18.16 to 4.19 , where did you get 
4.18.19 ?


linux 4.19.2 is now in [testing] repo, you could try that.

Lone_Wolf


Re: [arch-general] ClamAV Flagging systemd package

2018-07-14 Thread LoneVVolf

On 14-07-18 16:52, David Murray via arch-general wrote:

Greetings,

My nightly full-system ClamAV scan kicked out this last night:

/var/cache/pacman/pkg/systemd-238.133-4-x86_64.pkg.tar.xz: 
Unix.Trojan.Vali-6606621-0 FOUND

Is this something I should be concerned about?

TIA,
Dave


https://www.virustotal.com/#/file/1aef694958c06497a8c5e98b0e6914b2a9af48faff736fcb42e3855377ee8e19/detection

That shows 2 engines that detect something, Baidu and ClamAV .

https://pcfixguides.com/how-to-effectively-remove-unix-trojan-vali-6606621-0-from-your-computer/

It appears to be able to infect windows and Mac systems, and does look 
threatening.


Not sure who should look into this, but Arch Security Team seems most 
applicable.

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

LW


Re: [arch-general] scsi_mod.use_blk_mq (revisited)

2018-05-11 Thread LoneVVolf

On 11-05-18 06:57, Randy DuCharme via arch-general wrote:

Greetings again,

I've been continuing to fool with this.  I'm hoping someone smarter than I
can shed a little more light on it.  Here's what I've discovered since my
last post.

It seems that on my system, it takes more than the allowed 10 seconds for
the disks to appear.  I removed "quiet" from my boot command line and it
timed out looking for UUID=. .  So I looked for it and it
definitely was not there.  None of the sdXx devices were.  I looked again,
and yet again (ls /dev/sd*) and after about the 3rd or 4th attempt they
showed up.  So then, I mounted /dev/sdc3 to /new_root/, typed 'exit' and
after a warning about possibly failing to run as a user instance, it booted.

Any clues as to why this occurs?  I'm trying to find a way to increase the
pre-boot disk probe timer if possible.  So far, all I've found are tips
about speeding up the boot process, not slowing it down.

Many thanks in advance.

In order for your drives to be detected the kernel modules needed by the 
hardware must be loaded and active.
Your description matches a situation where some needed module is loaded 
too late in the boot process.


Use lspci -k to determine which kernel modules are needed for your sata 
/ raid controllers and add that one to the modules= line in 
mkinitcpio.conf .
Incase it's unclear which module is needed, try the one that handles the 
boot parameter (scsi_mod) .


LW


Re: [arch-general] Interesting Dual Boot Problems

2018-04-11 Thread LoneVVolf

On 11-04-18 18:32, David C. Rankin wrote:

Those are the only stray thoughts I have on the issue. If a cold-boot is
occurring when switching between OSs, then neither can have any effect on the
other (at least with a MBR setup).


Manufacturer windows driver can turn off network card using proprietary 
functions.

Linux is unable to undo that.

That setting is hidden in device manager , device , driver details or 
similar.
Not sure where that can be found in win10, but changing it there is only 
way to be sure it's disabled.

Higher level options to set it are usually only temporarily.


Re: [arch-general] archlinux install bottleneck

2018-02-19 Thread LoneVVolf

On 18-02-18 13:27, Jude DaShiell wrote:
After having run arch-chroot /mnt /usr/bin/bash one of the things I do 
is to run alsactl store.
alsactl store returns error 125 /var/lib/alsa/asound.state no such file 
or directory.  Certainly there's no such file since when alsa was run 
before arch-chroot got run on system boot /mnt/var/lib/alsa directory 
was empty having just run pacstrap on /mnt.  So since this is supposed 
to work, could it be arch-chroot script fails to collect and pass along 
enough of the right environment information to its chrooted environment 
for alsactl store to run?  Details are available at:

information at:
http://www.alsa-project.org/db/?f=43f6670eb3bde26ad6491d2faa631625109f88d0




Kernel release:4.13.3-1-ARCH

Looks like you are using an older iso to install ?
If so, have you tried with the 2018.02.01 iso ?


LW


Re: [arch-general] AL gnustep-core implementation misses gnustep-back

2018-01-11 Thread LoneVVolf

On 11-01-18 15:48, Bartłomiej Piotrowski via arch-general wrote:

On 2018-01-09 13:32, Sven-Hendrik Haase wrote:

I'd like to keep maintaining oolite if it's not too much work but I'm
definitely not going to touch GNUstep stuff. So if no one is going to
maintain GNUstep in official repos, we should drop oolite.


I'm going to drop oolite and remaining GNUstep packages on Monday,
unless someone adopts the latter.

Bartłomiej

Not the answer I was hoping for, but if noone steps up that seems the 
best option.


LW


[arch-general] AL gnustep-core implementation misses gnustep-back

2018-01-09 Thread LoneVVolf

In the recent repo clean up operation gnustep-back was dropped to AUR.

I have maintained the oolite package when it was still in AUR and 
remember plenty of problems with running oolite against faulty / 
incomplete gnustep-core implementations .


The gnustep upstream website [1] lists gnustep-back as a required 
package for every gnustep install .


The ANNOUNCE file in gnustep-back source code [2] states gnustep-gui & 
gnustep-back are 2 components of the display system used by gnustep .


I feel that removing gnustep-back from gnustep-core group goes against 
arch linux policy of staying as close to upstream as possible.


Lone_Wolf







[1] 
http://wwwmain.gnustep.org/resources/downloads.php?site=ftp%3A%2F%2Fftp.gnustep.org%2Fpub%2Fgnustep%2F#core


[2] ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-back-0.25.1.tar.gz


Re: [arch-general] Build configuration settings for samba

2017-12-03 Thread LoneVVolf

On 03-12-17 09:25, Newbugreport via arch-general wrote:

My Arch server hit https://bugzilla.samba.org/show_bug.cgi?id=10541 in a bad 
way, blocking all SMB writes from my Ubuntu 17.10 client. Since the bug is 
unfixed, I'd like to make a custom build of smbd to get things working. My test 
builds of samba don't appear to match how samba is built in Arch.

Where can I find documentation on how samba is build in Arch, especially 
configuration details?



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


Re: [arch-general] gscan2pdf - could it be included in the official arch repositories?

2017-09-26 Thread LoneVVolf

On 25-09-17 17:15, Stephan Fuchs via arch-general wrote:

Hello!

I would like to ask if the program gscan2pdf could be included in the
official arch repositories.
There are currently no
alternatives.
  
best regards

Stephan Fuchs



Hi,

[community] repo has 3 programs that could be an alternative :

simple-scan (gtk3)
scanlite (requires some kde libraries)
gambas3-gb-scanner (a frontend for scanimage command, written in the 
programming language gambas3 )


What functionality does gscan2pdf bring that none of 3 alternatives  have ?

LVV


Re: [arch-general] Recent updates cause ssh sessions to disconnect/reauth repeatedly for ~20 seconds?

2017-08-13 Thread LoneVVolf

On 13-08-17 01:09, David C. Rankin wrote:

All,

   After updates in the past day or two, I see new behavior for my idle ssh
connections that authorize as normal, but then are systematically disconnected
forcing a reauth at regular intervals of one-per second, for about 20 seconds.

Aug 12 17:46:11 valhalla sshd[3095]: userauth_pubkey: key type ssh-dss not in
PubkeyAcceptedKeyTypes [preauth]


Hi, that type of keys was disabled for security reasons in 2015, are you 
sure these connections from 192.168.6.104 are genuine ?

What kind of device is at 192.168.6.104 ?

https://wiki.archlinux.org/index.php/Secure_Shell#id_dsa_refused_by_OpenSSH_7.0

LW


Re: [arch-general] makepkg - any way to recompile only newly patched files in large packages?

2017-08-07 Thread LoneVVolf

On 07-08-17 09:39, David C. Rankin wrote:
I was wondering if there was a way to avoid the full 15 minute rebuild

of all of gtk2 and just compile gtkrecentchooserdefault.c to object and then
--repackage?



I don't know a way to do that, but do you have ccache installed ?

On my system it's set to use max 20G on a HDD .
When building things like mesa or llvm repeatedly with small changes 
this can shaves minutes of the build time.


LW

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


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

2017-07-08 Thread LoneVVolf

On 08-07-17 04:31, Evangelos Foutras via arch-general wrote:

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



An alternative solution would be to tailor things to the compiler used 
by the majority (gcc) and to avoid clang as much as possible.
That would ocourse require special settings for packages compiled with 
clang.


NOTE : whether that is a good idea is another matter, but it IS an option.


Re: [arch-general] Xorg configuration on a dual graphic card system

2017-06-06 Thread LoneVVolf

On 06-06-17 08:55, KangJing Huang via arch-general wrote:

Hi there,

I'm trying to setup my xorg configuration on my dual graphic card desktop
system. The system has two cards, one iGPU Intel HD Graphics 530, another
is a dGPU Nvidia GTX 1070 on PCIe. I plugged one monitor to the iGPU port
and another to the dGPU port and let the motherboard boot from iGPU.

Right now, the fbcon works well on the iGPU, and I installed Nvidia
non-free driver, and would like to run X on dGPU. I used the nvidia-xconfig
to generate a Xorg configuration, and after starting Xorg, I got display
from the monitor connected to dGPU, but it seems that the 3D rendering on
that screen is software-based, and `glxinfo | grep vendor` showed that
libglvnd on that X environment is selecting mesa as the GL library to use.
With mesa being called on a dGPU connected screen, apparently it could not
find a correct device to do dri, and fell back to software rendering.

Does anyone know the proper way of config X so that libglvnd could know
which GL library to use correctly in this case?

Thanks,
K.H.


Hi,

first step is to stop using nvidia-xconfig .
For most people X doesn't even start with nvidia-xconfig created config.

Your system uses Hybrid Graphics intel + nvidia , when using nvidia 
proprietary driver you basically have two options

Bumblebee or Optimus .

Check the wikipages for both to get an idea what's possible.


Re: [arch-general] Video output failure still

2017-04-23 Thread LoneVVolf

Pete,

do you have AUR nouveau-fw installed ? [1]

Please post the output of vdpauinfo .

LW




[1] https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware


Re: [arch-general] Firefox 52 Audio broken

2017-03-07 Thread LoneVVolf

On 07-03-17 21:14, Ralf Mardorf wrote:

On Tue, 7 Mar 2017 16:00:18 +0100, Carlchristian Eckert wrote:

As a workaround, have you tried using apulse? It is a pulseaudio
emulation for ALSA. Some time ago, I used it successfully to run Skype
(which also depends on pulseaudio) without having pulseaudio installed.


I don't know, if the required asoundrc could have impact on real-time
pro-audio usage. I won't test it.



I just tested apulse-git successfully, no changes to my alsa setup were 
needed.


LW


Re: [arch-general] Firefox 52 Audio broken

2017-03-07 Thread LoneVVolf

On 07-03-17 10:00, Allan McRae wrote:




Upstream changed to pulseaudio by default. Arch follows upstream

You can compile firefox yourself to set it being alsa only.

A



Allan,

if we really want to follow firefox upstream, we should :
- stop replacing the libraries upstream bundles with system libs,
- disable gold linker
- disable pie
- disable rust support

etc.

We don't follow upstream firefox now, do you have other reasons to leave 
out alsa support ?


Lone_Wolf




from firefox PKGBUILD :


ac_add_options --enable-gold
ac_add_options --enable-pie
ac_add_options --enable-rust


# System libraries
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-icu
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-system-bz2
ac_add_options --with-system-libevent
ac_add_options --with-system-libvpx
ac_add_options --enable-system-hunspell
ac_add_options --enable-system-sqlite
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman


Re: [arch-general] systemd latest upgrade

2017-02-01 Thread LoneVVolf

On 01-02-17 10:12, Jelle van der Waa wrote:

On 01/31/17 at 04:18pm, Jude DaShiell wrote:

However any package install now finishes with the
message:
Arming ConditionNeedsUpdate 


That's just a pacman hook to touch /var, for the recent CVE issue in
systemd  [1] [2]

[1] 
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd&id=59541b72a7ec32b30343a2a388b40ea1365f6308
[2] http://www.openwall.com/lists/oss-security/2017/01/24/4



The new hook checks for changes in and touches /usr, not /var or /run .

A search for systemd ConditionNeedsUpdate gives [*] .

that condition appears to be used for determining whether a change in 
/usr requires changes in /etc or /var.


There are some archlinux systemd services that use 
ConditionNeedsUpdate=/etc , but i can find none that use it with /var .


looks to me like this hook either fails defending fromn that CVE or has 
some other purpose.


LW





[*] 
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#ConditionNeedsUpdate=


Re: [arch-general] Old wine and intel graphics problem

2017-01-15 Thread LoneVVolf

On 15-01-17 13:59, eerozeteen . via arch-general wrote:

Hello,

Im trying to run Lineage2 Interlude on my laptop (processor Intel Core
i5-560M with integrated intel graphics) via Wine [1]. 1.5.0 is the last
wine version where people can run Lineage2 Interlude.


It looks like you misunderstand what test results in wine AppDB mean.

No one has tested LI2 interlude with a version past 1.5.0, but that 
doesn't mean it will fail with later versions .


Just try running it with latest wine, there's a big chance it will work.

LW


Re: [arch-general] Stronger Hashes for PKGBUILDs

2016-12-07 Thread LoneVVolf

On 07-12-16 11:44, Bennett Piater wrote:

On 12/07/2016 11:17 AM, Gregory Mullen wrote:

If the argument left is, I don't want (better checksum) because it's
shouldn't be thought of as a security check, and I want a security check.

Why can't the requirement be PGP sig's are now required, and we drop the
checksum completely?


Won't work because many upstreams don't provide signatures.
Maybe giving a warning ("source authenticity was not verified due to
lack of GPG signature") would work?



I vote to rename all *sums fields in PKGBUILD to :

this_is_just_a_checksum_and_does_no_authentication_at_all-xyzsums

Would it be possible to focus all this energy on ideas to make things 
safer instead of wrongly treating checksums as a security feature ?


LW


Re: [arch-general] howto remove old package version

2016-11-13 Thread LoneVVolf

On 13-11-16 11:16, niya levi via arch-general wrote:



On 13/11/16 00:48, niya levi wrote:


On 12/11/16 19:59, Damjan Georgievski wrote:

pacman -Syu
:: Starting full system upgrade...

warning: mesa: local (13.0.0rc2-2) is newer than extra (12.0.3-3.1)
warning: mesa-libgl: local (13.0.0rc2-2) is newer than extra (12.0.3-3.1)

how do i remove old version and install new with pacman,
have tried pacman -R but had dependency problems.

you should've mentioned that this is ArchLinux Arm

and yes, they reverted those packages (at leat on armv6 for
raspberrypi) I dunno why, don't even care




hi Damjan
i completely misunderstood the message, i thought i had had the earlier
version,
i also thought when it came to the packages versions arch and archlinux
arm were the same,
will remember this for future reference.
thanks
shadrock


sorry my question should be about downgrading not removing,
should i leave the version as it is or should i downgrade,
nothing seems to be broken but not sure if it will cause problems in the
future or with other software.

shadrock



https://archlinuxarm.org/packages/aarch64/mesa/log

Looks like AL Arm mesa versions went like this:

12.0.3-3
13.0.0rc2-2
12.0.3-3.1
13.0.0-1

Is your mirror uptodate ?


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

2016-10-10 Thread LoneVVolf

On 10-10-16 20:30, David C. Rankin wrote:


This particular box is an older
SuperMicro H8DME-2 board with a pair of quad-core Opterons.


I just realised I have a similar motherboard (Supermicro H8DAE-2 ) with 
the same chipset and also a pair of quadcore opterons on it.


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


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

2016-09-17 Thread LoneVVolf

On Fri, 2016-09-16 at 21:44 +0200, Bartłomiej Piotrowski wrote:
> Actually, why don't raise the bar higher? SSE2 has been introduced in
> 2001 – that's 15 years to upgrade one's hardware and given my sad
> experiences with computers, I find it hard to believe anyone has that
> old PC that happens to run Arch.
>
> We used to advertise ourselves as optimized for modern processors. Our
> "i786" really should include SSE3. For the same reason I would not
> complain about requiring SSE4 instructions for amd64.
>
>>

In the 2000's AMD and Intel followed different paths with extensions.
Checking https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions and its 
links suggest AVX was the point where the paths became the same again. 
AVX was designed in 2008 , but first procesoors that supported it were 
launched in 2011 .



My 2009 AMD opteron 2378 "Barcelona" processor advertises SSE, SSE2, 
3DNow & 3DNowExt .


I couldn't find specifics about 3DNowExt , but chances are big that 
software compiled with SSE3 , SSSE3 or SSE4 will crash on pre-2011 AMD 
processors.


LW


Re: [arch-general] Announcing pacpak

2016-07-10 Thread LoneVVolf
IF flatpak is to become supported on AL, i'd prefer pacman to handle it 
instead of a separate application.


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.


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

2016-05-19 Thread LoneVVolf

On 14-05-16 01:15, Carsten Feuls wrote:

Hello Everybody,

I have some trouble with pacman hooks.
Arch is going to use pacman hooks in every package.
etckeeper was one of the first package that use pacman hooks, without any
trouble.
But now it becomes more tricky to run.
My Problem is that the pacman hooks run in alphabetic order.
And not in a Prirority order.

How this problem could be solved?
Yes I know I can number every hook but I prefer a more upstream 
solution..



Sincerly Yours
Carsten Feuls



I do think there may be better way to solve this then adding a priority 
system for hooks.


this is current trigger used by etckeeper hooks :
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

I think the purpose of etckeeper is to keep track of changes in the /etc 
folder, right?


How about using this as trigger :

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = File
Target = /etc/*



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

2016-05-14 Thread LoneVVolf

On 14-05-16 01:15, Carsten Feuls wrote:

Hello Everybody,

I have some trouble with pacman hooks.
Arch is going to use pacman hooks in every package.
etckeeper was one of the first package that use pacman hooks, without any
trouble.
But now it becomes more tricky to run.
My Problem is that the pacman hooks run in alphabetic order.
And not in a Prirority order.

How this problem could be solved?
Yes I know I can number every hook but I prefer a more upstream solution..


Sincerly Yours
Carsten Feuls



I do think there may be better way to solve this then adding a priority 
system for hooks.


this is current trigger used by etckeeper hooks :
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

I think the purpose of etckeeper is to keep track of changes in the /etc 
folder, right?


How about using this as trigger :

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = File
Target = /etc/*


Re: [arch-general] startx on arch vm running on ESXI (when accessed via ssh - do I need a DM?)

2016-03-18 Thread LoneVVolf

On 18-03-16 20:21, David C. Rankin wrote:

/usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X 
server
You can get allow other users to run an xserver by creating 
/etc/X11/Xwrapper.config .


from man xorg.wrap :
  allowed_users = rootonly|console|anybody
   Specify  which  users  may  start  the X server through 
the wrapper. Use rootonly to only allow
   root, use console to only allow users logged into a 
physical console, and use anybody to  allow

   anybody.  The default is console.


Keep in mind that while that will allow you to run X through ssh, I have 
no idea if you'll be able to see the X screen.


LW


Re: [arch-general] JasPer vulnerabilities

2016-03-07 Thread LoneVVolf

On 07-03-16 10:55, Harrison Wells wrote:

Is the package JasPer in extra repo vulnerable to CVE-2016-1577,
CVE-2016-2089 and CVE-2016-2116? I noticed that the version number of
JasPer is same in Debian, Ubuntu and Arch, i.e. 1.900.1. Debian and Ubuntu
seem to have updated/patched it, is Arch not vulnerable to it?

With regards,

Harrison Wells

The most recent added patch appears to be jasper-1.900.1-CVE-2015-5203 .
I suggest you report this to arch-security mailinglist, 
https://lists.archlinux.org/listinfo/arch-security

LW


Re: [arch-general] Alternative init system proposal

2016-02-15 Thread LoneVVolf

On 15-02-16 16:54, João Miguel wrote:

A 2016-02-14T23:13:44 +0100, LoneVVolf escreveu:

On 14-02-16 17:17, João Miguel wrote:

Then I shall contact Artoo and add the packages back to the AUR as Nous
suggested. Though I don't see how a repository officially trusted by
Manjaro is less trusted than the AUR. Nevertheless, I do like the AUR, and
packages being there might help. Have a good day, João Miguel

Not long ago Artoo renamed his manjaro packages to openrc without any
discusssion with apg or apg openrc users.

It was after he was asked to remove his pakages from the AUR and after a
discussion in the Manjaro forums
I guess you mean the discussion here: 
https://forum.manjaro.org/index.php?topic=27333.0 ?


Everyone (interested) can read that and draw their own conclusion about 
what happened.

personally, i'm ok with "agreeing to disagree" on that subject.


Before artoo packages can be put back in AUR, that naming conflict needs to
be solved.

FWIW, there are currently at least 13 packages in the AUR (found by
searching and reading PKGBUILDs) from different people that install init
scripts to /etc/init.d and not Apg's /etc/openrc/init.d.


Even if that naming conflict were resolved, the division in the small AL
openrc community would continue to exist.

I think the easiest way to unite efforts would be to forget /etc/openrc.
I see that you want to avoid a conflict with initscripts, but if you
installed to /etc as Artoo, you'd be closer to upstream (Gentoo). I'm ok
with any directory, but I don't see the point in using /etc/openrc; who
uses both initscripts-fork and openrc, except for testing purposes?
Maybe you could change the default of that SYSCONFDIR variable to /etc,
and have the rare users of both systems change it to /etc/openrc (they
could get a warning in a post-install file or something like that).


Maybe the AL users wanting to remove systemd completely could investigate if
switching from openrc artoo way to openrc apg way is possible ?

I wouldn't put it off the chart, but note that users in Manjaro and
those of systemd-free.org already have binaries for Artoo's way, so a
middle ground between the ways, starting with identifying the
differences and figuring which way is best for each of those, would be
preferred IMHO.
using /etc/openrc makes it easy to use multiple init systems on 1 
machine, i think that is a good thing.

There is another good reason for it though :
Let's assume at some point in the future an arch developer or TU 
considers adding openrc/udev-alternatives to community repo.
They will look into the existing packages and check if they are high 
enough quality.


From arch packaging standards :
*Configuration files* should be placed in the |/etc| directory. If there 
is more than one configuration file, it is customary to *use a 
subdirectory* in order to keep the |/etc| area as clean as possible. Use 
|/etc/{pkgname}/| where |{pkgname}| is the name of the package (or a 
suitable alternative, eg, apache uses |/etc/httpd/|).


I feel in this specific case following arch packaging standards is more 
important then using the same path for configuration files as gentoo.


I've checked recent openrc init.d servicefiles, and it appears they work 
fine in any location provided openrc can find them.

If artoo way users want to stick to using /etc :
we can use an environment variable, say _OPENRC_SYSCONFDIR .
the openrc packages could set this var to the correct location.
Packages providing additional openrc services can then use that var to 
determine where they should install the files.

That would allow sharing of servicefiles.


Lone_Wolf

Active user of openrc apg way
co-maintainer of apg openrc (since this weekend)

Thank you for you efforts in maintaining an alternative, they are very
much appreciated.

Regards,
João Miguel

Thank you.
Your posts in this thread convinced me it was worth the effort to re-try 
to bring artoo & apg way closer together.


Lone_Wolf



Re: [arch-general] Alternative init system proposal

2016-02-14 Thread LoneVVolf

On 14-02-16 17:17, João Miguel wrote:
Then I shall contact Artoo and add the packages back to the AUR as 
Nous suggested. Though I don't see how a repository officially trusted 
by Manjaro is less trusted than the AUR. Nevertheless, I do like the 
AUR, and packages being there might help. Have a good day, João Miguel 


Not long ago Artoo renamed his manjaro packages to openrc without any 
discusssion with apg or apg openrc users.


Before artoo packages can be put back in AUR, that naming conflict needs 
to be solved.
Even if that naming conflict were resolved, the division in the small AL 
openrc community would continue to exist.


Maybe the AL users wanting to remove systemd completely could 
investigate if switching from openrc artoo way to openrc apg way is 
possible ?


Lone_Wolf

Active user of openrc apg way
co-maintainer of apg openrc (since this weekend)


Re: [arch-general] Alternative init system proposal

2016-02-12 Thread LoneVVolf

On 11-02-16 17:12, João Miguel wrote:


now there are no AUR packages for OpenRC.


You are wrong, please be more specific.

This is current situation:

- run AL without using systemd as PID1 / init system :
Aur and AL wiki have everything you need for that.
You will still have systemd installed and use udev from it.

(i am one of the AL users that uses this setup on my laptop and desktop)

- remove systemd completely from AL :
Some people do that, but documentation how to do this was removed from wiki.
The aur packages that helped with this setup were removed by the 
creator/maintainer.


Lone_Wolf


Re: [arch-general] DHCP server package orphaned

2015-09-10 Thread LoneVVolf

On 10-09-15 08:22, Mike Cloaked wrote:

Having seen that the dhcp server package has been orphaned yesterday,
hopefully this will be picked up and maintained as it is a pretty important
standard package for a server.


If you mean the dhcp package, the orphaning must have been temporarily .
Felix Yan is now mentioned as maintainer.

LW


Re: [arch-general] Komodo Edit

2015-08-23 Thread LoneVVolf

On 22-08-15 17:13, James wrote:
I installed Komodo Edit and  I want to put a quick launch button on my 
task bar but  it doesn't show up in the list of "installed applications".
That is weird because it shows up in the "Menu" in the "Programming" 
section.

I use lxde.
Komodo-Edit probably needs to run "update-desktop-database" in the 
post_install section of a .install-file


https://wiki.archlinux.org/index.php/KDE_package_guidelines#.install_files
has some details about how and why.

Logging out and in should make it available for 'installed applications" .

LW


Re: [arch-general] LTS Kernels

2015-08-22 Thread LoneVVolf

On 22-08-15 10:30, bildermej...@gmail.com wrote:

But I wonder if I can install an LTS kernel in an already existing installation 
as a fallback?


Yes, that's not very hard and a good idea.


The wiki sounds fairly straight forward, but I get lost where it says "install kernel" without 
saying how, and to "edit the grub config file" without an explanation, and to "generate the 
main configuration file".


Not sure whether I am getting in way over my head or if it is actually quite 
simple. That's what I need to know.
If you use kernel modules that are not part of the stock kernel (like 
nvidia , catalyst, vhba-modules ) additonal steps are needed.


For now i'll assume you don't have such modules.

- Almost every time an arch wiki page states "install program" , it 
means one of 2 things :

install with pacman
install from AUR with makepkg

The lts kernel is in official repos, so you can install it with pacman.

- to be able to boot the lts-kernel , you have to add an entry to your 
bootloader config for it.

Grub stores that info in grub.cfg , grub page lists where it can be found.

As Root :
copy grub.cfg to something like grub.cfg.original
open the file with your fav tekst editor.
Copy the entry for arch stock kernel to a new entry and change what is 
needed to have that boot the lts-kernel instead of the stock kernel.


Reboot and test if it works.

LW


Re: [arch-general] SOLVED Re: Realtek 8111/8168/8411 Blues - cannot get dhcpcd address (link UP)

2015-08-21 Thread LoneVVolf

On 21-08-15 04:58, David C. Rankin wrote:

On 08/20/2015 09:34 PM, David C. Rankin wrote:




$#%#@%#$%... You have to enable IOMMU in the BIOS before the NIC will 
work! I stumbled across this obscure little tidbit on the fedora forum:


http://forums.fedoraforum.org/showthread.php?t=295616

It triggers some nasty AMD I10 Page Faults/xhci messages during boot 
of the 201508 install media, but the network comes right up, dhcp 
works, no more lost packets, etc.


I wonder if this is related to it corrupting my USB drives I plug into 
it? Drives work the first time, sync, then umount. Next time you plug 
them in, filesystem is gone?


Oh well, at least I have a network now. I'll add it to the wiki.




Blame Gigabyte, the only reason to disable IOMMU is if you run a 32-bit OS .

On all x86_64 OSes running with IOMMU disabled will degrade graphics 
performance A LOT.

As you found , disabling IOMMU also affects other hardware badly.

TL;DR :
64-bit OS >>> ENABLE IOMMU


Some links :

https://en.wikipedia.org/wiki/IOMMU
http://developer.amd.com/community/blog/2008/09/01/iommu/

Lone_Wolf


Re: [arch-general] Tuxguitar: documentation and SWT/GTK

2015-07-19 Thread LoneVVolf

On 19-07-15 20:06, Alan E. Davis wrote:

Tux guitar works well, so far; however, when trying to access Documentation
through "Help>Documentation" Tuxguitar hangs.  I've spent some hours
researching this problem, and have gotten nowhere.  Every google search I
make leads one to mention of SWT, and apparently the most up to date 4.2
version, and some issue regarding gtk.


Also interesting, in the "About" screen, is the following information:

This product include third party libraries:
-> SWT (Standard Widget Toolkit): http://www.eclipse.org/swt/
-> iText (Free Java-PDF library): http://www.lowagie.com/iText/

The documentation is pretty good, in general, on the Archlinux Wiki.  I
could not find much useful information regarding this problem with
Tuxguitar with respect to Archlinux, even there.

Can someone shed some light, or, better still, suggest a way to solve this
problem.  I suppose I can try to get a PDF of the docs, and use that.

Alan Davis




|The PKGBUILD has this line twice : export 
CLASSPATH=/usr/share/java/swt.jar:$CLASSPATH That makes tuxguitar use 
the archlinux SWT version. The problems likely come from arch SWT being 
newer then wat tuxguitar expects. Try building the package yourself with 
those lines commented. Note that you need to make sure the tuxguitar 
provided swt.jar is included in the package. |




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

2015-07-03 Thread LoneVVolf

Some general comments :

- Openrc is a replacement for sysv init, not an addition.

- openrc has it's own equivalent of .service files, they are simpler 
then systemd servicefiles


- my personal opinion about openrc is that it's not mature enough yet 
for majority of linux users to replace systemd
The majority of Arch users however should be capable enough to use it 
efficiently.


- systemd has many good things, but also many flaws.

This blog post gives the best description of systemd flaws i am aware of :
http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

LVV


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

2015-07-01 Thread LoneVVolf

On 01-07-15 21:12, David Kaylor wrote:

I rest my case. Again, any reply is welcome.


You are wasting your keystrokes and your time.

Arch devs have long since decided to make systemd an integral part of Arch
Linux. And I didn't like it any more than you do, at first.
Actually there are 2 actively maintained implementations of openrc for 
arch :
Apg way (uses udev from systemd but everything else is openrc) and artoo 
way (can be used with eudev) .


Users of both variants communicate through this forum thread :
https://bbs.archlinux.org/viewtopic.php?id=152606

LVV


Re: [arch-general] no screen grabber

2015-05-22 Thread LoneVVolf

On 22-05-15 16:26, Aaron Caffrey wrote:

On 22/05/15 at 08:42am, James wrote:

$ sudo pacman --sync screengrab
error: target not found: screengrab

https://aur.archlinux.org/packages/screengrab/

Are the official packages binary packages and the AUR is compiling 
from source?

That's what it seems like.

How do I search for a binary screen grabber package?


https://en.wikipedia.org/wiki/RTFM


That's a bit harsh, Aaron.

James : check man pacman, you'll find plenty of search related options.

Lone_Wolf


Re: [arch-general] Add wpa_supplicant to the Group 'Base'

2015-04-28 Thread LoneVVolf

On 28-04-15 16:35, Jeremy O'Brien wrote:

I'll reserve my opinions on including wpa_supplicant in base, but I feel
that it at least deserves a mention in the Arch Installation Guide. It's
strange to me that the installer has better networking support than the
base system. I've installed Arch on 5 different laptops, and I've
forgotten about wpa_supplicant on every one of them. Maybe something
like "Other packages or groups can be installed by appending their names
to the above command (space seperated), possibly including the boot
loader or wireless networking packages" under "Install the base
packages". Thoughts?

Wrong section i think, and no need to use pacstrap.
After chrooting into your install, you can use pacman iirc .
The bootloader already has a section lower on the page, a new section 
"wireless" just after that

would be  a good idea i think.

LVV


Re: [arch-general] Add wpa_supplicant to the Group 'Base'

2015-04-27 Thread LoneVVolf

On 27-04-15 08:32, William Hatch wrote:

I second the motion for a network group. I've been bitten by a lack of 
wpa_supplicant on a laptop install more than once.


Given that dhcpcd & iproute2 are already in the base group, wired 
networking is already supported by

installing base.
For basic wl networking all you need are iw and wpa_supplicant.
Are 2 packages really worth it to create an additonal group or do you 
propose to remove dhcpcd & iproute2 from base to this new group ?


Re: [arch-general] How to autostart ufw on system startup?

2015-04-16 Thread LoneVVolf

On 16-04-15 06:25, Francis Gerund wrote:

Strange that the ufw install routine didn't do that automatically.


Nope, that's standard practice for arch pacakges.

Deciding what is or isn't started at boot is up to the user to decide.

LVV


Re: [arch-general] /etc/bash.bashrc not sourcing/setting HISTXXX environment

2015-04-07 Thread LoneVVolf

On 07-04-15 03:41, David C. Rankin wrote:

All,

  I generally create a system-wide /etc/bash.bashrc.local file to 
contain history defaults. E.g.:


$ cat /etc/bash.bashrc.local
HISTCONTROL=ignoreboth:erasedups
HISTIGNORE='[ ]*:&:?'

  (HISTSIZE & HISTFILESIZE are exported on a per-user basis in 
~/.bashrc) I then just add a line to source it in /etc/bash.bashrc:


$ cat /etc/bash.bashrc
#
# /etc/bash.bashrc
#

# - source /etc/bash.bashrc.local
[ -r /etc/bash.bashrc.local ] && . /etc/bash.bashrc.local

  Both files are present and readable:

$ ls -l /etc/bash.bashrc*
-rw-r--r-- 1 root root 697 Apr  6 20:01 /etc/bash.bashrc
-rw-r--r-- 1 root root 418 Mar 10 09:40 /etc/bash.bashrc.local

  I do this the same way on both Arch and SuSE. Chasing a bash bug on 
SuSE, I would check the the environment with:


$ env | grep HIST
HISTSIZE=2
HISTFILESIZE=2
HISTIGNORE= *:&:?:??
HISTCONTROL=ignoreboth:erasedups

  Doing a pacman update earlier to day, I just checked the environment 
on Arch on a whim:


$ env | grep HIST
HISTSIZE=5000
HISTFILESIZE=15000

  Huh? Where is HISTIGNORE and HISTCONTROL? Is there something unique 
to Arch that prevents sourcing or prevents setting HISTXXX in this 
manner. I can't think of anything offhand that would prevent it, but 
it certainly isn't being set. Any ideas on why?




/etc/bash.bashrc is sourced from /etc/profile .

from man bash :
Konsole output
 When bashis invoked as an interactive login shell, or as a 
non-interactive shell with the --loginoption, it
  first reads and executes commands from the file /etc/profile, if 
that file exists.


Verfiy your /etc/profile and are you sure you are running the command 
from an interactive login shell ?


LVV


Re: [arch-general] Install qgis

2015-02-28 Thread LoneVVolf

On 28-02-15 13:33, Viktor Garske wrote:

Hello,

when I try to install "qgis" I get


resolving dependencies...
warning: cannot resolve "qwtpolar>=1.1.0", a dependency of "qgis"
warning: cannot resolve "spatialindex>=1.8.0", a dependency of "qgis"
:: The following package cannot be upgraded due to unresolvable
dependencies:
   qgis

:: Do you want to skip the above package for this upgrade? [y/N]
error: failed to prepare transaction (could not satisfy dependencies)
:: qgis: requires qwtpolar>=1.1.0
:: qgis: requires spatialindex>=1.8.0


What does it mean?

Viktor

Viktor,

qgis is an AUR package, next time send this kind of message to the 
aur-general ML instead please.


Both qwtpolar and spatialindex are also AUR pacakges, build & install 
them yourself using makepkg.

Once that's done, try building qgis again.

Lone_Wolf


Re: [arch-general] anyone interested in a multilib qt-at-spi package?

2015-02-07 Thread LoneVVolf

On 07-02-15 04:34, kendell clark wrote:

hi all
  I'm not sure how to begin this, but here goes. In order for screen
readers, like orca, to be able to access applications written in qt4
(qt5 handles all of this built in}, it needs a package called
qt-at-spi. This is a bridge of sorts which links the qt accessibility
API's to the at-spi daemon which orca uses to read the screen. This is
in community, so this all works. However, there's an issue that's just
obscure enough that I'm not sure how to handle it. The issue arises
when 64 bit linux installations try to talk to 32 bit qt applications.
Since the qt at-spi bridge is 64 bit, it can't communicate with the 32
bit app, so orca cannot read it. THis makes applications such as
teamviewer and skype completely inaccessible on 64 bit systsms. I'm
not certain teamviewer is written in qt, but I do knos skype is. Ok,
ramble over. Is anyone interested in building a 32 bit version of the
qt-at-spi package and possibly throwing it in multilib? THis does not
need any maintenance, since this is only for qt4 applications, the
package has been deprecated since the code has been murged into qt5.
I've tried a few workarounds to no avail. I've tried downloading the
i686 package and trying to get pacman to install it, this didn't work.
I tried extracting the actual .so files out and placing them in lib32,
but I don't know enough about how the underlying system works to make
this work.
Thoughts?
Kendell clarK


Kendell,

Many lib32 programs are build on x86_64 by instructing the compiler to 
build 32-bit code.

The [extra] lib32-mesa package shows how that can be done.

Also look at lib32-at-spi2-core & lib32-at-spi2-atk in AUR.
If at-spi2 is not the version you need, you can probably use them as 
template for creating lib32-at-spi-* packages.


LVV


Re: [arch-general] [arch-dev-public] [extra] Dropping ocaml packages

2015-02-03 Thread LoneVVolf

On 03-02-15 11:47, Mike Cloaked wrote:

On Tue, Feb 3, 2015 at 8:33 AM, Tobias Powalowski <
tobias.powalow...@googlemail.com> wrote:


Hi guys,
I don't use it on any of my machines anymore, anyone who wants to step up?
Else those are candidates for AUR/community.

ocaml
greetings
tpowa



I noticed from the arch-dev-public list in the post quoted above that ocaml
is planned to be dropped to AUR or community.  I also notice that ocaml is
still a dependency for one of the kde packages.

# pacman -R ocaml
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: kdeedu-kalzium: requires ocaml

I guess it needs to be maintained else there may be problems with updates
to kde in the future?

Ocaml is a makedepend for llvm which is a makedepend for mesa .

Dropping such a package from [extra] doesn't seem like a good idea.


Re: [arch-general] Persistent black screen of death issues with radeon graphics

2014-11-26 Thread LoneVVolf

On 26-11-14 12:00, Robbie Smith wrote:

I am at a loss as to what the hell is going on with my laptop. It's a HP
Pavillion with the dual AMD graphics (7520G + 7500M), and I will never
again buy a laptop containing components from either manufacturer.

More often than not when I boot, when the kernel tries to do modesetting
the screen will just turn off. I can SSH in, so it's clearly booting up,
but the only hint that anything unusual is happening in the logs is this
error message:


[   28.879834] radeon :01:00.0: No connectors reported connected with modes
[   28.879842] [drm] Cannot find any crtc or sizes - going 1024x768
[   28.881975] [drm] fb mappable at 0xE0474000
[   28.881978] [drm] vram apper at 0xE000
[   28.881980] [drm] size 3145728
[   28.881982] [drm] fb depth is 24
[   28.881985] [drm]pitch is 4096
[   28.882332] radeon :01:00.0: fb1: radeondrmfb frame buffer device
[   28.997034] [drm] Initialized radeon 2.40.0 20080528 for :01:00.0 on 
minor 1

I feel like I've tried almost everything:
- Upgrading and downgrading kernels (I'm currently using 3.17.1)
- Various combinations of kernel boot parameters (fbcon=map:0,
fbcon=map:1, radeon.modeset=1, radeon.modeset=0, etc)
- Adding lines to /etc/X11/xorg.conf.d/20-radeon.conf that tell it which
PCI device to map to.
- Uninstalling and reinstalling the drivers

I used to use catalyst because that was the only driver that worked, but
as it doesn't support KMS, I couldn't use GNOME anymore, so switching
back to that isn't an option.

Searching for the problem doesn't seem to find anything relevant;
there's a few forum posts by Ubuntu users but mostly tumbleweed. The bug
tracker on freedesktop.org is awkward to navigate so I have no idea if
what I'm experiencing has occurred to anyone else. Even just knowing
where to go to report a bug or a more appropriate mailing list that
could point me in the right direction would be helpful at this stage.

The most frustrating bit is that this occurs almost at random. I could
use the laptop all day at the library, no issues; turn it off (because
suspend is broken on radeon), come home and no screen for what feels
like a thousand reboots.

Robbie Smith,

This sounds a bit like  a problem a friend of mine had with a HP 
Pavillion DV7 .

I assume you have an amd APU + discrete videocard combination ?
(lspci -k   output would help).

some questions / comments :

are you using latest bios/Uefi firmware ?

Are you sure catalyst was removed completely ?

the entire dmesg output from a good and bad boot to console would also help.
By comparing them we might find clues about the cause of your problems.

Lone_Wolf


Re: [arch-general] mce after linux-3.11.5-1 on NP900X3C

2014-11-15 Thread LoneVVolf

On 15-11-14 06:57, Rasmus Liland wrote:

On 2014-11-15 06:10, Mark Lee wrote:

On 11/14/2014 10:29 PM, Rasmus Liland wrote:

On 2014-11-15 04:01, Mark Lee wrote:

Are you booting with the new intel u-code?

You mean installing the intel-ucode package and enabling it in the
bootloader as per instructions at
https://wiki.archlinux.org/index.php/microcode ?

No, I haven't gotten around to it yet as I'm, since August 2012, a
user of the grub-legacy (0.97) package on this laptop. I know
grub-legacy doesn't support the loading of the microcode. I'll
switch to using Syslinux instead when I find a proper memstick.

Are you fairly sure this is a Intel microcode issue?


To Rasmus,

I'm not completely certain; but it would make sense. I'd test it out.

Regards,
Mark


Thank you for your help thus far. I'll examine this further tomorrow,
g'night.


From rasmus first post :
I'm experiencing machine check exceptions since every kernel after package
linux-3.11.5-1 (Oct 14 2013)

New intel microcode was only introduced with kernel 3.17 .
It's unlikely to have to do with this issue.


Rasmus,
check the log you posted again (bold added by me).

[19367.116196] mce: [Hardware Error]: CPU 1: Machine Check Exception: 5 Bank 4: 
b2100402
[19367.116202] mce: [Hardware Error]: RIP !INEXACT! 33:<7f8b4934c8b7>
[19367.116205] mce: [Hardware Error]: TSC 2824672b8e7
[19367.116211] mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 14010118857 SOCKET 
0 APIC 1 microcode 12
[19367.116213] mce: [Hardware Error]:*Run the above through 'mcelog --ascii'*

install mcelog , run it as the log tells you and post the result.

LW



Re: [arch-general] vnstat's pacnew

2014-09-02 Thread LoneVVolf

On 02-09-14 02:55, Ralf Mardorf wrote:

Unlikely that on Arch Linux eth0 is more often used, than enp3s0.
Does it makes any sense to place a log file into a directory?

Regards,
Ralf

From vnstat homepage :
vnStat is a console-based network traffic monitor for Linux and BSD that 
keeps a log of network traffic for the selected interface(s).


the network interface names like enps30 are created by by systemd/udev , 
BSD uses other methods.
Placing logfiles in /var/log makes perfect sense for every system that 
doesn't run systemd.


Also this .conf file is the one provided by upstream, and Arch Linux 
devs prefer a minimal patching approach, keeping packages as close to 
upstream as possible.


LW


Re: [arch-general] [arch-dev-public] systemd 216 coming soon to testing

2014-08-22 Thread LoneVVolf

On 22-08-14 11:07, Paul Gideon Dann wrote:
If I remember correctly, when the switch to systemd was first made, 
the migration guide on the wiki did in fact talk the user through 
forwarding the journal to syslog-ng by modifying some config files. Paul 


I'm 99% sure that those changes had to be made in syslog-ng config files 
, NOT in systemd config files.


Best way to handle this change seems to me to show a message when 
upgrading / installing systemd 216.


LW


Re: [arch-general] Can't SSH into Arch VM until login screen is viewed

2014-07-07 Thread LoneVVolf

On 07-07-14 18:59, Ben Booth wrote:

I have a weird issue I’m trying to figure out with Arch and SystemD, and I 
wonder if anyone here has run into this issue:

I’m running ArchLinux as a Xen VM. Every time I reboot the system, I can no 
longer ping it or access it via SSH. However, if I go into the XenCenter UI and 
click the “Console” tab to view the VM’s login screen, all of a sudden SSH and 
ping works again. It’s as if systemd is waiting for the login screen to be 
viewed before it allows SSH to work. Is this some kind of systemd 
socket-activated functionality related to the getty service? How can I prevent 
this so that I can log in via SSH after reboot without having to run the 
XenCenter UI?

Thanks,
Ben Booth


Ben,

Try adding console=ttyS0 as kernel parameter to the boot command.

see http://0pointer.de/blog/projects/serial-console.html for details

LW


Re: [arch-general] makepkg.conf CFLAGS

2014-06-02 Thread LoneVVolf

On 01-06-14 14:03, Yamakaky wrote:

Hi

I just discovered the gcc option march=native. It enables all the 
local-supported optimizations, without downsides except the 
non-portability of the binaries. Is there a reason why it isn't 
enabled by default, as cross platform compilation isn't used by most 
of the users (I think) ?


Yamakaky


Yamakaky, the non-portability is a very big downside imo.

When using -march=native on a core i7, those packages won't run on an 
amd processor or on an intel atom. They  might even give problems on a 
core i3.



All official packages for arch are build on systems running arch.
With current makepkg default, all packages build will run on all systems 
with same architecture (x86-64 / i686) .

Now assume makepkg had -march=native as default.
packages build for official repos now will fail on all systems that 
don't have same cpu family.

This effectively forces all devs to change makepkg defaults.
Incase they forget it, their offficial build will fail.

some user-specific examples :
user has a netbook with an intel atom processor and needs to compile 
program foo to work on it.

building foo on the netbook takes over an hour.
User tries building foo on his main system with a core i7, SSD etc and 
finds building foo takes only a few minutes there. foo build with 
makepkg default on the i7 will run flawlessly on the netbook.



user has an ageing AMD FX system and wants to replace that with an intel 
core i7 system.
they don't feel like re-installing, so just transfer the harddrive to 
the intel system.
if they used -march=native everything they build on the AMD FX system 
will need to be rebuild on the core i7 .


LW




Re: [arch-general] KDE Issue

2014-05-08 Thread LoneVVolf

On 07-05-14 22:23, Tomasz Kramkowski wrote:

On Wed, May 07, 2014 at 08:01:01AM -0400, Hunter Jozwiak wrote:

Hi all. I tried to install KDE for testing accessibility with Orca. However,
a friend of mine told me that the only icon that shows up is a hard drive,
and it sits at this icon forever and won't load. What could be going wrong?
Nothing on the forums shows information on this issue.


I can never remember the name of that thing, but I'm guessing that is
simply a session choosing screen(?).

Have you tried asking him to [double]click on the icon? If that doesn't
solve the "problem" then I don't know what will.


If i remember correctly during startup of KDE it shows 4 or 5 icons 
representing the stage of the it's startup.
The first one is a hard drive icon, second has to do with adding devices 
i think.


Hunter,
if the icon you got is indeed that harddrive icon, something is worng 
with the setup of KDE.

try creating a new testuser and start kde logged in as the testuser.

If KDE also doesn't start for the new testuser, then something is wrong 
with the kde installation.






Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

2014-05-05 Thread LoneVVolf

On 05-05-14 15:05, Maciej Puzio wrote:

Perhaps a larger audience would have allowed a
consideration of alternative solutions. An example of such a solution
would be hourly/daily/monthly/weekly timers that execute scripts from
relevant /etc/cron.* directories. That would allow for removal of
cronie while sidestepping timer elapse problems that we are discussing
here. It would also have a benefit of handling all cron tasks in
addition to logrotate/updatedb/man-db/shadow.

Thanks
Maciej Puzio

That sounds like a good idea.
Instead of removing the entire cron system, this would allow 
systemd-timers to function as an alternative to cron.
it would also reduce the increasing dependency archlinux has on systemd 
as init system.


Lone_Wolf




Re: [arch-general] PPPoE broken on upload

2014-04-22 Thread LoneVVolf

On 22-04-14 02:49, Wayne S wrote:

No answers on previous post so starting new topic.

Recent updates have caused problems with my PPPoE FIOS link. The upload speed 
has been reduced to near zero.

I "was" using arch linux box as a firewall router. I have a verizon fios connection 
that still uses the old pppoe. Recently the pppoe connection upload bandwidth went down to < 
50kbps (normally it is >25Mbps), however the download bandwidth is still around 58Mbps.

There was a recent thread about recompiling PPP to 2.4.6, however, whatever 
this change did in recent updates, has broken my router PPP connection upload 
speed.

What was the previous version of ppp that did work ?

During boot pppd 2.4.6 is started and the message RP-PPPoE plugin version 3.8d 
compiled against pppd 2.4.6. I see no errors.
latest rp-ppoe version in repos is 3.11.5 , have you tried with that 
version ?

please post a complete log of a boot.

I switched over to using the Verizon actiontec fios router and it works OK. I 
switched over to an archlinuxarm on a Utilite computer, and it works OK.

what version of ppp /rp-ppoe does the archlinuxarm system use ?
Have you compared the arm PKGBUILDs with the x86_64/i686 PKGBUILDs ?

  I built a new arch based firewall router on a different computer, and it has 
the same problem with the latest Arch on my existing router. Which leads me to 
conclude that something went wrong with pppoe after the recompile to 2.4.6.

Any help would be welcome on what is going on, or how to diagnose.

Wayne





Was the new arch based fw router a fresh install, or an existing system ?

Note : I know a bit about the ppp/rp-pppoe protocols but next to nothing 
about it's practical use.
My questions are intended to get information that will help 
troubleshooting this.


Lone_Wolf


Re: [arch-general] Error when I try update pacman -Syu

2014-03-25 Thread LoneVVolf

On 25-03-14 16:09, Maykel Franco wrote:

2014-03-24 18:58 GMT+01:00 Karol Blazewicz :

On Mon, Mar 24, 2014 at 5:54 PM, Thomas Bächler  wrote:

Am 24.03.2014 17:18, schrieb Karol Blazewicz:

jre7 is in the AUR so pacman won't update it, but jre7-openjdk is in
the repos and provides the same 'item' as jre7: java-runtime=7
https://aur.archlinux.org/packages/jr/jre7/PKGBUILD
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/
that's why they conflict.

That's not why they conflict. It's because jre7 explicitly has
java-runtime=7 as a conflict (among others). 'conflicts' has nothing to
do with 'provides'.


You seem to be using jre7. If you want to keep using it, you have to
keep jre7-openjdk out. Try adding it to IgnorePkg.

And how will that help?


root@arch-maykel /home/maykel/ # LANG=C yaourt -Rdd jre7-openjdk
error: target not found: jre7-openjdk

It seems that a package is updated and the newer version explicitly
depends on jre7-openjdk. This is probably a packaging error (although
after a quick glance at the repos, I cannot find any such package).


You're right, Thomas.
Maykel, install expac and run
expac "%n - %E" -S $(checkupdates) | grep jre7-openjdk


Thanks for all. This command not result anything


Maykel,

The error suggests you have jre7 installed from aur 
(https://aur.archlinux.org/packages/jre7/ ).

Do you remember why you have that installed ?
the output of pacman -Qi jre7might also help to figure that out.

Lone_Wolf



Re: [arch-general] PKGBUILD any way to create pkg-A & pkg-A-test that install w/o conflict

2014-03-08 Thread LoneVVolf

On 08-03-14 06:18, David C. Rankin wrote:

All,

   Is it possible to create multiple packages that have different package names
but are the same package (with different patches) and have them install without
conflict? (for testing) Currently I'm testing systemd patches for pkg
'tde-tdebase'.  I built a separate package with the systemd patches called
'tde-tdebase-systemd'. Both have the same provides=('tdebase').

   Whenever I attempt to install tde-tdebase-systemd, it conflicts with every
file from the old tde-tdebase packages requiring a 'pacman -Rdd tde-tdebase',
then a pacman -U tde-tdebase-systemd to install.

   I would like to find something like replaces=() that would work on simple
package installs without doing a Sysupgrade each time I switch back and forth.
Is this possible, or is it just better to keep the same pkgname and use
different pkgrel to distinguish (I've been doing it this way, but would like to
use a descriptive filename that identifies included patches) I know 'replaces'
is only for Sysupgrade, is there any workaround for normal package installs?


David,

Try using a virtual package and combining provides=()  with conflicts=()

example

pkgname="foo"
provides=('foo-base')
confilcts=('foo-base')

pkgname="foo-alternative"
provides=('foo-base')
confilcts=('foo-base')


switching between foo and foo-alternative should then be possible by 
doing a simple pacman -S (or -U) .


Note : it can be done without a virtual package foo-base, but imo using 
a virtual package makes it clearer what happens, especially if you want 
to test multiple alternatives.


LW