Re: [aur-general] Perl Upgrade, make test failures and you: The Hurt That Finds You First
I was wondering about this myself. I think the tests failing might indicate that broken modules are being used but it's probably too late to know for sure. Unofficial, platform-dependent perl modules (i.e. those with .so files) need to be rebuilt for perl 5.20 which I assume you noticed, John. To really get to the bottom of things, it helps to cut through the layers of abstraction and just run the test script directly. For example something like this might give you a more explicit error message: perl -Mblib src/perl-whatever-01/t/00-modules.t Back to your terse, error message. In the test harness, Wstat is the wait status of the perl process that ran the test. If you shift 512 right by 8 bits, you get 2, which is the exit status. This doesn't indicate a segfault, though, which is surprising. If that were true one of the first 8 bits would be set, I think. Anyways, it's probably too late to tell what was causing your test failures. -- -Justin
Re: [aur-general] Perl update
Sorry to revive this, I just saw this when searching my email for a CPANPLUS::Dist::Arch patch. perl-pathtools should, in theory, be provide-ed by the perl package. PathTools is a CPAN distribution, whose modules are core modules. PathTools includes venerable core modules like File::Spec and Cwd. So at first glance this looks like the provides.pl script in the perl perl source package has a bug and is missing perl-pathtools! I will look into this further, since this is ultimately my fault! John, I very much appreciate the sentiment :) but in Florian's defense he keeps the perl-cpanplus-dist-arch package very up to date and in a timely manner. The perl-cpanplus-dist-arch-git package doesn't get much usage and I should probably delete it. PathTools: https://metacpan.org/release/PathTools File::Spec in core: http://perldoc.perl.org/File/Spec.html provides.pl: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/perl -- -Justin
Re: [aur-general] TU Application - Ike Devolder
I like how Ike disarmed two potential flame war hijackings in one thread! Ike seems pretty cool. -- -Justin
Re: [aur-general] Package Deletion Request: perl-shared
On Sat, Feb 25, 2012 at 4:06 PM, Jason St. John jstj...@purdue.edu wrote: perl-shared[1] should be deleted because it is *very* out of date, has 0 votes, has been orphaned, and the official 'perl' package provides the same functionality[2]. [1] https://aur.archlinux.org/packages.php?ID=25536 [2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/perl Thanks! __ Jason St. John Graduate Research Assistant, Department of Computer and Information Technology, Purdue University Deleted, thanks. -- -Justin
Re: [aur-general] TU Resignation
Goodbye Angel! Best of luck to you. -- -Justin
[aur-general] aurperl orphanage
I'm orphaning about 600 perl packages from the AUR. I no longer have the time or feel the urge to maintain these packages anymore and there seems to be other people interested lately. About a year ago most of these packages were orphaned by xenoterracide and I wanted to keep an eye on them and update the ones people were using, or were complaining about being broken, adding comments to, etc. I think most of them are junk and don't really need to be on the AUR but I updated a little over 200 of them regularly. Anyways... if you like maintaining perl packages, pick up your favorite. I have a list of them all but it's pretty long so I didn't paste it in here. -- -Justin
Re: [aur-general] aurperl, who is?
Ive orphaned it. On Dec 17, 2011 5:30 AM, Florian Pritz bluew...@xinu.at wrote: On 17.12.2011 11:24, Piotr Rogoża wrote: Hello Who is the user aurperl? I need an updated one package which belong to this user i.e. perl-orlite-migrate: https://aur.archlinux.org/packages.php?ID=31055 I wrote to him, and I'm waiting. But isn't this fictitious user? Looks like it belongs to Justin. I've CC'ed him. -- Florian Pritz
Re: [aur-general] Developer/TU key signing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 juster, perlbrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJO6TquAAoJEF+Ube2YPUNmAvkH/RAj7aAJ0UhxS0w6Kqr/Xe7F Jomg9d3X+6mTcHSFhm3G17/ifv0JjGNoi5SYiso49KtGQt1TaCEtOWdByJBFMszH cksDSGGK2Z/sAZ8QuroOIl58xNpAMKEXxd9NGnaF9h4S/HXrGJEhdyVsETM4DAc2 01Uxso2F49mxiaksyJIWR6KoxUVWw+tI2eupZ7LXsT7u+//Ei8IwRA8Lh8vJbZ4l NwPqg2MlWUGNGCzBUwkFiuwHhueazZKmhS6+pZEnp+S5UVCKV7KjmEn8OpHql39A hben+5TySAFpNbpstR0nTqEy42wXKqt87mSLVHrA4qAodS3C46U6y5gZUsFP0HY= =Vyu1 -END PGP SIGNATURE-
Re: [aur-general] Orphaning a 1000 packages
On Thu, Nov 17, 2011 at 1:38 PM, Magnus Therning mag...@therning.org wrote: On Fri, Nov 11, 2011 at 09:15:32AM +0100, Lukas Fleischer wrote: On Thu, Nov 10, 2011 at 10:22:45PM +0100, Magnus Therning wrote: I'm the current maintainer of ArchHaskell and within the small team we've reached the decision to drop support for the huge set of package owned by the user arch-haskell on AUR. Currently we maintain 300+ binary packages, and we'd like to keep them on AUR. All others should be orphaned (or removed). Doing that manually would be painful to say the least, are there any tools that assist with mass-orphaning? Create a list of packages (plain text, one package per line) and I'll orphan them. I tried sending the list privately, but maybe it didn't make it to you. Anyway, I've uploaded a list, it's all packages owned by the user arch-haskell. http://therning.org/magnus_files/arch-haskell-pkgs.txt /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay I thought you wanted to keep some packages. Lukas was asking for a list of packages you wanted to orphan, not a list of all your packages. Am I correct in my understanding that you want to orphan every packages that is not also on the repo at http://www.kiwilight.com/haskell/i686/ ? -- -Justin
Re: [aur-general] Orphaning a 1000 packages
On Thu, Nov 10, 2011 at 4:22 PM, Magnus Therning mag...@therning.org wrote:
I'm the current maintainer of ArchHaskell and within the small team
we've reached the decision to drop support for the huge set of package
owned by the user arch-haskell on AUR.
Currently we maintain 300+ binary packages, and we'd like to keep them
on AUR. All others should be orphaned (or removed). Doing that
manually would be painful to say the least, are there any tools that
assist with mass-orphaning?
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
-- Alan Kay
It might churn your stomach ;-) but you could use my WWW::AUR perl
module set ...
use WWW::AUR::Login;
my $u = WWW::AUR::Login-new('arch-haskell', 'password');
for my $p ($u-packages) {
$u-disown($p);
}
You'd need the perl-www-aur package installed:
https://aur.archlinux.org/packages.php?ID=44180
--
-Justin
Re: [aur-general] Orphaning some community packages
I'll take perl-linux-pid. -- -Justin
Re: [aur-general] Mass orphan all ghost1227 packages
On Mon, Aug 15, 2011 at 12:33 PM, Andrea Scarpino and...@archlinux.org wrote: On Mon, 15 Aug 2011, 18:11:33 CEST, Jelle van der Waa je...@vdwaa.nl wrote: I noticed ghost still has a lot of packages in AUR, so i talked to him on irc and he said we can orphan all his packages. Can anyone mass orphan his packages for me? You can do that yourself. Anyway, this time I did. (Sorry I don't have a list of his packages). -- Andrea Here is a list of ghost's packages from an AUR scrape 11 days ago. https://aur.archlinux.org/packages.php?ID=6106 abe https://aur.archlinux.org/packages.php?ID=26339 alacarte-devel https://aur.archlinux.org/packages.php?ID=3792 album https://aur.archlinux.org/packages.php?ID=22592 apolos https://aur.archlinux.org/packages.php?ID=1292 base91 https://aur.archlinux.org/packages.php?ID=19603 beastieworker https://aur.archlinux.org/packages.php?ID=17964 beeswax https://aur.archlinux.org/packages.php?ID=28142 bitlbee-bzr https://aur.archlinux.org/packages.php?ID=24758 bitlbee-otr-bzr https://aur.archlinux.org/packages.php?ID=31879 cdm https://aur.archlinux.org/packages.php?ID=32120 cdm-git https://aur.archlinux.org/packages.php?ID=27239 cgrep Deleted clamz https://aur.archlinux.org/packages.php?ID=34686 clyde-git https://aur.archlinux.org/packages.php?ID=15812 code-browser https://aur.archlinux.org/packages.php?ID=31296 crawlr-git https://aur.archlinux.org/packages.php?ID=28148 crikey https://aur.archlinux.org/packages.php?ID=28932 curlpaste-git https://aur.archlinux.org/packages.php?ID=22602 dailystrips https://aur.archlinux.org/packages.php?ID=31736 dhard https://aur.archlinux.org/packages.php?ID=6372 digger https://aur.archlinux.org/packages.php?ID=31834 dtach-patched https://aur.archlinux.org/packages.php?ID=21336 ede https://aur.archlinux.org/packages.php?ID=335 eggdrop https://aur.archlinux.org/packages.php?ID=6108 ensemblist https://aur.archlinux.org/packages.php?ID=6252 fakenes https://aur.archlinux.org/packages.php?ID=5476 foff https://aur.archlinux.org/packages.php?ID=22608 fortunelock https://aur.archlinux.org/packages.php?ID=20563 freedink https://aur.archlinux.org/packages.php?ID=24674 froggix https://aur.archlinux.org/packages.php?ID=900 fsv https://aur.archlinux.org/packages.php?ID=19598 gboggle https://aur.archlinux.org/packages.php?ID=3262 gemdropx https://aur.archlinux.org/packages.php?ID=14305 gimp-plugin-jp2 https://aur.archlinux.org/packages.php?ID=41966 gmakeself https://aur.archlinux.org/packages.php?ID=21415 gmanedit https://aur.archlinux.org/packages.php?ID=26270 gmount https://aur.archlinux.org/packages.php?ID=22903 gnelib-svn https://aur.archlinux.org/packages.php?ID=9549 gnono https://aur.archlinux.org/packages.php?ID=14140 gnubg https://aur.archlinux.org/packages.php?ID=25379 gottet https://aur.archlinux.org/packages.php?ID=12481 gpaint https://aur.archlinux.org/packages.php?ID=26726 grepp https://aur.archlinux.org/packages.php?ID=29201 gtk-desktop-info https://aur.archlinux.org/packages.php?ID=16646 hamachi-gui https://aur.archlinux.org/packages.php?ID=4426 highmoon https://aur.archlinux.org/packages.php?ID=16572 indywiki https://aur.archlinux.org/packages.php?ID=24234 isoman https://aur.archlinux.org/packages.php?ID=20482 kagiru https://aur.archlinux.org/packages.php?ID=37853 kvmd https://aur.archlinux.org/packages.php?ID=18956 lalcal https://aur.archlinux.org/packages.php?ID=24025 lander https://aur.archlinux.org/packages.php?ID=8634 libvc https://aur.archlinux.org/packages.php?ID=35964 lolcode-git https://aur.archlinux.org/packages.php?ID=35552 lua-archive https://aur.archlinux.org/packages.php?ID=35553 lua-archive-git https://aur.archlinux.org/packages.php?ID=30955 lua-md5 https://aur.archlinux.org/packages.php?ID=35932 lualpm-git https://aur.archlinux.org/packages.php?ID=14148 madbomber https://aur.archlinux.org/packages.php?ID=23678 makeaur https://aur.archlinux.org/packages.php?ID=30638 maxview https://aur.archlinux.org/packages.php?ID=21731 meritous https://aur.archlinux.org/packages.php?ID=18519 mog https://aur.archlinux.org/packages.php?ID=8633 mutt_vc_query https://aur.archlinux.org/packages.php?ID=27384 netc https://aur.archlinux.org/packages.php?ID=15086 neverball-svn https://aur.archlinux.org/packages.php?ID=3375 njam https://aur.archlinux.org/packages.php?ID=29924 nobug-git https://aur.archlinux.org/packages.php?ID=21346 o2em https://aur.archlinux.org/packages.php?ID=29873 ompluad-git https://aur.archlinux.org/packages.php?ID=14048 open-invaders https://aur.archlinux.org/packages.php?ID=20291 openbravopos https://aur.archlinux.org/packages.php?ID=29377 opentyrian-enhanced https://aur.archlinux.org/packages.php?ID=16449 openyahtzee https://aur.archlinux.org/packages.php?ID=22798 orthos https://aur.archlinux.org/packages.php?ID=22146 ossvol https://aur.archlinux.org/packages.php?ID=10100 outguess https://aur.archlinux.org/packages.php?ID=22747 packup https://aur.archlinux.org/packages.php?ID=22642 penguin-command
Re: [aur-general] PCSX2 Plugins folder - suggestion?
On Thu, Jul 14, 2011 at 4:41 PM, rafael ff1 rafael.f...@gmail.com wrote: Hi all, I'm the maintainer of the package pcsx2-svn[1]. PCSX2 from now on will install files in a different folder than /opt/pcsx2 - I'm still going to adapt the PKGBUILD. Plugins, as I can see in Archlinux Packaging Standards [2], should go to /var/lib/pcsx2/PLUGINNAME.so... However, pcsx2 is a 32 bit package and only works in 64 bit because it uses lib32 packages. In my 64 bit system, I can see that the compilation of pcsx2 [gcc -m32, thanks to gcc-multilib] gives me ELF 32 bit plugins, which makes it a little bit weird to have it inside /var/lib/pcsx2 - which is a system's architecture folder. However, on 32 bit systems, there would be no problem putting plugins in /var/lib/pcsx2. Having that said, where should 32 and 64 bit compilations of PCSX2 put its plugins (talking about /varlib/pcsx2 and /var/lib32/pcsx2)? [1] http://aur.archlinux.org/packages.php?ID=21899 [2] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards Thanks in advance, Rafael I think that you mean /usr/lib/pcsx2 instead of /var/lib/pcsx2. Since plugins are just specialized dynamic libraries my gut feeling is they belong under /usr/lib. On the Arch Packaging Standards page it also says to use /usr/lib/pcsx2. Using two different folders depending on the host architecture is overly complicated. The advantage of a lib32 directory name is to separate lib32 dynamic libs from 64-bit dynamic libs right? There's no need to separate plugins if there is no chance of them getting accidentally used. They cannot be passively used but must be actively sought out in the predefined location. I don't use multilib so I may be wrong. -- -Justin
Re: [aur-general] error building perl-package-stash-xs
On Sun, Jul 3, 2011 at 4:45 AM, Andrea Scarpino and...@archlinux.org wrote:
On Sunday 03 July 2011 09:52:46 sacarde wrote:
ok, I unistall:
perl-moose-2.0007-1 perl-eval-closure-0.06-1 perl-scalar-list-utils-1.23-4
(for dependencies)
now perl-package-stash-xs build OK
We switched perl to 5.14.1, I guess you have to rebuild your perl modules from
AUR.
--
Andrea
Users must rebuild all their AUR perl XS modules. XS modules have
dynamic libraries compiled for the version of perl they were built
with. This command shows all the perl XS modules that are from the AUR
installed on the system.
pacman -Qmq | perl -ne 'print if /^perl/ grep { /.so$/ } `pacman -Ql $_`'
--
-Justin
Re: [aur-general] Delete request for perl-docs #22294
On Sat, Apr 16, 2011 at 2:25 PM, Xyne x...@archlinux.ca wrote: On 2011-04-16 12:02 -0400 (15:6) Dave Reisner wrote: On Sat, Apr 16, 2011 at 11:57:33AM -0400, Justin Davis wrote: Please delete perl-docs. I would like to resubmit it and rename it to perldocs. This is trivial, of course, but it bugs me. Packages for perl modules are prefixed with perl- but perl-docs is simply the documentation for perl and not a Docs module. The file it downloads is named perldoc and there is a command for reading installed perl documentation called perldoc so it seems more appropriate to call the package perldocs. I know it sounds crazy! Please humor me! Here is the link: http://aur.archlinux.org/packages.php?ID=22294 Thanks, Justin (aka aurperl) Consider yourself humored. dave It should probably be called perl-perldoc if you want to be rigorous, i.e. all Perl packages should be prefixed with perl- regardless if they begin with perl themselves. It makes it easier to write tools for Perl package management. That is what I do for modules but the whole point is to differentiate these docs from modules and avoid package name clashes. For example, there is a module named Perldoc on CPAN. If I called the package for these docs perl-perldoc like you suggest then that conflicts with the package name of the Perldoc module, should someone want to upload it to the AUR and name it, properly, perl-perldoc. The perldocs are just documentation, they don't even depend on perl, so they are not perl packages in the same sense that packages of perl modules are perl packages. They are perldocs, just like the perldoc command, just like the perldoc website. Naming conventions for modules do not need apply, and can actually cause problems as I mentioned above. Really, a different naming scheme makes automation easier (avoiding a headache) because it is now not possible to accidentally confuse perl-docs with a module named Docs on the AUR, based solely on the names of packages. PS thanks dave! -- -Justin
[aur-general] Delete request for perl-docs #22294
Please delete perl-docs. I would like to resubmit it and rename it to perldocs. This is trivial, of course, but it bugs me. Packages for perl modules are prefixed with perl- but perl-docs is simply the documentation for perl and not a Docs module. The file it downloads is named perldoc and there is a command for reading installed perl documentation called perldoc so it seems more appropriate to call the package perldocs. I know it sounds crazy! Please humor me! Here is the link: http://aur.archlinux.org/packages.php?ID=22294 Thanks, Justin (aka aurperl)
[aur-general] PKGBUILD URL has changed
I just wanted to let AUR helper authors (or other AUR enthusiasts) know that the PKGBUILD URL has changed on the AUR. All AUR helpers should update your code. I knew the AUR was updated recently but I did not realize that the URLs were changed for PKGBUILDs until I looked carefully at the AUR and the new patches. I found out earlier today and wanted to help others who might wonder why their AUR software slowly starts to break. The old scheme was: /packages/name/name/PKGBUILD The new scheme is: /packages/name/PKGBUILD Fun facts: Packages that were uploaded before the change still have an extracted package directory (/packages/name/name). The old packages also have a copy of their PKGBUILD in the new location.This means they have a PKGBUILD in both locations. Once a package is uploaded the old package directory is deleted so only one PKGBUILD remains (/packages/name/PKBUILD). So all packages uploaded after the change use the new PKGBUILD URLs. -juster
Re: [aur-general] Moving packages to Community
Not that I wouldn't mind the credit but it was Lukas Fleischer who implemented the official repo checking code and not me. He is also hosting the git repository for his branch of the AUR. Your idea sort of sounds like retiring a package to me. That seems like an interesting idea but I am not sure the benefits are worth the work involved. The benefits that I can see are: + keeping a backup of the source package (for whom? are they that valuable?) + keeping a backup of the comments, which hardly anyone can see (the original author? TUs?) Just to be specific, a TU clicks the Retire button on a package to retire it. A retired package is hidden from the general user. Only the original author can see it. I suppose TU or devs could see it as well, in a special swanky section of the site. Problems I brainstormed: - what happens if the original author disowns his invisible retired package? does he lose it never to found again? would anyone care? - what sort of design on the web could be used to show old retired package comments? you can't hide a package and show its comments. who is the end-user for old musty comments anyways? Anyways there you go. If I were the one expected to spend time programming this (for free) I would say that it's not worth the effort. -- -Justin
Re: [aur-general] Standardized CPAN Package Versions
On Sun, Feb 6, 2011 at 5:16 PM, Xyne x...@archlinux.ca wrote: Hi, I have CC'd this to aur-general as this concerns all CPAN packagers on Arch. CPAN package versions are a mess on Arch Linux. It seems that many if not most CPAN packagers on Arch are unaware of how CPAN deals with versions and thus they do not correctly translate the CPAN version. Most of the time a naive translation is used instead, and this prevents Pacman from working correctly. To give an example, CPAN considers 1.15 to be a later version than 1.23.0, whereas Pacman will consider the latter version the newer version. This is because 1.15 is short for 1.150 on CPAN, whereas 1.23.0 is short for 1.023.0. This can be confirmed using the version module[1]. Could you give real-life examples? I have not seen a case where CPAN is confused by that. You seem to be saying that the packagers are at fault here but I always blamed the CPAN module authors. From what I remember, the biggest problem is when changing the number of digits. For example, if you go 0.8, 0.9, to 0.10. Ding. Bad. Switching from decimal to dotted decimal (multiple decimal points) also has problems. Regarding the version module, ou will get different results using the older qv function. I assume you are using the parse class-method. Some old code still uses qv I imagine. I need to convert some of mine, for example. I will have to look carefully at this behavior before I do. How do you know that CPAN uses the version module for comparing versions? Again, do you have an example of bad version comparison CPAN is performing? Self-indulgent side-story: I once suspected CPAN used the date a package was uploaded for comparing versions. This is half true. Look at the Taint module: http://search.cpan.org/dist/Taint/ the only example I know of. The latest version is older in age than the other two versions on CPAN. Which one is downloaded? 0.9, the highest version which is also the one with the oldest upload date. Which one is displayed first? 0.7, the version uploaded most recently. I have written a simple Perl script[2] that addresses this issue.* It accepts CPAN versions as command-line arguments and prints out standardized Pacman package versions. The package versions enable Pacman to correctly compare CPAN packages, e.g. when resolving minimal dependencies. Because I do not understand the problem very well I have a hard time deciding if your script fixes it. -- -Justin
Re: [aur-general] Standardized CPAN Package Versions
On Sun, Feb 6, 2011 at 8:36 PM, Xyne x...@archlinux.ca wrote: You seem to think that I am saying that the versions on CPAN are wrong. I am not. I am saying that Arch packagers do not understand the CPAN version schemes and thus fail to correctly convert CPAN versions to Pacman package versions ($pkgver). You said a version comparison done by CPAN is wrong here: To give an example, CPAN considers 1.15 to be a later version than 1.23.0, ... You seem to be lumping the version module and CPAN together. This is what is confusing in your message. You mentioned a CPAN version scheme but there is no such thing. CPAN authors are free to version things like crazy, however they like. I can upload a distribution file to the CPAN with a version that is less than my last version. CPAN will politely notify me of my mistake and release the distribution anyways. For example, a CPAN package could be update from 0.199 to 0.2. Pacman will consider 0.199 to be the newer version, e.g.: $ vercmp 0.199 0.2 1 A force flag would thus be required to update the package. The standardized versions would be 0.199 and 0.200, which pacman can correctly compare. The whole point of this is that CPAN has a very specific versioning scheme that does not directly translate to Arch. It has syntax for major versions, minor versions, alpha versions, etc. They is also a mixture of different syntax due to legacy version strings that have not been updated. The provided script can generate standardized versions using the version module which was designed for this, and which is distributed as part of the Perl distribution and can thus be considered official itself. CPAN has no specific versioning scheme at all. Many versions of distributions on CPAN follow the simple decimal format like 1.23. Some have the dotted-decimal format of 1.23.45 etc. Others have dates for versions like 20101234. Sometimes new releases of a distribution change from one scheme to the next. It's chaos. The version module has in the past been unreliable. It is bloated and even changes behavior. This is mentioned in my previous email. The old behavior used the 'qv' function while the new behavior uses the 'parse' class method. Yes, they give different results. I even tried using the version module for my module's $VERSION, which ended up prefixing the version in my distribution file with a 'v'. Annoying. As the developer of tools to package CPAN packages for Pacman automatically (Pacpan and Bauerbill), I can assure you that the the lack of standardized versions in Arch poses a real-world problem. There is no way to reliably generate PKGBUILDs with versioned dependencies as long as there is no standard conversions. Certainly you know by now, I create a similar tool with my CPANPLUS::Dist::Arch module. You know I have seen the same problems. How about we slow down a little and work together to try to fix this. A good first step would be to clearly define the problem. There is also plenty of test data available, the entire CPAN and Backpan with thousands of versions to play with. What Kaiting says is absolutely correct. Why not test this out and gather some data before asking everyone to start using it? I would have to see for myself whether this worked for a majority of cases before adopting it. Before that, clearly defining the problem in a document with some real data would be helpful. Then some scripts could be made to gather versions and comparisons. We could even work with the perl community to try to clean up their versions or flag the offensive versions. There is also the problem which stopped me from probing further on this subject. If some packages do not use the same method as I do in normalizing versions than it is all for naught. There could be two packages with different version strings, representative of the same original CPAN distribution, which pacman evaluates differently. -- -Justin
[aur-general] Please Delete: perl-archlinux-messages
Please delete perl-archlinux-messages. I renamed the module from Archlinux::Messages to Archlinux::Term and uploaded a new package (perl-archlinux-term). Here is the link to the old perl-archlinux-messages: http://aur.archlinux.org/packages.php?ID=36397 -- -Justin
[aur-general] Delete request for perl-test-exception.
I uploaded perl-test-exception while in a hurry. Please delete it because the same version is already in [community]. http://aur.archlinux.org/packages.php?ID=11000 Thanks, juster / aurperl
[aur-general] Delete request for perl-scalar-util
Please delete perl-scalar-util: http://aur.archlinux.org/packages.php?ID=26539 I adopted it long ago and noticed it recently. The package should be called perl-scalar-list-utils (which already exists) and is generally not needed because it is included with perl. Thanks, juster / aurperl
Re: [aur-general] Augeas request
I don't know if it would help but I have created an ocaml module that you could use to interface with libalpm. The github repo is at https://github.com/juster/ocaml-alpm but it isn't completely finished. It works and is comprehensive but has no docs and no Makefile. Making packages from the AUR isn't very complicated if you already know which packages are from the AUR beforehand. You just download the source package (wget/curl), extract it, run makepkg in the extracted directory, and do what you want with the binary package. You loop/recurse over a list of package names doing this for each one. I suppose this would be a list of one single element: augeas? Having a needed package in the AUR doesn't seem like a deal breaker unless there is some sort of upstream policy preventing you from using the AUR. -- -Justin
Re: [aur-general] Tarball Guidelines
Just wanted to say I appreciated the one email I got from the bot that told me there was a .PKGINFO file in my source package. I adopted this package so I'm not sure how the original packager pulled that off. I like the idea. Yes, obviously it should be built into the AUR website itself. The problem is that it is a lot quicker and easier to make a bot. There's also the whole weird maintenance mode thing. The cool part is we've already beta tested this thing without modifying the AUR at all. I would not mess with binary files. I always assumed the packaging guidelines meant executable files instead of binaries. Yes executable (ELF) files are bad. I think this has been established earlier. One suggestion is that the comment adds Keenerd's email or some way to know where in the world it came from or who owns it. An anonymous bot! Fear! Another idea: instead of commenting en mass you could send an e-mail to the maintainer with a list of packages and their problems. If they have their e-mail available of course. -- -Justin
Re: [aur-general] Tarball Guidelines
On Sun, Dec 5, 2010 at 9:26 PM, keenerd keen...@gmail.com wrote: I've also come across a bug in the AUR. In short, the tarball URL provided by the RPC interface is different from the tarball taken from the html page. The RPC tarball is *exactly* what was uploaded. While the html tarball has been sanitized. ... Christopher Brannon also mentioned this on the aur-dev list, giving links to the flyspray bug reports as well: http://mailman.archlinux.org/pipermail/aur-dev/2010-November/001345.html I don't understand why the URLPath RPC field is necessary if the source package files always have the same predictable URL... -- -Justin
[aur-general] DELREQ for several gtk2/gnome/glib perl packages
I sent a delete request awhile ago but I haven't heard a response. In case it didn't send properly here it is again. These perl packages are already provided in the [extra] repository and due to naming confusion were uploaded to the AUR. I adopted these as the aurperl user when they were orphans. I noticed them last week when updating one. Here are the links, package names, and corresponding [extra] package. http://aur.archlinux.org/packages.php?ID=25815 perl-gnome2 [gnome-perl] http://aur.archlinux.org/packages.php?ID=25816 perl-gnome2-canvas [gnomecanvas-perl] http://aur.archlinux.org/packages.php?ID=25817 perl-gnome2-vfs [gnome-vfs-perl] http://aur.archlinux.org/packages.php?ID=25818 perl-gnome2-gconf [gconf-perl] http://aur.archlinux.org/packages.php?ID=25813 perl-gtk2 [gtk2-perl] http://aur.archlinux.org/packages.php?ID=25822 perl-gtk2-gladexml [glade-perl] http://aur.archlinux.org/packages.php?ID=25814 perl-pango [pango-perl] http://aur.archlinux.org/packages.php?ID=25812 perl-glib [glib-perl] http://aur.archlinux.org/packages.php?ID=25810 perl-cairo [cairo-perl] Please delete these packages since they are duplicates. Thanks! -- -Justin
[aur-general] Please Remove: perl-task-weaken
Please delete the perl-task-weaken package [http://aur.archlinux.org/packages.php?ID=41562]. I was in a hurry and didn't notice it was in the community repo. Thanks, -- -Justin
Re: [aur-general] AUR Improvement Thread
On Tue, Nov 16, 2010 at 8:17 PM, Kaiting Chen kaitocr...@gmail.com wrote: How can we make the AUR even better? I'll start: 1. Integrated distributed version control system I like this idea. At least the ability to track changes in PKGBUILDs would be fun. Similar to a wiki's revision history. Though a distributed VCS and not a centralized VCS is not really that necessary I use git mainly because it is fast, not because it is distributed. So I don't see why a distributed VCS would be any worse than a centralized one. The AUR is never going to be merging from another repo anyways... right? It would basically be read-only and might not even be publicly available as a repository so I don't see what difference it makes. You could even go off on a tangent and have AUR maintainers be able to push to their own git repository on AUR ... muah. 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) I don't really see how this fits in. The user can host their own repository already. I would rather KISS and leave the AUR source only. 3. Time-adjusted 'relevance' measure (votes are useful but suck at the same time; nobody cares if a packages was upvoted 9000+ times a million years ago, especially if it's already been obsoleted by something else) Good idea. Better statistics could be gathered by simply adding a timestamp to votes db entries. Maybe pretty graphs too! 4. An official client The unofficial clients do nicely as it is and an official one is not necessary. Improving the official RPC would be nice though. 5. LDAP support because LDAP makes everything so much better LDAP makes everything so much more complicated! I avoid it whenever possible. -- -Justin
Re: [aur-general] AUR Improvement Thread
On Wed, Nov 17, 2010 at 1:35 PM, Kaiting Chen kaitocr...@gmail.com wrote: ... I don't believe a centralized VCS is capable of this. Just so you know, a centralized VCS like svn or cvs can do the same thing. Just to reiterate, my personal preference is still git. I think it will be best because of its fast and light-weight nature. LDAP makes everything so much more complicated! I avoid it whenever possible. That is nonsense. With LDAP support one could for example query the details of a package $pkgname using the command: curl ldap:// ldap.archlinux.org/ou=community,dc=archlinux,dc=org??one?(pkgname=$pkgname) There's no way you can tell me that that's not awesome. --Kaiting. Sure I suppose if the LDAP spontaneously configures itself and populates itself with data that is just great. I was talking about configuring LDAP, deploying LDAP, and populating it with data. That sucks. Ever type LDIF by hand? Fun. That's not very awesome to me. You can do the same thing with AUR's RPC... without the fugly, esoteric LDAP syntax and without prior knowledge of how the directory is structured: curl http://aur.archlinux.org/rpc.php?type=infoarg=$pkgname; I don't think it would be worth the effort of the programmer to convert the AUR to use LDAP as a storage backend to get features we already have. However, using LDAP for a centralized authentication/authorization server for the sites in the archlinux.org domain? That would be sweet. -- -Justin
Re: [aur-general] AUR Improvement Thread
How does one commit to a local repository using SVN? I meant that you can do a 'svn update' or 'cvs update' to merge changes from the server into your working dir. -- -Justin
[aur-general] Please Remove: perl-catalyst-plugin-cache-memcached
Please remove the perl-catalyst-plugin-cache-memcached package because it has been deprecated upstream. AUR link: http://aur.archlinux.org/packages.php?ID=25759 CPAN page shows it is deprecated: http://search.cpan.org/~bobtfish/Catalyst-Plugin-Cache-Memcached-0.8/lib/Catalyst/Plugin/Cache/Memcached.pm Thanks! -- -Justin
Re: [aur-general] aur website default ssl
On Sat, Oct 30, 2010 at 4:42 AM, Philipp Überbacher hollun...@lavabit.com wrote: Often enough, and AUR is an example, it's sufficient to be logged in to change the current password. Knowing the session ID is thus almost equivalent to knowing the password. If the password is used in more than one place and sniffed out, then not only is the user's AUR account compromised but also other accounts on other websites. It is easier to run a sniffing program that are already setup to search POST form data for the parameter name password (or something similar) instead of targeting the AUR specifically and looking for the AURSID cookie. If the password is the same for the user's email account, the hacker just has to look the email up on the AUR and go from there. They can also cross-reference the email to other accounts. -- -Justin
Re: [aur-general] aur website default ssl
I'm glad I sparked a discussion! I however am still on the decidedly non-paranoid side. Yes I know how man in the middle attacks work. Yes I understand it's possible. No I don't think it's likely. Basically because there is no money involved. Take that as naivete or ignorance if you want but I'm not jumping on the bandwagon. Everyone has taken a technical low-level look at the problem but my point of view is a little broader. The AUR security model is so weak as it is. Anyone can upload any package to run arbitrary code on your machine. Just slapping on https as if to say we're secure now! doesn't make me feel more secure. If someone wants to mess with me they don't have to hijack my connection they just upload a bad package. Just to be clear I think the freedom of allowing anyone to upload a package is a good thing and worth the security risk. I haven't been bitten by any malicious packages so far though I usually check them. HTTPS is great, feel free to use it. Switching it to mandatory and telling me how much better off I am seems a bit like evangelism. I don't think HTTPS is bad I just think forcing everything to HTTPS is a lazier than fixing the login to use HTTPS. Yes people can sniff my session id to just about any site I visit. Session IDs change. Sniffing a password is much more dangerous. Passwords are personal property. Passwords can be reused... like on other ArchLinux sites. -- -Justin
Re: [aur-general] aur website default ssl
On Tue, Oct 26, 2010 at 1:50 PM, Ionuț Bîru ib...@archlinux.org wrote: Hi, we are now using default https for aur.archlinux.org. Some aur helpers may need adjustment, others like cower/slurpy already works as expected. Kudos for their maintainers for following the aur development Hi I maintain clyde lately. I try to keep it working anyways. This mandatory switch to https breaks clyde's AUR support. Clyde's AUR support is the only reason to use it, really... it is an AUR helper after all. Forcing all traffic to https is not what I would call default. Default would be cool but generally a default option is not the _only_ option. I hadn't joined aur-dev. I am assuming the switch was announced there. I already am a part of this mailing list and most of what I receive from it is junk to me. I also joined the pacdev mailing list long ago but filtered that because it fills my mailbox with stuff I don't care about. All I care about are API changes to libalpm, really, and I usually just diff the sources to find them. Out of curiosity I looked at slurpy on github and it hasn't been updated since July. Cower was updated 4 days ago. If an AUR helper uses a sufficiently high-level interface they won't need to update because they get forwarded to the HTTPS URI. Everything is automagically fixed for them. Clyde is probably the only AUR helper to suffer from this because of its low-level Luasocket library. Maybe paktahn as well. Kudos to falconindy at least for updating cower to use https by default. I'm glad that logins to the AUR are now encrypted. Previously they weren't which is always surprising to find out. Other than logins I could care less if my traffic is sniffed. I know the logic is easier to just switch _everything_ to HTTPS but could maybe we just use https for logins? Could you allow HTTPS to be optional (except for logins) and then give validity to the term default? -- -Justin
[aur-general] Please Remove: geography-countries, ip-country
These package do not follow the perl module naming guidelines for the AUR. They are also duplicates of existing packages perl-geography-countries and perl-ip-country. The maintainer has agreed they should be removed. * ip-country (http://aur.archlinux.org/packages.php?ID=2822) * geography-countries (http://aur.archlinux.org/packages.php?ID=2821) Thanks -- -Justin
Re: [aur-general] perl CPAN modules
On Tue, Sep 28, 2010 at 4:15 PM, Nathan O ndowens@gmail.com wrote: On Tue, Sep 28, 2010 at 6:12 PM, J. W. Birdsong jwbirds...@jwbirdsong.homelinux.com wrote: On 09/29/10 at 12:16am, Philipp Überbacher wrote: Excerpts from Nathan O's message of 2010-09-28 22:53:45 +0200: Not sure, didn't know if we had a way to do this, so I thought I would bring it up, kinda thought that it would be interesting to add to AUR if we didn't have something similar. On Tue, Sep 28, 2010 at 3:49 PM, Philipp Überbacher hollun...@lavabit.comwrote: Excerpts from Nathan O's message of 2010-09-28 22:40:10 +0200: I was looking at how Gentoo creates packages and I noticed one thing, is that Gentoo, during build, will use CPAN to get the required modules for the package that is being built. I was thinking, I wonder if this could be implemented into AUR? Is it very different or superior to doing this manually or using CPANPLUS? Example: http://aur.archlinux.org/packages/perl-audio-ecasound/perl-audio-ecasound/PKGBUILD Well, I'm not sure what you mean exactly. I have little experience with perl, but apparently you get sources always from cpan, and what CPANPLUS does is helping you with/automating PKGBUILD writing, dependency resolution and updating, afaik. You can also use Bauerbill --cpan Just check bauerbill man page. Ah Thanks for the pointes, I was hoping I seen a idea that we could use :) I created CPANPLUS::Dist::Arch, a plugin for CPANPLUS that does something similar to what you asked about: using CPAN to create perl packages. This is what Philipp is talking about. CPANPLUS is a program (named cpanp) that you use to install modules from the CPAN (central perl authors network). My module hooks into cpanp to package modules while it installs them. cpan2aur is a utility that I included with the module/plugin that can help to create AUR packages for perl modules. This can help with the PKGBUILD writing and automatically fills in the dependencies. I just wanted to clear up the confusion between terms. The plugin is available as the 'perl-cpanplus-dist-arch' package on the AUR. -Justin
Re: [aur-general] Help with a perl package needed
On Aug 26, 2010, at 9:43 AM, Philipp Überbacher wrote: I don't think anything uses nama as a module, so I rather stick with the current name. Okay it's no biggie. The 'provides' [bash] array in the PKGBUILD just gives aliases for package names. That way packages can essentially have more than one name. But again, it's no big deal as probably no one would use the alias. I did use it already, but I did so sloppily, just to get the job done. perl-audio-ecasound: http://aur.archlinux.org/packages.php?ID=40136 I just reread this message and realized you were talking about another AUR package. Before I didn't understand and did not respond. It seems that cpan2aur found the non-perl ecasound dependency properly so you should not need to use a PKGBUILD template. I don't see anything sloppy about it. :) Now that you have used cpan2aur to generate the perl-audio-ecasound package I hope you can use cpan2aur to automatically --check for new releases from CPAN and update the AUR accordingly because that was my reason for creating cpan2aur. If you are comfortable with this you may try the same with the nama package as I mentioned earlier. Sorry for the late response. Have fun, Justin
Re: [aur-general] Help with a perl package needed
Hey Philip,
Sorry for the delay I have looked at your AUR PKGBUILD and it looks very well
done. I can see you read the wiki page. Filling all those pkgdeps by hand is
very impressive. I have some minor suggestions and a plug for a module I made
that may help you.
One discrepancy I noticed is that I think perl-anyevent should be = 5, meaning
the package needs at least version 5. You might also consider having a provides
line like: provides=('perl-audio-nama'). This is the more or less standard
way of naming perl _module_ packages. Since your package provides both a module
and application, naming it 'nama' isn't bad at all, but the provides would
allow people to use the standard notation if they want to depend on the module.
Not really important but just for covering your bases.
The plug is that I have made a module for generating Archlinux package for perl
modules on the fly. It is not perfect though and sometimes you have to tweak
the PKGBUILD. My module is called CPANPLUS::Dist::Arch, available as
perl-cpanplus-dist-arch on the AUR. It comes with a program called cpan2aur
that can generate PKGBUILDs, upload them to the AUR, or check if a new version
of a module is available automatically.
To keep a long story short, if you want help maintaining your AUR package and
keeping it up to date you might find it useful. I use it for my AUR perl
packages. But to keep the PKGBUILD perfect like you made it you would have to
use a PKGBUILD template file. If you want to try it here are instructions:
Create a directory called 'nama'. I have such dirs under my ~/aur directory.
Copy this PKGBUILD template file to a file called PKGBUILD.tt:
# CPAN Name : Audio-Nama
# Maintainer : [% packager %]
# Generator : CPANPLUS::Dist::Arch [% version %]
pkgname='nama'
pkgver='[% pkgver %]'
pkgrel='[% pkgrel %]'
pkgdesc='Tk/CLI frontend for ecasound'
arch=('[% arch %]')
license=('GPL2')
options=('!emptydirs')
depends=([% depends %])
provides=('perl-audio-nama')
optdepends=('perl-audio-ecasound' 'perl-tk')
url='http://freeshell.de/~bolangi/cgi1/nama.cgi/00home.html'
source=('[% source %]')
md5sums=('[% md5sums %]')
build() {
DIST_DIR=${srcdir}/[% distdir %]
export PERL_MM_USE_DEFAULT=1 PERL5LIB= \
PERL_AUTOINSTALL=--skipdeps\
PERL_MM_OPT=INSTALLDIRS=vendor DESTDIR='$pkgdir' \
PERL_MB_OPT=--installdirs vendor --destdir '$pkgdir' \
MODULEBUILDRC=/dev/null
{ cd $DIST_DIR
perl Makefile.PL
make
[% IF skiptest %]#[% END %]make test
make install;
} || return 1;
find $pkgdir -name .packlist -o -name perllocal.pod -delete
}
'cd' back into the parent directory and type: 'cpan2aur nama'. This will build
a new source package file, generating a PKGBUILD from your template. Then type
'cpan2aur --check nama' to automatically check if a new version of Audio-Name
from CPAN is available and automatically upload the new version of the source
package. Or you can do things like 'cpan2aur --upload nama' to generate/upload
a source package from that directory's PKGBUILD.tt
I hope that helps you. I don't have steady internet lately so I might not reply
instantly if you need me but thanks for your AUR package!
-Justin
On Aug 22, 2010, at 2:56 PM, Philipp Überbacher wrote:
I think I have it correct now, but I wouldn't mind someone testing it or
making suggestions.
nama
http://aur.archlinux.org/packages.php?ID=40133
nama git version
http://aur.archlinux.org/packages.php?ID=40135
perl audio ecasound
http://aur.archlinux.org/packages.php?ID=40136
Regards,
--
Philipp
--
Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen. Bertolt Brecht, Der gute Mensch von Sezuan
[aur-general] Delete request for perl-yaml-xs
http://aur.archlinux.org/packages.php?ID=20982 I am the maintainer of this package please delete it. See the package's comment for the reason why. It is a misnamed duplicate. Thanks! Justin
Re: [aur-general] PKGBUILD-git that actually works with branches
On May 28, 2010, at 1:18 PM, Sebastian Schwarz wrote: Ah, I forgot about this. To suppress this notice just tell git-checkout to be `--quiet`. Is there a reason not to just use 'git checkout $_gitbranch' instead ? -Justin
Re: [aur-general] PKGBUILD-git that actually works with branches
On May 28, 2010, at 1:52 PM, Sebastian Schwarz wrote: By default git-clone only creates a remote tracking branch for master or whichever branch is specified with the `-b` option. Thus you either have to checkout the branch from the remote, I am no git wiz but it seems like you are making things more complicated than they have to be. When you type 'git checkout branchname' it automatically creates a remote tracking branch. I can see no good reason to checkout the remote branch (the one prefixed with origin/) and force it to suppress its warning when you can just checkout a branch normally. Your response was informative but did not tell me why you choose a more complicated route, instead of the straightforward 'git checkout branchname'. -Justin
