July 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] pkgrel updates
by Allan McRae 24 Sep '08

24 Sep '08

Hi TUs, I was looking at the pkg_diff page in order to build some packages for community64 and noticed something I found a bit worrying and after much thought, I decided to bring it up. It could all be entirely legitimate and if so I apologize. A large portion of recent updates (~2/3) are only bumped in the pkgrel, i.e. no pkgver update. While I realize some of these will be legitimate rebuilds, it is a bit of a concern to me given nothing major has moved from the testing repo and I don't recognize the packages from bug reports. I haven't looked at whose packages these are (and at this stage, I honestly don't care), but it seems a reminder about quality control on the packaging front is needed. I don't mean to sound overly grumpy, but this costs users and the mirrors bandwidth as well as giving the few x86_64 using TUs more work. I really don't like writing emails like this. We can all make good packages or else we wouldn't be TUs. So please double check your packages before uploading them. Regards, Allan

9 15

[aur-general] orphaning some packages in [community]
by Pierre Schmitz 22 Aug '08

22 Aug '08

Hi TUs, I would like to orphan some packages I don't use anymore. If you want to adopt them just drop a line or contact me. The packages are: gamin kdesvn knetworkmanager php-eaccelerator php-xcache php-xdebug qtcurve-gtk1 (there will be no new version; maybe a candidate for unsupported) solarwolf Greetings, Pierre -- 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

4 7

[aur-general] Trusted User Bylaws update
by Hugo Doria 11 Aug '08

11 Aug '08

Should we update the Trusted User Bylaws page [1]? There are some mentions to the old "tur-users", for example. I can do the update if you guys think that it is needed. Thanks. [1] http://dev.archlinux.org/~simo/TUbylaws.html -- Hugo Doria http://hdoria.archlinux-br.org

10 22

[aur-general] TU Application.
by Daenyth Blank 03 Aug '08

03 Aug '08

Hey all! I'm applying for a TU position, hopefully you'll consider me. My sponsor is Anders Bergh (anders). I go by the name Daenyth, and I've been using Linux for several years. I started on Slackware and switched to Arch about a year and a half ago. I'm 20, and I work as a sysadmin/tech support/office monkey at an ESL school in Boston. During my free time, I love listening to tons of music, chilling on IRC, and playing video games, among other things. I especially love playing around with pretty much anything Linux related. Right now I only maintain a handful of packages in the AUR[1], but I plan to expand what I have. One of my goals is to package lots of new software for Arch. I want Arch to be _the_ distro people talk about for package selection. I love the way Arch is designed, and the KISS philosophy, and I want to give back to the community that's been so wonderful to me. Currently my most popular package is "pkgtools". It's a bundle of things that I've written relating to arch packages. After collaborating with another author, I'll be including spec2arch, which is a tool aimed at helping developers provide basic PKGBUILD files from rpm .spec files. I also maintain a few Perl related packages, and hope to increase their number. I am one of the co-maintainers for the arch-games project[2]. For those who don't know, it's a user repo to provide binary packages for all the games in AUR, so that our users can more easily install them (many have long compile times or are otherwise annoying). Thanks for your consideration, --Daenyth [1] - http://aur.archlinux.org/packages.php?K=daenyth&SeB=m [2] - http://arch-games.twilightlair.net/wiki/index.php/Main_Page

7 9

[aur-general] prepare on KDE 4.1 move to [extra]
by Pierre Schmitz 02 Aug '08

02 Aug '08

Hi TU, KDE 4.1 will be moved to [extra] tonight or tomorrow. If you maintain packages in [community] which depend on KDE3 you might want to read this: * Look for a new upstream release which can be used with KDE 4. * If there is no new version change deps to kdelibs3 and try recompiling. * try sourcing qt3.sh and kde3.sh from /etc/profile.d/ * If configure fails try adding --without-arts. * Don't trust namcap saying there would be no dependency to kdelibs3. :-) * If the build still fails with some undefind references, try biulding in a clean environment without kdelibs-4 * If nothing helps your package might depend on stuff from kdebase or other KDE packages. You might think about removing it from [community] then. Pierre -- 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

7 9

[aur-general] Orphaning request
by rabyte 02 Aug '08

02 Aug '08

I'd hereby like to request the orphaning of all packages uploaded by funkyou. There's two packages flagged as outdated, He doesn't respond to comments and I tried to contact him via Jabber to no avail. -- Follow The White Rabyte . . .

4 4

[aur-general] Problem with community repo (x86_64)
by Eric Belanger 31 Jul '08

31 Jul '08

The community repo (x86_64) is no longer updating. From the logs: Traceback (most recent call last): File "/home/aur/aur/tupkg/update/tupkgupdate64", line 450, in <module> pkgname, ver = infoFromPackageFile(c_file) File "/home/aur/aur/tupkg/update/tupkgupdate64", line 218, in infoFromPackageFile raise Exception("Non-standard filename") Exception: Non-standard filename I don't know what might've caused that. There also now another error message: nice: /home/aur/run-tupkgupdate64: No such file or directory which is also in the logs for i686: nice: /home/aur/run-tupkgupdate: No such file or directory Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

4 5

[aur-general] Problem with compizconfig-backend-kconfig and KDE3
by DaNiMoTh 30 Jul '08

30 Jul '08

Hello to all, I am trying to compile this backend for ccsm with kde3 enabled, because with kde4 it seems don't work. So, I add to depends kdelibs3, qt3, added --without-arts, added source /etc/profile.d/{kde3,qt3}.sh, but in configure I read: checking for Qt... libraries /opt/qt/lib, headers /opt/qt/include using -mt checking for moc... /opt/qt/bin/moc checking for uic... /opt/qt/bin/uic checking whether uic supports -L ... yes checking whether uic supports -nounload ... yes checking if Qt needs -ljpeg... no checking for rpath... yes checking for KDE... libraries /opt/kde/lib, headers /usr/include What?!?! headers in /usr/include? Oh, no... and I can't compile it successful, because I have error like In file included from /usr/include/QtCore/qbasicatomic.h:209, from /usr/include/QtCore/qatomic.h:48, from /usr/include/QtCore/qvariant.h:47, from /usr/include/QtCore/QVariant:1, from /usr/include/kconfig.h:32, from kconfig_backend.cpp:24: /usr/include/QtCore/qatomic_arch.h:84:4: error: #error "Qt has not been ported to this architecture" kconfig_backend.cpp:29:23: error: kinstance.h: No such file or directory kconfig_backend.cpp:31:18: error: kipc.h: No such file or directory kconfig_backend.cpp:33:24: error: dcopclient.h: No such file or directory Also, the error that qt has not been ported to $CARCH (that is i686 in my case) is ridiculous ^^. I think the problem is that it use headers from /usr/include (kde4) that aren't like headers in kde3. Am I wrong in something? Thanks

2 2

Re: [aur-general] [arch-dev-public] Please stop the install message insanity
by bardo 30 Jul '08

30 Jul '08

On Mon, Jul 21, 2008 at 11:23 PM, Paul Mattal <paul(a)mattal.com> wrote: > Thanks for pointing that out. I changed this to a post_install in dnsmasq > 2.43-2, not post_upgrade, since this one you have to read the first time and > not thereafter. This is a problem I've been thinking about for a while. It happens far too often that a message needs to be shown to the user only the first time a package gets upgraded because something important has changed. Without the need to modify anything we could use the parameters passed to post_upgrade: if the old version is affected by the change (can we use anything like vercmp in install files?) then the message will be shown, otherwise it won't. It's an extra effort on our side, but it helps a lot in cleaning up package installation output. Of course we'll also need to pay attention to when it's time to remove the message. I have other possible solutions in mind, but they all require changes to pacman or arch, and by far they aren't KISS. Any additional proposal or comment? Corrado

5 4