Re: [aur-general] TU Resignation
On 31 August 2011 09:11, Loui Chang wrote: > Hello everyone! > > I haven't been very involved with the AUR for a long while, and I don't > really see that changing much. Since I only have a few packages I think > it's time for me to resign as a TU. I may still throw a few patches > around if I find the time. I've asked Lukas Fleischer to assume my duty > of adding new TUs. > > It was a pleasure to work with you folks. See you around! > > My former packages which I've recently disowned: > esmtp > libesmtp (dependency of balsa, collectd, and esmtp) > mhwaveedit > oldstand-font > tig > > Cheers. > > Hey Loui, thanks a lot, and best wishes for the future! Greg
Re: [aur-general] Moving packages to Community
2011/2/6 Ángel Velásquez : > 2011/2/5 Gergely Imreh : >> Hi, >> >> Recently a couple of my packages have been moved to Community but the >> process feels a little uneasy to me. > > First of all remove that "my" before packages, that's a problem, some > maintainers thinks that they're owners of the PKGBUILD, and isn't like > this, all PKGBUILDS belongs to the Arch Linux project, and you > contribute with them if you want, isn't an obligation. There are way too many comments to reply them all, but I do want to take an exception on this one. When I say "my", that is "packages that I have been maintaining". I'm not "owning" them, of course. There's a sense they do "belong" to someone: you don't delete or orphan a package on anyone's request until they made sufficient effort to contact the maintainer and fix any issues. The original issue I wanted to bring up: if delete/orphan needs some form of cooperation, then why moving does not? >> My impression is that AUR is treated as a "second class" source of >> packages compared to the official repos. Not surprising, of course, so >> many packages have problems. This is also underlined by the fact that >> yaourt and other AUR managers are not allowed in the official repos, >> as "not to give the impression that AUR is official" (paraphrasing >> what I've read before). > > Not at all, many of the packages on official repos belongs to AUR in > sometime, AUR is a playground, where you can find scripts for install > (PKGBUILD) experimental software. > >> >> If there is indeed this divide, it feels more than little weird, that >> popular packages are just taken in to Community without even asking >> the current managers. It gives me the message that "AUR has no value, >> except when we say it has, at which time thanks for your work but now >> bugger off". I beg your pardon, if it comes through too harsh. I >> wouldn't have objected to have those packages moved. I, however, >> object to unilateral decisions. >> >> My proposition is: could it be a policy to check with the maintainer >> first before initiating a move? If someone wants to keep a package >> then they should be able to, especially since they could not have been >> doing such a a bad job if their package has become popular. > > Absolutely no, as I said PKGBUILD doesn't belongs to anybody, just the > project, if a Dev or TU take one of them and move it to any official > repo is good to you, that means that the software that you were > packaging by hand it will be on binary 'cause is pretty stable and not > experimental at all. I beg your pardon, but I don't think this is at all about what is "good" for me (and by "me" I mean maintainers). If it was really about the good of the maintainer, then instead of just moving, the TUs and Devs would offer continued maintaining rights in Community for the - apparently successful - care taker. I know that this is technically not feasible at the moment. I believe, though, that it would be the The Right Thing (and saying this as part of that "Arch Linux Community", whose good you want to above all), but that's for another time, I'm not pushing that agenda here at all. > I understand your point about, I'm giving my time and receive nothing, > well dude, you should give without expecting anything, and you will be > more happier. I also understand the point about TU/Devs didn't said > anything to the PKGBUILD that you were maintaining will become a > package, well, maybe a little courtesy from the TU or Dev who did this > is good, but he doesn't have to ask your permission, remember you > contribute with the project giving your effort on those PKGBUILD but > that doesn't imply that you are owner of those PKGBUILD. > > Thanks for contributing with the Arch Linux project, And I hope now > you will contribute without hoping regalies or something. > I'm sorry again, but you don't seem to get it: I don't want anything more in return than what you expect from me -common courtesy. As for the comment that only very few people write back on the TUs notes of moving: I didn't either. Why? It's all settled already, what's there more to say? I don't think the number of replies have any relation to the number of people who cared. I'm very happy to contribute. I'm very happy to spend time fixing packages. I'm always checking whether there are orphan packages to fix up. I don't apply to be a TU because I never know how much time I have and don't want to do a shabby job. But this does not mean we all cannot work together. Everybody gets different thing from Arch, but it's arguably a fact that what's good for me, good for you too, and vice versa. Cheers, Greg
[aur-general] Moving packages to Community
Hi, Recently a couple of my packages have been moved to Community but the process feels a little uneasy to me. My impression is that AUR is treated as a "second class" source of packages compared to the official repos. Not surprising, of course, so many packages have problems. This is also underlined by the fact that yaourt and other AUR managers are not allowed in the official repos, as "not to give the impression that AUR is official" (paraphrasing what I've read before). If there is indeed this divide, it feels more than little weird, that popular packages are just taken in to Community without even asking the current managers. It gives me the message that "AUR has no value, except when we say it has, at which time thanks for your work but now bugger off". I beg your pardon, if it comes through too harsh. I wouldn't have objected to have those packages moved. I, however, object to unilateral decisions. My proposition is: could it be a policy to check with the maintainer first before initiating a move? If someone wants to keep a package then they should be able to, especially since they could not have been doing such a a bad job if their package has become popular. Cheers, Greg
[aur-general] delete request
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
Re: [aur-general] Changing AUR development infrastructure.
I know I'm an outsider (no TU, only did a bit of AUR developement before), so I just have a question: On 17 January 2011 09:19, Loui Chang wrote: > Here are the reasons I have for moving the repo: > * We don't need to create superfluous shell accounts on gerolde to > for push access to those repos. Those accounts already exist on > sigurd. If the issue is having to create extra shell accounts, could it be eliminated using gitolite/gitosis? That would allow more fine-grained control over the permissions of the different projects (which would definitely come up if there are more projects hosted on the same server). E.g. push privileges could be granted to people without TU status when needed, or TUs can be kept off projects they are not taking part in. Just a thought. Cheers, Greg
Re: [aur-general] move acerhk to [unsupported]?
On 11 November 2010 18:54, Christopher Brannon wrote: > It won't build against kernel 2.6.36. There hasn't been a release in a > long time. According to the homepage, the upstream author is no longer > actively supporting it. IMHO, it should move. I could make more of an > effort to patch it if someone is *really* interested. > > -- Chris > Doesn't acer-wmi solve the same problem? http://www.kernel.org/doc/Documentation/laptops/acer-wmi.txt I have an acer laptop at home working just fine (travelmate 4500), and I don't think I have ever used acerhk. Cheers, Greg
Re: [aur-general] aur website default ssl
On 28 October 2010 14:59, Justin Davis wrote: > On Wed, Oct 27, 2010 at 5:14 AM, Pierre Schmitz wrote: >> On Wed, 27 Oct 2010 11:40:19 +0300, Ionuț Bîru >> wrote: > >>> As i said earlier in a reply to Loui, maybe we can do it >>> better.Having https only for login and then redirecting to http is >>> like not having it at all. > > Ionut, > This is a ridiculous claim. Maybe we should tell that to amazon, > newegg, and oh I don't know... 99% of websites on the planet? Most > sites use https only for logins and transactions. Publicly available > information like aur comments, aur packages, images, etc don't really > need encryption. Just about everything sent to/from the AUR is not > sensitive information. Except login passwords. I would be pissed off > if amazon had the same point of view. What if amazon decided that > their https for logins and credit cards was the same as not having it > at all and removed it? As the discussion gets more technical, it is good to see what the people who actually know all about these issues have to say. I think it is very education (well, for me at least) to read Firesheep's author's comment on the people's reactions, and how there are many bad solutions that look like good ones. Eg. the "Why is it hard to stay safe - Forced SSL/HTTPS for posting of Login/Password credentials only" section. http://codebutler.com/firesheep-a-day-later Re: Amazon and others, just because the big guys do it, does not mean they do it right. >> Simply using https for all connections is the easiest and best solution >> imho. Everything in between is either insecure or inconvenient for the >> users. And I also don't see the need for it. Every sane http client >> should handle a http redirect and https. If it does not it's just a bug >> in the client. Of course it is unfortunate that this wasn't tested by >> the clyde author before. > > Pierre, > How is sending publicly available information unencrypted insecure? It > does not warrant a need for additional security in the first place. If > someone wants to see what comments you post on a package they go look > at the package's page. They don't have to sniff your traffic. I am > secure in my AUR traffic's triviality. Please correct me if I'm wrong, it's not just about sniffing, it's about hijacking your session. Eg. one could record your logging in, then come back later, and orphan your packages (a "better" bad case), or update it with malicious code (a worse one) while it looks like it was you Not saying one would do that, but if we are throwing around hypotheticals... Cheers, Greg
Re: [aur-general] [arch-dev-public] Python-3.x transition with python-2.7 update
On 6 July 2010 20:09, Ng Oon-Ee wrote: > On Tue, 2010-07-06 at 10:51 +0200, Lukáš Jirkovský wrote: >> On 6 July 2010 10:19, Isaac Dupree wrote: >> > On 07/06/10 01:57, Lukáš Jirkovský wrote: >> >> >> >> Hello Allan, >> >> I know that I'm just a regular user but I'd like to express my opinion >> >> too. I think the transition should be done when most modules and >> >> applications support Python 3. I'd not be surprised if the transition >> >> of majority of modules would take several years. By that time there >> >> may be a way how to do a dual rename. >> > >> > Hi Lukas, >> > Can you present a technical reason against doing the renaming now? Because >> > as far as I can see, Allan has worked out the kinks and it will actually >> > not >> > harm you as a regular user at all... >> > >> > (unless you write personal scripts in python that you want to work with >> > #!something on multiple distros? (then you probably want to run them in >> > python version 2) .. I'm not sure I can think of an easy way to do that; >> > maybe for each distro you use you could put a symlink in >> > /usr/local/bin/python2 for example.) >> > >> > -Isaac >> > >> >> Hi Isaac, >> I don't write Python scripts but yeah, I think this is a real problem. >> The other problem is that there are not many users of python 3 out >> there. >> >> In a more subjective way I think whenever something is set as default >> it should be the one which has most users (in both terms of people and >> software). >> >> Lukas > > As another user (who doesn't write Python), I'd state that 'majority > usage' is a pretty poor guideline for users of a Linux distro, and a > relatively small one at that. > > I'm all for the option which reduces workload on the packagers. Of > course if things break big-time then it may be a problem, but that's > what [testing] is for, and those of us using it should know what to do > if/when breakage occurs. > > Some more background info for those who are not that familiar why the Python 2 vs. 3 is such a big problem (there seem to plenty of people, and sorry for the ones who already know this inside out): http://wiki.python.org/moin/Python2orPython3 >From that page: "Popular modules that don't yet support Python 3 include Twisted (for networking and a bunch of other stuff), gevent (like Twisted but different), Django and Pylons (for building websites), PyGTK and PySide (for making GUIs), py2exe (for packaging your application for Windows users), PIL (for processing images), numpy (for number crunching)..." Thus I would mind a rebuild less, than losing my daily numpy/scipy/PyGTK... Arch is not in a position to force these packages to update to Python 3, and such I don't think it's a good idea to bump the default version up to 3. On the other hand, there are plenty of people who are experienced in code fixes, so maybe there would be some who would join the porting effort for those packages that they use on a regular basis. This could accelerate the transition. Cheers, Greg
Re: [aur-general] xz compression for AUR
Go here, and follow instructions on the bottom of the page: http://mailman.archlinux.org/mailman/listinfo/aur-general Greg On 1 April 2010 08:33, Bingjun Yin wrote: > > how to unsubscribe this mailing list ??? >
Re: [aur-general] unicap splitted in 3 packages
2010/2/8 Jordi Cerdan : > Hi, > > I currently maintain unicap package in AUR. This package has been > splitted in 3 new packages ( http://unicap-imaging.org/blog/ ): > libunicap, libunicapgtk and libucil. > > I think we have 2 solutions there, but I don't know which one is more > "elegant": > > - create 3 new packages and delete unicap > - rename unicap to libunicap and create 2 new packages > > Which one should we choose? Or use the (now not very new) split package design? AUR does not support it too well, but that's just cosmetic problem. I think that's not a problem with yaourt. Cheers, Greg
Re: [aur-general] Thanks to Ghost1227 and wonder
2010/1/19 Allan McRae : > Hi all, > > We should give a big cheer to Daniel (Ghost1227) and Ionut (wonder) for all > the work they have done on the [community] bug tracker recently. Over the > last week, the number of bugs has shrunk from ~120 to 17. That is a massive > effort! > > Thanks, > Allan > > Awesome, cheers guys, great job! :D Greg
Re: [aur-general] Status of the Chromium/Chrome packages on AUR
On 2009/12/9 下午 02:19, Pierre Schmitz wrote: Am Dienstag 08 Dezember 2009 22:00:04 schrieb Ionut Biru: i don't care how they update. i just don't want to see another n packages for the same thing just because the maintainer of -dev didn't updated in the second two after a new version was released. Doesn't anybody build a "real" package out of chromium yet? I might have a look otherwise. I think it's stable/usable enough to be put in a repo. (I know they don't release source tarballs, but it should be no really big deal to create them) The chormium-browser-svn works pretty fine for me these days (rebuilding the current one right now). Haven't tried the others, though. I can see, though, how people might not want to be this much on the bleeding edge... Cheers, Greg
Re: [aur-general] Unable to submit package
2009/11/29 Allan McRae : > edogawaconan wrote: >> >> After 'cleaning up' a package I'm maintaining (nginx-unstable), and >> verifying it can be built and works fine, AUR rejected the package. >> Reverting to old version (with updated version) works fine. >> >> error message: >> "Missing build function in PKGBUILD." >> >> package: >> http://aur.archlinux.org/packages.php?ID=18036 >> >> Problematic version attached. > > Attachments do not work on this list, but the error message is quite clear. > Does your PKGBUILD have a build() function? The error message is simple, but the meaning is not that straightforward: AUR can miss the build function when makepkg has no problem, e.g. in case of a bug in bash-type variable replacements I'm not saying that it is the case for this PKGBUILD, but wouldn't be the first bug like this, as much as I remember. Do .gz attachments work on this list? If they do, please attach the compressed faulty PKGBUILD. Cheers, Greg
Re: [aur-general] Install in a click from AUR webpages
2009/11/2 Giorgio :
> Here I little hack I coded to install packages directly from the AUR frontend.
>
> Needed:
> - yaourt
> - Firefox with greasemonkey (https://addons.mozilla.org/addon/748) or
> any greasemonkey-scripts accepting browser.
>
> Steps:
>
> 1. Create a small bash script called aur_opener.sh containing the
> following code:
>
> #!/usr/bin/env bash
> gnome-terminal -x /usr/bin/yaourt -S ${1//aur:\/\//}
>
> 2. Make the script executable
>
> 3. Open about:config in Firefox and add the following variable:
>
> network.protocol-handler.app.aur
>
> with value:
>
> path to aur_opener.sh
>
> >From now on, every time you click on a link like the following:
> aur://pkgname yaourt will start.
>
> 4. Install the greasemonkey script AURlizer
> (http://userscripts.org/scripts/show/61015).
>
> 5. Visit any page on the AUR db. A new symbol [↓] will appear next to
> the package name. Click on it and install!
>
> Enjoy.
> PS
> Obviously, it would be very easy to implement this directly into
> yaourt / the AUR db.
>
>
> --
> Giorgio F. Gilestro
> http://www.gilestro.tk
> +1 (608) 301 5864
> pgp id: 1024D/DE8D92BF
>
Interesting work, cheers! Probably this setup could be done as a
PKGBUILD (or at least most of it). Do you want to give that a try?
Greg
Re: [aur-general] AurJson - orphan packages
2009/9/14 Pierre Chapuis :
> Le Sun, 13 Sep 2009 18:23:02 +0200,
> Pierre Chapuis a écrit :
>
>> Hi,
>>
>> I was wondering if there's a way to know if a package is orphan using the
>> AurJson interface.
>>
>> If that's not the case, I think I will find a feature request for something
>> like:
>>
>> "Uploader":"pseudonym"
>>
>> in "info/results", with "pseudonym" set as "orphan" if the package is orphan
>> (I hope nobody has taken the pseudonym "orphan" on AUR...).
>>
>> Does that look fine to you?
>
> Of course I meant: "I will file a feature request"...
>
> Another possibility might be to add a boolean like OutOfDate, but the
> solution I proposed would also enable scripts to find the uploader of a
> package, which might be useful later. As far as I'm concerned, I don't really
> care since I only want to know if the package is orphan...
I'm CC-ing this to the aur-dev, as I think it belongs there.
The following patch adds the Orphan field to the aurjson output. For
username we would need to hit the database once more (maybe, have to
think more SQL for that), but the Orphan-ness is quite straightforward
to evaluate. So let's just do that first.
This patch, however, might clash with one patch I sent in a few days
ago [1], since that one hasn't been applied to the repo, yet. Anyway,
neither of those are hard to see where they should go...
Any comments?
Cheers,
Greg
[1] http://mailman.archlinux.org/pipermail/aur-dev/2009-September/000868.html
>From 2aba57717cac80f643886b25900c8d7ad14e9198 Mon Sep 17 00:00:00 2001
From: Gergely Imreh
Date: Mon, 14 Sep 2009 22:28:58 +0800
Subject: [PATCH] aurjson: add "Orphan" boolean field to JSON output
Signed-off-by: Gergely Imreh
---
web/lib/aurjson.class.php |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/web/lib/aurjson.class.php b/web/lib/aurjson.class.php
index 29fc424..85a3b89 100644
--- a/web/lib/aurjson.class.php
+++ b/web/lib/aurjson.class.php
@@ -19,8 +19,9 @@ include_once("aur.inc");
class AurJSON {
private $dbh = false;
private $exposed_methods = array('search','info');
-private $fields = array('ID','Name','Version','CategoryID','Description',
-'LocationID', 'URL','URLPath','License','NumVotes','OutOfDate');
+private $fields = array('ID','Name','Version','MaintainerUID','CategoryID',
+'Description','LocationID', 'URL','URLPath','License','NumVotes',
+'OutOfDate');
/**
* Handles post data, and routes the request.
@@ -139,6 +140,8 @@ class AurJSON {
if ( $result && (mysql_num_rows($result) > 0) ) {
$row = mysql_fetch_assoc($result);
mysql_free_result($result);
+$row['Orphan'] = ($row['MaintainerUID'] == "0" ? "1" : "0");
+unset($row['MaintainerUID']);
return $this->json_results('info', $row);
}
else {
--
1.6.4.2
Re: [aur-general] Chromium builds and runs on Pentium-m, but not on Desktop (Athlon 2800+)
2009/8/26 Xavier : > On Tue, Aug 25, 2009 at 9:45 PM, Bernard Mentink wrote: >> >> >> Small point, can you specify the steps on how to edit the code and re-build >> the package? I take it that there is another way to download/edit/build >> rather than >> the automated "makepkg" >> > > The problem is not makepkg itself, it's the PKGBUILDs who use > pre-compiled tarballs instead of compiling source code. > But maybe there is no way to do that for chromium, or it is overly > complex? I don't know, but I couldn't find any PKGBUILD using the > source. I was working on such a PKGBUILD, but run out of disk space while compiling... Gave up for a while because didn't have access to anything with more space, but now I have an external drive, might try it again...
Re: [aur-general] arch=('i686')
2009/8/5 Lucas Salies Brum : > How do I know that a package will work in an architecture different from mine? > Read the documents that the original coders wrote to see whether there's any indication that it won't. Try to test it if you can. Ask people with other platforms to test it. (I think usually there's very good feedback on AUR for such things, sometimes even advice how to fix it when it does not work). If you are really hardcore, have a virtual machine set up with Arch of the other architecture, so you can test it directly. But that's mostly overkill... Cheers, Greg
Re: [aur-general] Recommended Encoding for PKGBUILDS?
2009/7/2 Xavier : > On Thu, Jul 2, 2009 at 4:52 PM, wrote: >> >> On a somewhat related note, I wrote a patch today, and firefox thinks >> it's a binary or something and tries to download it instead of showing >> me the text: http://aur.archlinux.org/packages/acweight/acweight/ >> >> What did I do wrong there? >> The patch was created using: >> diff -u acweight/Makefile Makefile > destdircp.patch >> > > This is web server (lighttpd) setting again. > It's possible to specify that files with .diff or .patch extension are > actually of type text/plain and not application/octet-stream , but > this was not done. > > I am not sure what you can do on the client / web browser side. > I think it is not just the patch, looking around, e.g. "LICENSE" files and everything else beside PKGBUILDs are also shown as "application/octet-stream". Greg
Re: [aur-general] Removing comments from AUR
> Since i started this, even by stupidly replying to another thread, i > might as well answer > to that. > My suggestion is not having comments in the AUR at all, comments arent useful > to > the users. They are only useful to the maintainer. I would disagree... Sometimes it is good for maintaner-user feedback as well. E.g. one of my packages takes a long time to compile. It's a small package but one step looks as if it hung and stays there for about 10-15mins on my computer. I had one of the users place a comment that his compilation didn't work, it froze and he had to kill it after about 5 minutes. Told him to wait a bit longer and it worked. Sure it could be done in the BBS - but would be completely inefficient. Not many users for most of the packages so not many people know what's going on, and I'm not going to search through the forums every day to see if someone wrote about them... Now: comment placed, me notified, can act on it Or: someone makes a package. A TU or a more knowledgeable user points out some problems with it in comments so he can fix it. Other users see the comments and see the advice, one day when they will make packages they can take that advice that is now public, and not in someone's mailbox. Yeah, the Wiki is for such things, but how many little things are there that people don't Wiki up? Or how many time people still write on the mailing list while this and that does not work in a package when it should? Sure it "only" concerns the maintainer at that time but there are a much wider potential audience. Also, it can serve as a "call" for other users who are interested in that package (and probably set it to "notify") to call for someone else to adopt a package. And also, your assumption is 100% reliable dedicated knowledgeable maintainers. Which is obviously not the case... > If there is no > maintainer, if a user feels > the need to comment with an updated/altered script then he should > adopt it and fix it. > And even disown it afterwards if he feels like it. Not everyone is the same. Not everyone wants to take that responsibility. Is forcing them the right way? I'd see more people giving up a package before adopting it. If they want to adopt they would do it under the current arrangement. Though the "email the list if one package is very outdated and the maintainer don't give a" is probably not that clear for everyone, might be better to advertise it a bit more, but that's a different issue. > How's that for "KISS" ? I'd ask, if you have a website that supposed to be automated and self contained, how is it KISS to require people +1 registration to BBS, +1 registration to mailing list, +possibly much longer waiting to contact someone who can know the solution to the problem? Just thinking... Greg
Re: [aur-general] Removing comments from AUR
2009/6/25 Grigorios Bouzakis : > On Thu, Jun 25, 2009 at 1:58 AM, Loui Chang wrote: > >> On Wed 24 Jun 2009 23:53 +0200, Ronald van Haren wrote: >> > why not allow the maintainers in unsupported to delete comments for their >> > packages, I don't think it will be too much misused? I remove from time >> to >> > time the crap out of the comments in my community/aur packages so only >> the >> > more relevant things stay (if there are any). >> >> Yeah I think this idea is best out of the lot. >> > > Yeah it is a nice idea, only i dont think people are gonna spend time > deleting comments. > > Usually when a somewhat popular package gets uploaded theres a lot of > discussion about > how to do this & that etc. Then when the script reaches a fairly satisfying > point of decency > discussion stops. & then you mostly see comments like "1.2 is out" or > complete build scripts > or patches posted etc. > See for example http://aur.archlinux.org/packages.php?ID=24266 > > IMO its better that the first, and more important part of the discussion to > be done on the mailing > list, this way people who dont use the package can help. > People can also get familiar with the package that way. > Then email the maintainer directly. > Hi, I think there are way larger number of people maintaining packages in the "unsupported" than how many people are on this mailing list. In "unsupported" I don't agree with removing comments, or even deleting them for that matter. This is because the comments provide invaluable resource for information in one place. Adopted a neglected package that is way out of date? Look among the comments and more likely than not someone already did some modifications that made it work but didn't want to adopt the package. That would be a pain to find (even if you want to look for it) in a mailing list. And if the mail goes only to the developer, then it's all gone when they ignore it. Or bugs? How many "unsupported" maintainer would read the bug tracker to look for their own packages if someone filed a bug? Place a comment, and it's in one place, even get a notification. There's a reason why packages are in "unsupported" and not higher up I think the current "notify" and "flag" buttons are adequate for the most "hobby maintainers". For "community", that's of course a different matter, just get rid of comments and force people to file bugs. Maybe that will improve the standards in the "unsupported" as well. Cheers, Greg
Re: [aur-general] test request
2009/6/4 M Rawash :
> i'd like people with 32bit machines to test
> http://aur.archlinux.org/packages.php?ID=26733 for me.
>
> for some reason it gives me a "wrong ELF class" error on my i686
> machine, so you'd have to actually run it before you can confirm that it
> works..
>
> thanks,
> M Rawash
>
>
Hi, some comments about the package:
1) for me it compiles just fine, but when try to run it, pops up an
error dialog with:
/usr/share/textadept//core/lua_dialog.lua:33: module 'gtk' not found:
no field package.preload['gtk']
no file '/usr/share/textadept//core/gtk.lua'
no file './gtk.lua'
no file '/usr/local/share/lua/5.1/gtk.lua'
no file '/usr/local/share/lua/5.1/gtk/init.lua'
no file '/usr/local/lib/lua/5.1/gtk.lua'
no file '/usr/local/lib/lua/5.1/gtk/init.lua'
no file 'gtk.so'
2) lua is listed as optional dependency, but in the PKGBUILD it is
explicitly included. Is that right that way?
3) according to namcap libffi is not needed, and it compiles fine
without it. couldn't run it yet, so not sure that's really necessary
4) ".so" files are usually located at /usr/lib/${pkgname}
5) LICENSE is installed twice, once in /usr/share/licenses, and once
in /use/share/textadept
Cheers,
Greg
Re: [aur-general] hsftp build error
2009/6/3 Abhishek Dasgupta :
> 2009/6/3 Nathan Owe. :
>> well i thought hsftp is working but i get this error :
>> The following are set in config.h
>>
>> pty/tty type: GLIBC
>> /bin/sh ./mkinstalldirs /usr/bin
>> /bin/install -c -s -m 755 hsftp /usr/bin/hsftp
>> /bin/install: cannot create regular file `/usr/bin/hsftp': Permission
>> denied make: *** [install-binPROGRAMS] Error 1
>> ==> ERROR: Build Failed.
>> Aborting...
>> Error: Makepkg was unable to build hsftp package.
>>
>
> Some notes on the PKGBUILD:
> - You needn't put variables which are empty, that'll make
> the PKGBUILD shorter.
> - The description should not start with the package name
> as it is redundant information.
> - license is an array. (use namcap to check the PKGBUILDs)
> - $startdir/src is deprecated, one should use $srcdir now.
>
> The PKGBUILD is trying to install stuff into .usr/bin which
> is not allowed as you are running makepkg as a non-root
> user. Most probably the Makefile uses some variable other
> than DESTDIR to determine the location of installed packages.
>
> --
> Abhishek
>
+1 for all of the above, and the particular fix you need is defining
the directories manually. Check the makefile, or as example of another
package that needed this check "tcc". Here you go:
# Maintainer: Nathan Owe.
pkgname=hsftp
pkgver=1.15
pkgrel=1
pkgdesc="An ftp emulator that looks as an ftp session, but uses ssh to
transport commands and data."
arch=(i686)
url="http://la-samhna.de/hsftp/";
license=("GPL")
depends=('glibc')
makedepends=('gcc')
source=(http://la-samhna.de/hsftp/${pkgname}-${pkgver}.tar.gz)
md5sums=('933b25a898978650a2a18372b5208a00')
build() {
cd ${srcdir}/${pkgname}-${pkgver}
./configure --prefix=/usr
make || return 1
make bindir=${pkgdir}/usr/bin mandir=${pkgdir}/usr/share/man \
install || return 1
}
Re: [aur-general] Filenames with "_" in it
2009/6/1 Thomas Bohn :
> I have one package[1] in AUR which has a "_" in the original file name.
> When I put
>
> source=(http://downloads.sourceforge.net/bibcursed/$pkgname_$pkgver.tgz)
>
> in the PKGBUILD, it won't work. When I put an \ before the _ it works but
> on the AUR page this \ will also show up and break the link to the
> original file.
>
> Thomas
>
If you have underscores next to variable names, shouldn't you use {}
brackets? Because since underscores are accepted in bash variable
names, this situation can be ambiguous.
So use it like:
source=(http://downloads.sourceforge.net/bibcursed/${pkgname}_${pkgver}.tgz)
(And using brackets is generally a good idea, I think...)
Nevertheless, probably it worth checking out the replacement of \ on
AUR, I'll try when I have some time...
Cheers,
Greg
[aur-general] updating: community/mitter
Hi,
I've seen that community/mitter has been out-of-date for a long
time, and the package could be improved somewhat anyway, so updated
it. Would a TU add the update, if the package owner does not seem to
do it?
Cheers,
Greg
# Contributor: Geoffroy Carrier
pkgname=mitter
pkgver=0.4.5
pkgrel=1
pkgdesc="A PyGTK/console client for Twitter"
arch=('i686' 'x86_64')
url="http://code.google.com/p/mitter/";
license=('GPL3')
depends=('python' 'pygtk')
provides=(${pkgname})
source=(http://$pkgname.googlecode.com/files/$pkgname-$pkgver.tar.gz)
build() {
cd "${srcdir}/${pkgname}-${pkgver}"
python setup.py install --root="${pkgdir}" || return 1
install -D -m644 "${pkgname}.desktop"
"${pkgdir}/usr/share/applications/${pkgname}.desktop"
}
md5sums=('0432f3d2d00e8d048bf0839e2d857e51')
Re: [aur-general] adopting from community: pinot
> I did attached it to my email > Did it get stripped from it? (did happen on the aur-dev list before) > Attaching it again... > My bad, attached PKGBUILD twice, but not Changelog... Greg ChangeLog Description: Binary data
Re: [aur-general] adopting from community: pinot
2009/4/20 Daniel J Griffiths : > Andrea Scarpino wrote: >> >> 2009/4/20 Gergely Imreh : >> >>> >>> Hi, >>> >>> I was checking orphan packages that should be revived. I found Pinot >>> [1] and made a new version. Since it is in "community", though, it >>> cannot be adopted. I attach the new version of the package here >>> (tar.gz, because it has Changelog, PKGBUILD and .install) and you can >>> apply it to the CVS version. Or if you release it from community, I'll >>> adopt it then. >>> Cheers, >>> Greg >>> >>> >>> [1] http://aur.archlinux.org/packages.php?ID=8700 >>> >>> >> >> It's orphan from some days, we have three new TUs, so I hope one of >> them will adopt it. >> >> > > You neglected to attach your PKGBUILD... > I did attached it to my email Did it get stripped from it? (did happen on the aur-dev list before) Attaching it again... PKGBUILD Description: Binary data PKGBUILD Description: Binary data pinot.install Description: Binary data
[aur-general] adopting from community: pinot
Hi, I was checking orphan packages that should be revived. I found Pinot [1] and made a new version. Since it is in "community", though, it cannot be adopted. I attach the new version of the package here (tar.gz, because it has Changelog, PKGBUILD and .install) and you can apply it to the CVS version. Or if you release it from community, I'll adopt it then. Cheers, Greg [1] http://aur.archlinux.org/packages.php?ID=8700
