Re: [aur-general] lb32-irrklang removal request
On Tue, Dec 10, 2013 at 8:52 AM, John Schroeder jschr...@gmail.com wrote: Package Name: lb32-irrklang URL to AUR page: https://aur.archlinux.org/packages/lb32-irrklang/ I accidentally created the package lb32-irrklang when I met to create lib32-irrklang. I am the maintainer of these packages. Deleted, thx. -- Maxime
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 4 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (2 total) == * pidgin-lwqq-0.2c.20131206-1 (i686) * pidgin-lwqq-0.2c.20131206-1 (x86_64) == Incomplete signoffs for [community] (4 total) == * pidgin-lwqq-0.2c.20131206-1 (i686) 0/1 signoffs * virtualbox-modules-4.3.4-2 (i686) 0/1 signoffs * pidgin-lwqq-0.2c.20131206-1 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.4-2 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. thomas - 1 signoffs
[aur-general] Status of package gregorio-svn
Dear David, Your package gregorio-svn in AUR[1] needs maintainance. It currently doesn't follow the new VCS PKGBUILD Guidelines[1], and doesn't build correctly with the latest upstream source changes. Please fix your package, or at least disown it, so other people can go on with its maintainance. CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio [1] https://aur.archlinux.org/packages/gregorio-svn [2] https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines
[aur-general] Merge request (pygeoip into python2-pygeoip)
Hello, Could you please merge my package pygeoip [1] into python2-pygeoip [2] ? Since it is a python2 package its correct name should be python2-pygeoip. Thanks 1: https://aur.archlinux.org/packages/pygeoip/ 2: https://aur.archlinux.org/packages/python2-pygeoip/
Re: [aur-general] Merge request (pygeoip into python2-pygeoip)
On Tuesday, December 10, 2013 14:06:20 sebast...@sleduc.fr wrote: Hello, Could you please merge my package pygeoip [1] into python2-pygeoip [2] ? Since it is a python2 package its correct name should be python2-pygeoip. Thanks 1: https://aur.archlinux.org/packages/pygeoip/ 2: https://aur.archlinux.org/packages/python2-pygeoip/ Merged, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[aur-general] 'provides' info in AUR
Hey, I wonder if it is possible to query the `provides` of a package in AUR?
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough?
Re: [aur-general] 'provides' info in AUR
2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that?
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this.
Re: [aur-general] 'provides' info in AUR
2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this. Okay, understand, so that's a todo, I guess.
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this. Okay, understand, so that's a todo, I guess. Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to: 1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful. The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this would leave you with a useless feature as only a fraction of applicable packages would have the data. d
Re: [aur-general] 'provides' info in AUR
2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this. Okay, understand, so that's a todo, I guess. Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to: 1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful. The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this How about change `makepkg --source` to let it generate a PHP-parsing friendly format like the `ini` format in the final src tarball, doss this solves everything? would leave you with a useless feature as only a fraction of applicable packages would have the data. d
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 3:16 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: 2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this. Okay, understand, so that's a todo, I guess. Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to: 1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful. The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this How about change `makepkg --source` to let it generate a PHP-parsing friendly format like the `ini` format in the final src tarball, doss this solves everything? That's exactly what .PKGINFO files are and it's imho the only sane way to do this. Problem are, they're not generated by -S. would leave you with a useless feature as only a fraction of applicable packages would have the data. d
Re: [aur-general] 'provides' info in AUR
2013/12/10 Jerome Leclanche adys...@gmail.com: On Tue, Dec 10, 2013 at 3:16 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: 2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Dave Reisner d...@falconindy.com: On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: 2013/12/10 Karol Blazewicz karol.blazew...@gmail.com: On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote: Hey, I wonder if it is possible to query the `provides` of a package in AUR? Is e.g. 'cower -ii wine-git' good enough? Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this. Okay, understand, so that's a todo, I guess. Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to: 1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful. The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this How about change `makepkg --source` to let it generate a PHP-parsing friendly format like the `ini` format in the final src tarball, doss this solves everything? That's exactly what .PKGINFO files are and it's imho the only sane way to do this. Problem are, they're not generated by -S. would leave you with a useless feature as only a fraction of applicable packages would have the data. That shold be an easy fix, I guess, someone just need to acctually submit the patch and discuss it with Allan.
[aur-general] Disowning some packages
Hi, I'm disowning some of my packages because I do not need them any more. Feel free to adopt them. :) Stefan https://aur.archlinux.org/packages/python2-hgapi/ https://aur.archlinux.org/packages/python-hgapi/ https://aur.archlinux.org/packages/shovel/ https://aur.archlinux.org/packages/git-extras/ https://aur.archlinux.org/packages/python2-feedgenerator/ signature.asc Description: OpenPGP digital signature
Re: [aur-general] Disowning some packages
Taking shovel. J. Leclanche On Tue, Dec 10, 2013 at 3:29 PM, Stefan Tatschner ste...@sevenbyte.org wrote: Hi, I'm disowning some of my packages because I do not need them any more. Feel free to adopt them. :) Stefan https://aur.archlinux.org/packages/python2-hgapi/ https://aur.archlinux.org/packages/python-hgapi/ https://aur.archlinux.org/packages/shovel/ https://aur.archlinux.org/packages/git-extras/ https://aur.archlinux.org/packages/python2-feedgenerator/
Re: [aur-general] TU application - Sponsored by Balló György
Hi Martin, Thanks for applying! I think it's positive that you've got some experience under your belt. The randomly chosen AUR packages you maintain that I inspected looks well crafted, sound and healthy to me. Just from quickly browsing the Arch Installer on github, it looks promising too. I won't ask about vim vs emacs so... what's your favorite git command? -- Best of luck, Alexander Rødseth xyproto / TU
Re: [aur-general] TU application - Sponsored by Balló György
Hi, I am fond of all the `git` commands mentioned in my blog about migrating Bazaar to Git. * http://flexion.org/posts/2012-10-migrating-bzr-to-git.html If I had to pick an absolute favourite `git` command then `git commit` but `git stash` is pretty handy. -- Regards, Martin. On Tue, 2013-12-10 at 22:08 +0100, Alexander Rødseth wrote: Hi Martin, Thanks for applying! I think it's positive that you've got some experience under your belt. The randomly chosen AUR packages you maintain that I inspected looks well crafted, sound and healthy to me. Just from quickly browsing the Arch Installer on github, it looks promising too. I won't ask about vim vs emacs so... what's your favorite git command? signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
git commit sounds like a fine choice of to me. :) But what's with the top posting? Is it a statement, or due to the choice of email client? I know some mobile email clients makes it hard not to top post. In any case, I think you have a fine application and wish you the best of luck in the rest of the discussion period and in the following vote. - Alexander / xyproto
Re: [aur-general] TU application - Sponsored by Balló György
On 2013-12-10 18:27 + Martin Wimpress wrote: a great application Regards, Martin. Hi, That is a very nice application. It leaves no doubt concerning your skill and dedication (assuming that it's all true... Balló left carrying rubber gloves, so I expect that he was thorough in vetting you). Having someone from upstream maintain the MATE ecosystem would ensure a great user experience, and you are clearly capable of maintaining the packages in a repo. Your PKGBUILDs look good overall but I noticed two things. The first is the absence of quoted variables (e.g $srcdir), but you mentioned that you wrote a script to generate PKGBUILDs so perhaps that is a single, central fault? The second is the absence of prepare functions. There are numerous packages that modify existing source files in the build and/or package functions (e.g. several replace python with python2). All such modifications should be done in a separate prepare function when possible. Beyond that there were just a few niggles. For example, I wonder why you check if the CARCH variable is empty in the brother-mfc7360n-lpr package [1]. The arch array restricts available architectures to x86_64 and i686, so the warning doesn't make sense to me. There are also some apparently inherited PKGBUILD issues, e.g. the missing package function in nullmailer [2] but I presume those will be fixed whenever the next update happens. Regards, Xyne Btw, if anyone is interested, I have added a maintainer option to pbget because I wanted to grep all of the PKGBUILDs (e.g. $ pbget --maintainer flexiondotorg; grep -r --color -C 3 sed). [1] https://aur.archlinux.org/packages/br/brother-mfc7360n-lpr/PKGBUILD [2] https://aur.archlinux.org/packages/nullmailer/
Re: [aur-general] TU application - Sponsored by Balló György
Hi, On Tue, 2013-12-10 at 23:10 +0100, Alexander Rødseth wrote: git commit sounds like a fine choice of to me. :) But what's with the top posting? Is it a statement, or due to the choice of email client? I know some mobile email clients makes it hard not to top post. Not a statement. It was due to the defaults and a new install that hadn't been configured. In any case, I think you have a fine application and wish you the best of luck in the rest of the discussion period and in the following vote. Thanks. -- Regards, Martin. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
Hi, On Tue, 2013-12-10 at 22:14 +, Xyne wrote: That is a very nice application. It leaves no doubt concerning your skill and dedication (assuming that it's all true... Balló left carrying rubber gloves, so I expect that he was thorough in vetting you). Having someone from upstream maintain the MATE ecosystem would ensure a great user experience, and you are clearly capable of maintaining the packages in a repo. Thanks for your kind words. If you want to find out if my background is genuine you can ask over at #mate-dev@freenode Balló has also been very helpful over the last week or so. Your PKGBUILDs look good overall but I noticed two things. The first is the absence of quoted variables (e.g $srcdir), but you mentioned that you wrote a script to generate PKGBUILDs so perhaps that is a single, central fault? Balló has pointed that out too and it will be resolved in the next few days. The second is the absence of prepare functions. There are numerous packages that modify existing source files in the build and/or package functions (e.g. several replace python with python2). All such modifications should be done in a separate prepare function when possible. Also recently pointed out and I have actually started the transition, see the mate-file-archiver PKGBUILD below. * https://github.com/mate-desktop/archlinux-packages/blob/master/mate-file-archiver/PKGBUILD The other PKGBUILDs that require prepare() will be updated in the next few days. Beyond that there were just a few niggles. For example, I wonder why you check if the CARCH variable is empty in the brother-mfc7360n-lpr package [1]. The arch array restricts available architectures to x86_64 and i686, so the warning doesn't make sense to me. I based the PKGBUILD on another in the AUR. I needed to get a new printer working for my in-laws (who also run Arch Linux) and only did the bare minimum to get the packages working. I'll clean them up at some point. There are also some apparently inherited PKGBUILD issues, e.g. the missing package function in nullmailer [2] but I presume those will be fixed whenever the next update happens. Partly an inheritance issue and partly that I've learnt a hell of a lot in the past few months sorting out the MATE packages for Arch Linux and haven't applied all I have learnt to the other packages. I'll get the `nullmailer` package sorted ASAP. Thanks for the feedback, it is all very useful. -- Regards, Martin. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application - Sponsored by Balló György
2013. 12. 10, kedd keltezéssel 18.27-kor Martin Wimpress ezt írta: Hi, I'd like to submit my application to become a Trusted User. I've been sponsored by Balló György (aka City-busz). You can find my public key here: * http://pool.sks-keyservers.net/pks/lookup?op=getsearch=0x654B877A0864983E I'm a forty something information technology professional and Linux enthusiast. I live in Hampshire, England, with my wife and daughter. I have some grey hair, a beer belly and I'm a killer systems administrator. I'd like to join the team because I'd really like to bring MATE to the official Arch Linux [community] repository. I've been a member of the MATE team for some months now and in that time I've: * Become the principle Arch Linux package maintainer * Got MATE 1.6 stable on Arch Linux * Created a new build script to automate package builds * Created new build hosts to build MATE packages for i686 and x86_64 * Created new build hosts to build MATE packages for armv6h and armv7h * Signed the unofficial MATE package repositories * Been given root shell accounts on all the MATE infrastructure servers * Created a new website for the MATE project (http://mate-desktop.org) * Become a MATE Forum moderator and administrator * Taken ownership of every MATE package in the AUR * Started MATE 1.7 packaging for Arch Linux * Gone on many bug hunting expeditions Here are all the relevant links regarding my work with the MATE team. * http://mate-desktop.org * http://mate-desktop.org/blog/2013-11-16-mate-1.6-packages-for-arch-linux/ * https://github.com/mate-desktop/archlinux-packages * https://github.com/mate-desktop/mate-desktop.org * http://forums.mate-desktop.org/viewforum.php?f=4 * http://wiki.mate-desktop.org/archlinux_custom_repo * http://repo.mate-desktop.org/archlinux/ Here's some additional background about myself. I've been running Linux distributions since 1995, I've transitioned through Slackware, Redhat, Crux, Debian/Ubuntu and settled on Arch Linux nearly 2 years ago. I dev using Shell, Python, PHP, SQL, HTML/CSS and know enough C/C++ to bug hunt. I started using CVS in the late 1990s and moved to Subversion then Bazaar and now Git. Some examples of my personal projects. * https://github.com/flexiondotorg/ArchInstaller * https://github.com/flexiondotorg/oab-java6 * https://github.com/flexiondotorg/nullserv By day I work for Flight Data Services. I'm the technical lead and created the business plan that led to us Open Sourcing most of our technologies. * https://github.com/FlightDataServices * http://www.flightdatacommunity.com/ Most of my contribution to Arch Linux has been through the AUR and you'll find me lurking in #archlinux@freenode. I contributed my first package to the AUR on the first week I started using Arch Linux. Since then I've adopted a few packages and added a selection of my own. * https://aur.archlinux.org/packages/?SeB=mK=flexiondotorg In addition to MATE I'd be interested in migrating some of my other packages to [community], for example: * https://aur.archlinux.org/packages/bzr-fastimport/ * https://aur.archlinux.org/packages/finalterm-git/ (when stable) * https://aur.archlinux.org/packages/lib32-nss-mdns/ * https://aur.archlinux.org/packages/lib32-xulrunner/ * https://aur.archlinux.org/packages/libaacs/ * https://aur.archlinux.org/packages/nullmailer/ I've contributed to countless Open Source projects over the years and I am a member of my local LUG. When I'm not geeking out I play with my daughter and go running. Like all great Open Source contributors I scuba dive ;-) Oh yeah, I love Arch Linux. I'm confirming my sponsorship. I think that the MATE desktop environment will be a great addition for Arch Linux, and Martin will be a great addition for the team. :) A discussion period of 5 days has been started now. -- György Balló Trusted User signature.asc Description: This is a digitally signed message part
[aur-general] Merge request: sdlpal--sdlpal-git
Hi, Please merge my package sdlpal[1] into sdlpal-git[2]. The upsteam now use git to manage source code. [1]: https://aur.archlinux.org/packages/sdlpal/ [2]: https://aur.archlinux.org/packages/sdlpal-git/ Thanks, Shaw
