Re: [aur-general] TU Resignation
On 31 January 2010 23:42, Paulo Matias wrote: > Hi all, > > Besides loving Arch, a few reasons made me leave it as my main > distribution. I could surely adapt Arch to my new personal needs, due > to its simplicity and flexibility, but due to lack of time and real > life pressure, it would not be possible anytime soon. So I'm resigning > as a Trusted User. > Best of luck with the future! Abhishek
Re: [aur-general] TU Resignation abhidg
2010/1/29 Allan McRae : > On 29/01/10 01:22, Abhishek Dasgupta wrote: >> >> Hi all, >> >> So long ... >> > > Good luck with you studies and the rest of real life. Hope to see you come > back when you have more time again. > Thank you all! @Gerardo: I'm studying an integrated MS course with a physics major. @Xyne: Thanks for adopting those! ghemical was one of my more used packages. Abhishek
[aur-general] TU Resignation abhidg
Hi all, So long ... Real life has been getting busier and busier lately, with my final year in university coming up. I've not been able to devote much time to Arch in the last month at all; thus I'm resigning as a Trusted User. I've a few packages in [community], many of them are scientific packages which I used once. I hope someone will take them up, otherwise they can move to unsupported. Arch was my first exposure to open-source contribution and it's been a great two years! Thanks to everyone (Hugo, Aaron, Allan, and others who have helped me) and also Varun, thanks to whom I could become a part of this community. PS I really hope someone makes a stable distro out of the Arch core (Starch? :) ). One of the main reasons for quitting is that I don't have a reliable internet connection where I'm most of the time, and can't keep up with a rolling release any more. PPS The zsi package has a missing dep (python-setuptools). Could someone fix it? Thanks! Regards, Abhishek Dasgupta
[aur-general] Inactivity
Semester exams are starting next week, so I'll be inactive till 8th Dec. Cheers, Abhishek
Re: [aur-general] script to check a binary package for architecture-independence
2009/11/2 Thomas Bächler : > Chris Brannon schrieb: >> On second thought, I wonder if these sorts of checks should be done >> within namcap? > > They should. Two checks: > 1) Is an arch=any package architecture-dependent -> error > 2) Is an arch=whatever package architecture-independent -> warning > > If you know python and have the time, you should write a patch against > namcap.git and mail it to Hugo. I told him once that it's a good feature, no > idea if he got to it. You can check namcap.git to see if he did something, > and check the bugtracker if there is a feature request already. > It's not in namcap.git. You could look at elfflies.py - that already checks for ELF files in the package. This would fit in neatly there. Abhishek
Re: [aur-general] 64-bit build machine
2009/10/15 Giovanni Scafora : > 2009/10/15, Abhishek Dasgupta : >> Is the 64-bit build machine still available? > > I'm building gnonlin and blueman packages for x86_64. > Thanks!
[aur-general] 64-bit build machine
Is the 64-bit build machine still available? Abhishek
Re: [aur-general] spam in out-of-date notifications for [community] packages
2009/9/29 Aaron Griffin : > On Tue, Sep 29, 2009 at 10:18 AM, Chris Brannon wrote: >> It seems that someone is sending spam via out-of-date notifications >> for packages in the official repos. >> How do I clear the out-of-date flag on my packages these days? >> I can't seem to be able to do that with the new interface. > > Yeah, this happens, and we haven't really found a good solution to > this spam problem. I guess we could ban the IP address... > > If anyone has an idea to solve the spam issue that's not super > intrusive, the code (archweb_pub) is publicly available :) Can't we use Pierre's script to auto-check for updated packages? Most upstream authors have a sane versioning system -- so it should not be too difficult. Abhishek
Re: [aur-general] [arch-dev-public] automatic package builder
2009/9/25 Ronald van Haren : > Hey guys, > > Past week I was reading through the buildbot manual, but I decided not to > use it. IMO it is far too complex, fat and not something which has the > needed functionality easily available (you can extend it with python > scripting, but what's the fun of that huh?) > > So yesterday I decided I will write my own. I'll give it some more though > what functionality we need most (ability to prioritize tasks, manually > adding tasks, getting changes from svn to name a few). > > So what do I need from you? > - name (what's a tool without a name huh?) How about ogee? From wikipedia, Ogee is a type of arch which looks very similar to the Arch Linux logo. > - git-repo (not direct, but sometime in the next two weeks or so. Maybe we > need to first pick a name too) > - ideas. What do you guys want to see first? How do we want to get notified > (daily mail, using a webpage which lists success of all completed/pending > tasks, something else)? You get the idea, now is the time to speak up. > I think a website would be really cool. Something like Ubuntu's PPA -- that system is really nice. Abhishek
Re: [aur-general] TU applying/voting.
2009/9/23 member SpeedVin : > Hello Laszlo thanks for some testing about this licenses I don't include > them in my PKGBUILD because they are autodetecting by AUR but if it's needed > Tommorow I will include them in PKGBUILD and update them on AUR. > And about xextproto-git when I building it , it need newest version of > inputproto ;) > Thanks. > Licenses are not autodetected by AUR. Abhishek
Re: [aur-general] out-of-date notifications
2009/8/20 Ronald van Haren : > you should get the out-of-date notifications for packages you've > adopted in your own mailbox. Those are not send to the mailing list. > > Ronald Just tested by flagging a package out-of-date, nob...@a.o mailed directly to my Inbox. I never noticed that all the out-of-date notifications in arch-notifications are for orphaned packages. Abhishek
[aur-general] out-of-date notifications
Is it possible to have out-of-date notifications to be Cc-ed to the maintainer? Then I can check arch-notifications web interface for the other notifications and still get out-of-date notifications for my packages. Abhishek
Re: [aur-general] Please delete kde4-crystaldiamond-icons
2009/8/10 Vojtech Horky : > Hi, could some of the TUs, please, delete kde4-crystaldiamond-icons as > it already exists as kde4icons-crystaldiamond. > I created the package as I haven't noticed it in search results. > Sorry for the trouble. Thanks in advance. > > - Vojta Done.
Re: [aur-general] Moving from AUR to community
2009/8/10 Xyne : > On Sun, 9 Aug 2009 19:10:35 +0200 > Pierre Schmitz wrote: > >> Am Sonntag 09 August 2009 19:08:24 schrieb Xyne: >> > Is this still possible? >> >> Afaik AUR and [community] are not connected anymore. >> >> -- >> >> Pierre Schmitz, http://users.archlinux.de/~pierre > > So should I delete packages in the AUR after I upload them to > [community]? > Yes.
Re: [aur-general] PD license/no license
2009/8/8 Allan McRae :
> Anton Shestakov wrote:
>>
>> Hey there.
>> I want to submit sdlmame-cheats package to AUR. Basically, this package
>> would provide a single file; archived collection of user-provided xml files
>> for using in sdlmame. But I have some difficulties with it's license. I
>> couldn't find it nor on the official site, nor in the archive.
>>
>> Actually, I've asked on local forum what license they are providing their
>> work under [1]. The reply was, I quote, "Any individual cheats in this
>> forum/submitted can be taken as Public Domain. I don't know if the
>> collection needs a license or what type of license to put on the full
>> collection". So what do you think, can I put a "license=('PD')" in PKGBUILD?
>> Or even no license at all?
>>
>> [1] http://www.mamecheat.co.uk/forums/viewtopic.php?f=5&t=3450&start=0
>>
>
> Public Domain has no consistent definition across coutries so is not good
> for an unwritten licence. I'd use license=('unknown').
>
> Allan
The CC0 license is a better alternative to public domain:
http://wiki.creativecommons.org/CC0_FAQ
If you use Public Domain or CC0, please make sure to install
a copy of the terms in /usr/share/licenses/$pkgname as these
are not in the licenses package.
Re: [aur-general] latexmk is gone?
2009/8/6 Stefan Husmann : > latexmk is part of texlive-bin 2009 in [testing]. This can cause file > conflicts, so I removed the PKGBUILD from AUR. > > This issue came up in the forum, too. You can do a forum search and copy and > paste the PKGBUILD from there. It can also be obtained for a while from http://aur.archlinux.org/packages/latexmk/latexmk/PKGBUILD -- Abhishek
Re: [aur-general] [arch-dev-public] ViewVC URLs for splitted packages
2009/8/4 Roman Kyrylych : > Hi! > > The View SVN Entries link for splitted packages is broken. > For example: > http://www.archlinux.org/packages/extra/any/kde-meta-kdeplasma-addons/ > The link on that page points to > http://repos.archlinux.org/viewvc.cgi/kde-meta-kdeplasma-addons/repos/extra-any/ > but because it is a splitted package the SVN tree can be viewed at > http://repos.archlinux.org/viewvc.cgi/kde-meta/ > One way is using symlinks; other is using pkgbase information from .PKGINFO (not sure if pkgbase is included in .PKGINFO though) in the web interface. -- Abhishek
[aur-general] spam on the mailing lists
While the AL lists are well-maintained and mostly spam free, sometimes a few get through, as on the arch-dev-public list today. I don't know if list admins can specifically mark a message as a spam from the server side but there should be a way to do so. I could mark as spam from Gmail but then there's a chance other posts in arch-dev-public would also be classified as spam (that happened before with me with aur-general). This spam could be because of some server problem, a few months ago this kind of spam used to come (from arch-dev-pub...@archlinux.org) and Aaron had fixed it. -- Abhishek
Re: [aur-general] Install files upload
2009/7/26 Vit : > Hi all! > I'm new here and I can't upload .install file. Upload page says: > "Unknown file format for uploaded file." So how can I attach an > .install file to the existing package? > Best regards, > Vit. You can't, you should upload a source tarball (make using makepkg --source). -- Abhishek
Re: [aur-general] Package search for community repo
2009/7/24 Loui Chang : > I know archiving is easy. I could just do a mysqldump. > Is there an application that you need the data for? > No, just the data could be useful in the future. -- Abhishek
Re: [aur-general] Package search for community repo
2009/7/23 Loui Chang : > On Thu 23 Jul 2009 22:04 +0530, Abhishek Dasgupta wrote: >> This information could be kept archived somewhere. A simple HTML dump >> of the all the community package pages would suffice. > > Well, I won't remove the packages outright. I'll just dummify them so > they won't appear in the AUR. Any particular reason that you'd want to > archive it though? > Archiving the pages is easy, also some comments in the package pages are useful for now. -- Abhishek
Re: [aur-general] Package search for community repo
2009/7/23 Roman Kyrylych : > This is absolutely no-go because this way bugtracker will be flooded > with out-of date messages > that have no useful information. Agreed. The web interface is the best place to mark out-of-date. For now, people can send to the maintainer directly. > +1 for complete merging community into main website (with limited > permissions for TUs) > and removing community-related part of AUR > (with a notice that if there was some important info in comments - it should > be > reported as bugs or it will be lost) This information could be kept archived somewhere. A simple HTML dump of the all the community package pages would suffice. > (if there would be possibility to limit permissions per category then > I would love > to merge Community Packages bugtracker project as well, > but that's not an option at this time). That'd be really nice if possible. Then I wouldn't have to file two bugs for each namcap tag. -- Abhishek
Re: [aur-general] AUR Trusted User Guidelines
2009/7/23 Gerardo Exequiel Pozzi : > Abhishek Dasgupta wrote: >> I've updated the guidelines. Could someone go through it and see if >> there's anything I've missed? I've only put the [community] specific >> stuff there. >> >> > Looks good, thanks :) > > No talk about 'any'. Is not currently implemented at this moment for > community? I suspect that the answer is "no", because there are no > directory 'any' in FTP for comminity like for other repos. Right? > The 'any' architecture support has been rolled out in /arch-new/ on gerolde. Aaron said that'd he'd install the updated scripts after dbscripts supports handling splitted packages. -- Abhishek
Re: [aur-general] AUR Trusted User Guidelines
I've updated the guidelines. Could someone go through it and see if there's anything I've missed? I've only put the [community] specific stuff there. -- Abhishek
Re: [aur-general] AUR Trusted User Guidelines
2009/7/23 Ronald van Haren : > I've unprotected it for one day (I think it works). Let me know if you need > more time or when you are finished earlier so I can set it back. > Thanks. I will be done by 2000 UTC. -- Abhishek
[aur-general] AUR Trusted User Guidelines
The guidelines have to be updated for the shift to devtools. I could update it but the page is locked. -- Abhishek
Re: [aur-general] Package search for community repo
2009/7/23 Heiko Baums : > Am Wed, 22 Jul 2009 19:46:45 -0400 > schrieb Eric Bélanger : > >> The 'flag out of date' option for community still works (unless it was >> disabled). Users just need to check the package version in the repo >> instead of the version displayed in AUR to know if a package is >> out-of-date or not. > > I understood the message on the AUR homepage so, that the community > packages shall be removed from AUR (in the future). Or did I > misinterpret it? > I think it's best to remove the list of [community] packages from the AUR instead of keeping them in a frozen state. http://archlinux.de has updated information for [community]. That could be used till [community] is integrated into the main website or some other solution is found. -- Abhishek
Re: [aur-general] Package search for community repo
2009/7/23 Evangelos Foutras : [snip] > That would be best, in my opinion. It would be quite practical to put > [community] alongside with the other repos. Additionally, if the permission > system in use allows it, we (TUs) could use [testing] (instead of the > proposed [community-testing]) for [community] packages as well. > Setting permissions on a per-package basis is harder than setting permissions on a whole repository; this was discussed in the original thread for moving [community] to devtools. -- Abhishek
Re: [aur-general] Initial manual cleanup
2009/7/20 Xyne :
>> They are not. Any packages are not supported yet. We are testing support for
>> any packages in addition to split packages on the main arch server. When
>> this is complete, I will release new dbscripts
>
> Do I need to replace ('any') with ('i686' 'x86_64') in the PKGBUILD for
> inclusion in [community] or is it enought to replace "any" in the
> package tarball's name?
>
Just changing the package tarball name wouldn't work I think;
since .PKGINFO is still going to contain arch = any.
--
Abhishek
Re: [aur-general] CVS freeze and move to SVN/official tools
2009/7/15 Loui Chang : > On Wed 15 Jul 2009 20:55 +0530, Abhishek Dasgupta wrote: >> >> Yay! Will the community packages still show up on AUR? > > No. Community is being decoupled from the AUR. > So they'll show up in the archlinux.org main webpage or are they disappearing from the web frontends in the interim? -- Abhishek
Re: [aur-general] CVS freeze and move to SVN/official tools
2009/7/15 Aaron Griffin : > Hey guys, > I'd like to put a freeze on community CVS later today. Sadly, CVS > doesn't respect files set to RO, so there's not too much I can do > server-side. > > I'm going to do the SVN conversion in approx 8 hours or so, maybe > sooner, if I get some time while at work. > In the meantime, this document should explain the usage of the offical > tools and svn: > http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager > Yay! Will the community packages still show up on AUR? -- Abhishek
[aur-general] license convention for public domain packages
There are widely varying methods for specifying the license of a public domain package in Arch Linux. We should standardise and use one of them. Some packages use - 'Public Domain' (unclutter, python-webpy) - 'PD' (ttf-mph-2b-damase) - I think some packages might also be using 'none'. I saw one package using 'custom:public' (shuffle) Also, there is the question of whether we should have public domain declarations for each package in /usr/share/licenses or put a public domain declaration in /usr/share/licenses/common and refer to that. -- Abhishek
Re: [aur-general] Adopted
2009/7/6 Ray Kohler : > Is there actually a feed that shows all updates, and not just new packages? > The obvious one on the AUR main page only shows new packages. > http://aur.archlinux.org/rss2.php shows all updates. -- Abhishek
Re: [aur-general] CVS problem? AUR Comment for moovida
2009/7/5 Abhishek Dasgupta : > Also [community] does not have a repo viewer right now > since aur.archlinux.org is not on gerolde any more. > > -- Forget that, repos.archlinux.org does have [community] but I don't know whether it's updated against the latest CVS (after the AUR move). -- Abhishek
Re: [aur-general] CVS problem? AUR Comment for moovida
Also [community] does not have a repo viewer right now since aur.archlinux.org is not on gerolde any more. -- Abhishek
[aur-general] script for running namcap on a AUR maintainer's packages
It's useful to run namcap on a maintainer's packages on the AUR, especially when people apply for TU. This pair of scripts fetches the package names belonging to a maintainer (it only fetches the first 100 results though) and the second runs namcap on the package list by downloading the PKGBUILDs from AUR. -- Abhishek aur-maintainer-pkgs Description: Binary data namcap-aur-pkgs Description: Binary data
Re: [aur-general] Requesting orphanage of libssh and hydra
2009/7/3 SergeantSpoon : > I am interested in taking up maintaining libssh and hydra in the AUR, > and the current maintainer has been inactive for almost a year. I > tried contacting him via email but he has not responded, so I can only > assume that he is no longer interested in maintaining either. > > If a TU could set me as the maintainer or ophan both packages that > would be great, as I have PKGBUILDS that are completely updated and > function ready to be uploaded. > Orphaned. -- Abhishek
Re: [aur-general] Application for TU
A few notes on your PKGBUILDs - url is a string, not an array (amule-upnp) - package description should not start with pkgname (baltazar, dirac-codec) - you can use $pkgname-$pkgver in source array, makes maintenance easier (cpuspeed) - backup array has preceding slashes (cpuspeed) - if you put a package in depends, there is no need to put it in makedepends as well (rtpproxy) - putting in '|| return 1' would be nice here (wireless-applet); this is especially important when you'll include patches. -- Abhishek
[aur-general] rsync for AUR
Is it feasible to setup an rsync for AUR packages? Would it increase load on the server a lot? Installing packages from AUR would become simpler, as tools can work on the local cache instead. It'll be also easier to keep backups. -- Abhishek
Re: [aur-general] (no subject)
2009/6/30 Sergej Pupykin : > --- Original message --- > From: Aaron Griffin > To: "Discussion about the Arch User Repository (AUR)" > > Subject: Re: [aur-general] (no subject) > Date: Tue, 30 Jun 2009 02:10:51 -0500 >>AG> On Tue, Jun 30, 2009 at 2:05 AM, Sergej Pupykin >>wrote: > >>>no> what aur helper do u recommend that will download/build/install all > >>>no> deps too like yaourt > >> > >> I fix aur-sync recently to work with new AUR server. It is not yaourt > >> replacement, but I think yaourt has same problems... > >>AG> Out of curiosity, what were the problems? > > My problem was in parsing http://aur.archlinux.org/packages/ index > html. Date format was changed. I am not sure if yaourt parses web pages to > search packages... > http://aur.archlinux.org/packages/ is not representative of the packages in AUR as packages which are deleted still live on as folders in this directory for sometime. -- Abhishek
Re: [aur-general] Please delete my package 'newton-archemedia'
2009/6/29 Sven-Hendrik Haase : > Hey, > > please delete my package 'newton-archemedia ' as it appears to have been > superseded by 'newton-dynamics-beta'. > Deleted. -- Abhishek
Re: [aur-general] AUR Moving
2009/6/29 bardo : > 2009/6/29 Loui Chang : >> Actually I just realised that it's a longstanding bug/feature that the >> update script does not update the AUR database for x86_64 only packages. >> So that's normal behaviour. i686 packages are being updated. > > The repo doesn't seem to be updated, though. I uploaded the packages > about five hours ago, and my mirror has surely synced since then[0], > but a -Sy never downloaded the [community] db... > > [0] http://archlinux.puzzle.ch/community/os/x86_64/lastsync > >From the ftp://archlinux.org/community/os/i686 page community.db.tar.gz. . . . . . . Jun 27 18:01 so it hasn't been updated at all since the AUR move. If the new [community] repo is at the new server, then what's the link to access the repofiles, or does gerolde sync the packages back to itself? Since the mirrors all sync from archlinux.org they'll be getting the old community.db.tar.gz only. -- Abhishek
Re: [aur-general] AUR Moving
2009/6/28 bardo :
> Confirmed ssh works, just like cvs checkout and commit. Well, at least
> they seem to. I uploaded three packages (eclipse-{emf,gef,mylyn}) for
> x86_64 with communitypkg some time ago, but the only confirmation I
> got is that running 'cvs update' checks out my latest changes. I can't
> find evidence of updates, not in AUR, nor in mirror sync, nor in
> repos.archlinux.org.
Loui said that the [community] repo was being synced, probably
[community] is not activated yet.
> Provided I didn't wait very much (less than two hours) is there
> something that still needs to be configured for the new server or are
> the services ok? Do uploads already work as expected? And finally, has
> AUR<->[community] sync gone for good?
>
I suppose AUR/[community] link will go away with the SVN move next
week, or will it? It'd be nice if [community] also shows up on the
archlinux.org interface.
--
Abhishek
Re: [aur-general] mod_scgi package
2009/6/28 Henri Häkkinen : > Hello. > > The AUR package 'mod_scgi' seems not to have a maintainer. I would be > willing to take the maintenance of this package. My AUR account is > 'henux'. > > http://aur.archlinux.org/packages.php?ID=22171 > http://aur.archlinux.org/packages.php?SeB=m&K=henux > Just click the "Adopt Packages" button. -- Abhishek
Re: [aur-general] Remove vim-scripts-align
2009/6/28 Magnus Therning : > Please remove this package (http://aur.archlinux.org/packages.php?ID=26319). > > I have no intention of supporting it as the upstream author makes it > available as a VBA. This means it can be easily kept up-to-date from inside > Vim using GetLatestVimScripts, and pacman need not be involved at all. > > /M > > -- > Magnus Therning (OpenPGP: 0xAB4DFBA4) > magnus＠therning．org Jabber: magnus＠therning．org > http://therning.org/magnus identi.ca|twitter: magthe > > Deleted -- Abhishek
[aur-general] automatic package creation from pypi
Quite a while back, the idea of automatically creating PKGBUILDs from pypi came up: http://www.archlinux.org/pipermail/aur-general/2008-August/002099.html It'd be really cool if we could get something similar to cabal2arch for PyPI. Checking the PyPiXmlRpc [1] page does not show any field for listing dependencies of the package though. Is there any way of getting the dependencies of a python module programmatically? [1]: http://wiki.python.org/moin/PyPiXmlRpc?action=show&redirect=CheeseShopXmlRpc -- Abhishek
Re: [aur-general] AUR Moving
2009/6/27 Aaron Griffin : > A few notes to the TUs: > > * Make sure you have checked out via "aur.archlinux.org" and > everything should go smoothly for you > * Later tomorrow, please send me an ssh key for use on the machine, > and I will setup a shell account for you. > * A conversion to SVN and db-scripts will follow in the next week or so. > that means this, right? CVSROOT=":pserver:@aur.archlinux.org:/srv/cvs/cvs-community" for the next week, after that of course aurtools will be gone. -- Abhishek
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/6/24 Aaron Griffin : > Which part? Is there a patch I forgot to merge, or are you just > bumping the dbscripts as a whole? > No, I was just saying that the any architecture could be tried out for the kde-unstable branch to find any remaining bugs. -- Abhishek
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/14 Aaron Griffin : > On Wed, May 13, 2009 at 2:18 PM, Abhishek Dasgupta wrote: >> 2009/5/14 Abhishek Dasgupta : >>> 2009/5/14 Aaron Griffin : >>>> One quick thing to note - because pacman reads .PKGINFO files to get >>>> metadata, it's nice to have them at the beginning of the tar. tar >>>> --append is going to slap them on the end. This could make a >>>> significant difference on larger packages >>>> >>> >>> The previous commit was actually placing .PKGINFO at the end. The >>> attached patch fixes that and also uses fakeroot otherwise the tarball >>> would get the permissions of the user running convert-to-any. >>> >> >> forgot to attach last time. > Bump. Probably this can be tried out for the kde-unstable branch to iron out any bugs that are remaining? -- Abhishek
Re: [aur-general] readline GPL violation on two pkgs?
2009/6/24 Gerardo Exequiel Pozzi : > Btw now a rebuilded my local pkg of ngspice-r19 with libedit and seems > to works fine ;) > Thanks :) BTW libedit is already in extra though it's out of date http://www.archlinux.org/packages/extra/i686/libedit/ -- Abhishek
Re: [aur-general] readline GPL violation on two pkgs?
2009/6/24 Gerardo Exequiel Pozzi : > Hi, > > I just do a quick scan of soft linked with readline and I think that > these two pkgs that are linked with readline violates GPL: > > extra/tftp-hpa > community/ngspice > > Both have the "old" BSD (4-clause) license and is linked with readline > that is GPL, so there is an incompatibility [#1] > > In the case of ngspice recomends to link with libedit to avoid legal > issues [#2] Okay, when I bump ngspice to r19 I'll link against libedit. -- Abhishek
Re: [aur-general] Delete package gtk-engine-glory
Deleted 2009/6/16 H.Gökhan SARI : > Can you please delete the package gtk-engine-glory on AUR? I accidentally > uploaded it as a gtk engine, however it's a theme only. > > -- > H.Gökhan SARI > h...@difuzyon.net > -- Abhishek
Re: [aur-general] Incorrect name when downloading from source=()
2009/6/16 Côme Pruvost : > Hello, > > To package cellwriter, I need to download this patch[1]. But once > downloaded, the name of the file is > "attachment?aid=-5287197620305474653&name=cellwriter-1.3.4-cellwidget-dont-disable-xinput.diff" > instead of just > "cellwriter-1.3.4-cellwidget-dont-disable-xinput.diff". > > - Is it a big problem ? I mean if another user do not use wget will my > PKGBUILD work for him ? > - Is there a way to force a correct behavior ? > > [1] > http://cellwriter.googlecode.com/issues/attachment?aid=-5287197620305474653&name=cellwriter-1.3.4-cellwidget-dont-disable-xinput.diff > You can always download the patch, rename it and put in the source tarball (makepkg --source) -- Abhishek
Re: [aur-general] hsftp build error
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
Re: [aur-general] Remove Request for mitter-svn
2009/6/1 Thomas Bohn : > Please remove the package mitter-svn: > http://aur.archlinux.org/packages.php?ID=19446 > > They switched to git. So the packages is useless. > Deleted
Re: [aur-general] delete ctunnel
2009/6/1 Vinzenz Vietzke : > nathan owe. schrieb: >> http://aur.archlinux.org/packages.php?ID=26922 needs deleting, for some >> reason it won't build i give up > first point: > i think using "sudo" in a pkgbuild isn't really useful, especially when > there is no dependency on the sudo-package. > PKGBUILDs should not use sudo at all. Everything in the build() function should work without superuser privileges. -- Abhishek
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.
>
Try
source=(http://downloads.sourceforge.net/bibcursed/${pkgname}_${pkgver}.tgz)
--
Abhishek
Re: [aur-general] A letter of resignation as a TU
2009/5/30 Mikko Seppälä : > Oh, the time has come for young one to enter the world and feel the > first had experience of cruelty, blood and peasoup. > To take on arms and abandon all hope on having personal feelings or > time to infiltrate the community cvs. > Nonexisting datalinks preventing duties to be performed. No keyboard > to write on but the paper and wood. > Last of the original comm64 porters dying. > Time to leave the duties to be performed by wonder who? > TIME TO RESIGN! > > > Or in short: > I'm off to army in about a month, so I'm resigning unless you want to > mark me as inactive for over a year :p > wonder has agreed to take over lib32 so no pkgs to be adopted (unless > someone wants bin32-wine from unsupported, trying to get maintainer for it). > Objections? yes? no? > Ok, thats it. > Have a smooth ride. > That was a wonderful poem Bye, and best of luck. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/30 Abhishek Dasgupta : > I'll write a script to fetch the maintainers of all packages in the > official repositories and store them in a simple text file, so that > people who need the maintainer information for the whole archive > can just use that instead of polling archlinux.org > The list of maintainers will soon be at http://abhidg.mine.nu/arch/maintainers.txt It'll be updated daily at 0430 UTC. The script used is given below: #!/bin/sh URL="http://www.archlinux.org/packages"; OUTPUT=/arch/maintainers.txt arch=i686 if [ ! -f /etc/abs.conf ]; then echo "This program needs 'abs' (pacman -S abs)." exit 1 fi if [ ! -x /usr/bin/curl ]; then echo "This program needs 'curl' (pacman -S curl)." exit 1 fi . /etc/abs.conf pushd "$ABSROOT" >/dev/null for repo in core extra; do pushd $repo >/dev/null for i in *; do maintainer="$(curl -s $URL/$repo/$arch/$i/maintainer/)" if ! (echo $maintainer | grep -q DOCTYPE); then echo "$i $maintainer" >> $OUTPUT.new fi done popd >/dev/null done if [ -f "$OUTPUT" ]; then mv "$OUTPUT" "$OUTPUT.old" fi mv "$OUTPUT.new" "$OUTPUT" -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/23 Abhishek Dasgupta : > Of course, all that is really needed is an easy way of getting the current > maintainers. I'll work on adding some kind of API to the web interface > to output the maintainer name given an URI like this: > http://archlinux.org/packages/core/i686/bash/maintainer > This is now in place: for example see http://www.archlinux.org/packages/extra/i686/namcap/maintainer/ I'll write a script to fetch the maintainers of all packages in the official repositories and store them in a simple text file, so that people who need the maintainer information for the whole archive can just use that instead of polling archlinux.org -- Abhishek
Re: [aur-general] [PATCH] __init__.py: gnomemenu removed, prettify code
Bump. Any opinions on this patch? 2009/5/13 Abhishek Dasgupta : > Updated patch to remove gnomemenu from namcap.1 as well. > > -- > Abhishek >
Re: [aur-general] Package Removal discid
2009/5/26 Heiko Baums : > When adding a new task to Flyspray, I only see these repos in the > "Category" field: > Packages: Extra > Packages: Core > Packages: Testing > Bugs for [community] packages are reported in a separate project called "Community Packages". http://bugs.archlinux.org/index.php?project=5 -- Abhishek
Re: [aur-general] Package Removal discid
2009/5/25 Heiko Baums : > At least for now, it is necessary to have community packages also in > AUR, because there's no package database for community as it is for > core, extra and testing. At least I don't know such a package database. community.db.tar.gz on the mirrors is downloaded every time you do a pacman -Sy. > So AUR is the only possible place, where to flag a community package as > out-of-date, where to file bug reports for a community package or where > to contact the package maintainer for other purposes regarding such a > package. Bugs for [community] packages should be reported in the Community Packages section of the Arch Linux bugtracker and *not* in comments. -- Abhishek
[aur-general] [PATCH] Add URL to get maintainer of a package
This is a simple patch to make URLs like http://archlinux.org/core/i686/bash/maintainer return the current maintainer for the package in plaintext. I don't know if the code works or not since I've almost no experience in Django. I'm not sure whether simply returning pkg.maintainer shall suffice. -- Abhishek 0001-Add-URL-to-get-maintainer-of-a-package.patch Description: Binary data
Re: [aur-general] changing the status of the maintainer field
2009/5/23 Angel Velásquez : > But now talking about the topic, you can also set the "Maintainer" > flag with an env var and adding it to the .PKGINFO (I thought Andrei > Thorp suggested this anyway) and past maintainers can be parsed in > another .PKGINFO Field. This will need modifications of the makepkg > script (and adding this to pacman in the -i option), but I think this > is a good solution, for having the *actual* maintainer with -Qi or > -Si. > Adding the Maintainer field to .PKGINFO has a few problems: - This makes this quite complicated, needing changes to both makepkg and pacman. - The information gets outdated and there should be only _one_ easily accessible information source about the current maintainer which is retrievable by scripts. For example, if you build a package which is not updated often; and after a few months you orphan it and it's picked up by someone else, it will not be visible to the user when the user does a pacman -Qi; that's why it's better IMO to keep this sort of information only in the PKGBUILDs. Of course, as Allan said, there might not be enough motivation to change the maintainer field in the PKGBUILD if one wishes to adopt a new package. I suppose though, that it would be easy to write a script to do such things automatically. Assuming we have one maintainer for each package, this script (not fully fleshed out, but you get the idea) should work: #!/bin/sh # adopt: adopt a package from the repositories # Change this to wherever you keep your full/partial SVN checkout. if [! -f /etc/makepkg.conf ]; then echo "adopt: no makepkg.conf found!" exit 1 fi source /etc/makepkg.conf if [ -z $MAINTAINER ]; then echo "adopt: Please set the MAINTAINER variable in /etc/makepkg.conf" exit 1 fi if [ -z "$SVNROOT" ]; then echo "adopt: Please set the SVNROOT variable in /etc/makepkg.conf" exit 1 fi if [ -z "$1" ]; then echo "Syntax: adopt pkgname" exit 1 fi pkgname="$1" if [ ! -d "$SVNROOT/$pkgname" ] echo "adopt: no package $pkgname in $SVNROOT" exit 1 fi pushd "$SVNROOT/$pkgname" > /dev/null if [ ! -f PKGBUILD ]; then echo "adopt: $pkgname exists, but no PKGBUILD." fi sed -i "/^maintainer.*/d" PKGBUILD echo "maintainer=($MAINTAINER)" >> PKGBUILD svn commit -m "changed maintainer to $MAINTAINER" # probably give a check to see if uname of svn user same as $MAINTAINER echo "adopted $pkgname" popd > /dev/null # EOF A small note: I'm using makepkg.conf here but MAINTAINER and SVNROOT could be put in some other configuration file as well. Finally after setting all this up; adopting should become as easy as: $ adopt pkg pkg adopted That's it! All the manual work is hidden away in this script. Of course, all that is really needed is an easy way of getting the current maintainers. I'll work on adding some kind of API to the web interface to output the maintainer name given an URI like this: http://archlinux.org/packages/core/i686/bash/maintainer -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/22 Allan McRae : > I am very much against adding _unnecessary_ fields to PKGBUILDs... If > these are not needed by makepkg or pacman, they should only be comments. It > is going to take a lot of convincing for me to think otherwise. > As long as the information in # Maintainer tags and the web interface is the *same*, there is no problem. What is required is an easily accessible database of current maintainers for each package. It's always best to have as much information available in easily downloadable form. One way (and there can be numerous different ways of doing this) is to put this in the PKGBUILD in a parseable form -- the reason for a bash array with the username: - makes it easily parseable by bash scripts - putting only the username and no other extraneous information as email etc can change. - ignored by makepkg as it does not recognise it (and doesn't need to) - has no effect on the binary As an example consider the *files.db.tar.gz stuff. Before that if one wanted to check the filelist of a particular package, one would need to download that particular package and check out its contents. Now, the files database is put in an easily accessible location which enables programs like pkgfile to access and make use of that information. While this information could have been put as a kind of API (like the AUR JSON interface) that would have reduced usability for users who would like to view a filelist offline. Currently there is no _simple_ way for scripts of finding the maintainer of a given package in the official repositories. The only way is to parse the webpage which is hackish and certainly not KISS. An abs (or even svn) checkout does not help since there is no necessity that the Maintainer tag in the PKGBUILD and the maintainer listed in the web interface is the same; which just makes the Maintainer tag in the PKGBUILD totally irrelevant since one has to check the web interface anyway. All this was discussed in the arch-dev-public thread I mentioned a few posts back. At that time, most people seemed to agree that this was a good idea but nothing came of it. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/22 Heiko Baums : > Comments are more flexible, so that more maintainers and contributors > can be added to the PKGBUILD.In this case the PKGBUILD can be parsed > by AUR - it's already done anyway - when a package is uploaded to AUR. No, it isn't; no script parses the Maintainer or Contributor tags since they are just comments and in quite a few cases have incorrect maintainers listed. > Nevertheless I think, there's another point. Aren't the PKGBUILDs > licensed under the GPL? > I've no idea about this. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/22 Gerardo Exequiel Pozzi : > 1) Technical purposes: Having a "# Maintainer" comment line can provide > a simple way to shell scripts to identify the maintainer, that in many > cases the maintainer != packager. (pacman -Qi) This help in many cases, > for example reporting a "mass change/rebuild/bug/feature/etc/random". > > 2) Ethical: While many of the PKGBUILD are trivial changes to the > PKGBUILD.proto, beyond this, which made this PKGBUILD took some > maintenance time of work, and giving a kind of support for it. So, I > think it is important that this be retained. > > I started the thread to revive the idea of having a separate maintainer field for the official repositories which could be parsed by scripts to update the web interface, instead of using the web interface to change the maintainer as is done currently. This of course does not apply to the AUR and the question of Maintainer vs Contributor tag (already discussed before many times) is irrelevant here. Currently a dev/TU has to go to the package page and click "Adopt". Also he/she has to update the Maintainer tag accordingly to match it with the web interface which is often not done. If the maintainer tag was a proper field like maintainer=(username) then to adopt the package, all one would need to do is change the value of the maintainer variable and commit to trunk. The web interface would pick the changes from trunk and update itself. This would make the maintainer tag more relevant and easier to parse by scripts. This does not apply to the AUR since everything depends on the web interface there. IMO, the official repositories should have their metadata independent of the web interface, in the PKGBUILDs if possible. If this change is implemented, then one would not need to visit the web interface for such a common task. -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/21 : > email addresses can change and be off, the tag in the PKGBUILD rarely > contains the username but the realname is mostly the same, all > provided a new maintainer didn't forget to add his credentials to the > PKGBUILD. So yeah, the information is almost always different to some > degree. > > But: what must be the same? I realise that it would be nice if it > was the same. A discussion on similar lines took place a while back but died out: http://www.archlinux.org/pipermail/arch-dev-public/2008-September/007835.html -- Abhishek
Re: [aur-general] changing the status of the maintainer field
2009/5/21 Alper KANAT : > And what if I adopted a package from someone? Am I a Contributor or a > Maintainer on that case? > In all cases the Maintainer tag if present should have the same information as that of the web interface. Otherwise it loses its relevance. -- Abhishek
[aur-general] changing the status of the maintainer field
Many packages in Arch don't have Maintainer tags in their PKGBUILDs (around 345 last time I checked). Also quite a few the PKGBUILDs are not updated by the current maintainer. It is better to do away with maintainer tags altogether, since their functionality can be obtained from the web interface itself. Another alternative which I prefer (and which was discussed a while back) is to elevate the maintainer tag to a proper *required* tag which would be parsed by the Django frontend to update the maintainer list. -- Abhishek
Re: [aur-general] removing versionpkg from [community]
2009/5/20 Ronald van Haren : > On Wed, May 20, 2009 at 11:53 AM, Abhishek Dasgupta wrote: > >> I'll be removing versionpkg [1] from [community] soon as its functionality >> is already built into makepkg now. It was last updated two years ago >> by dtw, > > Just remove it, both actually. The source of make_e17 is not available > anymore and probably wouldn't work anyways as the last update was a year > ago. Since then there have been a few additions/changes to the e17 sources > so I doubt all needed modules are available in the script (if it were > actually there). > If people want to build e17 from source I have a python script which is > linked on the wiki which makes use of the PKGBUILDs in ABS and there is > easy_e17 available which just installs all packages without creating > .pkg.tar.gz from it. > Removed versionpkg and make_e17. -- Abhishek
[aur-general] removing versionpkg from [community]
I'll be removing versionpkg [1] from [community] soon as its functionality is already built into makepkg now. It was last updated two years ago by dtw, However this will break make_e17 [2] which depends on versionpkg. [1]: http://aur.archlinux.org/packages.php?ID=9272 [2]: http://aur.archlinux.org/packages.php?ID=7616 -- Abhishek
Re: [aur-general] [arch-dev-public] Get notified on website updates
2009/5/15 Pierre Schmitz :> > You want to get notified when there is a new upstream release. The problem is > that not all projects offer rss feeds or an announce mailing list. And if they > do they are sometimes too verbose or don't cover the updates you like. > > So needed something to watch a certain website and tell me if anything > changed. There are a lot of webservices, firefox plugins etc..; but they are > all too complicated and just don't offer what I need. Some other similar programs: * http://jue.li/crux/ck4up/ * Debian's uscan which can also download new tarballs if it detects them. It is much more complicated however. -- Abhishek
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/14 Abhishek Dasgupta : > 2009/5/14 Aaron Griffin : >> One quick thing to note - because pacman reads .PKGINFO files to get >> metadata, it's nice to have them at the beginning of the tar. tar >> --append is going to slap them on the end. This could make a >> significant difference on larger packages >> > > The previous commit was actually placing .PKGINFO at the end. The > attached patch fixes that and also uses fakeroot otherwise the tarball > would get the permissions of the user running convert-to-any. > forgot to attach last time. -- Abhishek 0001-convert-to-any-use-fakeroot-and-put-.PKGINFO-at-top.patch Description: Binary data
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/14 Aaron Griffin : > One quick thing to note - because pacman reads .PKGINFO files to get > metadata, it's nice to have them at the beginning of the tar. tar > --append is going to slap them on the end. This could make a > significant difference on larger packages > The previous commit was actually placing .PKGINFO at the end. The attached patch fixes that and also uses fakeroot otherwise the tarball would get the permissions of the user running convert-to-any. -- Abhishek
Re: [aur-general] [PATCH] __init__.py: gnomemenu removed, prettify code
Updated patch to remove gnomemenu from namcap.1 as well. -- Abhishek 0001-remove-vestiges-of-gnomemenu-prettify-__init__.py.patch Description: Binary data
[aur-general] [PATCH] __init__.py: gnomemenu removed, prettify code
Each module is put on a separate line in alphabetical order. This makes removal and addition of modules easier to spot in the diffs. I've used split() here so that I can do without the quotes and commas in the list. Signed-off-by: Abhishek Dasgupta --- Namcap/__init__.py | 34 -- 1 files changed, 32 insertions(+), 2 deletions(-) diff --git a/Namcap/__init__.py b/Namcap/__init__.py index 5100ed3..484d8a8 100644 --- a/Namcap/__init__.py +++ b/Namcap/__init__.py @@ -17,9 +17,39 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -__tarball__ = ['depends', 'directoryname', 'fileownership', 'gnomemenu', 'perllocal', 'permissions', 'symlink', 'urlpkg', 'capsnamespkg', 'emptydir', 'scrollkeeper', 'libtool', 'gnomemime', 'licensepkg', 'infodirectory', 'fhsmanpages', 'fhsinfopages'] +__tarball__ = """ + capsnamespkg + depends + directoryname + emptydir + fhsmanpages + fhsinfopages + fileownership + gnomemime + infodirectory + libtool + licensepkg + perllocal + permissions + scrollkeeper + symlink + urlpkg -__pkgbuild__ = ['md5sums', 'tags', 'url', 'invalidstartdir', 'capsnames', 'carch', 'sfurl', 'badbackups', 'license', 'arrays'] +""".split() + +__pkgbuild__ = """ + arrays + badbackups + capsnames + carch + invalidstartdir + license + md5sums + sfurl + tags + url + +""".split() __all__ = __tarball__ + __pkgbuild__ -- 1.6.2.3 -- Abhishek Dasgupta <http://abhidg.mine.nu> GPG 67972DOF pgp.mit.edu
Re: [aur-general] some candidates for moving to unsupported
2009/5/12 Abhishek Dasgupta : > Hi, > > I was going through the community bugtracker and I found a few > bugs which can be solved by moving the relevant packages to [unsupported]. > > games/campgen (maintained by dtw) moved to unsupported. > x11/xgl (#13581) (orphan) > Comment on #13581 (tomd123): > > The link says "It was finally removed [1] from the X server in favor > of AIGLX on June 12, 2008.". XGL is deprecated. I think it needs to > be removed. I've kept this in [community] for now. pkgstats shows > 5% usage. > Deprecated documentation packages (maintained by dsa) removed and closed relevant bugs. -- Abhishek
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/13 Abhishek Dasgupta :
> I've attached a diff for convert-to-any which does away with all the
> committing stuff and just makes an i686/x86_64 package into an
> architecture independent package putting the file in the same directory.
> I tested the code here and it's working.
>
updated patch using die() and some other corrections like
using quotes when accessing variables, etc.
Currently, I'm copying the i686/x86_64 package to $WORKDIR/build
and extracting it there. This causes some additional disk i/o which can
be done away with if I directly extract from the package. However
this does ensure that the original package is unharmed.
--
Abhishek
--- convert-to-any 2009-05-11 20:16:15.0 +0530
+++ convert-to-any 2009-05-13 10:32:36.0 +0530
@@ -5,24 +5,15 @@
# -- Abhishek Dasgupta
-. "$(dirname $0)/db-functions"
[ "$UID" = "" ] && UID=$(uid)
+OUTDIR="$(pwd)"
+WORKDIR="/tmp/convert-to-any.$UID"
if [ $# -ne 1 ]; then
-echo "Syntax: $(basename $0) "
+echo "Syntax: $(basename $0) "
exit 1
fi
-repo=$(echo $1 | sed "s#\(.*\)/.*#\1#g")
-pkg=$(echo $1 | sed "s#.*/\(.*\)#\1#g")
-
-if [ -f "$(dirname $0)/config" ]; then
-. "$(dirname $0)/config"
-else
-TMPDIR=/srv/tmp
-FTP_BASE=/srv/ftp
-fi
-
if [ -f /etc/makepkg.conf ]; then
. /etc/makepkg.conf
else
@@ -31,14 +22,8 @@
PKGEXT=".pkg.tar.gz"
fi
-repo_lock $repo any
-WORKDIR="$TMPDIR/convert-to-any.$pkg.$UID"
-ftppath="$FTP_BASE/$repo/os"
-
cleanup() {
trap '' 0 2
-# unlock
-repo_unlock $repo any
rm -rf "$WORKDIR"
[ "$1" ] && exit $1
}
@@ -53,56 +38,32 @@
cleanup 1
}
-# Enter the temporary build directory
-# and convert the i686 package into an
-# architecture-independent package.
mkdir -p "$WORKDIR/build"
-pushd "$WORKDIR/build" >/dev/null
-oldpkgname=$ftppath/i686/$pkg*
-if [ -f "$oldpkgname" ]; then
-cp "$oldpkgname" .
-else
-die "E: Package $oldpkgname not found in $ftppath/i686"
+oldpkgname="$1"
+
+if [ -z "$oldpkgname" ]; then
+die "convert-to-any: which package to convert?"
fi
-for architecture in i686 x86_64; do
-if [ -f "$ftppath/$architecture/$repo.db.tar.$DB_COMPRESSION" ]; then
-cp $ftppath/$architecture/$repo.db.tar.$DB_COMPRESSION \
-$repo-$architecture.db.tar.$DB_COMPRESSION
-else
-touch $repo-$architecture.db.tar.$DB_COMPRESSION
-fi
-done
+pkg="$(basename $oldpkgname)"
+newpkgname=$(echo $pkg | sed "s/-\(i686\|x86_64\)$PKGEXT/-any$PKGEXT/")
-if [ ! -d "$ftppath/any" ]; then mkdir -p "$ftppath/any"; fi
+if ! cp "$oldpkgname" "$WORKDIR/build/$pkg"; then
+die "convert-to-any: failed to copy package to $WORKDIR"
+fi
+pushd "$WORKDIR/build" >/dev/null
# Conversion of i686 package into "any" package.
-echo -n "Extracting $pkg..."
mkdir -p package
-tar zxf $pkg*i686$PKGEXT -C package
-echo " done."
+if ! tar zxf "$pkg" -C package; then
+ die "convert-to-any: error in extracting $oldpkgname"
+fi
-sed -i "s/arch = i686/arch = any/g" package/.PKGINFO
-newpkgname=$(ls $pkg*i686$PKGEXT | sed "s/i686/any/g")
+sed -i "s/arch = \(i686\|x86_64\)/arch = any/g" package/.PKGINFO
pushd package >/dev/null
-tar czf "$newpkgname" * .PKGINFO
+tar czf "$OUTDIR/$newpkgname" * .PKGINFO
popd >/dev/null
-mv "package/$newpkgname" .
-echo "Created $newpkgname."
-
-# New package is ready, move it into place and update db.
-mv "$newpkgname" "$ftppath/any/"
-for architecture in i686 x86_64; do
-# rm -f $ftppath/$architecture/$pkg*$PKGEXT
-ln -s "$ftppath/any/$newpkgname" "$ftppath/$architecture/$newpkgname"
-repo-remove -q $repo-$architecture.db.tar.$DB_COMPRESSION $pkg
-repo-add -q $repo-$architecture.db.tar.$DB_COMPRESSION $newpkgname
-mv $repo-$architecture.db.tar.$DB_COMPRESSION "$ftppath/os/$architecture"
-echo "Updated $repo-$architecture for $pkg."
-done
-echo -n "Cleaning up..."
popd >/dev/null
cleanup
-echo " done."
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/13 Aaron Griffin :
> On Tue, May 12, 2009 at 4:57 AM, Firmicus wrote:
>> Aaron Griffin:
>>> Regarding the new convert2any script you added - I'd prefer to fix the
>>> existing script rather than add a new one - or at least preserve some
>>> of the logic (such as sourcing of makepkg.conf)
>>
>> All right, perhaps Abhishek can do that? ;)
>
> Yeah, I'm gonna try to merge your changes into the existing script.
> It's not a show-stopper though
>
I've attached a diff for convert-to-any which does away with all the
committing stuff and just makes an i686/x86_64 package into an
architecture independent package putting the file in the same directory.
I tested the code here and it's working.
I would've attached a git patch but for some weird reason no application
in the terminal can access the net! Firefox works fine though.
--
Abhishek
--- convert-to-any 2009-05-11 20:16:15.0 +0530
+++ convert-to-any 2009-05-13 10:13:30.0 +0530
@@ -5,24 +5,15 @@
# -- Abhishek Dasgupta
-. "$(dirname $0)/db-functions"
[ "$UID" = "" ] && UID=$(uid)
+OUTDIR="$(pwd)"
+WORKDIR="/tmp/convert-to-any.$UID"
if [ $# -ne 1 ]; then
-echo "Syntax: $(basename $0) "
+echo "Syntax: $(basename $0) "
exit 1
fi
-repo=$(echo $1 | sed "s#\(.*\)/.*#\1#g")
-pkg=$(echo $1 | sed "s#.*/\(.*\)#\1#g")
-
-if [ -f "$(dirname $0)/config" ]; then
-. "$(dirname $0)/config"
-else
-TMPDIR=/srv/tmp
-FTP_BASE=/srv/ftp
-fi
-
if [ -f /etc/makepkg.conf ]; then
. /etc/makepkg.conf
else
@@ -31,14 +22,8 @@
PKGEXT=".pkg.tar.gz"
fi
-repo_lock $repo any
-WORKDIR="$TMPDIR/convert-to-any.$pkg.$UID"
-ftppath="$FTP_BASE/$repo/os"
-
cleanup() {
trap '' 0 2
-# unlock
-repo_unlock $repo any
rm -rf "$WORKDIR"
[ "$1" ] && exit $1
}
@@ -56,53 +41,34 @@
# Enter the temporary build directory
# and convert the i686 package into an
# architecture-independent package.
-mkdir -p "$WORKDIR/build"
-pushd "$WORKDIR/build" >/dev/null
-oldpkgname=$ftppath/i686/$pkg*
-if [ -f "$oldpkgname" ]; then
-cp "$oldpkgname" .
-else
-die "E: Package $oldpkgname not found in $ftppath/i686"
+oldpkgname=$1
+
+if [ -z $oldpkgname ]; then
+echo "convert-to-any: which package to convert?"
+ exit 1
fi
-for architecture in i686 x86_64; do
-if [ -f "$ftppath/$architecture/$repo.db.tar.$DB_COMPRESSION" ]; then
-cp $ftppath/$architecture/$repo.db.tar.$DB_COMPRESSION \
-$repo-$architecture.db.tar.$DB_COMPRESSION
-else
-touch $repo-$architecture.db.tar.$DB_COMPRESSION
-fi
-done
+newpkgname=$(echo $oldpkgname | sed "s/-\(i686\|x86_64\)$PKGEXT/-any$PKGEXT/")
-if [ ! -d "$ftppath/any" ]; then mkdir -p "$ftppath/any"; fi
+mkdir -p "$WORKDIR/build"
+if ! cp $oldpkgname "$WORKDIR/build/$(basename $oldpkgname)"; then
+echo "convert-to-any: failed to copy package to $WORKDIR"
+exit 1
+fi
+pushd "$WORKDIR/build" >/dev/null
# Conversion of i686 package into "any" package.
-echo -n "Extracting $pkg..."
mkdir -p package
-tar zxf $pkg*i686$PKGEXT -C package
-echo " done."
+if ! tar zxf $oldpkgname -C package; then
+ echo "convert-to-any: error in extracting $oldpkgname"
+exit 1
+fi
-sed -i "s/arch = i686/arch = any/g" package/.PKGINFO
-newpkgname=$(ls $pkg*i686$PKGEXT | sed "s/i686/any/g")
+sed -i "s/arch = \(i686\|x86_64\)/arch = any/g" package/.PKGINFO
pushd package >/dev/null
-tar czf "$newpkgname" * .PKGINFO
+tar czf "$OUTDIR/$newpkgname" * .PKGINFO
popd >/dev/null
-mv "package/$newpkgname" .
-echo "Created $newpkgname."
-
-# New package is ready, move it into place and update db.
-mv "$newpkgname" "$ftppath/any/"
-for architecture in i686 x86_64; do
-# rm -f $ftppath/$architecture/$pkg*$PKGEXT
-ln -s "$ftppath/any/$newpkgname" "$ftppath/$architecture/$newpkgname"
-repo-remove -q $repo-$architecture.db.tar.$DB_COMPRESSION $pkg
-repo-add -q $repo-$architecture.db.tar.$DB_COMPRESSION $newpkgname
-mv $repo-$architecture.db.tar.$DB_COMPRESSION "$ftppath/os/$architecture"
-echo "Updated $repo-$architecture for $pkg."
-done
-echo -n "Cleaning up..."
popd >/dev/null
cleanup
-echo " done."
[aur-general] some candidates for moving to unsupported
Hi, I was going through the community bugtracker and I found a few bugs which can be solved by moving the relevant packages to [unsupported]. games/campgen (maintained by dtw) Old and the homepage says that there is no version which works with wesnoth 1.6 in Arch repositories. This would remove this package from the python 2.6 rebuild list (#13831) x11/xgl (#13581) (orphan) Comment on #13581 (tomd123): The link says "It was finally removed [1] from the X server in favor of AIGLX on June 12, 2008.". XGL is deprecated. I think it needs to be removed. Deprecated documentation packages (maintained by dsa) devel/gnome-vfs-docs (#13512) devel/glade-docs (#13509) devel/libxml2-docs (#13559) devel/libsoup-docs (#13536) -- Abhishek
Re: [aur-general] Mutt vs Gmail (Was: An idea for vim scripts/plugins)
2009/5/11 Andrei Thorp : > Also, despite the mutt way being pretty nice and unixy (letting me > script it easily into my window manager and so on), gmail just has an > excellent interface with the folding, images, and so on. I hate to not > use the classic mail setup everywhere, but it's just not as tidy > anymore :/ > > What do people think on this topic? I personally find gmail to be > extremely convenient, but I'm willing to be enlightened otherwise. > I use the gmail interface mostly but keep a backup using offlineimap. In principle it's possible to use mutt+offlineimap but with my slow internet connection it takes quite a while to sync; also offlineimap crashes quite often when trying to download attachments over 5 MB. Earlier I used fdm but that downloaded quite a few mails more than once. -- Abhishek
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/6 Firmicus : > Why move up-to-date packages to simply change the arch parameter? We can > easily change it in the PKGBUILDs in trunk and it will occur > automatically with the next update. There is no benefit in converting > the actual packages, really. It may save some space on the server and > the mirrors but the risk that we thereby mess things up does not > justify this IMHO. > Agreed. The only advantage would be for people mirroring the repos. > PS: I've attached my updated patch for dbscripts, with additional > changes for cron-jobs/adjust-permissions > and cron-jobs/check_archlinux/check_packages.py > The attachment didn't come through, probably it was deleted by mailman. -- Abhishek
Re: [aur-general] [arch-dev-public] Status of arch=any ?
2009/5/6 Firmicus : > OK, back to topic. First of all, the git repo you gave me does not have > the patches from Abhishek. I finally figured out that I had to pull his > branch any-arch from github. Aaron's git repo also mirrors my any-arch branch on github so you should have got it when you cloned. > > I have fixed quite a few bugs in db-update and rewritten some sections > (patch attached). > > Then I have tested it quite intensively with all possible scenarios, > and, as far as I can tell, it works fine! > > BTW, the script convert-to-any is quite broken. I have first tried to > fix it but soon realized it is actually not a good idea to rely on it at > all. Better to create clean packages for arch=any instead. > There are quite a lot of packages which need to be moved to the any architecture. If all of them have to be rebuilt it'll be a waste of time. I'll look through the convert-to-any script and try to fix it next week. Making this script work properly will save us a lot of time later. -- Abhishek
Re: [aur-general] Huge packages in community
2009/5/3 Abhishek Dasgupta : > rsync has an exclude option which can selectively exclude files > from being synchronized. Removing a package from community.db.tar.gz > is also easy. > Also, just noticed this option in rsync(1): --max-size: don't transfer any file larger than SIZE -- Abhishek
Re: [aur-general] Huge packages in community
2009/5/3 Chris Brannon : > This argument is about a technical problem, rather than a social > or cultural one. The debate will go away when the technical problem is > solved. > Packages in [community] have categories, and one of those categories is > "games". One solution is a "partial mirror" script, which excludes > packages from a mirror based on their category. > This also obviates any perceived need to split [community]. > Someone has to write the script, but it seems like a good idea to me! > rsync has an exclude option which can selectively exclude files from being synchronized. Removing a package from community.db.tar.gz is also easy. -- Abhishek
Re: [aur-general] Deletion request for 'changefirefoxicon'
2009/4/26 Daenyth Blank :
>
> Damn, did anyone save a copy? I want to see it...
>
At least for a few days I think, AUR keeps a copy:
http://aur.archlinux.org/packages/changefirefoxicon/changefirefoxicon/PKGBUILD
In case it's deleted, I'm reproducing it here:
pkgname=changefirefoxicon
pkgver=0.1
pkgrel=1
pkgdesc='Change the Firefox icon in Arch to the original one.'
arch=('i686','x86_64')
license=('GPL3')
url='http://saffire.puntolibre.org'
depends=()
source=http://saffire.puntolibre.org/Proyectos/ChangeFirefoxIcon/ChangeFirefoxIcon-$pkgver.tar.gz
md5sums=('bab25c933d01ae2eee50b8299ccfe024')
build() {
pacman -U
http://saffire.puntolibre.org/Proyectos/ChangeFirefoxIcon/ChangeFirefoxIcon-0.1.tar.gz
}
--
Abhishek
Re: [aur-general] Deletion request for 'changefirefoxicon'
2009/4/26 Sven-Hendrik Haase : > I request the AUR package 'changefirefoxicon' be deleted for duplicate (of > 'firefox-branded') and severe breach of all good PKGBUILD rules. Just look > at it, but I warn you as you might fall right from your chair either > laughing or crying. Please just delete it. > Deleted. That was certainly the strangest PKGBUILD I'd ever seen! -- Abhishek
Re: [aur-general] namcap modules: gnomemenu gnomemime
2009/4/22 Hugo Doria : > Hi Abhishek, > > gnomemenu.py can be removed. I will remove it and create a > desktopfiles.py that verifies if all .desktop files from the package > are in /usr/share/applications. > > To fix gnomemime.py a change from "/opt/gnome/share/" to "/usr/share" is > enough. > > What do you think? > OK, just one thing, isn't /usr/share/mime/ shared by all freedesktop.org apps? Or is it just GNOME? I've a suggestion for the tag name for desktopfiles.py: desktop-file-incorrect-placement -- Abhishek
Re: [aur-general] namcap modules: gnomemenu gnomemime
2009/4/15 Abhishek Dasgupta : > The code in the these two files is quite old since they refer > to the /opt/gnome path for GNOME files which was changed > to /usr quite a while back. > > They should either be deleted or changed to reflect the current > changes. Are the tags relevant for the current GNOME? > bump. any thoughts? -- Abhishek
Re: [aur-general] Packaging perl modules - best practices for dependancies?
2009/4/20 Oliver Charles : > Hi all, > > I used to use Arch a while ago, and packaged quite a few Perl modules > [1]. After switching operating systems, I've come back to Arch - and I > need to be a good maintainer of my packages :) > > I remember when I wrote these how frustrating it was manually writing > just about every package for the dependancy tree. Personally, I'm of > the stance that you should choose one package manager and stick with > it - either all CPAN or fully Pacman/AUR. However, I've seen quite a > few packages that do not do this. Instead, they rely on the fact that > Build.PL and Makefile.PL are both capable of installing dependancies > from CPAN. > > Like I said, I personally don't like this approach of mixing 2 package > managers, it just seems like a recipe for confusing both package > managers. > > Could anyone shed some light on what the *correct* procedure is - and > also if there any tools out there that will scrape CPAN to build > packages, before I write my own (in Perl, of course ;) > You can use perl-cpanplus-pacman [1] or pacpan [2] (webpage [3]). [1]: http://aur.archlinux.org/packages.php?ID=5954 [2]: http://aur.archlinux.org/packages.php?ID=23495 [3]: http://xyne.archlinux.ca/info/pacpan
[aur-general] [PATCH] fix some errors and omissions in tags and namcap.1
namcap.1: changed capitalisation of archlinux to Arch Linux updated namcap version, date and copyright year fixed some spelling mistakes added machine-readable flag to the man page. tags: fixed description of file-world-writable fixed description of directory-not-world-executable fixed spelling mistake (dependences) Signed-off-by: Abhishek Dasgupta --- namcap.1 | 19 +++ tags |6 +++--- 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/namcap.1 b/namcap.1 index af0ccf4..d5b3554 100644 --- a/namcap.1 +++ b/namcap.1 @@ -1,22 +1,25 @@ -.TH namcap 1 "July 24, 2007" "namcap 2.0" "User Commands" +.TH namcap 1 "April 19, 2009" "namcap 2.2" "User Commands" .SH NAME namcap \- package analysis utility .SH SYNOPSIS \fBnamcap [options] [package|PKGBUILD] ... .SH DESCRIPTION .PP -\fBnamcap\fP is a \fIpackage analysis\fP utility that looks for problems with archlinux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files. +\fBnamcap\fP is a \fIpackage analysis\fP utility that looks for problems with Arch Linux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files. .PP -Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info arguement. Information messages give information that might be helpful but isn't anything that needs changing. +Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing. .SH OPTIONS .TP .B "\-i, \-\-info" display information messages .TP +.B "\-m, \-\-machine\-readable" +displays easily parseable namcap tags instead of the normal human readable description; for example using non-fhs-man-page instead of "Non-FHS man page (%s) found. Use /usr/share/man instead". A full list of namcap tags along with their human readable descriptions can be found at /usr/share/namcap/tags. +.TP \fB\-r\fR RULELIST, \fB\-\-rules=\fRRULELIST only apply RULELIST rules to the package .IP -RULELIST is a comma-seperated list of rule names; if RULELIST=list then namcap returns a list of valid rules and their descriptions +RULELIST is a comma-separated list of rule names; if RULELIST=list then namcap returns a list of valid rules and their descriptions .SH RULES .TP .B arrays @@ -35,12 +38,12 @@ capsnames checks a PKGBUILD to verify the package name does not include upper ca capsnamespkg checks a package to verify the package name does not include upper case characters .TP .B depends -depends runs ldd on all executables, gets the link-level dependencies, finds the smallest subset of dependencies that cover the link-level dependencies, and compares that list to the depends of the package. It returns messages in three cases: dependency detected and not included, dependency included but already satisfied, and dependency included and not needed. These suggestions are just guidelines and all package builders should take this into account (ie. you're smarter than namcap is) +depends runs ldd on all executables, gets the link-level dependencies, finds the smallest subset of dependencies that cover the link-level dependencies, and compares that list to the depends of the package. It returns messages in three cases: dependency detected and not included, dependency included but already satisfied, and dependency included and not needed. These suggestions are just guidelines and all package builders should take this into account (i.e. you're smarter than namcap is) -Some cases where namcap fails are dlopen() and obscure links. dlopen()'d libraries don't show up because they are loaded at run time: in the case of a prgram that loads plugins. Obscure links are the cases where only a small portion of the package needs something to run; usually, the small portion won't be accesed unless that thing is installed (i.e. a java plug
[aur-general] namcap modules: gnomemenu gnomemime
The code in the these two files is quite old since they refer to the /opt/gnome path for GNOME files which was changed to /usr quite a while back. They should either be deleted or changed to reflect the current changes. Are the tags relevant for the current GNOME? -- Abhishek
Re: [aur-general] python-apsw package
2009/4/13 Juan Miguel Cejuela : > To Abhishek, > > Thank you for answering. However, I can't make $srcdir/LICENSE since the > license is not included in their source. I made it copying it from their > web. > > *Then, how I can move LICENSE without using $startdir?* > > I can do ../$srcdir but that seems even worse > > I see in some packages that in their source array include simply LICENSE > plus the real source. I guess the file LICENSE located in the package > tarball is fetched and then included in the src, but I don't see any > documentation about this in the wiki. > You should keep LICENSE in the source array. All files in the source array are symlinked in $srcdir, so you'll be able to use $srcdir/LICENSE. The current PKGBUILD does work, but I guess you manually made a tarball and uploaded it. If you'd used makepkg --source then LICENSE would not have been included in the src.tar.gz produced. -- Abhishek
Re: [aur-general] python-apsw package
2009/4/12 Juan Miguel Cejuela :
> I have just updated and started to maintain the python-apsw package (the
> current version in AUR was from Oct 2007, when the last version is from Feb
> 2009)
>
> This package is needed for the tribler package (bittorrent client)
>
> Please let me know if you use this library and therefore whether the package
> is useful.
>
> And of course, give me any suggestion for the PKGBUILD since this is my
> first package I submit.
>
> Have a good day!!
The PKGBUILD looks OK, just use $srcdir and $pkgdir since
$startdir is not guaranteed to remain around.
So the build() function would be:
build() {
cd $srcdir/apsw-3.6.11-r1
python setup.py install --root=$pkgdir/
install -D -m644 $srcdir/LICENSE $pkgdir/usr/share/licenses/$pkgname/LICENSE
}
--
Abhishek
Re: [aur-general] Questions from a new TU
2009/4/12 Xyne : [ snip ] > Wouldn't it make more sense to use these tags to determine the port > when uploading binary packages to community? This would also be useful > for uploading "any" packages (which I suppose need to be uploaded > twice). Just to clarify, currently [community] does not support the "any" architecture, so you'll have to use arch=(i686 x86_64) > 2) How can I upload both x86_64 and i686 packages from the same > machine? When trying to upload an i686 package with communitypkg, it > complains that it couldn't find the x86_64 package. I did change the > port of tupkg but I didn't try it without communitypkg. I have a 64-bit machine on which I have a 32-bit chroot where I build the i686 versions, see for example: http://wiki.archlinux.org/index.php/Arch64_FAQ#Can_I_build_32-bit_packages_for_i686_inside_Arch64.3F http://wiki.archlinux.org/index.php/Arch64_Install_bundled_32bit_system In the i686 environment which I chroot to using linux32, CARCH etc is set to i686, so communitypkg does not complain. -- Abhishek
Re: [aur-general] Watch list
2009/4/12 Xyne : > You could write a script to parse the output from > http://aur.archlinux.org/rpc.php?type=search&arg= > > That includes whether is outdated, the number of votes, version > number, etc. If you want comments then I think you need to scrape the > web page. > The code for seeing comments is there in yaourt. -- Abhishek
Re: [aur-general] namcap tag: hicolor-icon-cache-not-updated
2009/4/11 Jan de Groot : > Looks great, and really saves me doing some work (or bugs sneaking in > new versions of packages). > > This dependency check on hicolor-icon-theme, does it traverse down the > dependency tree, or does it only look at what is in depends=()? It just looks at depends() right now. I'll see if I can make use of the information gleaned in Namcap/depends.py to check for hicolor-icon-theme further down in the dependency chain. > As for the gtk-update-icon-cache check: there's an alternative provided > by xdg-utils. An example can be found in openjdk6 and cups. This method > uses xdg-icon-resource. OK, I'll add support for checking this in the code. -- Abhishek
[aur-general] namcap tag: hicolor-icon-cache-not-updated
According to http://wiki.archlinux.org/index.php/Gnome_package_guidelines#GTK_Icon_cache packages which install icons in /usr/share/icons/hicolor should depend on hicolor-icon-theme and invoke gtk-update-icon-cache. I've made a namcap module [1] which checks for the existence of the /usr/share/icons/hicolor directory and then sees if gtk-update-icon-cache is called in the install file and if hicolor-icon-theme is in the depends array. Otherwise it is reported as an error. http://github.com/abhidg/namcap/blob/d0f27f98d4e91b3fe37fc41395d0ba713f421013/Namcap/hicoloricons.py -- Abhishek
