- Aur-general - lists.archlinux.org

[aur-general] orphan request: hamlib
by Wijnand Modderman-Lenstra 22 Apr '14

22 Apr '14

Hello, Please flag the hamlib package in AUR as orphaned, so I can push a new PKGBUILD for this unmaintained package. Out of date: flagged at 2013-06-04 Package: hamlib[1] Thanks, Wijnand[2] [1]: https://aur.archlinux.org/packages/hamlib/ [2]: https://aur.archlinux.org/account/maze/

2 1

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 22 Apr '14

22 Apr '14

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 10 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 15 packages missing signoffs * 1 package older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (10 total) == * cinnamon-control-center-2.2.3-3 (i686) * cinnamon-settings-daemon-2.2.1-3 (i686) * rethinkdb-1.12.3-1 (i686) * simple-scan-3.12.0-2 (i686) * weston-1.4.0-3 (i686) * cinnamon-control-center-2.2.3-3 (x86_64) * cinnamon-settings-daemon-2.2.1-3 (x86_64) * rethinkdb-1.12.3-1 (x86_64) * simple-scan-3.12.0-2 (x86_64) * weston-1.4.0-3 (x86_64) == Incomplete signoffs for [community] (15 total) == * waf-1.7.15-2 (any) 1/2 signoffs * agg-1:2.4r93-1 (i686) 0/1 signoffs * cinnamon-control-center-2.2.3-3 (i686) 0/1 signoffs * cinnamon-settings-daemon-2.2.1-3 (i686) 0/1 signoffs * python-msgpack-0.4.2-1 (i686) 0/1 signoffs * rethinkdb-1.12.3-1 (i686) 0/1 signoffs * simple-scan-3.12.0-2 (i686) 0/1 signoffs * weston-1.4.0-3 (i686) 0/1 signoffs * agg-1:2.4r93-1 (x86_64) 0/2 signoffs * cinnamon-control-center-2.2.3-3 (x86_64) 0/2 signoffs * cinnamon-settings-daemon-2.2.1-3 (x86_64) 0/2 signoffs * python-msgpack-0.4.2-1 (x86_64) 0/2 signoffs * rethinkdb-1.12.3-1 (x86_64) 0/2 signoffs * simple-scan-3.12.0-2 (x86_64) 0/2 signoffs * weston-1.4.0-3 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (1 total) == * waf-1.7.15-2 (any), since 2014-03-21 == Top five in signoffs in last 24 hours ==

1 0

[aur-general] Remove Request : r-mathlib
by Peng Zhang 22 Apr '14

22 Apr '14

it is part of r now.

3 2

[aur-general] Delete requests: eve-git and tiling2-git
by Doug Newgard 22 Apr '14

22 Apr '14

eve-git: https://aur.archlinux.org/packages/eve-git/ This program is dead upstream. I mirrored the source to be able to keep the package alive, but now the webkit library it relies on has had a major API break. It's beyond my ability/interest to fix right now, so it just needs to be removed. tiling2-git: https://aur.archlinux.org/packages/tiling2-git/ This is a module for Enlightenment that I thought was going to live in it's own repo for a while. Instead, it was merged into the main E tree, making this package redundant. There's nothing worth merging.

2 1

[aur-general] Removal request
by Charles Bos 22 Apr '14

22 Apr '14

Hi, Can the following package be deleted please: https://aur.archlinux.org/packages/libnautilus-extension-ubuntu/ I originally uploaded it because the AUR doesn't yet support split packages but it doesn't really make sense to compile the whole of nautilus twice and then throw most of it away so I've made sure that libnautilus-extension-ubuntu is provided in this package: https://aur.archlinux.org/packages/nautilus-ubuntu/ Thanks

2 1

[aur-general] disown request: ruby-ruby2ruby
by Jeremy Audet 22 Apr '14

22 Apr '14

Hi, Please disown ruby-ruby2ruby. [1] I flagged the package out of date 25 days ago, commented on it 19 days ago and emailed the maintainer 14 days ago. [1] https://aur.archlinux.org/packages/ruby-ruby2ruby/ — Jeremy 'Ichimonji10' Audet

2 1

[aur-general] Please remove these packages from AUR
by Jesus Alvarez 21 Apr '14

21 Apr '14

Please remove the following packages: zfs zfs-utils spl spl-utils Thanks! Jesus A.

5 6

[aur-general] [Merge Request] flamerobin
by Berno Strik 21 Apr '14

21 Apr '14

Can you please Merge [1] into https://aur.archlinux.org/packages/flamerobin-git/ The last update of [1] was in April 2009. [1] https://aur.archlinux.org/packages/flamerobin

2 1

Re: [aur-general] AUR Git mirror stopped updating
by keenerd 21 Apr '14

21 Apr '14

Yeah, something stopped working when we recently migrated servers. There are a couple of ways of fixing it, but nothing straightforward. -Kyle http://kmkeen.com On 4/18/14, Martin Panter <vadmium%2Bal(a)gmail.com> wrote: > Hi Kyle, I heard you were in charge of the AUR Git mirror at > <http://pkgbuild.com/git/aur-mirror.git>. Doesn't seem to have updated > for six days or so; maybe you could have a look? > > Thanks, Martin >

1 1

[aur-general] GHC 7.8.1 packaging decisions for Arch Linux
by Thomas Dziedzic 21 Apr '14

21 Apr '14

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

6 8