- Aur-general - lists.archlinux.org

[aur-general] xf86-video-intel-git open for adoption
by Thomas Dziedzic 25 Mar '11

25 Mar '11

I have started using the regular point releases from the repos instead of the -git packages of mesa. Disowning xf86-video-intel-git [1] [1] - https://aur.archlinux.org/packages.php?ID=18678

1 0

[aur-general] Deletion Request: vdr-streamdev-cvs
by David Spicer 25 Mar '11

25 Mar '11

Hi, Please delete my package vdr-streamdev-cvs[1]. The vdr-streamdev plugin has moved to git for development now. TIA, David Spicer [1] https://aur.archlinux.org/packages.php?ID=37714

2 1

[aur-general] Packaging with DKMS support
by Jason Melton 24 Mar '11

24 Mar '11

Hello, Over on the rtl8192se package[1], we have been discussing how to best support DKMS in packaging (at the AUR level), and I would like to ask for wider and more experienced comments. I have put my thoughts here and in more detail on my personal Arch wiki page[2]. Thank you. = DKMS Overview = In case anyone doesn't know, DKMS[3] is "Dynamic Kernel Module Support", a Linux technology from Dell that basically re-builds drivers for you when the kernel changes. Big Pro: It is a pain to remember to rebuild some drivers after a kernel upgrade or change, especially crucial drivers like wireless or video card. DKMS automates this process, is robust and used by many distros. Big Con: It complicates the packaging process, and introduces an additional "layer". Primarily, I hope that I can show the Con can be greatly reduced, and the Pro is so valuable it should be considered the suggested way to build kernel modules. Secondly, I hope to get feedback from more experienced packagers. = Packaging DKMS = DKMS is great. I'd like to see it incorporated more in Arch. One way to do so it to provide robust and useful DKMS-enabled packages as an alternative to the "vanilla" driver packages. Another way would be to build in DKMS in the driver package by default, and only "activate" it if the user has dkms on their system. In either alternative, more explicit and comprehensive packaging guidelines would be beneficial. Right now, when it comes to DKMS and the AUR, we generally have 2 packages: a "vanilla" package (ex: rtl8192se) and a "DKMS enabled package" (ex: dkms-rtl8192se).[4] My proposal is to package DKMS support into the "vanilla" package, and let the package .install file determine whether to let DKMS control the drivers or not. In this proposed scenario, there need only be one driver package. Here are the sample files: A sample PKGBUILD.[5] A sample install.[6] A sample dkms.conf.[7] Here is basically what happens: The package installs like normal, with the addition of the source code. In the .install file, if DKMS is present on the system, we set it up for DKMS to take over the drivers, calling one dkms_<event handler> from each needed corresponding "vanilla" <event handler>, and overwriting the installed driver. Since DKMS will only overwrite a file we just installed, pacman can still track what package owns the file. We do the reverse when uninstalling. = Pros = DKMS means the user need not remember to rebuild drivers after a kernel update or for a different kernel running on the system. 1 package can support DKMS and non-DKMS users If there are clear guidelines for DKMS packaging in AUR, more modules will pick it up, enriching Arch = Cons = Slightly more complicated PKGBUILD Source code installed (although many users keep the package on disk as it is now because they need to manually rebuild the package after an update) More complicated install file (but still template-able and very similar to the existing install file) = A further note = Everything across all the necessary files (PKGBUILD, install, dkms.conf) can be "templated" so the packager need not manually update the names/versions across multiple files. I have a very simple example script that generates the install file and the dkms.conf from the information in the PKGBUILD and a install.template [8]. = Conclusion = DKMS reduces the complexity of knowing what package a user should install for what kernel, and remembering to rebuild modules after a kernel change by moving that complexity into the packaging process. DKMS offers a great benefit to users at a small cost to packaging and should be made a recommended practice when packaging kernel drivers. Again, thank you for taking the time to read this and I welcome your feedback. [1]http://aur.archlinux.org/packages.php?ID=34281 [2]https://wiki.archlinux.org/index.php/User:Ushimitsudoki [3]http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support [4]http://aur.archlinux.org/packages.php?ID=47330 [5]http://paste.pocoo.org/show/358740/ [6]http://paste.pocoo.org/show/358741/ [7]http://paste.pocoo.org/show/358742/ [8]http://paste.pocoo.org/show/358745/

5 6

[aur-general] AUR Cleanup Day or aur-general for deletes?
by Aaron DeVore 24 Mar '11

24 Mar '11

To delete a package, is it better to use the AUR Cleanup Day page on the Arch wiki or send an email to this mailing list? -Aaron DeVore

3 2

[aur-general] [AUR-General] Request remove: opensc-opendni-devel and opensc-dnie-devel
by SpinFlo 24 Mar '11

24 Mar '11

please. remove this two packages: http://aur.archlinux.org/packages.php?ID=43589 http://aur.archlinux.org/packages.php?ID=42657 outdated/orphan (by me) and rename/upload (by me) to opensc-dnie-svn and opensc-opendnie-svn greetings

2 1

[aur-general] Aur package deletion : caml2html-full
by Baptiste 24 Mar '11

24 Mar '11

Hello, I would like to delete an AUR package, whose name is `caml2html-full' (it is replaced by `caml2html') Thanks in advance, Baptiste -- "C'est mieux, mais il y a plus cher ailleurs" : ____ _ _ _ _ ___ _ / ___| \ | | | | | / / | (_)_ __ _ ___ __ | | _| \| | | | |/ /| | | | '_ \| | | \ \/ / | |_| | |\ | |_| / / | |___| | | | | |_| |> < \____|_| \_|\___/_/ |_____|_|_| |_|\__,_/_/\_\ GNU/Linux fan && Archlinux user

3 4

[aur-general] Deletion request: samsung-unified-driver-*
by Tobias 24 Mar '11

24 Mar '11

Hi there, could you please delete the following packages: samsung-unified-driver-base [1], samsung-unified-driver-printer [2] and samsung-unified-driver-scanner [3]. They are outdated and were orphaned until I became their maintainer. The packages are duplicates of samsung-unified-driver which seems to be activly maintained. Cheers 2beers [1] http://aur.archlinux.org/packages.php?ID=31763 [2] http://aur.archlinux.org/packages.php?ID=31764 [3] http://aur.archlinux.org/packages.php?ID=31765

2 1

[aur-general] Deletion request: raptor-menu-git
by Jason Melton 24 Mar '11

24 Mar '11

raptor-menu-git: http://aur.archlinux.org/packages.php?ID=24577 Won't compile, upstream project is "kinda discontinued" [1] [1] https://github.com/ruphy/raptor/issues/1

2 1

[aur-general] Deletion Request: python2-pywebkit
by N30N 23 Mar '11

23 Mar '11

python2-pywebkit: http://aur.archlinux.org/packages.php?ID=43392 This package has been awaiting deletion for a while so I assume it's never properly been requested. Laters, Aldrik.

2 1

[aur-general] Deletion request
by Seven Seven 23 Mar '11

23 Mar '11

Plasmate has moved to git, please remove plasmate-svn http://aur.archlinux.org/packages.php?ID=31559. Thanks.

2 1