- Aur-general - lists.archlinux.org

[aur-general] Python 3
by Xyne 21 Jan '11

21 Jan '11

Andrea Scarpino wrote: > Hi AUR maintainers, > I did a change in the pyqt package to add Python 3 support to it and to allow > everyone to install both the Python2 and the Python3 version. > Every package now need to depends on python2-qt (or python-qt if uses Python > 3) instead of pyqt. > The packages in [extra] and [community] have been updated, please do the same > with your packages in AUR. > > Also, the packages which depend on sip have to be fixed with the right > dependence: python2-sip (or python-sip if the package uses Python 3). > > Thank you! > > -- > Andrea I'm replying because this is tangential... why don't we specify "python3" instead of "python" as a dep to make packages future-proof? Even if Python 4 doesn't come out for a decade or more, it just seems that it would be logically consistent.

2 1

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all
by Pierre Chapuis 21 Jan '11

21 Jan '11

On Thu, 20 Jan 2011 00:25:15 +1000, Allan McRae <allan(a)archlinux.org> wrote: > The problem is that the transitive closure can not be assumed to be > correct. > > e.g. At the time A is built: > > A -> B,C,D,E > B -> C,D,E > C -> D,E > > Then B is updated and > > B -> C,D,E,F. > > Now the assuming a transitive closure for the dependency list for A > is incorrect. Installing the listed dependencies of A with the > equivalent of -Sd would result in F not being installed which would > break A through broken B. > > So either: > 1) we require a largely unnecessary rebuild of A > 2) we always check the dependencies of uninstalled dependencies. > > Note #2 is less burden on packagers and is more efficient in the > examples given above if both B and D are installed (two checks vs > four), and that will be the case for most system updates. When none > of A - E are installed, they are probably equally efficient. Yes, I agree with that: dependencies will always have to be checked at package install time. That means that any approach based on a "transitive closure" at packaging time is useless. What could also happen is that C is updated and no longer needs E. Then, with a "transitive closure", A would still install E, which would be useless for the user. So the only way to be safe is not to be clever and to specify real dependencies, eg: Real deps --------- A -> B,D B -> C C -> D,E Transitive closure ------------------ A -> B,C,D,E B -> C,D,E C -> D,E Current Arch way ---------------- A -> B B -> C C -> D,E What should be done ------------------- A -> B,D B -> C C -> D,E -- Pierre 'catwell' Chapuis

4 3

Re: [aur-general] TU Application -Thomas Hatch: Voting period
by Thomas S Hatch 21 Jan '11

21 Jan '11

On Thu, Jan 20, 2011 at 10:27 AM, Andrea Scarpino <andrea(a)archlinux.org>wrote: > On Thursday 20 January 2011 17:16:41 Peter Lewis wrote: > > Congratulations Tom! Welcome aboard the good ship TU! > We was waiting Xyne here, anyway your accounts on AUR/BBS/Flyspray are > updated > since yesterday ;) > > Welcome aboard. > > -- > Andrea > Thanks Andrea, I noticed yesterday when I logged into the AUR, I have already deleted some packages :) I wonder where Xyne is? -Tom

2 1

[aur-general] Any workaround/fix for broken qtile-git?
by Angus 21 Jan '11

21 Jan '11

I really want to try out qtile, but qtile-git in AUR or a dependency of it is broken (and seems to have been so for at least a while). Specifically, running qtile results in: File "/usr/lib/python2.7/site-packages/libqtile/drawer.py", line 138, in __init__ self.height, TypeError: pycairo was not compiled with xpyb support Two of its dependencies are flagged out of date... Anyone know more about the status of this? Should I instead attempt to build from source myself?

1 0

[aur-general] Any TU feel like maintaining eric5 in extra/community?
by Angus 20 Jan '11

20 Jan '11

