Re: [arch-general] Kernel 4.19 preventing Firefox from playing videos
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
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)
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
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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=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
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
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
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
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
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
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.
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.
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?)
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
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
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
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
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
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
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
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)
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
On 19-07-15 20:06, Alan E. Davis wrote: Tux guitar works well, so far; however, when trying to access Documentation through HelpDocumentation 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. snip 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
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
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
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'
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'
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?
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
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 # snip # - 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
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?
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
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
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
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
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
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] makepkg.conf CFLAGS
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
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}?
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
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
On 25-03-14 16:09, Maykel Franco wrote: 2014-03-24 18:58 GMT+01:00 Karol Blazewicz karol.blazew...@gmail.com: On Mon, Mar 24, 2014 at 5:54 PM, Thomas Bächler tho...@archlinux.org 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
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
