[arch-general] Inconsistencies with cc and c++ binaries
The /usr/bin/cc executable is a symbolic link to /usr/bin/gcc whereas the /usr/bin/c++ executable appears to be a hardlink to /usr/bin/g++. Why are the links different types? Wouldn't it be more clear to make both symbolic links or both hard links? -- Jordan
Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On Thu, Apr 10, 2014 at 5:21 AM, Daniel Micay danielmi...@gmail.com wrote: On 09/04/14 11:12 PM, Allan McRae wrote: Now that aside is finished, what is the deal with that arch-haskell group? Is it still going? Would they want to provide packages officially instead? It's definitely still active. They seem to have all the necessary automation worked out. AFAICT they do an automated conversion from the cabal files and maintain a set of patches for adding external dependencies, etc. https://github.com/archhaskell Indeed, it's still active. Not steaming-full-ahead-lika-a-freight-train active, but we're bringing in updates and adding new packages at a somewhat leasurely pace :) The tool that makes it possible is cblrepo - https://github.com/magthe/cblrepo Beyond that there are a few scripts that makes the chore of keeping packages up-to-date largely automated. The experience is that a single person can keep over 200 packages up-to-date with spending about 15-30 minutes per week. The builds of course take longer than that (sometimes much longer), but they don't require active monitoring. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus
Re: [arch-general] Yakuake not expand with shorcut
2014-03-20 13:24 GMT+01:00 Maykel Franco maykeldeb...@gmail.com: Hi, I like very much yakuake. I like expand the terminal to right, left, up, down with shourcut , but not found when assign the keys. Attach photo. http://imgur.com/a/sf4it - Grow terminal to the left, to the right, to the top...not found with keys... Why? I don't now why. Yakuake in gentoo works very well to expand the terminal. Yakuake depend the konsole. Sorry for my english. Thanks in advanced. I resolved my problem. For expand yakuake to up, down, left, right...I use the shourtcut: Mayus + Alt + up/down/left/right Thanks for all.
Re: [arch-general] Error when I try update pacman -Syu
2014-03-25 21:14 GMT+01:00 LoneVVolf lonew...@xs4all.nl: 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 I have install the jre7 because java openjdk use 90% CPU when connect to proxmox VMs. Also, jre7 works to applications very well, as netbeans, jitsi... Now, I have installed openjdk: maykel-arch /home/maykel :( # java -version java version 1.7.0_51 OpenJDK Runtime Environment (IcedTea 2.4.6) (ArchLinux build 7.u51_2.4.6-1-x86_64) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode) And at the moment, works very well... Thanks for all.
Re: [arch-general] X11vnc in xbmc archlinux
2014-04-07 15:08 GMT+02:00 Bigby James bigby.ja...@crepcran.com: On Mon, Apr 07, 2014 at 01:06:06PM +0200, Maykel Franco wrote: 2014-04-07 13:00 GMT+02:00 ger...@gmail.com ger...@gmail.com: I need start x11vnc when computer boot... Sorry for my english. Thanks for your response. -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams There's probably a systemd unit for the VNC daemon you're using; enable it like any other. You can start the VNC client on login by adding it to .xinitrc (or using the autostart feature of your desktop environment). Thanks. I try and comments the results.
Re: [arch-general] Error in chrome when I moved sidebar
2014-03-11 18:24 GMT+01:00 Daniel Micay danielmi...@gmail.com: On 11/03/14 12:54 PM, Maykel Franco wrote: Hi, I get this lines in chrome when I moved sidebar the right: http://es.tinypic.com/view.php?pic=14kbeyws=8#.Ux8-xpDuKnk Can I help me please? Is a bug the chrome? Thanks in advanced. Looks like a video driver bug, I doubt it's a Chrome bug. You should really be using Chromium though, not Chrome. It's nearly identical but is open-source and has fewer old bundled libraries. You can use both the pepper flash plugin and PDF viewer in Chromium. If you've disabled the Chrome GPU blacklist in the past, revert that change. Look into whether your video drivers are broken by testing other OpenGL applications. How I can use video driver? I have two graphic card, intel and nvidia: maykel-arch /home/maykel # lspci | grep -i VGA 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 630M] (rev a1) Thanks.
Re: [arch-general] My Apache Sever Compromised?
On 2014-04-09 19:32, Jameson wrote: On Tue, Apr 1, 2014 at 9:30 AM, Nowaker enwuk...@gmail.com wrote: 199.83.93.35 - - [29/Mar/2014:22:04:54 -0400] GET http://ro2.biz/pixel.png HTTP/1.0 200 151 But the most interesting part is that your apache is replying with 200, that is OK! Nice catch! It's certainly a proxy. Thanks for everyone's help with this. I did in fact have ProxyRequests set to On thinking it was needed for reverse proxies as well, and have turned it off. Now, when I open up port 80, it looks like they're still trying, but I'm replying with 404. Is that what it should be doing? I probably also need to make sure I have some throttling setup in case this is too much for my Internet connection. One approach I've seen mentioned and which seemed fun, but -- I hasten to add -- have never personally tried is to start returning shock site images for all such requests (obviously not for all 404s, just attempts at abusing you as a proxy). Regards,
Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On 2014-04-09 09:07, Magnus Therning wrote: Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps. It should be noted that cabal-install isn't a package manager in the true sense[1]. I'm not sure this is an argument against making the change you propose, but it's worth noting. With sandboxing/hsenv I've actually found cabal-install it to work much better than attempting to use distro packages for some libraries. (There error messages for stuff that requires native C libraries aren't always stellar, but that's something you quickly get used to.) There are quite a few other language/frameworks that have language-specific build/package systems, Python, Ruby, Perl, node.js... Are Python developers on Arch pointed towards using pip to install Python libs? I can only speak to node.js, but I think the general consensus there is to only use the distro-provided node.js and npm and then have user-specific/project-specific node_modules directories. (This is driven in part by npm's design and the extreme pace at which the ecosystem seems to be moving.) Given the limitations of GHC when it comes to module interoperability between versions, I think this approach makes sense for GHC too. (Btw, there's work afoot to adress this, but it's probably a few years off: http://plv.mpi-sws.org/backpack/ ) I think sometimes the right thing is to point users to another package manager, e.g. packaging vim scripts for system wide installation is a bit silly, since installing a vim script affects ALL users on the system. So doing that would require providing some sort of vim-script manager to users. Then there's very little difference compared to just telling users to use Vundle/Pathogen/whatever directly instead. However, this isn't the case for Haskell/GHC... AFAIK (and unfortunately) globally installed Haskell/GHC packages can greatly constrain what other packages you can install in a sandbox. That's been a huge problem for me in practice, which is why I personally always install ONLY ghc and cabal-install and use cabal sandboxing/hsenv for the rest. (Did this on Ubuntu as well when I was a user of that.) I think it would be a good idea to strip everything back to just having GHC and cabal-install in the base and to take some time to rethink how packaging everything else should work. I don't know if Cabal supports such a thing, but one idea off the top of my head for a new approach would be to have a distro-provided read-only *sandbox* which other read/write sandboxes could be *overlaid* on top of. That would mean that you could opt out of the distro-installed packages if you need to, but could still install distro packages if you, e.g. wanted/needed a Haskell program which depended on having haskell packages installed (git-annex?). Crazy idea? Regards,
Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On 2014-04-10 06:39, Thomas Dziedzic wrote: On Wed, Apr 9, 2014 at 8:12 PM, Allan McRae al...@archlinux.org wrote: Now that aside is finished, what is the deal with that arch-haskell group? Is it still going? Would they want to provide packages officially instead? I wouldn't actually be opposed to this idea. A lot of effort is duplicated with regards to Archlinux's official haskell packages and Arch-Haskell's packages. We could try to work out something between the existing haskell package maintainers and arch-haskell maintainers. It might lead to a possibly better overall haskell experience on archlinux. Arch-haskell could maintain official haskell packages using pacman. I (and anyone interested) could support haskell package installation using the cabal-install route. Would this mean that only ghc and cabal-install would be in any of the official repos and that everything else would be relegated to arch-haskell? If so, then +1. (As mentioned in another email I think Haskell distro packaging in general could use a rethink, possibly based on sandboxing.) Regards,
[arch-general] Error in wireshark-gtk2 in show interfaces for capture
Hi, I have installed wireshark-gtk2. But when go to Capture/Interfaces I get this error: There are no interfaces on which a capture can be done. I follow this steps: Setting network privileges for dumpcap 1. Ensure your linux kernel and filesystem supports File Capabilities and also you have installed necessary tools. 2. setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap 3. Start Wireshark as non-root and ensure you see the list of interfaces and can do live capture. Limiting capture permission to only one group 1. Create user wireshark in group wireshark. 2. chgrp wireshark /usr/bin/dumpcap 3. chmod 754 /usr/bin/dumpcap 4. setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap 5. Ensure Wireshark works only from root and from a user in the wireshark group Thanks in advanced.
Re: [arch-general] svntogit stuck
Am 10.04.2014 06:23, schrieb Kevin Mihelich: Both packages.git and community.git appear to be stuck again, with no updates for the past day. On Fri, Mar 28, 2014 at 2:14 PM, Joel Teichroeb j...@teichroeb.net wrote: packages.git looks fine to me now, but community.git is still stuck. I killed the lock file again, and now the log spits this out. Evangelos, what's going on here? == Updating 'packages' Git repository on Thu Apr 10 11:54:02 UTC 2014 - Fetching changes from SVN git svn rebase command failed; skipping to next repository == Aborted updating 'packages' on Thu Apr 10 11:54:10 UTC 2014 signature.asc Description: OpenPGP digital signature
Re: [arch-general] svntogit stuck
On 10/04/14 14:55, Thomas Bächler wrote: Am 10.04.2014 06:23, schrieb Kevin Mihelich: Both packages.git and community.git appear to be stuck again, with no updates for the past day. On Fri, Mar 28, 2014 at 2:14 PM, Joel Teichroeb j...@teichroeb.net wrote: packages.git looks fine to me now, but community.git is still stuck. I killed the lock file again, and now the log spits this out. Evangelos, what's going on here? == Updating 'packages' Git repository on Thu Apr 10 11:54:02 UTC 2014 - Fetching changes from SVN git svn rebase command failed; skipping to next repository == Aborted updating 'packages' on Thu Apr 10 11:54:10 UTC 2014 Thomas, thanks for looking into it; I fixed the Git repo just now. Generally it's not safe to remove the lock file without identifying the reason the script failed. It's not a very robust script and the Git repo can be left in an inconsistent state which would require manual rollback of several package branches. I pushed a change that should make it fail significantly less (gerolde being unreachable for pushing has been the cause of failure 2-3 times now): https://github.com/foutrelis/arch-svntogit/commit/ecc3090 signature.asc Description: OpenPGP digital signature
Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On Thu, Apr 10, 2014 at 01:34:00PM +0200, Bardur Arantsson wrote: On 2014-04-09 09:07, Magnus Therning wrote: Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps. It should be noted that cabal-install isn't a package manager in the true sense[1]. I'm not sure this is an argument against making the change you propose, but it's worth noting. With sandboxing/hsenv I've actually found cabal-install it to work much better than attempting to use distro packages for some libraries. (There error messages for stuff that requires native C libraries aren't always stellar, but that's something you quickly get used to.) I know some people swear by cabal-install, but I've personally never gotten into using it. The sandbox feature does look neat and I've been meaning to try it out. A very first attempt just now did not impress me though: it wanted to downgrade bytestring for no discernible reason. Probably a user error though. I think it would be a good idea to strip everything back to just having GHC and cabal-install in the base and to take some time to rethink how packaging everything else should work. Personally I think it depends on what everything else is. One approach would be to centre everything around applications. To some extent I think that is the (maybe not explicit) rule for the rest of the packages. That would mean libs aren't packaged for their own sake, only in order to provide an application. This would mean that it'd be entirely possible to /only/ have ghc + cabal-install and still package all applications written in Haskell[^1]. /M [^1]: Ghc still links applications statically it seems so building in a sandbox and then only package the resulting executables. -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpgubFeQGYHF.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] GHC 7.8.1 packaging decisions for Arch Linux
On 04/09/2014 01:27 AM, Thomas Dziedzic wrote: Problem 2: Users are confused whether they should install packages from the repos or using cabal-install. This in turn sometimes causes them to install some packages from official repos, some from the aur, and some using cabal-install Explanation: Packages should ideally be installed from one place, either using repos/aur or cabal-install. Said that, it is entirely possible to use both repos/aur and cabal-install but for simplicity, one source is preferred. Doesn't every language with its own package manager have this problem? For example, Python. Is there a good solution? Users knowing about this issue and making their own decisions is the current solution on every distro I'm familiar with. Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps. This is the way I do it on my personal computer, FWIW. If there were any packages in the repo written in Haskell that are used by non-Haskellers, then all those packages' deps would have to be in the repos too. (e.g. darcs and pandoc, which are in AUR currently). Cheers, -Isaac
Re: [arch-general] [aur-general] [arch-dev-public] GHC 7.8.1 packaging decisions for Arch Linux
On Thu, Apr 10, 2014 at 7:20 PM, Jeremy Audet ichimonj...@gmail.com wrote: Doesn't every language with its own package manager have this problem? For example, Python. Is there a good solution? Users knowing about this issue and making their own decisions is the current solution on every distro I'm familiar with. Aye. There are some upshots to allowing users to install software via either the system package manager or a language-specific one, instead of forcing them down a single path. For example, with ruby: tools such as bundler, rbenv and rvm provide users with some awesome capabilities, such as being able to install multiple versions of Ruby and multiple versions of gems, either system-wide, in a user's home directory or in a custom directory. That's very useful, and the user should have that option - but if the user wants a simpler, more straightforward option, they can use `gem` or `pacman`. (And the choice between gem and pacman has its own tradeoffs.) Couldn't the same be said of Haskell packages? Using pacman to manage haskell packages provides some niceties, such as automatic updates (whenever -Syu is performed), whereas cabal-install provides its own niceties, such as access to numerous packages. So... is there anything wrong with letting the user choose the tool that suits their needs? I guess I should modify my wording for Change 2 to be: Change 2: Make a news item stating that either cabal-install or pacman packages are now the recommended way to install haskell packages. Not both in one system.