eric is a feature rich IDE (mainly) for python. eric4 is for use with python2 and is packaged in extra as "eric". eric5 is for use with python3. Both branches seem to be equally stable. eric5 is currently available in the AUR, but now that its python3 related dependencies (python-qscintilla/python-qt/pyqt/python-sip) have all become available in extra it should be straightforward to maintain eric5 in extra as well. (I'm not the AUR maintainer, just a thankful yet whiny user.)

3 3

[aur-general] TU Application -Thomas Hatch
by Thomas S Hatch 20 Jan '11

20 Jan '11

Hello, ArchLinux Tus Xyne has agreed to sponsor me as a TU. I am very excited at the potential opportunity to become more directly involved with the development of ArchLinux. I atteneded Southern Utah University (SUU) where I studied Computer Science. While at SUU I set up one of the first American ArchLinux mirrors, a mirror which is still in operation – locke.suu.edu. At SUU I also worked as a research assistant and developed a (now defunct) Linux distribution based on Arch called Axiom Linux for rediculously parallel compute clusters. It was based on Larch and involved a modified Arch installer, (this was before the aif days). Since then I have worked as a trainer for Red Hat, then a systems software developer for a United States DOD contractor and I am presently employed as a Sr Systems Engineer at Beyond Oblivion. My contributions to Arch so far have been: Created and maintained a working puppet package for Arch, and updated the existing puppet pacman code. Ported libguestfs to Arch, this involved working with the libguestfs developers to create a build port specific to Arch since the build process requires the creation of a specialized Arch Qemu Vm image. Set up MooseFS support for Arch – This is a VERY cool project that I strongly recommend people take a look at : moosefs.org I have been working on standardizing the Ocaml packages for Arch and currently maintain about 25 Ocaml packages. I am the author of the Varch Project: http://code.google.com/p/varch/ My packages and project staging repo is at: http://code.google.com/p/enterprise-archlinux/ I am working on a project that I hope will greatly benefit Arch called quarters: http://code.google.com/p/quarters/ It is still sparse, I just started a re architect And my packages for you to look over: https://aur.archlinux.org/packages.php?SeB=m&K=thatch45 All in all, I am deeply passionate about open source and Linux, I believe in the pragmatic approach to Linux and have continued to find Arch as one of, if the the, superior Linux distribution out there today, not only in principal, but also in engineering. My hope is to assist in bringing ArchLinux further into the forefront of the overall Linux community and to continue to port enterprise grade software to Arch. Hopefully my current contributions suffice to allow me to work as a TU, if there is anything in my contributions or packages that needs improvement, or if there is anything else I can do to improve my standing, please let me know so I can make my application as spotless as possible. -thatch45 -Thomas S Hatch

14 38

[aur-general] delete request
by jonathan 20 Jan '11

20 Jan '11

please delete http://aur.archlinux.org/packages.php?ID=22403 as I am not developing it, and it is redundant to pkgfile. thanks, Jonathan "wide-eye'

4 3

[aur-general] Request removal: ffmpeg-vp8-svn, servicemenu-kvm-kde4, winff-corrected
by Lou 20 Jan '11

20 Jan '11

ffmpeg-vp8-svn http://aur.archlinux.org/packages.php?ID=37297 Orphan. Does not compile. FFmpeg in extra now has libvpx encoder making this package useless. servicemenu-kvm-kde4 http://aur.archlinux.org/packages.php?ID=36180 Orphan. Uses depreciated options that will not work with ffmpeg from extra. Upstream has been inactive for nearly 2 years. winff-corrected http://aur.archlinux.org/packages.php?ID=31348 Source is 404. Maintainer said, "do whatever you want. I do not use Linux anymore."

2 1

[aur-general] delete request
by Gergely Imreh 20 Jan '11

20 Jan '11

Please delete python3-pyke http://aur.archlinux.org/packages.php?ID=45332 I uploaded a new package, python-pyke to follow the name convention of Arch for Python packages. Cheers, Greg

2 1

[aur-general] Request removal: emoc, myencoder, hypervideoconverter
by Lou 19 Jan '11

19 Jan '11

These are all old and orphaned packages that are encoding GUIs to ffmpeg. emoc http://aur.archlinux.org/packages.php?ID=34109 Doesn't work. Just sits there and does not actually convert any videos. myencoder http://aur.archlinux.org/packages.php?ID=31640 Source does not pass the validity check. Upstream states, "MyEncoding development has been scaled back" on 2010-06-20. hypervideoconverter http://aur.archlinux.org/packages.php?ID=21735 Flagged out of date. Upstream not updated since 2008-11-17 and its settings appear not to be compatible with ffmpeg in repository.

2 1