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

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

09 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] 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

Re: [aur-general] Eclipse plugin packaging standardization proposal
by bardo 08 Dec '08

08 Dec '08

First of all, nobody really wrote /against/ this proposal and nobody said there's no need for a standard, so I suppose everyone's ok with it. If this is not the case, just speak up, otherwise I'll wait for a week from the last comment and then proceed to wikify it. On Thu, Nov 20, 2008 at 5:37 PM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > / syntax is actually for replacement. The syntax above says "replace > with nothing". The # and % syntax is for deletion (matching from the > front or back of the word, respectively). I doubt there's any real > difference as far as performance goes. I'll keep the slash syntax, then, it's also simpler to customize. Thanks fo the great explanation :) >> (2) you could use the jar command to extract a jar file instead of >> unzip. that's what it's made for. it's in the jdk which is a dependancy >> of eclipse. so you can expect user to have jar command and jdk package >> (jar is also in java-gcj-compat) I modified the PKGBUILD to use jar instead of unzip, thanks. However I had to do some other changes. As I pointed out in the post: «I was noticed that I can directly use jar, which the user already has since it's part of the JRE. This is great, since it spares a makedepend! However, jar can't extract to directories other than the current one: this means that, after the directory creation, it's necessary to cd before extracting. Since there were many occurrences of the destination path I decided to use a custom variable even though somebody might not like it, because there's a great improvement in readability.» Quick link reference: http://blog.bardland.org/2008/11/20/arch-linux-eclipse-plug-in-packaging-a-… Corrado

2 1

[aur-general] pkgstats and community - attempt 2
by Allan McRae 03 Dec '08

03 Dec '08

This whole thing has got a bit out of hand... All I wanted to do was organize a meeting for TUs to discuss the results of the pkgstats script. And now I arrive back to ~70 email with back and forward about how things should be. I am actually quite disappointed with some of the responses there. I'll put this out there first before I carry on with this email. I am a dev. I am a TU. I do not care about titles and my only aim here is to serve the Arch community better. I am not taking a dev or TU point of view here at all. I may not have been around as long as others but I know the history of the community repo and the AUR voting system. That being said, the pkgstats results point to a problem in the [community] repo. I suggested we should discuss this on IRC at some stage. ~70 emails later, that option seems to have been forgotten. So here is the issue: * There is no point taking up server space and bandwidth with packages that nobody or very, very few people use. * pkgstats points to a few hundred packages that fall into the not very used category in both [extra] and [community]. The devs are discussing what to with packages in [extra]. Note that does not necessarily mean those packages are automatically dropped to the AUR as that make no sense for some packages. I.e. compromise is being made. Please read that again. Compromise... So we need to think about what the purpose of the [community] repo is. It is obviously to supplement [core] and [extra]. Packages in [core] are the base of a system, packages in [extra] define Arch as a distro and are widely used by its users, packages in [community] do what? So lets start there. What should the [community] repo be doing? What is its purpose? There is no point discussing anything else until that is well defined. All responses must start with "The [community] repo is ..." Allan

6 5

[aur-general] Current TUs
by Aaron Griffin 02 Dec '08

02 Dec '08

Would someone mind telling me which people on this list are no longer TUs? This is the CVS passwd file... whoops http://dev.archlinux.org/~aaron/tu_names

8 16

[aur-general] TU Meeting
by Allan McRae 01 Dec '08

01 Dec '08

Hi TU's, I would like to organize a TU meeting on IRC to discuss the results of the pkgstats script and the direction for the [community] repo. I am probably the person with the worst time zone issues so I am happy to take a very late night time slot. I guess a weekend would be best to deal with the multiple time zones. So how are peoples availabilities (provide times/timezones): 15/16 November 22/23 November 29/30 November It would be good if someone (who isn't me...) sets up a temporary wiki page to handle this. Allan

15 37

[aur-general] mailing list archives not showing up
by Abhishek Dasgupta 01 Dec '08

01 Dec '08

The mailing list archives at http://archlinux.org/pipermail/* are returning a 404. -- Abhishek

2 1

[aur-general] My thoughts on the [Community] policy discussion
by Drew Frank 01 Dec '08

01 Dec '08

Hi all, First off, I'd like to introduce myself so you can weigh my observations appropriately. My name is Drew. I'm a casual Arch user, and until recently my only experience with the AUR was using yaourt to download and install packages (and pacman to install from [Community], but I didn't really understand what that meant). Recently I've been following the discussion on this list regarding how to determine which packages belong in [Community]. Despite my lack of Arch/AUR mastery, I'd like to offer my two cents. I claim: 1. If it were possible to know with certainty that a given package were not in use by anybody (or only by a very small number of people), there would be overwhelming agreement that the package does not belong in [Community]. 2. Both vote counts and pkgstats statistics, as they are currently generated, are flawed metrics of package popularity. 3. Nearly all of the controversy over various [Community] admission policies stems from the fact that different people place different levels of trust in the information provided by votes and pkgstats. I feel like I'm a bit late to the party, but unless there is a critical need to act now my recommendation would be to first set up a system whereby accurate usage statistics are obtained and then proceed to develop policy based on accurate, interpretable statistics. Drew

2 2

[aur-general] huge differencies between i686 and x86_64 community repo
by Jaroslav Lichtblau 01 Dec '08

01 Dec '08

Hi fellow TUs! A quick look on the nice page showing differencies between our i686 and x86_64 repos [1], shows a pretty impresive list in our [community] repository. Could we please work on this a bit and keep it synchronised! IMHO even if some of us don't have access to both architectures, we can talk to someone who does and builds it for us. Have a nice day Jaroslav [1] http://www.archlinux.de/?page=ArchitectureDifferences -- Die Liebe ist der einzige Weg, auf dem selbst die Dummen zu einer gewissen Größe gelangen. -- Honoré de Balzac

4 3

Re: [aur-general] TU Meeting
by stefan-husmann＠t-online.de 01 Dec '08

01 Dec '08

-----Original Message----- > Date: Sun, 30 Nov 2008 00:02:22 +0100 > Subject: Re: [aur-general] TU Meeting > From: Allan McRae <allan(a)archlinux.org> > To: "Discussion about the Arch User Repository (AUR)" > <aur-general(a)archlinux.org> > Hey all, > > Well the meeting went ahead. Not a great turn out.... > > Here is the log: > http://dev.archlinux.org/~allan/tu-meeting-2008-11-29.txt > > Allan > > Hello, maybe it is due to my low irc experiences but I believes I was in the correct channel at nine pm. yesterday and ten yesterday , but nothing happened. Stefan

2 1