December 2008 - Aur-general - lists.archlinux.org

[aur-general] packages for adoption
by Roman Kyrylych 08 Mar '09

08 Mar '09

Hi again! Thank you all for your replies! :-) Here's the (commented) list of packages: :: Unsupported :: * 4l * lightscribe * lightscribe-labeler * lightscribe-sdk LightScribe support will have to stay in Unsupported because the license doesn't allow redistribution (as I understand). * abraca * coyote * esperanza-git * kpdf2 * swiftfox-pentium2 * wterm These packages are actually not mine, another user has asked me to keep an eye on them half year ago, some time ago he agreed that it would be good to orphan them * cronolog * cronolog-beta * dav * moe * ndn - closed-source * ndn-beta - highly unstable * new-murrine-configurator - AFAIR it should replace murrine-configurator (it should have become official by now, but this should be checked) * teapop :: Community :: * abyssws - closed source 32-bit only, may go to Unsupported * agave * audacious-docklet - dead * audacious-itouch-control - no new version expected * bakery * balsa * brasero + libburn + libisofs * cherokee * colorer - no new version for a long time, required for mc-colorer, but is usable without it * computertemp * confuse * eiciel * esekeyd - no new version expected, not very useable 'cause runs everything as root, so special steps should be taken to make it work nicely with GUI apps (see config I created) * everygui - no new version is expected * font-mathematica * gdm-themes - licenses need to be reviewed, I've lost my local PKGBUILD modification :-( * gdmap - does not compile with recent gtk2 versions, no new version is expected * gimmage - no new version for a long time * gimmix - no new version for a while, but it was said that there will be new major version with GUI overhaul * glom - AFAIR it requires libgdamm for libgda 3.0 which is not stable (not in Extra at least), that's why I haven't updated it yet (and had no time to dig further) * gnochm * gnome-commander * gnome-schedule * gnomebaker - was dead, then resurrected, but no new versions since then * gpa * gpg-crypter * gshutdown - no new version is expected * gstm - no new version is expected * gtk2_prefs - no new version is expected * gtvg * gwget - needs regular patching of configure/makefiles to work with the latest epiphany * hal-cups-utils * hardware-monitor - dead, doesn't work with lm_sensors 3, no patch is known (=> Unsupported/remove) * homebank * iksemel * iniparser - there is version 3 beta, but it should be a separate package due to API change and existence of packages in Community that makedepend on it (e.g. isomaster), so this package should be left untouched * isomaster * kungfu * libconfig * libesmtp * libgdamm * libgtksourceviewmm * libgtksourceviewmm2 * libnewt * libxnvctrl - with each new nvidia driver it should be checked if new version of NVControl exists (nvcontrol.h) * link-monitor-applet * mc-colorer - patched mc with highlighting provided by colorer, no utf8 support, no new version for long time * metakit * mtpaint * music-applet * mxml * nautilus-actions * nautilus-audio-convert * nautilus-locked-folder * nautilus-open-terminal * nautilus-share * network-ups-tools - needs fixing * opera-static * parano * partimage - probably some bugs exist, not sure * pycups * python-pychm * rawstudio * rlocate - needs update for 2.6.25, but doesn't do its job anyway because LSMs are static since 2.6.24, no patch exists on Internet though it's a well-known issue, I was able to make it build and load, but not do the job (so move to Unsupported and wait for adventurous hacker to make it working) * rlocate-utils - userspace companion for the above * screenlets * sensors-applet * serpentine * superswitcher * system-config-printer * tea * tea-lite - cut down version of the above (note that the patch for libcurl removal is not needed when building in a clean chroot) * ttf-freefont - there were concerns about its quality (mainstream, not package) * ttf-liberation * urlgfe * visitors * vmoviedb * vsftpd-ext - patched vsftpd with more features, useful for users of Cyrillic charsets * webfs * wzdftpd * xcursor-* :: VirtualBox and (make)dependencies :: * virtualbox-* * dev86 * iasl * xalan-c Note: some of these are no longer needed since v1.6 :: will maintain by myself :: * aspell-uk, openoffice-spell-uk, openoffice-uk - I'm Ukrainian ;-) * hddtemp - abandoned, but still maintained by Debian and is very useful, from time to time new patches or db update arrives * pessulus - looks like it is (or will be soon) integrated into Sabayon Also, I'd like to maintain VirtualBox (though I won't be able to update until this weekend) unless there someone that has experience in building that beast wants to grab it. Due to Sun's downloading silliness - I think the source should be stored on our ftp, otherwise it gets downloaded with the huge filename. If you are interested in maintaining some packages - just adopt them. It won't be a problem for me to update those that will be left, if new versions of them are not released frequently, so don't feel it as your duty to grab all of them. That's all. -- Roman Kyrylych (Роман Кирилич)

