[arch-general] [Proposal] add python 3 support for gvim in [extra]
Hey all, I would like to add progress to the bug FS#34397 - [gvim] has --disable-python3interp [0]. I feel like it's about time to start looking into supporting python 3 in gvim. After some research, it looks like it would be problematic to support both python versions compiled into the same vim version. That said, python2 seems to still be the primary target of most vim plugins. Though a lot of these plugins also support python 3 at the same time. Currently there is no obvious right answer to which python version we should support since python2 obviously has the most support, but on the other hand, we should support the latest version of python since that is where the future lies. This proposal is to keep the existing vim/gvim packages in [extra], but add a 3rd split version called gvim-python3 or just gvim-python which would provide the exact same features as gvim except with python 3 support instead of python 2. This would allow the community to start experimenting with python 3 support and start reporting any issues to upstream vim plugins. While allowing users that don't really want to live on the edge to still use gvim as they previously had been using it. Eventually I would like to replace gvim with the python 3 version and provide a gvim-python2 version so that the default becomes python 3 but we would still provide a python 2 version for people that still need it. After some more time, I would like to eventually drop gvim-python2 to the aur and only support the python 3 version. I still don't know when these switches will happen, but for now, I would like to take the first step. It also seems that there is a python 3 version of gvim available in the aur [1]. Hopefully this would allow more people to experiment with python 3 support by removing the need to compile it and have it in supported repos. What do yall think? [0] - https://bugs.archlinux.org/task/34397 [1] - https://aur.archlinux.org/packages/gvim-python/
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.
Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On Wed, Apr 9, 2014 at 12:07 AM, Magnus Therning mag...@therning.orgwrote: I'm guessing this means cabal-install now is the only package outside of [community] that uses ghc to build. Is that right? That would be correct. Is the plan then that any future tools (i.e. non-libraries) implemented in Haskell would go into [community]? This would also be correct. I believe that most people who use packages in our supported repos don't actually use the haskell libraries themselves, but rather the tools that depend on them. (e.g. xmonad) I am not against keeping these tools around and their dependencies if someone wants to maintain them, but I personally have no interest in maintaining them myself. devil advocate There is nothing that say one HAS to wait for a ghc upgrade in order to provide newer versions of Haskell packages. As you point all that's needed is a rebuild of all the packages that depend on the upgraded one. If that's messy it sounds like you are using bad tools to handle upgrading. Are you really suggesting ArchLinux abandon packaging a whole class of software just because the tools are inadequate? /devils advocate I am aware that the way we are packaging haskell packages is non optimal and could be automated away. I already have a tool that automates the rebuild of [extra] packages, but since I don't/want to maintain any packages that aren't dependencies of cabal-install, I haven't looked into automating those builds. I don't want to focus solely on this point though because I just felt like I should make people aware of this problem. This isn't the only reason why I want to move away from haskell packages in pacman. 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. I agree. Cabal does lack even basic features that other people would expect from a package manager. For example, upgrades, removal. Although there are ways to have the same effect as upgrading since you can have multiple versions of the same package installed, you could just install the same package after a cabal update. That's why I suggested writing up a tip sheet on basic cabal usage for people who aren't as used to cabal as others. 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 think that the languages you mentioned could be split up into 2 categories. Python and Perl have a large number of interested developers and trusted users maintaining those packages. Python has over 700 packages, and Perl has over 500 packages and so, there is a lot of interest in those languages. On the other hand, you have Haskell, Ruby, and Node.Js where they have a smaller following. Haskell has about 90 packages (including i686/x86_64), Ruby has about 60, and Node.Js has approximately none. The popular languages have a critical mass which I believe lets people get away with using the pacman package manager. So for languages like python and perl, it might make sense to use pacman. But for languages like haskell, ruby, and node.js I believe using the system package manager leaves a lot to be desired. How do you envision this actually working? I would like to officially announce that there are 2 paths of maintaining haskell packages on your system. One would be using cabal-install and I would encourage users to try using it. The other would be to use whatever is in the supported repositories. I would also like to officially announce that one or the other is supported, but they should be mutually exclusive. The set of packages in [extra]/[community] is rather small today, in the order of 3 dozen, so does this mean that users are already turning to the Arch devs when they are having problems compiling Haskell packages? No. I believe that most users actually know what the correct path is. I just want to make it officially announced rather than having any potential confusion on which path to take and which paths are supported.
Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
On Wed, Apr 9, 2014 at 12:35 AM, Jelle van der Waa je...@vdwaa.nl wrote: I would like to keep XMonad/XMobar in [community] it does seem to take up a big chunk of the haskell-* packages we have in our repos. But I've never ran into real big issues packaging haskell libraries, one minor issue is that the developers tend to oversplit packages for example haskell-data-default-* . This really makes packaging haskell libraries annoying. I don't want to prevent people from maintaining haskell packages in supported repos. I just want to make cabal-install a path with which people don't have to think twice about. I would prefer that we don't package vim plugins or firefox extensions. Firefox has it's own extension manager and vim has a lot of solutions which work better then pacman I also share this belief about haskell. Both pacman and cabal-install have their own pros and cons, but for my personally, I find that cabal-install has more benefit to me personally for haskell packages. How many haskell developers actually use our packages in the repos/aur rather then using caba-install? I can only speak from personal experience, but I have used cabal-install exclusively for a couple of years now not just for development but for also installing tools like xmonad. My guess is that given the limited supply of packages in our repos, I can guestimate 0 use it for development but there might be a lot of users that actually use the haskell tools like xmonad.
Re: [arch-general] [arch-dev-public] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux
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.
[arch-general] GHC 7.8.1 packaging decisions for Arch Linux
Hello all, With the arrival of ghc 7.8.1 [0], I would like to address the following problems with a restructuring of how we treat haskell packages in archlinux: Problem 1: Updating any haskell package has been delayed until we bump ghc. Explanation: ghc is unable to produce a library that has a stable abi. In other words, if a library gets rebuilt (even if it's the same exact source), we will need to rebuild all package that depend on it, and this would in turn a messy rebuild for any kind of rebuild. 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. Problem 3: Our repos are unable to package every haskell package Explanation: hackage has over 5000 haskell packages in it currently. There is no way we will be able to support that many packages in our official repos without some kind of automation. And even if it would be possible, it would not necessarily be desirable. In addition, it is entirely possible to have multiple versions of the same package installed at the same time. Cabal has a very elaborate dependency solver in order to find versions that will work for all package versions installed. In addition, cabal-install 1.18 (the latest released) has added support for sandboxes, meaning that when developing haskell programs, you are now able to setup a sandbox environment that will only contain the haskell packages you want. I would like to propose the following changes to address the mentioned problems and having the ability to use sandboxes to isolate development environments. Change 1: Move every haskell related package out of [extra] into [community] except ghc and cabal-install. This includes the following 8 packages: haskell-http, haskell-mtl, haskell-network, haskell-parsec, haskell-random, haskell-text, haskell-transformers, haskell-zlib Explanation: These packages are only required to build cabal-install. Since we converted the cabal-install package to use the bootstrap script that comes with it, we no longer depend on these packages for anything in [extra]. 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. Change 3: Support users who are unable to install haskell packages that do not compile under archlinux. This would require working with the user and upstream to open up tickets and write patches for programs. At the very least we can work with the user if they do not to open up upstream bug reports and track them in our own bug tracker. There might be some packages which we would probably consider unsupported like bindings to packages that are not in the supported repos and packages that have no upstream activity and ones that are effectively unmaintained. Hopefully with the proposed changes, we can improve our user experience with using official tools to maintain haskell packages. I realize that some changes might be controversial especially change 3. This is why I posted this here in order to discuss the possibilities. I would also love to hear some opinions from vegai since he has some previous experience package haskell and has had similar thoughts in the past. Also if you're not a developer or trusted user, I would also like to hear your opinion since it would affect you also. Thanks for your time, - Tom [0] - https://github.com/ghc/ghc/releases/tag/ghc-7.8.1-release
[arch-general] Moving the latest vim to [extra].
I usually update vim every 50 new patches. But the latest vim has been in testing for 300 patches because there have been some major changes introduced in preparation for 7.4 which have introduced a load of new bugs. I just updated vim in [testing] to 7.3.1270. I have been using the latest vim and have found that it is sufficiently bug free for me for general use. Please give vim in [testing] a shot and make sure to report any bugs. Unless there are any major issues, I want to finally move it to [extra] this wednesday. The area where you are most likely to experience any issues is when using the new regexp engine. If you notice slow syntax highlight or wrong regular expression matching, make sure to report it and set regexpengine=1 for a temporary workaround to switch to the old regular expression engine. Thanks and have a great weekend :)
[arch-general] GHC 7.6.1 now in [testing]
Hey everyone! It's that time again for arch to get the latest ghc! GHC 7.6.1 comes with a bunch of new and exciting features: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html This morning, all the haskell packages should have been rebuilt against the latest ghc and I have moved all haskell pkgs to testing. One caveat is that cabal-install wasn't rebuilt but it should still work while upstream works on patching it for ghc 7.6.1 It took just under a month to do the full rebuild because of the amount of patching and coordination with upstream we had to do. I will let it sit in testing for a week so that aur maintainers for haskell pkgs have time to investigate and patch their packages. I would like to thank everyone who worked on this rebuild! Cheers!
[arch-general] haskell updated on arch
Ghc 7.4.2 was just moved to [extra]. There should be no problems since it was only a minor bump. haskell-binary was moved to the aur since ghc already provides it. Release notes: http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html Happy hacking!
[arch-general] ghc 7.4.1 moved to extra
I have finally moved the new ghc to arch repos. With this cleanup comes a bit of change. The decision has been made that ghc will be updated to the latest stable version and haskell-platform will be moved to the aur. This means you should remove the haskell-platform related packages before updating. I will also keep only essential packages and their dependencies related to haskell in [extra]. For now this means cabal-install and ghc + their depends. I have closed the following bugs with this release: https://bugs.archlinux.org/task/23247 - [ghc 7.0.2] ghci -package ghc causes panic https://bugs.archlinux.org/task/27132 - [ghc] re-enable the strip makepkg option https://bugs.archlinux.org/task/18917 - [ghc] ghc.install :: test if directory exists https://bugs.archlinux.org/task/28758 - [haskell-text] uninstallable due to removal of haskell-deepseq https://bugs.archlinux.org/task/25991 - haskell-glut: undefined references to pretty much all glut functions https://bugs.archlinux.org/task/25072 - [alex][happy][cabal-install] missing makedepnds The following bugs are still open which I will fix as soon as cabal-install and darcs are buildable: https://bugs.archlinux.org/task/27249 - [cabal-install] Add bash completion support https://bugs.archlinux.org/task/26955 - [darcs] missing makedependence haskell-hashed-storage0.6 There are still some issues left with the current situation of haskell on arch, but these will take time and communication with upstream. *I need to figure out what to do about haddock since ghc only packages the binary and thus provides only half the package with ghc. This is the reason why we packaged haskell-haddock even though the ghc package already provides the haddock binary. *The post-install messages related to haskell packages can get pretty long. There is a proposed solution with a patch, but I need to figure out if there is any way we can work it out with upstream first. *There is no cabal-install or darcs version that is marked as stable and currently builds with ghc 7.4.1 These packages are statically linked so it shouldn't matter for now. I will be keeping an eye on these packages and waiting for upstream to provide new stable versions that builds against the latest ghc. Cheers!
Re: [arch-general] ruby 1.9.3_p125-1 in [extra]
On Sun, Feb 26, 2012 at 4:40 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Saturday 25 Feb 2012 14:04:03 Thomas Dziedzic wrote: If you run sudo gem install foo, it will install to /root/.gem/ruby Are you sure? Won't it install to your normal user's home, but with root privileges? Paul I'm sure
[arch-general] ruby 1.9.3_p125-1 in [extra]
I have released ruby 1.9.3_p125 into [extra]. This is a version bump (p0 - p125) and all tests passed for me. Along with the update, I will be introducing the following new conventions as part of my ruby cleanup project. /usr/lib/ruby/vendor_ruby is now the correct location where non-gem ruby libraries installed with pacman should go. If your package installs anything to /usr/lib/ruby/site_ruby, you have to update to the new location. Site_ruby is only there for files installed specifically by the user without a package manager. A new file will be created at /etc/gemrc where I add --user-install as the default option for gem. This will install all gems by default to $HOME/.gem/ruby. You will have to add the new bindir to your PATH if you decide to install gems that provide binaries. export PATH=$PATH:$(ruby -rubygems -e 'puts Gem.user_dir')/bin As a result of the above change, all ruby gem packages will have to add a --no-user-install flag when running gem in the PKGBUILD. If you run sudo gem install foo, it will install to /root/.gem/ruby To install to the system-wide gems location (not recommended), you will have to either remove --user-install from /etc/gemrc or you will have to pass the --no-user-install flag when using gem as root. Cheers!
Re: [arch-general] [arch-dev-public] Ruby directory clean up proposal.
On Wed, Feb 15, 2012 at 3:58 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Tuesday 14 Feb 2012 01:53:01 Peter Lewis wrote: I think it's worth separating out the user and the admin in this argument. To install a gem system-wide, you have to do something like sudo gem install XXX, right? This is almost always a bad idea, IMO, and people hopefully won't do it at least during the normal run of working with ruby. Personally, I don't let gem mess with anything outside my home directory. I'm worried. I use sudo gem install to install gems system-wide. It's not practical to use Arch packages for this instead, because I can't rely on a given gem always being packaged for Arch. I also don't really see the point of packaging a package from another packaging system which already happily co- exists with pacman. I have no issue using gem to administer system gems, since they always stay in /usr/lib/ruby and don't interfere with the rest of the system (except for /usr/bin, admittedly). Some people choose to use pacman packaged gems because it handles deps better and patches could get included to fix some issues. I will only be implementing the changes in the planned layout only this cleanup. That means I wont be moving system-wide installation to /var/.. yet Don't worry, I wont forget about users that use gem to install to system wide locations. As already mentioned, I will make the default gem install to $HOME/.gem/ruby and if you so choose, you can edit your gemrc to install to the system wide location (/usr/lib.. for now). Can you clarify if you're planning to make it impossible to use gem to install system gems? I *really* want to avoid using pacman for system gems and gem elsewhere. It makes no sense to me. I'd rather use gem for all gems. I wont be forcing anyone to use pacman instead of gems, now or in the future. Maybe a quick summary of the plans so far? Paul Summary of the changes in this cleanup: /usr/lib/ruby/site_ruby - This directory is for user specific installation and should never be touched by the package manager. /usr/lib/ruby/vendor_ruby - ruby packages installed with pacman which aren't gems go here $HOME/.gem/ruby/[ruby_base_version] - default target when running gem install foo because --user-install is now in the gemrc file /etc/gemrc - contains gem: --user-install to install user installed gems with gem to $HOME/.gem/gems If the user chooses to install gems using gem, they will have to add the bin directory to the $PATH: export PATH=$PATH:$(ruby -rubygems -e 'puts Gem.user_dir')/bin. System wide installation of gems by default will be disabled. If you want system wide gems, either run gem with the --no-user-install flag like sudo gem install --no-user-install foo You can also install to the system wide location by removing --user-install from /etc/gemrc
Re: [arch-general] [arch-dev-public] Ruby directory clean up proposal.
On Wed, Feb 15, 2012 at 9:06 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Wednesday 15 Feb 2012 08:59:10 Thomas Dziedzic wrote: /usr/lib/ruby/site_ruby - This directory is for user specific installation and should never be touched by the package manager. /usr/lib/ruby/vendor_ruby - ruby packages installed with pacman which aren't gems go here $HOME/.gem/ruby/[ruby_base_version] - default target when running gem install foo because --user-install is now in the gemrc file /etc/gemrc - contains gem: --user-install to install user installed gems with gem to $HOME/.gem/gems If the user chooses to install gems using gem, they will have to add the bin directory to the $PATH: export PATH=$PATH:$(ruby -rubygems -e 'puts Gem.user_dir')/bin. System wide installation of gems by default will be disabled. If you want system wide gems, either run gem with the --no-user-install flag like sudo gem install --no-user-install foo You can also install to the system wide location by removing --user-install from /etc/gemrc This all sounds mostly fine. I assume that sudo gem install will simply install the gem using root-owned files in the home directory, right? Paul Correct, by default sudo gem install foo would install to /root/.gem/ruby which isn't system wide. If you really want system wide installs, either run sudo gem with --no-user-install or remove --user-install from /etc/gemrc
Re: [arch-general] [arch-dev-public] Ruby directory clean up proposal.
On Tue, Feb 14, 2012 at 3:04 AM, Peter Lewis ple...@aur.archlinux.org wrote: On Monday 13 Feb 2012 20:47:01 Thomas Dziedzic wrote: /etc/gemrc - contains gem: --user-install to install user installed gems with gem to $HOME/.gem/gems I didn't know about --user-install, but I just set GEM_HOME (actually, I use RVM). Can what you want be done by globally setting GEM_HOME to be based off of $HOME? Or is --user-install the preferred way? I did look into $GEM_HOME but I thought this was inadequate since running sudo gem install foo would still install foo to the system-wide gem directory. Having --user-install in /etc/gemrc forces it to install to /root/.gem/gems instead. Great, I should have read up on --user-install then. Sounds great. And as much as I have to admit that I'd really like to be able to install gems system-wide and use their built-in dependency management, bundler etc... I think that road probably leads to madness and death, especially when many popular gems will still be managed by pacman (and rightly so). So, I would be careful about doing this, and would suggest that we go for only letting 'gem' install things under $HOME. Anything that should go system-wide should have a PKGBUILD. Right, by default I want it so that you wont be able to install system wide gems with gem. But I can't stop users removing --user-install from the gemrc file and installing to the system-wide directories. Perhaps we have an argument for proposing an option like --user-install that doesn't allow users to disable it then. I think just making --user-install the default will be fine. I don't want to stop people from doing this completely since there will always be around it. I have another plan brewing in regard to letting users separately install pacman installed gems and gem installed gems to the system-wide directory. I wont do it in this cleanup iteration, but next cleanup, I will add a /var/lib/gems or /var/lib/ruby/gems folder specifically so that when running sudo gem install without --user-install, it will install to /var/lib/.. and gems installed via pacman will install to /usr/lib/ruby/gems. This will cleanly seperate pacman installed ruby gems to /usr and sudo-gem without --user-install installed gems to /var. This will bring ruby and rubygems into fhs compliance, at least afaik :) Nice. Just out of interest, what RUBYLIB order precedence would you use, to deal with the case when some similar things (say different versions of the same gem) were installed in /usr/lib/ruby and /var/lib/gems at the same time? The order will be $HOME/.gem/ruby, /var/lib/gems, /usr/lib/ruby/gems Just to reiterate, the var path will be for system wide gems installed with gem. The usr path will be for gems installed with a PKGBUILD. Upstream seems to be fine with this order also. Doing this will require modifying the GEM_PATH and all PKGBUILDs that install ruby gems. This wont break the PKGBUILDs just make them uncompliant with our standards, instead it will just install to /var if you don't change them which will be in GEM_PATH. BTW, GEM_PATH is the location where rubygems searchs for gems. I have already talked with upstream rubygems devs and they seem to agree that this is a good plan :) I'm certain I will go with 1 this cleanup and will implement the above on the next cleanup. All great. Of course, suggesting RVM for user-installed gems(ets) is probably also a good idea. For rails development, I can't recommend rvm enough, you can manage multiple gemsets with multiple ruby versions, and have it automatically load project specific .rvmrc files when you cd into those directories. This is probably one of the nicest language management tools for a programming language I have encountered so I would recommend it :) Ofc, rvm might be overkill if you're just doing development on small projects, or if you just don't need a clean separation of multiple ruby environments. Agreed. It really is a breeze to use. I don't do much rails, but just use clean gemsets along with bundler, most of the time. It helps with predicting what's going to happen when I want to run the code on another machine. PS. A while ago I was getting very frustrated that the version of rubygems bundled with ruby itself was so out-of-date so quickly, but 'gem update --system' is a very bad idea in combination with pacman. So, I spent a while hacking together this package, which installs the latest version of rubygems itself alongside ruby, system-wide: https://aur.archlinux.org/packages.php?ID=50346 It's hacky, but it works :-) I wish there was a cleaner way. I was also thinking about this, and I might split rubygems off into a seperate package and have ruby optdepend or depend on it so I can update the package separately from ruby. Hell yeah. Please do. I assume you're aware of this: https://bugs.archlinux.org/task/17611 I wasn't aware
Re: [arch-general] GHC 7.4.1 or HP 2011.4.0.0??
On Mon, Feb 13, 2012 at 11:59 PM, Magnus Therning mag...@therning.org wrote: We ought to be ashamed, Debian unstable now has GHC 7.4.1! ;) http://packages.debian.org/sid/ghc In the meantime I've put together a repo with GHC 7.4.1 (x86_64 only) and a few packages: http://is.gd/L7ZBQC /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay Hi, I will be working with vega in around 2 weeks to update ghc and cleaning up the haskell pkgs. I'm not working on it right now because I'm currently focusing on cleaning up our ruby package and guidelines. Vega is working on a tool to help us with the update. If you really need ghc 7.4.1, I have a preliminary package for ghc at http://pkgbuild.com/~td123/ghc.tar Binaries are available under http://pkgbuild.com/~td123/ Note this is completely unsupported and should be only used if you know what you're doing. Not specifically saying this to you, but other people that come across reading this :) -Thomas Dziedzic
Re: [arch-general] GHC 7.4.1 or HP 2011.4.0.0??
On Tue, Feb 14, 2012 at 3:35 PM, Magnus Therning mag...@therning.org wrote: On Tue, Feb 14, 2012 at 12:07:13PM -0600, Thomas Dziedzic wrote: On Mon, Feb 13, 2012 at 11:59 PM, Magnus Therning mag...@therning.org wrote: We ought to be ashamed, Debian unstable now has GHC 7.4.1! ;) http://packages.debian.org/sid/ghc In the meantime I've put together a repo with GHC 7.4.1 (x86_64 only) and a few packages: http://is.gd/L7ZBQC Hi, I will be working with vega in around 2 weeks to update ghc and cleaning up the haskell pkgs. I'm not working on it right now because I'm currently focusing on cleaning up our ruby package and guidelines. Vega is working on a tool to help us with the update. All right, so it's coming that's good :-) Am I to understand that this means HP will go? That's the plan so far. In the meantime I'll try to build as many of the packages in [extra]/[community] as possible. That ought to be useful to you later on, particularly if any patches are necessary. This would be really awesome if you found the time to do this especially if you found any breakages and patches that fixed those. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
Re: [arch-general] [arch-dev-public] Ruby directory clean up proposal.
On Mon, Feb 13, 2012 at 7:53 PM, Peter Lewis ple...@aur.archlinux.org wrote: Hi, I'm not a dev, so am replying on arch-general, but a TU who uses a lot of ruby on Arch. Thanks for thinking about this. I too have been trying to come up with my own sane way of using ruby - gems particularly - with Arch. On Sunday 12 Feb 2012 17:37:17 Thomas Dziedzic wrote: Current layout: /usr/lib/ruby/site_ruby - packages either installed here /usr/lib/ruby/gems/[ruby_base_version] - or here, this directory contains both pacman installed packages and packages installed using the gem tool. Planned layout: /usr/lib/ruby/site_ruby - manually installed files by user go here, packages shouldn't touch this /usr/lib/ruby/gems/[ruby_base_version] - pacman packages built from gems go here /usr/lib/ruby/vendor_ruby - ruby packages installed with pacman which aren't gems go here $HOME/.gem/ruby/[ruby_base_version] - used by the gem command to install packages unmanaged by pacman +1 from me, except that we should probably emphasise that /usr/lib/ruby/site_ruby really is for site-specific stuff. Anything that is generic enough to be able to go in a pacman package (and/or a gem) should do. /etc/gemrc - contains gem: --user-install to install user installed gems with gem to $HOME/.gem/gems I didn't know about --user-install, but I just set GEM_HOME (actually, I use RVM). Can what you want be done by globally setting GEM_HOME to be based off of $HOME? Or is --user-install the preferred way? I did look into $GEM_HOME but I thought this was inadequate since running sudo gem install foo would still install foo to the system-wide gem directory. Having --user-install in /etc/gemrc forces it to install to /root/.gem/gems instead. If the user chooses to install gems using gem, they will have to add the bin directory to the $PATH: export PATH=$PATH:$(ruby -rubygems -e 'puts Gem.user_dir')/bin. Yep, or just something derived from $GEM_HOME if we were to use that approach instead. Benefits of this change include: Using the proper directory layout introduced in ruby 1.9 (using vendor_ruby). Clean separation of pacman installed packages (/usr/lib/ruby/gems/[ruby_base_version] /usr/lib/ruby/vendor_ruby) from gem installed packages ($HOME/.gem/ruby/[ruby_base_version]). Problems left: The user will still be able to install to the system wide gem directory /usr/lib/ruby/gems/[ruby_base_version] if they remove --user-install from /etc/gemrc Possible remedies: 1) Leave it as is. If the user runs gem with --no-user-install then gem will still install the files to the system wide directory at /usr/lib/ruby/gems/[ruby_base_version] and will install binaries to /usr/bin This should provide a clean default and is the easiest path. This option is still better than the one we currently use where we try to install to the system wide location by default. I think it's worth separating out the user and the admin in this argument. To install a gem system-wide, you have to do something like sudo gem install XXX, right? This is almost always a bad idea, IMO, and people hopefully won't do it at least during the normal run of working with ruby. Personally, I don't let gem mess with anything outside my home directory. Using --user-install with sudo will install to /root/.gem :) And plain gem install XXX will not accidentally install system-wide, right? right, putting --user-install into /etc/gemrc will put gem install foo into ~/.gem Ruby is quite good for separating between development and deployment environments - it seems to make sense for us to do a similar thing here, seeing the Arch OS layer itself as a particular kind of deployment, where things are managed by pacman. 2) Change all ruby pacman packages to use local _gemdir='/usr/lib/ruby/vendor_ruby' This would free up /usr/lib/ruby/gems/[ruby_base_version] which we could move to /var/lib/ruby/gems/[ruby_base_version] for system wide gems installed with the gem command. And as much as I have to admit that I'd really like to be able to install gems system-wide and use their built-in dependency management, bundler etc... I think that road probably leads to madness and death, especially when many popular gems will still be managed by pacman (and rightly so). So, I would be careful about doing this, and would suggest that we go for only letting 'gem' install things under $HOME. Anything that should go system-wide should have a PKGBUILD. Right, by default I want it so that you wont be able to install system wide gems with gem. But I can't stop users removing --user-install from the gemrc file and installing to the system-wide directories. I have another plan brewing in regard to letting users separately install pacman installed gems and gem installed gems to the system-wide directory. I wont do it in this cleanup iteration, but next cleanup, I will add a /var/lib/gems or /var/lib/ruby/gems folder specifically
Re: [arch-general] I can't upgrade to pacman4
On Mon, Jan 16, 2012 at 5:05 PM, Karol Blazewicz karol.blazew...@gmail.com wrote: 2012/1/17 朱格宏 zhugehon...@gmail.com: Hi,i found some problem when upgrade to pacman4 i use pacman -Syu and it told me :: package-query: require pacman3.6 but my pacman is 3.5.4-4, how to slove it? Update package-query. You get the error because you're about to install a new version of pacman, probable pacman 4.0.1-4. remove package-query and yaourt, update, install package-query and yaourt.
Re: [arch-general] a plea for python 2
python2 will refer to some version of Python 2.x python3 will refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions above snippet taken from: http://www.python.org/dev/peps/pep-0394/
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault.
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen s.jan...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. The full quote is: More conservative distributions that are less willing to tolerate breakage of third party scripts continue to alias it to python2. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. Also, when do you suppose widely adopted will occur? If you leave space for interpretation, then expect opinions that don't match yours. This is a recommendation and someone is going to have to take the first step eventually. Here is a metaphor in the spirit of the season: Arch is the snowplow that is shoveling the snow to the sides of the road to make it easier for other distros to pass. I see this thread turning into the threads when it was first announced, and I refuse to go down that path, again... Here is the python maintainer's blog post about it: http://allanmcrae.com/2011/03/the-python2-pep/ Cheers!
[arch-general] python2-werkzeug and python2-flask moved to [community].
I decided to pull these brilliant projects into [community]. I have renamed them from python-* to python2-* so please adjust your dependencies accordingly.
[arch-general] Recently orphaned [community] packages, TUs should take a look if they might be interested in adopting them.
Hi, I recently went over all my packages in community, and have decided to orphan the following due to lack of interest and because I haven't used them in a long time celt - Low-latency audio communication codec extrema - Extrema is a powerful visualization and data analysis tool. ghdl - A complete VHDL simulator, using GCC technology. gnofract4d - A fractal browser with PyGTK gui grass - Geographic Information System (GIS) used for geospatial data management and analysis, image processing, graphics/maps production, spatial modeling, and visualization. gtkwave - A wave viewer which reads LXT, LXT2, VZT, GHW and VCD/EVCD files gts - GNU Triangulated Surface Library. luakit - luakit is a highly configurable, micro-browser framework based on the WebKit web content engine and the GTK+ toolkit.Stable release mpdscribble - An mpd client which submits track info to last.fm netbeans - Netbeans IDE development platform. protege - Free, open source ontology editor and knowledge-base framework wordpress - Blog Tool and Publishing Platform All of them are working as far as I know, and they have no outstanding bugs except a couple which are in the list of pushing the .desktop file upstream https://bugs.archlinux.org/task/23387 (already reported) and luakit has an extremely minor upstream bug https://bugs.archlinux.org/task/25761 which is also reported. Cheers!
[arch-general] Clojure 1.3.0 update and removal of clojure-contrib from [community].
Hi Archers, I have just pushed clojure 1.3.0 to [community]. A list of changes can be found at [1]. One major recent change is that upstream has split up the monolithic contrib package into separate sub-projects [2]. This means that clojure-contrib is no longer necessary for clojure 1.3.0 and individual contrib projects should be packaged separately into the AUR. I have removed clojure-contrib from [community] as a result. Have a nice weekend! Clojure 1.3.0 changes [1] - https://github.com/clojure/clojure/blob/1.3.x/changes.txt Where did clojure.contrib go? [2] - http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go
Re: [arch-general] Any suggestions on frequently rebuilding a git package?
On Mon, Sep 19, 2011 at 12:35 AM, Philipp Überbacher hollun...@lavabit.comwrote: Excerpts from XeCycle's message of 2011-09-18 17:33:56 +0200: Hi, I build Emacs from git quite frequently, about twice a month or so. However the PKGBUILD from AUR rebuilds everything each time, which takes too many time I think. Perhaps Emacs is small, but I think there should be a way to prevent too many rebuilds --- is that possible? 1. Don't use -c (clean) 2. Comment line 47 and 48 (PKGBUILD-git.proto), uncomment if you want a clean build. Regards, Philipp I used to do this with a couple of packages and it worked for me. Keep a clone of all git repos under some folder like ~/.vcs and then I put http://pastie.org/2558220 into ~/.vcs/update I then ran the update script before each time I wanted to rebuild the packages. Finally change the _gitroot variable to /home/username/.vcs/projectname and it will automatiically clone it from your hard drive. I usually saved this PKGBUILD for later so that I don't have to change it each time. You could also write a script to autodl the pkgbuild and replace the _gitroot. Hope this helps. Cheers
[arch-general] Mongodb 2.0.0 out for testing in [community-testing]
Hello, I will keep mongodb 2.0.0 in [community-testing] for a day or 2 so that users can test it out. Please report any issues you have. I switched to using the new --shutdown flag in the rc.d script to stop the daemon. I have tested the new mongodb and everything seems to work fine for me, but I want to be cautious and not have a repeat of last time I changed something in mongodb :) Have fun testing! The release notes http://www.mongodb.org/display/DOCS/2.0+Release+Notes The changelog https://jira.mongodb.org/secure/IssueNavigator.jspa?requestId=10140
[arch-general] Removal of jre/jdk and jre6/jdk6 from [community]
Oracle recently decided to remove the DLJ (Operating System Distributor License for Java) from their license on their own proprietary implementation of java [1]. For a good article explaining the situation, please refer to [2]. This means that you will have to use openjdk6 from [community] or get jre/jdk (java 7) and jre6/jdk6 (java 6) from the AUR. My personal opinion is that although openjdk6 is more buggy, I encourage everyone to use it and report bugs against it from now on. This will be better for linux in the long run. I will not be maintaining these packages in the AUR anymore. Oracle's original blog post [1] - http://robilad.livejournal.com/90792.html Article explaining the move [2] - http://sylvestre.ledru.info/blog/sylvestre/2011/08/26/sun_java6_packages_removed_from_debian_u
Re: [arch-general] replacement for clyde
2011/8/19 Cédric Girard girard.ced...@gmail.com: On Fri, Aug 19, 2011 at 12:01 PM, Karol Babioch ka...@babioch.de wrote: I'm using yaourt and am now wondering what is wrong with it, when you actually know of it, and don't want to use it ;)? Is there any flaw so far? At the time of packer first release (January 2010), yaourt was slow and had some awful code in it. yaourt also made the choice to accept arguments where it add no value (like yaourt -R, only delegating to pacman). I haven't tested yaourt since. I was using packer and now have switch to pacaur. Both are fine but I find pacaur handling in a better way dependency resolution on AUR packages. -- Cédric Girard I've used yaourt for a couple of years now. It has always worked for me for the most part, and having a common command for everything is very convenient for me. alias y=yaourt and you have one of the simplest ways to do a complete update of your system, y -Syua I always ignored people's comments because the majority argues that it is either too slow, or the code is ugly. These same people would probably be horrified looking through vim's code :P These points alone do not make a very convincing argument for me, which is why I grew numb to them.
Re: [arch-general] replacement for clyde
2011/8/19 Cédric Girard girard.ced...@gmail.com: On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic gos...@gmail.com wrote: I've used yaourt for a couple of years now. It has always worked for me for the most part, and having a common command for everything is very convenient for me. alias y=yaourt and you have one of the simplest ways to do a complete update of your system, y -Syua I understand this may seems convenient to some. For me it is just useless and just abstract things from the user. Definitely a valid opinion, as abstraction might be convenient or inexpedience to different audiences, which is why there really isn't a right answer. Programming also has this quality. If I want to run pacman -Rs foo, why would I be motivated to do yaourt -Rs foo instead if yaourt only call pacman -Rs foo ? I always ignored people's comments because the majority argues that it is either too slow, or the code is ugly. These same people would probably be horrified looking through vim's code :P These points alone do not make a very convincing argument for me, which is why I grew numb to them. Well you're right, by itself the quality of the code is not an argument for the end-user. But when the lack of quality impacts speed and this can be supported by figures then I'd say it makes things completely different. I agree that your arguments have a valid point of view all the way up to this point where you lost me. For me, lack of quality is in the same category as lack of quality impacts speed For example, lets have the same badly written algorithm compiled with no optimization and the other being compiled with -O999 ZOMG!! It doesn't matter to me if one ruins your system faster, it will still do the same thing. This is why I think the lack of quality impacts speed issue being completely different from lack of quality is invalid. That said, the situation may have evolved since and it may not be relevant anymore to throw these arguments against yaourt. -- Cédric Girard
[arch-general] Java 6 back in [community]
As a result of problems oracle has faced with java 7, it has marked it for developers only: http://java.com/en/download/faq/java7.xml This is why I have decided to bring back java 6 into [community] and it will coexist with java 7 for the time being. jre/jdk - java 7 jre6/jdk6 - java 6 java 6 packages conflict with java 7 packages, so you will not be able to have them both installed at the same time. Note, this is only temporary until Oracle announces yet again, that java 7 is available for general use. I expect this to be at around the time update 1 or 2 comes out for java 7. After they announce this, java 6 is going back into the aur. Happy hacking!
[arch-general] Moving qgis from [community] into the AUR.
QWT was bumped to 6.0 and qgis is currently incompatible with the new version. In order to update qwt, we will have to drop qgis into the aur. I have looked into patching qgis to be compatible with qwt 6. I managed to get an initial patch accepted, but there is a lot more work to be done, on code that I'm unfamiliar with. upstream bug report: http://hub.qgis.org/issues/3562 -Thomas Dziedzic
[arch-general] bpython/bpython2 in community-testing
I've renamed the current community/bpython to community-testing/bpython2. bpython is now the python3 version in community-testing. The reason for the wait is because of a crash that should be fixed in python 3.2.1: https://bugs.archlinux.org/task/23536 Please test and thanks for your time!
Re: [arch-general] gnome2.32
On Thu, Jul 7, 2011 at 8:40 PM, sergio lenzi lenzi.ser...@gmail.com wrote: On Thu, Jul 7, 2011 at 10:11 PM, C Anthony Risinger anth...@xtfx.me wrote: On Thu, Jul 7, 2011 at 5:38 PM, Vic Demuzere v...@demuzere.be wrote: On Jul 7, 2011 10:26 PM, Ionut Biru ib...@archlinux.org wrote: everything you said above is plain wrong. EVERYTHING go read the wiki or use gnome manuals 1) you can set up nautilus to manage your desktop (use gnome-tweak-tool if you are not skilled enough) 2) alt+right click doh, is specified all over the internet at this point, not only in the manual 3) see 1 and system settings-keyboard-shortcuts Can you please spare us and start discovering? Is not that hard to open a manual or search on google That's what I thought, but I have never used fallback mode so I don't know how usable it is. I do know some non-geek end users who actually like gnome 3 shell, though. I think it's a better idea to spend your time on improving fallback mode in gnome 3, than spending it on maintaining outdated software. I know you are right... I must have to find a way to present a transition if ever, between gnome2 and gnome 3. My users needs an update perhaps once a year.. Meanwhile I will install again gnome3 in the test computer nvidia chipset, amd 2 cores. So I expect theat by JUN 2012, gonome3 have become more stable, and then I will start to send new notebooks with gnome3 interface... C Anthony 8-| did I just read that you're shipping snapshots of archlinux to users and plan on updating them next year??? archlinux may not be the distro for you...
[arch-general] Important changes for mongodb 1.8.2-2
In response to the following bug report https://bugs.archlinux.org/task/24983 I have applied the attached fix to mongodb and as a result there have been some backwards incompatible changes. dbpath has been changed to /var/lib/mongodb logpath has been changed to /var/log/mongodb/mongod.log There have been other minor fixes, please check out the bug report for full details.
Re: [arch-general] Java 7 is now in [community-testing] and needs testing.
On Wed, Jun 29, 2011 at 2:45 AM, KESHAV P.R. skodab...@gmail.com wrote: On Wed, Jun 29, 2011 at 07:47, Thomas Dziedzic gos...@gmail.com wrote: On Tue, Jun 28, 2011 at 9:04 PM, Jan Steffens jan.steff...@gmail.com wrote: On Tue, Jun 28, 2011 at 11:41 PM, Thomas Dziedzic gos...@gmail.com wrote: The only program that doesn't work with Java 7 afaik is minecraft, the specific problem can be tracked here: http://getsatisfaction.com/mojang/topics/minecraft_doesnt_work_with_java_7 Hopefully we can have enough users complaining that the devs will take notice. Replacing the 32-bit libraries with their 64-bit copies, and running minecraft with LD_LIBRARY_PATH=/opt/java/jre/lib/amd64 makes it work properly here. Awesome! I'm now fully on java 7 :) I would like to hear about anyone else's experience also which will give me some more feedback. Cheers! Sorry if this has been mentioned before, but is this about the binary jre/jdk releases or the open source openjdk. I currently have openjdk6 (and icedtea-web) installed in my system (x86_64) but did not find an equivalent package for Java 7. Thanks in advance. Regards. Keshav These are the binary jre/jdk releases.
Re: [arch-general] Java 7 is now in [community-testing] and needs testing.
On Wed, Jun 29, 2011 at 10:04 AM, Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: On Wed, Jun 29, 2011 at 10:38 AM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Jun 29, 2011 at 2:45 AM, KESHAV P.R. skodab...@gmail.com wrote: On Wed, Jun 29, 2011 at 07:47, Thomas Dziedzic gos...@gmail.com wrote: Sorry if this has been mentioned before, but is this about the binary jre/jdk releases or the open source openjdk. I currently have openjdk6 (and icedtea-web) installed in my system (x86_64) but did not find an equivalent package for Java 7. Thanks in advance. ... These are the binary jre/jdk releases. But the reference implementation from Oracle will be based on OpenJDK http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto Linux user #524555 --- have you read the comments on that page? http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the#comment-1307902502754 I couldn't find a great link that explains it, but the main diffs are that jre/jdk provide proprietary extensions and provide better a better runtime experience. Note that reference implementation only means that it is a correct implementation of a specification and does not mean anything else.
[arch-general] Java 7 is now in [community-testing] and needs testing.
Hi, Java 7 is getting released on July 28th so I thought it would be a good time to let users test it out. I have just pushed jre/jdk 7 build 147 into [community-testing] so that users can have a month in advance to report bugs, and notify upstream projects if they are incompatible with java 7. You should be able to install jre/jdk 7 without the need to enable any of the testing repos. I have tested it on my computer with a couple of browser games which seem to work fine. The only program that doesn't work with Java 7 afaik is minecraft, the specific problem can be tracked here: http://getsatisfaction.com/mojang/topics/minecraft_doesnt_work_with_java_7 Hopefully we can have enough users complaining that the devs will take notice. A summary of the changes that come with Java 7: http://openjdk.java.net/projects/jdk7/features/ Bugs that are not packaging bugs should be submitted to http://bugreport.sun.com/bugreport/ The Java 7 feedback forum is located at http://www.java.net/forums/jdk/java-se-snapshots-project-feedback?force=259 Cheers!
Re: [arch-general] Java 7 is now in [community-testing] and needs testing.
On Tue, Jun 28, 2011 at 9:04 PM, Jan Steffens jan.steff...@gmail.comwrote: On Tue, Jun 28, 2011 at 11:41 PM, Thomas Dziedzic gos...@gmail.com wrote: The only program that doesn't work with Java 7 afaik is minecraft, the specific problem can be tracked here: http://getsatisfaction.com/mojang/topics/minecraft_doesnt_work_with_java_7 Hopefully we can have enough users complaining that the devs will take notice. Replacing the 32-bit libraries with their 64-bit copies, and running minecraft with LD_LIBRARY_PATH=/opt/java/jre/lib/amd64 makes it work properly here. Awesome! I'm now fully on java 7 :) I would like to hear about anyone else's experience also which will give me some more feedback. Cheers!
Re: [arch-general] Reboot - Versioned Kernel Installs
On Fri, Jun 10, 2011 at 8:29 AM, Vic Demuzere v...@demuzere.be wrote: On 10 June 2011 15:25, Paul Gideon Dann pdgid...@gmail.com wrote: Also, I wonder what happens if power is lost whilst pacman is installing a new kernel? I haven't tried this, but it wouldn't surprise me if the system ended up with a truncated kernel that wouldn't boot. That's a bug right there, although it's a pretty tiny corner case, granted :) Paul Is that the case? The kernel should be replaced only after the new one is ready, else it would fail if you pushed CTRL+C while updating the kernel as well. Vic paul, please check out https://bugs.archlinux.org/task/8585 for the power issue I really don't see how implementing this feature would give any more benefits to say installing an -lts kernel or some other kernel you know just works. On the other hand, I do see versioned kernels increasing the complexity of the system.
Re: [arch-general] Bachelor thesis
2011/6/9 Marek Otahal markota...@gmail.com: On Thursday 09 of June 2011 10:34:45 Luštický Josef wrote: Hello everyone, I'm Josef Lusticky and I'd like to write a Bachelor thesis about operating systems. I'm student of Faculty of Information Technology in Brno, Czech Republic and I have been using Linux since 2006 and Archlinux since 2008. I'm enthuasistic user of Arch and Linux in general and I'd like to help this project by improving or creating some stuff. I'd like to implement some driver or port of app. I know C, assembly and some scripting languages. Yes, I know there is the pacman package signing feature missing, but I do not consider it work for one person and I would rather work on something like userspace tools needed for kernel (e.g. filesystem tools, etc.). Can you recommand me something good for my skills? Best regards, Josef Lusticky Ahoj Pepo :) I just remembered your email from yesterday when I was crying about the fortune of kmobiletools. It is/was a great tool, but the development has ceased. Please see my wish: https://bugs.kde.org/show_bug.cgi?id=270266 and consider if you would like to work on that project? :) It's developed in C(++?), can touch driver issues (if you want), and definitely is highly popular and has good promises for the future. The old hackers are still around, so they should be able to help you with some details if you needed. It just crossed my mind so I gave it a try and pass the idea to you. Have a nice day, cau, Marek -- Marek Otahal :o) I've heard btrfs is still missing a proper fsck
Re: [arch-general] AUR deletion request
On Sat, May 14, 2011 at 10:54 AM, |^ `/ () () | ( (-) | ryooichi+a...@gmail.com wrote: Thomas, if you simply surf to http://is.gd/Tn8wBO,and omit the last four packages (because they do not begin with archtrack), you will have your list with links. Evangelos, the reason for the deletion is that I'm refactoring my approach and these packages are no longer needed. They really just psuedo-packages anyway. Btw, why is it that package maintainers can't just delete their own packages? deleted
Re: [arch-general] AUR deletion request
On Thu, May 12, 2011 at 9:12 PM, |^ `/ () () | ( (-) | ryooichi+a...@gmail.com wrote: Can a TU for the AUR please delete all packages owned by ryooichi (myself) that begin with archtrack? Thank you! Can you please post links to all the packages you want deleted?
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 8, 2011 at 12:19 PM, Grigorios Bouzakis grb...@xsmail.com wrote: Hello, can anyone think of a reason the rc.d scripts are added to kdm, gdm and slim? They are not recommended by anyone they are to be blame for occasional weird problems. The standard and IMO only way is to start them from inittab. They dont come from upstream i dont know when they were added, i remember them being there ever since i started using Arch, they may come from CRUX or something. I am considering requesting them removal from all display managers. In [0] Pierre said some people want to keep them for backwards compatibility. Backwards compatibility is desired only when something works correctly. Thoughts? [0]: https://bugs.archlinux.org/task/20109 -- () against html e-mail | usenet email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html I agree with you and you bring up a valid point. We should be using only one system if the other one doesn't provide any useful benefits. Also, what is meant by backwards compatible backwards compatible with what?
Re: [arch-general] Gnome3 and Gnome2
On Sun, Apr 10, 2011 at 6:47 AM, Tom uebersh...@googlemail.com wrote: So, now that Gnome 3 has been released, and after reading the announcement that it will 'by default' replace gnome2 in the near future, I'd like to ask if there are any plans on 'keeping' gnome2 around for use with arch linux. I ask this, because I've been using gnome3 from the unstable repository, and know, that a lot of people are not going to like the change, especially because so called 'fall-back-mode' is just a joke, and gnome-shell, at least to me is plain broken. I'm merely voicing my opinion here, no flames :-P But to have a choice would be great! Tom Hi Tom, AFAIK there are no plans to officially support gnome2. People have complained about this in the recent past, but these complaints are useless because arch keeps up with upstream, no matter if people like the change or not. These people should have already known that this is part of arch's philosophy. That said, you, or anyone else who wants gnome2 can step up and maintain a custom gnome2 repository for everyone. Sincerely, Tom2 :)
Re: [arch-general] Python 3.2mu breaks pycairo ?
On Tue, Mar 22, 2011 at 7:24 PM, Fons Adriaensen f...@linuxaudio.org wrote: Hello all, A full system update yesterday replaced Python 3.1 by 3.2mu (what does the 'mu' mean BTW) and this seems to break pycairo: Traceback (most recent call last): File ./mkmeter.py, line 3, in module from cairo import * File /usr/lib/python3.2/site-packages/cairo/__init__.py, line 18, in module from ._cairo import * ImportError: /usr/lib/python3.2/site-packages/cairo/_cairo.cpython-32mu.so: undefined symbol: PyCObject_FromVoidPtr And indeed PyCObject_FromVoidPtr() and its inverse, PyCObject_AsVoidPtr() are no longer available in Python 3.2. They can be replaced by P = PyCObject_FromVoidPtr(X, destroy) -- P = PyCapsule_New(X, 0, destroy) X = PyCObject_AsVoidPtr(P) -- X = PyCapsule_GetPointer(P, 0) and the 'destroy' function now takes a PyObject* instead of PyCObject*, so you have to use PyCapsule_GetPointer() inside it to get the C/C++ pointer. Ciao, -- FA Please report a bug report at bugs.archlinux.org
Re: [arch-general] Introducing Salt
On Sat, Mar 19, 2011 at 5:29 PM, Thomas S Hatch thatc...@gmail.com wrote: If you are familiar with a project spearheaded by Red Hat called Func, Salt is very similar. On Thursday I released my first release of the Salt remote execution manager, Salt is a tool to allow an admin to execute remote commands on sets of systems over the network in an extremely fast and efficient way. I have a blog post explaining it in better detail here: http://red45.wordpress.com/2011/03/19/salt-0-6-0-released/ Packages are in the AUR! - https://aur.archlinux.org/packages.php?ID=47512 Tell me what you think! It is of course open source, Apache licence, and I am open to collaboration! -Thomas S Hatch Hi Thomas, I have seen a great deal of effort on your part in this project. I congratulate you on your initial release, and best of luck (not that you need it)! Useful link to source: https://github.com/thatch45/salt
[arch-general] MongoDB 1.8 released to [community]
Overall a pretty big release with lots of new goodies. Release notes: http://blog.mongodb.org/post/3903149313/mongodb-1-8-released Tested and it works for me, so I pushed it immediately. Please file any bugs you might encounter. Cheers!
Re: [arch-general] Dropping Oracle OpenOffice
2011/3/7 Ng Oon-Ee ngoo...@gmail.com: On Mon, 2011-03-07 at 22:00 -0600, Thomas Dziedzic wrote: just an fyi, openoffice itself is *huge* and now that it is going to be dropped to the aur, it will most likely lose all audience because of how long it takes to compile from source. + libreoffice is just a better version of openoffice imo, so there should really be no one that uses it. People who want openoffice will probably just use the -bin packages? You got it, unless someone is dedicated :P
Re: [arch-general] Dropping Oracle OpenOffice
On Wed, Mar 9, 2011 at 1:01 AM, Jude DaShiell jdash...@shellworld.net wrote: For such a transition, I think it will be helpful for everybody using arch-linux to name aall libri-openoffice packages libri-openoffice-supported and all oracle-openoffice packages oracle-openoffice-unsupported. Debian at any rate has a playground area where unsupported packages go within its repositories as well. That might get the message across to even windows users. Certainly if I do a new installation of arch-linux I'd want libri-openoffice-supported on my system as opposed to anything else.On Tue, 8 Mar 2011, Ng Oon-Ee wrote: On Mon, 2011-03-07 at 22:00 -0600, Thomas Dziedzic wrote: just an fyi, openoffice itself is *huge* and now that it is going to be dropped to the aur, it will most likely lose all audience because of how long it takes to compile from source. + libreoffice is just a better version of openoffice imo, so there should really be no one that uses it. People who want openoffice will probably just use the -bin packages? I think naming the libreoffice packages libre-openoffice packages is just misleading. People should learn the new name.
Re: [arch-general] Dropping Oracle OpenOffice
On Mon, Mar 7, 2011 at 12:13 PM, Squall Lionheart
headmastersqu...@gmail.com wrote:
On Mon, Mar 7, 2011 at 10:45 AM, Andreas Radke a.ra...@arcor.de wrote:
LibreOffice has recently proved to be a solid replacement for Oracle
OpenOffice. I'm about to drop all Oracle OOo packages from our repos.
First my time is limited. I've asked so many times for help in the
Office packaging area and nobody stepped in.
Then there's the poor distribution support Oracle spends on the
distributions. They almost do not care about custom distribution builds
and their interest. They break the build against system libs
every now and then and it takes ages to contact the relevant devs to
fix their bugs. Development is only driven by the profit interests of
Oracle... You can put in here all the arguments the Document foundation
has given at its birth.
So don't expect any efforts to fix bugs in Oracle packages anymore. As
soon as they will break due to a .so name bump or something like this
I'll remove all the packages from our repos if nobody else is willing
to maintain them.
Any objections to add
replaces=('openoffice-base') to the next LibO pkg?
-Andy
I am an OpenOffice user and as long as LibreOffice will provide the same (or
similar) experience, I'm game for the change. Not a big Oracle fan and if I
can avoid their software on my computer, it would be preferred.
+1
I've been following LO development for a couple weeks now and it is
really impressive.
There is a *ton* of legacy code and stupid things getting removed
because of how conservative openoffice development was.
Re: [arch-general] Dropping Oracle OpenOffice
On Mon, Mar 7, 2011 at 5:19 PM, Sven-Hendrik Haase s...@lutzhaase.com wrote:
On 07.03.2011 18:45, Andreas Radke wrote:
LibreOffice has recently proved to be a solid replacement for Oracle
OpenOffice. I'm about to drop all Oracle OOo packages from our repos.
First my time is limited. I've asked so many times for help in the
Office packaging area and nobody stepped in.
Then there's the poor distribution support Oracle spends on the
distributions. They almost do not care about custom distribution builds
and their interest. They break the build against system libs
every now and then and it takes ages to contact the relevant devs to
fix their bugs. Development is only driven by the profit interests of
Oracle... You can put in here all the arguments the Document foundation
has given at its birth.
So don't expect any efforts to fix bugs in Oracle packages anymore. As
soon as they will break due to a .so name bump or something like this
I'll remove all the packages from our repos if nobody else is willing
to maintain them.
Any objections to add
replaces=('openoffice-base') to the next LibO pkg?
-Andy
+1
Solid and pragmatic suggestion.
just an fyi,
openoffice itself is *huge* and now that it is going to be dropped to
the aur, it will most likely lose all audience because of how long it
takes to compile from source. + libreoffice is just a better version
of openoffice imo, so there should really be no one that uses it.
Re: [arch-general] [arch-dev-public] GHC 7.0.2 and Haskell packages in [testing] and [community-testing]
On Sat, Mar 5, 2011 at 2:26 AM, Rémy Oudompheng remyoudomph...@gmail.com wrote: Hello, GHC has been updated to 7.0.2 in the [testing] and [community-testing] repositories. As with all GHC upgrades, you may have to cleanup globally registered packages if they did not upgrade properly, as well as your local Haskell packages. The usual parts of Haskell Platform (everything except OpenGL) are also in [testing]. Haskell Platform has been updated to version 2011.2. Regards, Rémy. Excellent! I upgraded haskell, recompiled and now xmobar works (it didn't work a couple of months ago in [staging]). Great job! Cheers!
Re: [arch-general] Gaussum package is not updated - can any administrator leave it orphan?
On Sat, Mar 5, 2011 at 10:14 AM, Hector Martinez-Seara hse...@gmail.com wrote: Hi all, the Gaussum package has not been updated for a long time. Now in its current state is not usable. I sent a email to the maintainer to try to address the situation or at least free the package. I didn't get any answer: ### Archlinux package gausssum is out of date Hector Martinez-Seara to fmying show details 28 Feb (5 days ago) Dear fmying, the package gausssum in archlinux AUR has been out of date for a long time. Please proceed to its update. In the case you can't or you are not interested please proceed to disown the package it so I can update it. You can do that from the archlinux.org webpage in AUR section. once you have logging. If you cannot disown the package please let me know and I will send an email to the administrator so they can do it. Hector # Can any administrator leave this package orphan so I can became its maintainer and update it. Hector There is no such package, please post a link.
Re: [arch-general] Gaussum package is not updated - can any administrator leave it orphan?
On Sat, Mar 5, 2011 at 10:41 AM, Stefan Husmann stefan-husm...@t-online.de wrote: Am 05.03.2011 17:35, schrieb Hector Martinez-Seara: sorry I forgot an s in the name is gausssum ( three s) https://aur.archlinux.org/packages.php?ID=24842 On 5 March 2011 18:31, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Mar 5, 2011 at 10:14 AM, Hector Martinez-Seara hse...@gmail.com wrote: Hi all, the Gaussum package has not been updated for a long time. Now in its current state is not usable. I sent a email to the maintainer to try to address the situation or at least free the package. I didn't get any answer: ### Archlinux package gausssum is out of date Hector Martinez-Seara to fmying show details 28 Feb (5 days ago) Dear fmying, the package gausssum in archlinux AUR has been out of date for a long time. Please proceed to its update. In the case you can't or you are not interested please proceed to disown the package it so I can update it. You can do that from the archlinux.org webpage in AUR section. once you have logging. If you cannot disown the package please let me know and I will send an email to the administrator so they can do it. Hector # Can any administrator leave this package orphan so I can became its maintainer and update it. Hector There is no such package, please post a link. Hello, someone, maybe Thomas, already orphaned the package. Next time please send such requests for AUR-packages to aur-general. Regards Stefan I also just noticed this, I didn't orphan it
[arch-general] [boost/boost-libs] PKGBUILD update for 1.46.0 + many improvements
Hey, this is mainly targeted at the maintainers of boost/boost-libs, but others are free to check it out, I have reworked the PKGBUILD for boost/boost-libs and I have managed to update the beast to 1.46.0 I have a full file [1] and a diff [2] against the previous version (1.45.0). I have also built the PKGBUILD for both i686 and x86_64 in clean chroots and provided the results [3]. Notable changes include: * bump version to 1.46.0 * enable icu support in regex * fix FS#22370 - [boost] does not include MPI [4] * fix FS#22471 - [boost-libs] no libboost_thread.so [5] * minor PKGBUILD cleanups Disabling single thread building and just building the multithreaded libs cut the number of files in boost-libs by about a half :) I was also told by upstream there isn't a need for enabling single threaded support. The only boost bug open is FS#22178 - [boost/boost-libs] Support for Python 3 [6] and I tried enabling support, but got errors, so it will just have to wait. Upstream doubts they support the latest python3.2, which I was told in irc. [1] - http://pkgbuild.com/~td123/boost/PKGBUILD [2] - http://pkgbuild.com/~td123/boost/PKGBUILD.diff [3] - http://pkgbuild.com/~td123/boost/ [4] - https://bugs.archlinux.org/task/22370 [5] - https://bugs.archlinux.org/task/22471 Cheers!
Re: [arch-general] wiki page for Building Trinity on Arch - You want it here or on the trinity site?
On Sun, Jan 30, 2011 at 1:00 AM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 01/29/2011 12:09 AM, Thomas S Hatch wrote: 2011/1/28 David C. Rankin drankina...@suddenlinkmail.com On 01/28/2011 11:30 PM, Ng Oon-Ee wrote: So what say the powers that be? Do the wiki page here or at Trinity? The wiki is for Arch-related documentation, so why not? Yes! wiki it up! kde3 is only dead as long as noone maintains it. That's how Arch works, after all. So yes, I think putting Trinity on the wiki is fine, and it should/will only get nixed if it stops getting maintained. Thanks Peter, Ray, Thomas and Ng, I'll get the framework done this weekend. It is a double bonus doing it here, Trinity uses FosWiki and it is miserable compared to mediawiki :) -- David C. Rankin, J.D.,P.E. Thanks David, I am excited to see it! -Thomas S Hatch Guys, I have gotten the outline for the Trinity page completed and have made good headway getting the contents up. I still have information to add, but my fingers wore out. I get the remaining info up in the next day or so. The page is: https://wiki.archlinux.org/index.php/Trinity I still need to know what to do with the PKGBUILDs I have so far. I don't know if I should upload them as part of the wiki, or just provide links to them on another site. I'll create the links once I know where you guys want me to put them. I can just leave them on my server (it's no size or bandwidth issue) If you have thoughts or ideas for solving some of the problems mentioned in the wiki, let me know. I'm shallow on experience with PKGBUILDs, but learning fast. That's it for now. The best place for any PKGBUILD is really in the AUR and maybe under a seperate source control, but that's not really required.
Re: [arch-general] Question about automated builder
On Thu, Jan 27, 2011 at 1:12 PM, Thomas S Hatch thatc...@gmail.com wrote: On Thu, Jan 27, 2011 at 12:01 PM, C Anthony Risinger anth...@extof.mewrote: On Thu, Jan 27, 2011 at 12:37 PM, Thomas S Hatch thatc...@gmail.com wrote: On Thu, Jan 27, 2011 at 11:24 AM, Ray Rashif sc...@archlinux.org wrote: On 28 January 2011 01:36, Thomas S Hatch thatc...@gmail.com wrote: I have been passively working on a similar project called quarters, but I must admit that my motivation is somewhat low not knowing if the project is in demand. So here is my question, do we think that something like this would be a benefit to Arch? Is this the type of project that should merit my attention? You have my personal full support. Does this Koji allow people to upload their own .spec/.src packages and offer them a build? I'm thinking something like that for quarters would be good. We can separate the building into 3 categories: == Distribution == This is where devs and TUs connect. If you can work out some kind of integration, it will be totally seamless. Subversion hooks can trigger the builds, which then are placed in the respective home folders in gerolde/sigurd. They can be auto uploaded with dbscripts as well but I don't know if that's a good idea, mainly because there needs to be inspection (namcap and other habits) before the binary gets served across the mirrors. == Projects == Any third-party packaging initiative can hook up to the system, and in turn get their binaries cooked. No-one is responsible for bad packages. == Community == Users submit a PKGBUILD and in turn can download a Pacman package. No-one is responsible for bad packages. HAHA! I had not thought of that! I love it! The build system can build user packages from uploaded PKGBUILDS, I would need to add some extra security on the chroots (or build them in super thin virtual machines), but that would be great, users could verify that their packages were top notch before submitting them to the AUR and TUs could check packages much more easily. As for the svn hooks, I was actually looking at polling the scms, this way an scm can be completely detached from the builder and the builder can just arbitrarily build from any old scm. I think that the solution here is to configure the scms with specific criteria, so that they build into specific repos. And thanks for your support Ray, it means a lot :) did somebody say distributed AUR? add a little P2P sharing of the PKG bits into localized repositories and you got yourself a winner. C Anthony Honestly, a build system could check AUR packages for cleanliness and make a binary repo of working clan packages? We have been discussing this in the TU chat, and there is a lot of excitement about it, I am going to post some degign docs on the wiki here in a few days (give me some time to put it together :) ) and then we can have a free for all on how we want this to work. In the meantime, keep throwing ideas at me so I can work them into the design! Thanks again for the feedback! -Thomas S Hatch Hey, as I said in the irc, I also have given my full support for this. I am willing to work on this also. I see a lot of potential especially in the aur portion of this system. Mainly because it would guarantee that pkgs in the aur are correct in the sense that they have correct dependencies, makedependencies and proper variables (no $startdir) and that then can be built in a clean chroot. Also, just to reiterate what I've said to Thomas Hatch, I have implemented an aur clean chroot build system that works recursively: https://bbs.archlinux.org/viewtopic.php?id=111366
Re: [arch-general] Question about automated builder
On Thu, Jan 27, 2011 at 2:06 PM, Thomas S Hatch thatc...@gmail.com wrote: On Thu, Jan 27, 2011 at 12:57 PM, C Anthony Risinger anth...@extof.mewrote: On Thu, Jan 27, 2011 at 1:48 PM, Thomas S Hatch thatc...@gmail.com wrote: Awesome, I actually have a few servers I will use, and since it will be distributed, we will be able to use a lot of servers as builders all reporting to a single master. why all the distributed goodness, then a crippling single master? it would not be much more difficult to use 1-to-1 queues-to-server. nodes that fill up return a redirect, or denial. a simple DNS scheme can facilitate auto-discovery... nodes register for an ID under the domain, any simply move down the list. TXT records can provide the lists of root nodes if you really want. with more work, this can be made to work through NAT, a la p2-esque, but that's more ambitious. As for the web end, I was thinking of having the web frontend just act as a notification area about the queue and the builds, so people could check on build stats and download experimental pkgs etc. Then the queue would be managed via the scms. no way man, go big or go home! web interface is full out AUR replacement. C Anthony Hmm, a pure peer setup? My thought on the master has more to do with central job control, and the fact that distributing can be easily done, the master is a lightwieght server compared tot he builders, and the master will just present what needs to be build and pull whats built into repos, this way the master can scale out to a ton of builders and all of the decisions about who builds is done by the builders talking to each other. Of course we could have separate master dedicated to specific repos and configurations but share the builder pool, so that we have a simple many to many relationship. I prefer the central server idea rather then a purely distributed system simply because we can't distribute workload well with a purely distributed one. Imagine serving openoffice and libreoffice to one server and some python module to another server. At least with the central server, we have more control over this.
Re: [arch-general] [AUR] Please, orphan the xdg-user-dirs-gtk
On Wed, Jan 26, 2011 at 2:28 PM, Robson Roberto Souza Peixoto robsonpeix...@gmail.com wrote: Please, orphan the package - xdg-user-dirs-gtk http://aur.archlinux.org/packages.php?ID=14273 done thanks fyi, next time post a reason. Just say the guy is inactive, as I have seen by your comments on that package.
Re: [arch-general] Rail Model font for coders
On Sun, Jan 23, 2011 at 12:25 PM, Yaro Kasear y...@marupa.net wrote: On Sunday, January 23, 2011 12:20:17 pm Nathan Wayde wrote: On 23/01/11 18:13, hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_h are_h...@lavabit.com wrote: .you're a troll and a spammer. Get the hell off my mailing list. Meeku: This attitude does not do the reputation of your o/s any good. If you don't want to use the font fine. just so you know, your silly overly long email address alone qualifies you for spamming and the first mail sent by your was immediately flagged as such. It also doesn't help that your messages appear somewhat like it was written by a spammer and the you proceed to argue about it as-if your original mail was relevant to this ML. I googled his e-mail. Seems he spammed the debian-user list, too. At least he is courteous enough not to top post.
Re: [arch-general] When will Arch switch to Systemd
On Wed, Jan 19, 2011 at 5:06 PM, Laurent Carlier lordhea...@gmail.com wrote: Le mercredi 19 janvier 2011 16:02:52, C Anthony Risinger a écrit : On Wed, Jan 19, 2011 at 3:59 PM, C Anthony Risinger anth...@extof.me wrote: Any ideas when will Arch switch to systemd based booting system ? oh, and the last couple pages in the forum sound promising in regards to arch specific unit files, though i'd have to look closer as i haven't had a chance to try systemd myself for some time. any comments from someone out there currently using systemd and the arch unit files from AUR? C Anthony Let me resume: Currently there is no plan and no date. ++ I'm not convinced systemd is better than the current initscripts in its current state. I've seen problems from people using systemd in the forums and in other sources. You should work on improving systemd on arch and getting everything documented if you really do like it.
Re: [arch-general] a python rewrite of pkgfile
On Sun, Jan 16, 2011 at 9:54 AM, solsTiCe d'Hiver solstice.dhi...@gmail.com wrote: hi. I started in August a rewrite in python of pkgfile from pkgtools package. The idea was to speed it up and avoid the use of a tree of file and use a sqlite3 db instead. I wrote it quickly and proposed a merge (on github) to Daenyth. He seems to respond well, reviewing the code. But then nothing, except that I vaguely begin to hear about a C python module that read *.files.tar.gz directly. I had to guess that my solution of using an sqlite3 db was not appreciated. I have to admit the intermediate step needed to convert *.files.tar.gz files into sqlite3 db was not that good. By accident, on IRC, I learned that it was brain0 that wrote the module and picked it up on its git repo. I modifed my python code, and made addition to the C module. Later, I also added to the module the possibility to extract full info of a package from desc and depend files in *.db.tar.gz to finalize the rewrite. So it's finished for quite some time now. Daenyth says he appreciated the hard work but I see no progress on merging or releasing something so far. The benefit of the rewrite: - super faster speed (thanks to brain0 C module) - download database files from mirror only if updates are available (for http mirrors only) - as a bonus you got a python module written in C that can read packages info in *.files.tar.gz or *.db.tar.gz it's on github https://github.com/solsticedhiver/pkgtools/tree/plan-A a PKGBUILD to build a package of pkgtools with the new pkgfile http://paste.pocoo.org/show/321584/ Maybe you could provide the PKGBUILD in the AUR?
Re: [arch-general] Pkgtools v22
On Sun, Jan 16, 2011 at 12:29 PM, Daenyth Blank daenyth+a...@gmail.com wrote: Hi All, I'm happy to announce that after a far-too-long wait, the latest version of pkgtools is released! This version is a complete rewrite from the ground up. The slow parts have been rewritten in C for a huge speed increase, and the body has been rewritten in python. Many thanks for brain0 and solstice for doing most of the hard work in making this release happen. It should be hitting the mirrors today, and pkgtools-git from AUR is ready if you just can't wait. Enjoy! Great job!
Re: [arch-general] Vuze doesn't work after update
On Sat, Jan 15, 2011 at 9:47 AM, Madhurya Kakati mkakati2...@gmail.com wrote: HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED. This is a known issue: https://bugs.archlinux.org/task/22432 FS#22432 - [vuze] 4.6 fails to start on x86_64 What's interesting is that I can't find a 64bit version of vuze anymore like there was with the older version. and what's more interesting is that I downloaded the file on a 64bit computer and still got the 32bit version. Is this an upstream problem?
Re: [arch-general] Vuze doesn't work after update
On Sat, Jan 15, 2011 at 10:02 AM, Thomas Dziedzic gos...@gmail.com wrote: On Sat, Jan 15, 2011 at 9:47 AM, Madhurya Kakati mkakati2...@gmail.com wrote: HI, I just updated Vuze bittorrent client to its latest version and now it doesn't run. I am using 64 bit arch and openjdk6. The output when I run vuze on the terminal is: $ vuze Starting Azureus... Suitable java version found [java = 1.6.0_20] Configuring environment... Java exec found in PATH. Verifying... Browser check failed with: Cannot load 32-bit SWT libraries on 64-bit JVM Auto-scanning for GRE/XULRunner. You can skip this by appending the GRE path to LD_LIBRARY_PATH and setting MOZILLA_FIVE_HOME. checking /usr/lib/xulrunner-devel-1.9.2 for GRE Can not use GRE from /usr/lib/xulrunner-devel-1.9.2 because it's missing libxpcom.so. checking /usr/lib/xulrunner-1.9.2 for GRE GRE found at /usr/lib/xulrunner-1.9.2. Browser check failed with: Could not initialize class org.eclipse.swt.widgets.Display Can't create browser. Will try to set LD_LIBRARY_PATH and hope Vuze has better luck. setting LD_LIBRARY_PATH to: /usr/lib/xulrunner-1.9.2 setting MOZILLA_FIVE_HOME to: /usr/lib/xulrunner-1.9.2 Loading Azureus: java -Xmx128m -cp ./Azureus2.jar:./swt.jar -Djava.library.path=/usr/share/vuze -Dazureus.install.path=/usr/share/vuze -Dazureus.script=/usr/bin/vuze -Dazureus.script.version=2 org.gudy.azureus2.ui.swt.Main file:/usr/share/vuze/Azureus2.jar ; file:/usr/share/vuze/swt.jar ; file:/usr/share/vuze/ changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at org.gudy.azureus2.ui.swt.Main.init(Main.java:114) at org.gudy.azureus2.ui.swt.Main.main(Main.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.aelitis.azureus.launcher.MainExecutor$1.run(MainExecutor.java:37) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:197) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:174) at org.eclipse.swt.internal.C.clinit(C.java:21) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.clinit(Display.java:132) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:84) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:63) at com.aelitis.azureus.ui.swt.Initializer.init(Initializer.java:163) ... 12 more Exit from Azureus complete No shutdown tasks to do Azureus TERMINATED. This is a known issue: https://bugs.archlinux.org/task/22432 FS#22432 - [vuze] 4.6 fails to start on x86_64 What's interesting is that I can't find a 64bit version of vuze anymore like there was with the older version. and what's more interesting is that I downloaded the file on a 64bit computer and still got the 32bit version. Is this an upstream problem? BTW, I would like to continue this discussion on the bug webpage, not on the ml please. thanks.
[arch-general] sage-mathematics 4.6.1 in [community-testing]
This message is targeted for sage-mathematics users. If you have a chance, please try sage-mathematics in [community-testing]. This is a new release with a few failed automated unit tests, but a few are usually expected. Please let me know if you have any troubles when using the new version. Otherwise I will move it to [community] this afternoon. Cheers!
Re: [arch-general] We want to help
On Thu, Dec 16, 2010 at 9:33 AM, C Anthony Risinger anth...@extof.me wrote:
On Thu, Dec 16, 2010 at 1:09 AM, Alexander Duscheleit
ji...@archlinux.us wrote:
On Tue, 14 Dec 2010 12:12:46 -0600
C Anthony Risinger anth...@extof.me wrote:
On Tue, Dec 14, 2010 at 7:14 AM, Allan McRae al...@archlinux.org
wrote:
* git://ius.student.utwente.nl/aur2 -- Thralas's repository
* git://git.berlios.de/aur2 -- Djszapi's repository
* git://github.com/SpeedVin/aur2.git -- SpeedVin's AUR2 forked
repo with some patches and translation's.
I'll add AUR3 to the mix... -
https://bbs.archlinux.org/viewtopic.php?id=99839
i haven't made any release or update to BBS (or README :-) in some
time, but a fair amount of work + thought has gone into this. if
you'd like, check out the 'pmvc-refactor' branch here:
https://github.com/extofme/aur-pyjs/tree/pmvc-refactor
it will be the path forward, and is based on the lightweight puremvc
framework to add a little sanity. i encourage you to take a look, as
the code is remarkably small, fast, free of any HTML/compatibility
nuances, but still leverages the full power of the most advanced GUI
available... a web browser, an excellent language... python, and a
competent widget library based on GWT. it's a fully client side
javascript (or python-DOM) application requiring nothing from the
server (or a local daemon...) other than JSON-RPC endpoints, which can
be implemented in any language.
[...]
Just out of curiosity, how will this accommodate links/lynx or
brltty/espeak/etc. users?
it would not i suppose -- someone else would need to create a front
end that renders static HTML. the rest of the code and library could
be reused... i don't have much interest in implementing that, but i do
plan to work on a CLI interface once other aspects have been
completed, so that would be an option too.
the frontends speak with a local JSON-RPC daemon, so really it can be
anything (in fact one of my super secret awesomo goals is to wire a
visualizer to the daemon once it's distributed, and visualize the
Archlinux network).
i'm about to have a whole lotta time freed up, so i'll finally be able
to work on this again... this project's on my mind everyday and it
annoys me when i can't work on it :-)
C Anthony
If you guys are willing to work on any part of the code in the aur,
there are 3 things that I have always found missing in the aur which I
think are essential.
FS#15043 - Need better parsing of PKGBUILDs
https://bugs.archlinux.org/task/15043?project=2
Does this need explaining? It's also pretty annoying.
There are tons of examples on the aur where download sources are like
http://foo.com/foo-{pkgver:0:5.tar.gz
The above example isn't the only thing that is bad at being parsed,
check out bug report for full details.
FS#16394 - Split Packages in AUR
https://bugs.archlinux.org/task/16394?project=2
Obviously things like mesa would greatly benefit from this. Also would
allow us to remove a lot of redundant packages.
FS#21600 - canonical links
https://bugs.archlinux.org/task/21600?project=2
Although this isn't a necessity, and should probably get low priority,
I think this would be a nice addition. It would make links to the aur
human understandable.
Well hope you take what I said into some consideration.
Cheers!
Re: [arch-general] Testing kills shm and pts
On Sun, Dec 12, 2010 at 12:37 PM, jesse jaara jesse.ja...@gmail.com wrote: So I enabled testing, community-testing and kde-unstable updated yaourt -Syu and reebooted. Now when ever I boot the machine the /dev/shm and /dev/pts get mounted so that only root can write into them. So I cannot use shm as a normal user and no terminal emulator can create a /dev/pts/0 node. 2010/12/12 Kaiting Chen kaitocr...@gmail.com Um what? You're going to need to be a little more specific. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/ -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. ( ) come join the dark side. /_|_\ (we have cookies.) Please don't top post. Anyways, this sort of thing really belongs in bugs.archlinux.org
Re: [arch-general] why is sage-mathematics so huge?
On Fri, Sep 10, 2010 at 1:17 AM, Auguste Pop augu...@gmail.com wrote: Hi, I just noticed that there is a sage-mathematics package in community repository and tried to install it and found out that the package is really huge. I understand that sage is always shipped in a gigantic bundle, but the arch package is considerably larger than official packages provided for other Linux distributions. For lzma compressed archives, they are typically around 330MB, while the arch package is about 630MB. Why is the package so big? I have just noticed that the arch version is 4.5.3, the version on its official site is still 4.5.2. Is this the reason for the big package? Thank you for your kind attention. Yours, Hi Auguste, I don't know the exact answer to this question, but I think I may know why. Currently, sage keeps all the spkgs in the package. Also it is built with fat binaries although this itself probably doesn't add such a significant amount. I'll investigate this and let you know.
Re: [arch-general] why is sage-mathematics so huge?
On Fri, Sep 10, 2010 at 8:41 AM, Thomas Dziedzic gos...@gmail.com wrote: On Fri, Sep 10, 2010 at 1:17 AM, Auguste Pop augu...@gmail.com wrote: Hi, I just noticed that there is a sage-mathematics package in community repository and tried to install it and found out that the package is really huge. I understand that sage is always shipped in a gigantic bundle, but the arch package is considerably larger than official packages provided for other Linux distributions. For lzma compressed archives, they are typically around 330MB, while the arch package is about 630MB. Why is the package so big? I have just noticed that the arch version is 4.5.3, the version on its official site is still 4.5.2. Is this the reason for the big package? Thank you for your kind attention. Yours, Hi Auguste, I don't know the exact answer to this question, but I think I may know why. Currently, sage keeps all the spkgs in the package. Also it is built with fat binaries although this itself probably doesn't add such a significant amount. I'll investigate this and let you know. Back with some results :) I have gone through the directory to see what made it so big, and I realized my initial suspicions were correct. I have removed about 300mb of spkgs (compressed) and a lot of extraneous logs. The changes are already in trunk along with a few other bug fixes. Changes should be visible for the next sage release (4.6). Thanks for your interest!
Re: [arch-general] wireshark 1.4.0-2 crashes
On Mon, Sep 6, 2010 at 10:15 AM, mwnn mwnn...@gmail.com wrote: Hi, I am running the x86 version of Arch. The recently updated wireshark segfaults on my machine. Here is the backtrace of the core file generated by gdb. (gdb) bt #0 0xb4e3731f in PyObject_IsInstance () from /usr/lib/libpython2.6.so.1.0 #1 0xb4e37bd7 in PySequence_Check () from /usr/lib/libpython2.6.so.1.0 #2 0xb67487e3 in register_all_py_protocols_func () from /usr/lib/libwireshark.so.0 #3 0xb5c5725c in proto_init () from /usr/lib/libwireshark.so.0 #4 0xb5c440ba in epan_init () from /usr/lib/libwireshark.so.0 #5 0x0808d22b in main () (gdb) Regards, mwnn http://bugs.archlinux.org/task/20749
Re: [arch-general] 3 minutes and 12 seconds Youtube video of My Arch Linux
On Sun, Aug 29, 2010 at 11:01 AM, Gary Wright wrigg...@gmail.com wrote: On Sun, Aug 29, 2010 at 5:56 AM, Mr. Teo En Ming (Zhang Enming) of Singapore enming...@lavabit.com wrote: My Arch Linux is essentially a Linux from Scratch (LFS) 6.5 which I have compiled and installed from scratch, following the LFS 6.5 Handbook very closely. After finishing the basic LFS 6.5 installation, I have installed the pacman package manager from Arch Linux, essentially making the LFS 6.5 installation an Arch Linux installation. With the pacman package manager in place, I was able to install the X.org X Windowing Server and the GNOME Desktop Environment with ease. Sorry to feed the trolls, but look at 0:31 in the video. Apparently he hasn't been following LFS too closely... he seems to have cribbed the bootscritps from Arch as well, making me think he just changed the hostname and the name of the kernel he was using on a perfectly good Arch machine. Although his computer's hdd, or whatever that annoying sound is, makes me think that he went through with the lfs install :)
Re: [arch-general] 2.6.35-ARCH panic in VirtualBox 3.2.8-1
On Fri, Aug 20, 2010 at 10:53 PM, Martín Cigorraga martosurf7...@gmail.com wrote: Tonight I did a clean install of Arch in a VirtualBox VM and after updating the system I can't boot anymore because there's a kernel panic, see attached screenshot for the output error log [0] Ok, I was a dumb because I didn't make any snapshot before upgrading -was working well with ISO shipped kernel- nor made a backup of kernel files in /boot before blindly upgrade, but I think this a good time for ask you seriously consider implementing an automatic backup for kernel before upgrading to a new one (I know this had been treated no so much time ago in the list and that there's an active wiki about this topic). By the way, thanks a lot for fixing K3b so fast. Best, -Martín [0] goog_933442720 http://www.fileden.com/files/2010/5/7/2852027/My%20Documents/Screenshots/archvbkernelpanic.jpeg I always have a backup kernel that I just built once, and never touch to avoid these issues. Kernel26-lts might be a good one to use for the backup kernel. I think that having an automatic backup would just add unnecessary complexity. Just my 2 cents. Cheers!
Re: [arch-general] Latest K3b update is broke
On Thu, Aug 19, 2010 at 1:55 PM, Martín Cigorraga martosurf7...@gmail.com wrote: After a # yaourt -Syu which showed: Objetivos (2): k3b-2.0.1-1 [8,14 MB] qimageblitz-0.0.6-1 [0,06 MB] I downloaded and installed both packages. Now I got this error when launching K3b: k3b: error while loading shared libraries: libkcmutils.so.4: cannot open shared object file: No such file or directory Please tell the package maintainer to check it. -Martín Rebuilding it might fix it. Could have been built outside of a chroot or the lib version has changed.
Re: [arch-general] [arch-dev-public] Large packages in repositories
On Tue, Aug 17, 2010 at 9:12 AM, Dan McGee dpmc...@gmail.com wrote: Hey guys, A package went in so big today that it made reporead blow up on my local database due to the installed size being 2GB: http://www.archlinux.org/packages/community/i686/sage-mathematics/ http://www.archlinux.org/packages/community/x86_64/sage-mathematics/ File /usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py, line 44, in execute return self.cursor.execute(query, args) django.db.utils.DatabaseError: integer out of range I'm wondering if we need to be more careful when it comes to these big packages entering our repositories. This one is especially suspect as of its 71096 files (and 71094 in the other architecture), a ton of them are things like *.py, *.pyc, *.html, or *.png files. This is ripe for splitting into a -data package (or not including some of this junk, if it is that, at all). mysql select count(*), substring_index(path, '.', -1) from package_files where pkg_id = 49860 and path like '%.%' group by substring_index(path, '.', -1) order by count(*) desc limit 25; +--++ | count(*) | substring_index(path, '.', -1) | +--++ |29787 | png| | 9410 | py | | 6602 | pyc| | 1804 | h | | 1722 | html | | 1659 | txt| | 1168 | pyo| | 988 | doctree| | 988 | rst| | 886 | hpp| tl;dr: I think we need some standards with these huge packages, and people need to be a lot more cognizant as to how big they are. We have lost more than one mirror due to complaints over needed space and stuff like this doesn't help. If any TU's would like to forward this along and solicit their thoughts I'd appreciate it. -Dan There was a 4 day long thread about this in aur-general http://mailman.archlinux.org/pipermail/aur-general/2010-August/009854.html
Re: [arch-general] [arch-dev-public] The Great Python Rebuild of 2010 begins
On Tue, Aug 17, 2010 at 10:46 AM, Allan McRae al...@archlinux.org wrote: Hi, I have pushed the new python (3.1) and python2 (2.7) packages to the new [staging] repo so rebuilds can start there. Remember the staging repo should never be used outside a build chroot... If you do, everything python related will break on your system. TUs will not be able to start uploading rebuilds yet as they do not have a staging equivalent, but we will sort something out for them once we get all the db-scripts/devtools changes tested for the main one first. The package pool is going to save us a heap of issues when this gets moved so it is worth the wait. The key things to remember with the rebuild are: - build in clean chroots. Most packages will detect python2 or python-2.7 once they see no python and use that. Some will need simple patching. - change your dependencies to python2 - check files for #!'s with /usr/bin/python or /usr/bin/env python. If you have those you will need to do a sed to change them to python2. If you come across a package that you can not easily fix, add it to http://wiki.archlinux.org/index.php/DeveloperWiki:Python_Todo_List#Packages_with_rebuild_issues and I will take a look at it. Have fun, Allan This would probably be also a good time to remind the maintainers that there are still packages left for the community cleanup.. only a few are still remaining. I would like to finally see the community cleanup marked as complete :) emerald-themes - ronald gnochm - dgriffiths grub-gfx - orphan kydpdict - jswierczynski libnewt - dgriffiths libnsbmp - dgriffiths libnsgif - dgriffiths libtrash - jswierczynski magickthumbnail - orphan man-pages-cs- jlichtblau man-pages-pt_br - jlichtblau mandvd - jlichtblau mdf2iso - dgriffiths miniracer - dgriffiths mt-daapd- orphan noyau - orphan nrg2iso - dgriffiths pork- jlichtblau premake - dgriffiths pstreams- dgriffiths pygoocanvas - orphan python-certtool - orphan python-geotypes - orphan python-gnupginterface - aschaefer python-pysqlite-legacy - ronald qt-recordmydesktop - dgriffiths qucs- spupykin sfarkxtc- jlichtblau shfs-utils - jlichtblau texlive-bibtexextra-doc - shusmann texlive-core-doc- shusmann texlive-fontsextra-doc - shusmann texlive-formatsextra-doc- shusmann texlive-games-doc - shusmann texlive-genericextra-doc- shusmann texlive-htmlxml-doc - shusmann texlive-humanities-doc - shusmann texlive-langcjk-doc - shusmann texlive-langcyrillic-doc- shusmann texlive-langextra-doc - shusmann texlive-langgreek-doc - shusmann texlive-latex3-doc - shusmann texlive-latexextra-doc - shusmann texlive-music-doc - shusmann texlive-pictures-doc- shusmann texlive-plainextra-doc - shusmann texlive-pstricks-doc- shusmann texlive-pstricks-doc- shusmann texlive-publishers-doc - shusmann texlive-science-doc - shusmann
Re: [arch-general] one suggestion for aur edbrowse package
On Tue, Aug 17, 2010 at 9:25 PM, Jude DaShiell jdash...@shellworld.net wrote: In its present configuration it's a good package. However someone who unpacks the edbrowse package for the first time ought to be told while running as a user account to prepare to use edbrowse for the first time first run the setup.ebrc package. Once that's done, necessary set up edbrowse needs to have gets done. Please post this on the comments of said package.
[arch-general] Fwd: [arch-dev-public] /dev/shm permissions and building in chroot
On Fri, Aug 13, 2010 at 10:51 PM, Allan McRae al...@archlinux.org wrote:
Hi,
I have been tracking down a python3 bug and it turns out to be caused by
our chroot building. Essentially the permissions of /dev/shm are different
in the chroot than on the system:
al...@mugen /home/arch/chroot/stable-i686/copy/dev
ls -ld shm
drwxr-xr-x 2 root root 40 Jul 12 15:16 shm
al...@mugen /dev
ls -ld shm
drwxrwxrwt 2 root root 40 Aug 14 10:23 shm
So when configure scripts try to test for POSIX semaphores by writing in
that directory, they fail.
Looking at the relevant line in mkarchroot:
mount -o bind /dev ${working_dir}/dev
Doing that manually show the same issue. Should we add
chmod 1777 ${working_dir}/dev/shm
after the mount? It fixes my issue but feels hackish. Any other
suggestions?
Allan
oops
I don't have time to try it now, but we could try mounting it without a bind
as described here:
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/kernfs.html
Cheers!
Sorry for sending it to arch-general, but I don't have write access to
arch-dev-public :P
Re: [arch-general] donate for the improvement and development
On Tue, Jul 20, 2010 at 8:49 AM, Denis Kobozev d.v.kobo...@gmail.com wrote: On Sat, Jul 17, 2010 at 8:20 PM, Thomas Dziedzic gos...@gmail.com wrote: Always check the wiki :) http://wiki.archlinux.org/index.php/Getting_Involved I seem to remember a website where you could post things like I want somebody to implement feature X in Arch and I will pay $N for it or I would be willing to implement feature X in Arch if somebody paid me $M for it, but it's not in the wiki. I cannot find it by Googling, either... Denis. https://bbs.archlinux.org/viewtopic.php?pid=618869 It doesn't exist anymore because there was a lack of interest.
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
2010/7/17 Евгений Борисов fle...@gmail.com: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. 2010/7/17 ganlu rhythm@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010年07月17日 15:46, Ionuț Bîru wrote: On 07/17/2010 09:27 AM, Madhurya Kakati wrote: Hi, While updating to a new kernel pacman replaces the older kernel with the new one. Is there someway to keep the older kernel in /boot and have new entries for new kernel in menu.lst while keeping old entries intact? no You can alway do it manually, simply copy the old kernel image as other name before you update, then modify the correspondent line in menu.1st file. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQWwCAAoJEOaLWowX7DBTyPYH/jVEL3/YbKpw4g2YQeEDIKhN E1HHpBq0LLxHmqe5N8C79VzGV8V2RSu/B6qsmzjO3f98xd2E+ev4Etd8YGOV5vvU pkKu+UOeDEubFrX75L1/802wTIfO5DI21VaLpRKD/+JJ2R2rTa1Bk2HmTF5DWmoh mpVXOydJyIXNeu2BVUemjn4TK2t6IGs22yCI107F5uD3SV1ZtpavsZ3xZCav3e6B x2R8C2NCF/r3BnVE3BYh9AlX617/F03hCQPOKMyXjLnMylrVvfkxMM1Q9kW97pcl nGR+1YUbNgTnaylyls2dOp4UAwzALcCDVwq9oJnitTcR6f/OlIH6ELUtX0gvUUU= =t+0W -END PGP SIGNATURE- If the point is to have a kernel that works, check out the -lts kernel. I on the other hand, have used kernel26-rc in the AUR as my main kernel, and kernel26 as a backup on my desktop :P
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee ngoo...@gmail.com wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. Agreed with Ng Oon-Ee on this one.
Re: [arch-general] Keep older kernel intact while upgrading to new kernel
On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: I think it's a bad idea, because the directory /lib/modules/$oldVersion$ will be removed when the package is upgraded kernel. Trivial solution not exists. My solution is to hand-roll my own kernels and initramfs'es after removing the kernel and mkinitcpio packages. The way Arch handles its kernel packages is a weak point -- Fedora and Ubuntu get this bit right. Yeah, why not keep all previous kernels and headers around. We could automatically extend menu.lst too! It wold be better than updating to a new kernel, rebooting, and having to boot to a LiveCD to get back into your system because the new kernel fscked things up. Keeping versioned header files also comes in handy -- I take it you heve never tried any sort of testing with out-of-tree drivers or kernel subsystems? Using DKMS on arch is a pointless waste of time because older kernel headers are not kept around. I'm not sure what you like about Fedora and Ubuntu handling of kernels, but I found it very annoying to have all that stuff hanging around. Would be worse with rolling release I'm sure. I like knowing that I will not have to hunt for a LiveCD or a rescue USB drive if a kernel update renders the system unbootable. This wouldn't be a problem if you have a backup kernel :)
Re: [arch-general] donate for the improvement and development
On Sat, Jul 17, 2010 at 6:36 PM, Dmitry Korzhevin dkorzhe...@lsupport.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any site which listed the current Arch Linux project objectives, on which user can donate development or improvement of this tasks? - -- Best regards, Dmitry Korzhevin Tel: +38 (039) 295- Office Phone: +38 (044) 383-14-12 E-mail: dkorzhe...@lsupport.net Jabber ID: dkorzhe...@lsupport.net Skype: dkorzhevin URL: http://lsupport.net Linux Support LLC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMQj6GAAoJEGuRMpfwJUbRnksH/jJwCFrHZiu5wfBhAYKYtcN2 6JBe+6EIVfmKmJGzvUhD2MVTwcjajIGC3oXq8ekVrxV+sH/QheGxGX+QRleJvfxb 1aK0n0zyiYnz8OXEleGgNYqqwsy/ccFiPndH/4rv4YX3Ttm5EZODwq/dVJ9/O6qg Zp32Yn1UbNkHiwnendRTS1Ig5vcbWXuPFr/obST2jPViK1Yj4EMk6nfjN2sQouRd yJQEJLqOSvlu7pCWckewANGQ7pYQbB1OSGAdEMs5kC9+Ludt5zTlJs0bxj1cD7/g /7M0bc4lSU1gqykcLetCuWXbMkbXQC9bhBrhwbnA/q05s66NFgxpSDbhHSzk7pk= =tSai -END PGP SIGNATURE- Always check the wiki :) http://wiki.archlinux.org/index.php/Getting_Involved
Re: [arch-general] Need Help working on radeon/kernel bug - Where can I get .35rc kernel
On Sat, Jul 17, 2010 at 7:36 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, On the kernel/radeon, Andreas suggested: try a .35rc kernel if it's fixed meanwhile. if not ask on the upstream radeon list and then probably file the issue to the Xorg tracker for radeon. My question: (1) where would I look to find the Arch .35rc kernel? I got the rest :p http://aur.archlinux.org/packages.php?ID=31932 kernel26-rc
Re: [arch-general] Tasks for newbie at online bug squashing (during Archcon)?
On Fri, Jul 16, 2010 at 2:16 PM, Mathias Huber hu...@mathiashuber.de wrote: Hi, I've seen there will be an online bug squashing with Archers worldwide during Archcon on July 22 and 23 http://bbs.archlinux.org/viewtopic.php?id=83844. I've set some time apart to join the fun. However, I am an Arch newbie, though long standing Linux user. What will there be for me to do? Can you find me some trivial tasks? [...] Have you taken a look at the following wiki? http://wiki.archlinux.org/index.php/Getting_Involved Yes I have, but it isn't very specific as far as Bug Days are concerned If you truly don't possess any coding skills (web included), then I think helping out in the wiki would be most appreciated. I have some web coding skills (HTML, CSS, PHP, JS), which have become a bit rusty -- anyone remember the dot com years ;-) Well, let's see. Any suggestions will be appreciated, the more concrete the better. Cheerio, Mathias Now that you mentioned web coding... my ideas have just opened up. Here are some bugs dealing with web stuff: http://bugs.archlinux.org/index.php?string=webproject=1search_name=type[]=sev[]=pri[]=due[]=reported[]=cat[]=status[]=openpercent[]=opened=dev=closed=duedatefrom=duedateto=changedfrom=changedto=openedfrom=openedto=closedfrom=closedto=do=index also, don't forget that http://bugs.archlinux.org/index.php?project=2 (aur) is full of web related bugs. For something more concrete, my 2 pet peeves for the arch website are: 1. inconsistent headers between the new headers and the bugs/aur header 2. websvn is b0rked and needs some repairs. If you can fix those, that would be awesome :) Btw, you can do whatever you think will improve archlinux. Hope this helps. Cheers!
Re: [arch-general] What broke ctrl+c ??
On Fri, Jul 16, 2010 at 9:52 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, I have a strange problem. ctrl+c is completely broken on my system. It won't cancel Jack Schit. It is the strangest thing I've seen. I apologize if there is some archain Arch notice on this I apologize, I've missed it. This is easy to test. Just to 'ping anywhere' and then try and kill it with ctrl+c. I have to open another terminal and either 'killall ping' or kill the pid to get the thing to stop. Same thing happens if I mistype a cli and need to cancel the execution (like if I mistype a ' instead of a and the script continues on a new line) What's up with this? Works for me. What packages did you upgrade and what did you do recently?
Re: [arch-general] What broke ctrl+c ??
On Sat, Jul 17, 2010 at 12:49 AM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 07/17/2010 12:01 AM, Corey Johns wrote: On Fri, Jul 16, 2010 at 10:58 PM, Thomas Dziedzicgos...@gmail.com wrote: On Fri, Jul 16, 2010 at 9:52 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, I have a strange problem. ctrl+c is completely broken on my system. It won't cancel Jack Schit. It is the strangest thing I've seen. I apologize if there is some archain Arch notice on this I apologize, I've missed it. This is easy to test. Just to 'ping anywhere' and then try and kill it with ctrl+c. I have to open another terminal and either 'killall ping' or kill the pid to get the thing to stop. Same thing happens if I mistype a cli and need to cancel the execution (like if I mistype a ' instead of a and the script continues on a new line) What's up with this? Works for me. What packages did you upgrade and what did you do recently? Try a new keyboard to help isolate the problem. I would, but this is a laptop :p The list of packages updated recently are: [2010-07-14 17:29] Running 'pacman -Sy wesnoth' [2010-07-14 17:29] synchronizing package lists [2010-07-14 17:30] Note: [2010-07-14 17:30] == If you experience sound problems try setting your SDL_AUDIODRIVER environment variable to dma [2010-07-14 17:30] == eg. export SDL_AUDIODRIVER=dma ; wesnoth [2010-07-14 17:30] == If dma doesn't work,other options are: dsp,alsa,artsc,esd,nas try to find the right output. [2010-07-14 17:30] installed wesnoth (1.8.2-2) [2010-07-15 04:32] Running 'pacman -Syu' [2010-07-15 04:32] synchronizing package lists [2010-07-15 04:33] starting full system upgrade [2010-07-15 04:47] removed obexd (0.28-1) [2010-07-15 04:47] upgraded bluez (4.67-1 - 4.69-1) [2010-07-15 04:47] upgraded clutter (1.2.8-1 - 1.2.10-1) [2010-07-15 04:47] upgraded udev (159-1 - 160-1) [2010-07-15 04:47] upgraded device-mapper (2.02.69-1 - 2.02.70-1) [2010-07-15 04:47] upgraded eventlog (0.2.9-1 - 0.2.12-1) [2010-07-15 04:47] upgraded fbpanel (6.0-1 - 6.1-2) [2010-07-15 04:47] upgraded glitz (0.5.6-1 - 0.5.6-2) [2010-07-15 04:47] upgraded gparted (0.6.0-1 - 0.6.1-1) [2010-07-15 04:47] upgraded gvfs (1.6.2-1 - 1.6.3-1) [2010-07-15 04:47] upgraded gvfs-obexftp (1.6.2-1 - 1.6.3-1) [2010-07-15 04:47] upgraded initscripts (2010.06-2 - 2010.07-1) [2010-07-15 04:47] upgraded linux-firmware (20100606-1 - 20100623-2) [2010-07-15 04:47] upgraded mkinitcpio (0.6.6-1 - 0.6.7-1) [2010-07-15 04:47] Updating module dependencies. Please wait ... [2010-07-15 04:47] MKINITCPIO SETUP [2010-07-15 04:47] [2010-07-15 04:47] If you use LVM2, Encrypted root or software RAID, [2010-07-15 04:47] Ensure you enable support in /etc/mkinitcpio.conf . [2010-07-15 04:47] More information about mkinitcpio setup can be found here: [2010-07-15 04:47] http://wiki.archlinux.org/index.php/Mkinitcpio [2010-07-15 04:47] [2010-07-15 04:47] Generating initial ramdisk, using mkinitcpio. Please wait... [2010-07-15 04:47] == Building image default [2010-07-15 04:47] == Running command: /sbin/mkinitcpio -k 2.6.32-lts -c /etc/mkinitcpio.conf -g /boot/kernel26-lts.img [2010-07-15 04:47] :: Begin build [2010-07-15 04:47] :: Parsing hook [base] [2010-07-15 04:47] :: Parsing hook [udev] [2010-07-15 04:47] :: Parsing hook [autodetect] [2010-07-15 04:47] :: Parsing hook [pata] [2010-07-15 04:47] :: Parsing hook [scsi] [2010-07-15 04:47] :: Parsing hook [sata] [2010-07-15 04:47] :: Parsing hook [filesystems] [2010-07-15 04:47] :: Generating module dependencies [2010-07-15 04:47] :: Generating image '/boot/kernel26-lts.img'...SUCCESS [2010-07-15 04:47] == SUCCESS [2010-07-15 04:47] == Building image fallback [2010-07-15 04:47] == Running command: /sbin/mkinitcpio -k 2.6.32-lts -c /etc/mkinitcpio.conf -g /boot/kernel26-lts-fallback.img -S autodetect [2010-07-15 04:47] :: Begin build [2010-07-15 04:47] :: Parsing hook [base] [2010-07-15 04:48] :: Parsing hook [udev] [2010-07-15 04:48] :: Parsing hook [pata] [2010-07-15 04:48] :: Parsing hook [scsi] [2010-07-15 04:48] :: Parsing hook [sata] [2010-07-15 04:48] :: Parsing hook [filesystems] [2010-07-15 04:48] :: Generating module dependencies [2010-07-15 04:48] :: Generating image '/boot/kernel26-lts-fallback.img'...SUCCESS [2010-07-15 04:48] == SUCCESS [2010-07-15 04:48] upgraded kernel26-lts (2.6.32.15-1 - 2.6.32.16-1) [2010-07-15 04:49] upgraded kernel26-lts-headers (2.6.32.15-1 - 2.6.32.16-1) [2010-07-15 04:49] upgraded libssh (0.4.4-1 - 0.4.5-1) [2010-07-15 04:49] upgraded libwebkit (1.2.1-1 - 1.2.2-1) [2010-07-15 04:49] when you use a non-reparenting window manager [2010-07-15 04:49] set _JAVA_AWT_WM_NONREPARENTING=1 in [2010-07-15 04:49] /etc/profile.d/openjdk6.sh [2010-07-15 04:49] upgraded openjdk6 (6.b18_1.8-1 - 6.b18_0.hg_20100715-1) [2010-07-15 04:49] upgraded lucene (2.9.2-1 -
Re: [arch-general] Tasks for newbie at online bug squashing (during Archcon)?
On Thu, Jul 15, 2010 at 4:40 PM, Mathias Huber hu...@mathiashuber.de wrote: Dear Archers, I've seen there will be an online bug squashing with Archers worldwide during Archcon on July 22 and 23 http://bbs.archlinux.org/viewtopic.php?id=83844. I've set some time apart to join the fun. However, I am an Arch newbie, though long standing Linux user. What will there be for me to do? Can you find me some trivial tasks? Most bugs I find in flyspray are beyond my capabilities -- X.org flaws or missing hardware support. I think I could update simple package builds, or correct a wrong path here and there. Apart from that, I am quite good at writing documentation. Should I comb the Arch wiki? Do I need to have a spare Arch system at hand to test things? Maybe someone could take this newbie by the hand? Cheers, Mathias Have you taken a look at the following wiki? http://wiki.archlinux.org/index.php/Getting_Involved If you truly don't possess any coding skills (web included), then I think helping out in the wiki would be most appreciated. I don't have any other ideas :/
Re: [arch-general] mercurial in Extra out of date
On Tue, Jul 6, 2010 at 10:43 PM, PT M. pen...@gmail.com wrote: On Wed, Jul 7, 2010 at 11:36 AM, Dan McGee dpmc...@gmail.com wrote: On Tue, Jul 6, 2010 at 10:33 PM, PT M. pen...@gmail.com wrote: It's been a week since mercurial 1.6 released, extra/mercurial 1.5.4-1 is still in the repository. OMG! Raise the alarm!!! You do realize none of us are full-time around here, right? The maintainer will get to it when he can. Until then, learn to use ABS. calm down calm down ... if I sent this to the wrong place, sorry, i just wanted the maintainer got noticed, maybe i shoud sent to him directly? I do know abs, and thanks. -Dan Mercurial has already been flagged out of date: http://www.archlinux.org/packages/extra/i686/mercurial/ You could also send a working pkgbuild to hopefully speed this up :P