11 12

[aur-general] Error uploading packages in AUR
by Angel Velásquez 08 Jan '09

08 Jan '09

Hi, I was trying to upload a PKGBUILD into AUR but I got an error, I can't see what is exactly the error (display_errors = Off on the php.ini config, maybe). I just got a blank page and I cannot add a new PKG, can you review?, I will add the tar.gz with the PKGBUILD, thanks -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 Arch Linux Trusted User

4 4

[aur-general] storming in for no reason with crazy ideas
by eliott 07 Jan '09

07 Jan '09

Hello! Long time reader, first time poster (in quite a while). I was bored today, so I read through some of the mailing list archive. Whew! Anyway, I had one of those crazy ideas that is, well, crazy. As this is the internet and I have some free time, allow me to subject you all to my crazy idea! Hooray! *coughs* Why not move towards separating the duties of the current AUR system from the duties of the TU system. I propose making the TUs 'associate arch devs', and having them use the main arch repository system, but in a reduced security/permission role. Something like TUs getting access to community only, like they have now..but using the same dev tools system as the mainline devs, having community just be 'another repo' in the main site interface (just like extra and core). Sure it will take a bit of effort, but it would streamline some processes for sure! Detriments: - TUs wouldn't be as autonomous as they historically have been. This could be good or bad, but putting it in the 'bad' category, because people fear change..and this is a change. - It would take _some amount_ more than 0 value of effort to get the TUs into the mainline dev system. Benefits: - Less tools to support, as the TUs would then use the same dev tools as devs, but with limited permissions. - Process streamline - Clearer path for migration from 'associate dev' to 'dev'. Just flip a bit in the permissions for the devtools, and they can now move packages to extra or core, etc. - Decouple community from the AUR. The AUR would then 'be its own bag'. Leaving end user voting as a guide for moving packages into community (or not..whatever), then packages in community would disappear from the aur when they were adopted into community. - Greater visibility for community repository. It is already included by default, so it should be treated as such... a vital component to the overall arch ecosystem. - Future AUR rewrites or refactoring would be greatly simplified. - The existing TU toolchain and server daemon can be jettisoned into the abyss, to live with other lovecraftian horrors. So there you have it. Talk amongst yourselves. I will be over here..hiding in the shrubbery. o.O

15 40

[aur-general] namcap reports
by Abhishek Dasgupta 01 Jan '09

01 Jan '09

Hi all, I've created a web based report [1] from running namcap on the [community] tree. The design is inspired by lintian reports [2] (I am not much of a designer anyway :) ) There's a script which makes the namcap.log by traversing the community tree, then another python script cooks it up into HTML. Since namcap is quite verbose, I created some tags corresponding to the namcap warnings/errors (like: bad-backups => Backup entries should not have preceeding slashes). The packages have been listed by the namcap tag. Right now there's no view of what tags a particular package has, but I plan to add it sometime in the future. There's also an RSS feed for each tag. [1]: http://abhidg.mine.nu/arch/namcap-reports [2]: http://lintian.debian.org -- Abhishek Dasgupta <http://abhidg.mine.nu> GPG 67972DOF pgp.mit.edu

7 13

[aur-general] the future of empathy, libtelepathy..
by stefan-husmann＠t-online.de 31 Dec '08

31 Dec '08

Hello, there has been a thread on aur-general in October 2008 about this issue, but the situation is not satisfying IMHO: We have a package of empathe in AUR _and_ in [testing].Both are or were orphaned, and the package in AUR was taken by a user and upgraded to version 2.25. I was chatting with him, and we reverted the change and uploaded a release 2.25 as empathy-devel. I think this should not happen again. What is the decision? Will empathe go to [extra] soon? If it is desired to keep the version in AUR, I suggest a developer should take it and keep it until it reaches [extra]. Or it should be removed. Thoughts? Regards Stefan

3 2

[aur-general] package removal
by Grigorios Bouzakis 31 Dec '08

31 Dec '08

liblo is already in extra: http://aur.archlinux.org/packages.php?ID=1710 also theres the packages brain0 uploaded in testing yesterdau, as well as libnl which is in extra & iw in community: http://archlinux.org/pipermail/arch-general/2008-December/003127.html Greg

4 3

[aur-general] Out for holidays
by Kessia 'even' Pinheiro 30 Dec '08

30 Dec '08

Hi all, I'll be out for the holidays until Jan 5. Happy new year! -- Kessia Pinheiro Student at Computer Science - UFBa Trainee with ProCaTI founds - DiSup/CPD - UFBa Arch Linux Trusted User Linux Counter User #389695 - [http://counter.li.org] http://even.archlinux-br.org --- X Fórum Internacional Software Livre - fisl10 24 a 27 de junho de 2009 PUCRS - Porto Alegre - Brasil

1 0

[aur-general] disowning a few packages
by M. Rawash 30 Dec '08

30 Dec '08

I'm going to disown a few packages that I'm no longer interested in maintaining. most of them are up-to-date and work properly, so you don't have to do any work right away, here's the list: - empathy - libtelepathy - telepathy-mission-control - desktop-data-model - hippo-canvas - online-desktop - bigboard - gadmin-httpd - gnac - perl-data-dumper - perl-weather-com - perl-html-calendarmonthsimple - mm ok, i lied about the "few" bit :P I'll reclaim some of these packages if none adopted them within a week, but expect their quality to drop significantly since i won't be testing any of them beyond successful builds..

3 3

[aur-general] Renaming a package?
by joyfulgirl＠archlinux.us 30 Dec '08

30 Dec '08

Hello! I just adopted the dillo2-cvs package; however, dillo development has recently changed to mercurial. I have a working PKGBUILD for this new -hg package, but was wondering whether there was any way to just change the name of the original package rather than create a new one. If so, if there's a TU who could rename it to dillo-hg I'd appreciate it. If not, would a TU mind deleting the dillo2-cvs package? Thanks a lot! Ivy -- If I Ever Become An Evil Villainess... 104. My undercover agents will not have tattoos identifying them as members of my organization, nor will they be required to wear military boots or adhere to any other dress codes.

2 1

[aur-general] Looking for a KDE maintainer
by Pierre Schmitz 28 Dec '08

28 Dec '08

Hi TUs, a long time ago I announced that I was looking for some help maintaining KDE: [1]. Finally I worte to aur-general to get some feedback form you, the Trusted Users. To reduce my workload and make the KDE packages even better I am looking for someone to support me. Just to make things clear: I don't need someone to just build or upload packages. All this including simple pkgver bumping and md5sums update is already automated: [4]. With a major update every 6 and a minor update every month this shouldn't be handeld by only one single person (that's me) anymore. So, what would be your tasks? * Prepare and test KDE 4.2 (see [2]) * add and maintain new (and old) dependencies * check and fix existent dependencies * fix bugs which are reported by users * prepare, test and finally implement splitted packages A simple Todo list with some notes about the unstable repo and schedule can be found at [3] I am looking for someone, who * is a TU and therefore has packaging experience * likes and uses KDE (of course) * is able to work on his own (means, don't ask me what to do next for every little step ;-)) * should have enough time to work mainly on KDE * likes to work in a small team * is reliable Don't take this list too serious. Even if you don't match all of this items, just write me if you are interested. If you have further questions you should answer this mail and send it to aur-general. Greetings, Pierre PS: And don't worry. Even if I don't find someone to help me with KDE, it wouldn't mean the end of the world. I'll still try to provide you the best KDE packages for Arch. :-) [1] http://archlinux.org/pipermail/arch-dev-public/2008-November/009126.html [2] http://archlinux.org/pipermail/arch-dev-public/2008-December/009538.html [3] http://wiki.archlinux.org/index.php/DeveloperWiki:KDE [4] http://git.archlinux.de/build-scripts/tree/kde -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

1 0