Re: [aur-general] Deletion request for xf86-input-wiimote-git
On Friday, December 13, 2013 02:51:35 David Manouchehri wrote: > I've placed a new package under the proper name xf86-input-xwiimote-git. > I've asked Herrmann (dvdhrm) if he wants to maintain it himself (which > is why I orphaned it); if he doesn't, then I'll pick it back up myself. > > xf86-input-wiimote-git can be deleted. Removed, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[aur-general] Deletion request for xf86-input-wiimote-git
I've placed a new package under the proper name xf86-input-xwiimote-git. I've asked Herrmann (dvdhrm) if he wants to maintain it himself (which is why I orphaned it); if he doesn't, then I'll pick it back up myself. xf86-input-wiimote-git can be deleted. -- David Manouchehri
Re: [aur-general] Request for merging python-dulwich into python2-dulwich as well as its -git version
On Friday, December 13, 2013 11:40:29 郑文辉 wrote: > 1. [python-dulwich][1] => [python2-dulwich][2] > 2. [python-dulwich-git][3] => [python2-dulwich-git][4] > > [1]: https://aur.archlinux.org/packages/python-dulwich > [2]: https://aur.archlinux.org/packages/python2-dulwich > [3]: https://aur.archlinux.org/packages/python-dulwich-git > [4]: https://aur.archlinux.org/packages/python2-dulwich-git Both merged, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] Disown a number of ruby-* packages
On Wednesday, December 11, 2013 15:35:44 Anatol Pomozov wrote: > Hi > > I have a dream to make rails from packages work on Arch again. > > Currently rails and many of its dependencies are out-of-date with > broken dependencies. I would like to get ownership on many of the > 'kidoz' user ruby-* packages. I emailed kidoz 10 days ago about > transferring his out-of-date (or even all) ruby packages to me. He did > not reply. Taking into account that many of his packages are > out-of-date (some of them ~4months now) I consider kidoz inactive. > > Some of the packages need to be merged, some of them deleted, but > let's talk about it later. > > Ok, could you please disown following packages: > > https://aur.archlinux.org/packages/ruby-columnize/ > https://aur.archlinux.org/packages/ruby-erubis/ > https://aur.archlinux.org/packages/ruby-hike/ > https://aur.archlinux.org/packages/ruby-hoe/ > https://aur.archlinux.org/packages/ruby-hpricot/ > https://aur.archlinux.org/packages/ruby-i18n/ > https://aur.archlinux.org/packages/ruby-multi_json/ > https://aur.archlinux.org/packages/ruby-rack-test/ > https://aur.archlinux.org/packages/ruby-rails-aio/ > https://aur.archlinux.org/packages/ruby-railties/ > https://aur.archlinux.org/packages/ruby-rdoc/ > https://aur.archlinux.org/packages/ruby-rmagick/ > https://aur.archlinux.org/packages/ruby-rmagick2/ > https://aur.archlinux.org/packages/ruby-sinatra/ > https://aur.archlinux.org/packages/ruby-sprockets/ > https://aur.archlinux.org/packages/ruby-thor/ > https://aur.archlinux.org/packages/ruby-tilt/ > https://aur.archlinux.org/packages/ruby-actionmailer/ > https://aur.archlinux.org/packages/ruby-actionpack/ > https://aur.archlinux.org/packages/ruby-activemodel/ > https://aur.archlinux.org/packages/ruby-activerecord/ > https://aur.archlinux.org/packages/ruby-activeresource/ > https://aur.archlinux.org/packages/ruby-arel/ > https://aur.archlinux.org/packages/ruby-bundler/ > https://aur.archlinux.org/packages/rails/ All disowned, thanks. Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] Possible to switch the votes/comments for two packages?
On Thursday, December 12, 2013 04:46:57 Rashif Ray Rahman wrote: > On 8 December 2013 21:07, member graysky wrote: > > On Sunday, December 8, 2013, Rashif Ray Rahman wrote: > >> 1. Backup mprime > >> 2. Merge mprime into mprime-bin > >> 3. Delete non-relevant comments from mprime-bin > >> 4. Reupload mprime from backup > >> > >> This should work to retain mprime-bin's data, but I'm not intricately > >> familiar with the process. Unfortunately, you can't remove > >> non-relevant votes (but you can tell others to remove theirs). > > > > I have both backed-up here. Can you or another TU implement this 4 step > > plan? > > Sorry, this got lost. I thought Felix was already helping you. Anyway, > merged. You can now take over from (3). Oops, sorry I forgot about this... Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [aur-general] AUR Registration
Sorry, I should have mentioned that. I have checked my spam folder On 12/12/13, Karol Blazewicz wrote: > On Thu, Dec 12, 2013 at 12:06 PM, Daazed McFarland > wrote: >> Not really sure if I am going about this the correct way. >> I have attempted to register in the AUR and I still have not received >> a confirmation email. I think I registered about 2 days ago. > > Did you check your spam folder? >
[aur-general] Request for merging python-dulwich into python2-dulwich as well as its -git version
1. [python-dulwich][1] => [python2-dulwich][2] 2. [python-dulwich-git][3] => [python2-dulwich-git][4] [1]: https://aur.archlinux.org/packages/python-dulwich [2]: https://aur.archlinux.org/packages/python2-dulwich [3]: https://aur.archlinux.org/packages/python-dulwich-git [4]: https://aur.archlinux.org/packages/python2-dulwich-git
Re: [aur-general] Corrected package ekeyd ready for AUR
> Date: Fri, 13 Dec 2013 01:13:59 +
> From: tho...@preissler.co.uk
> To: aur-general@archlinux.org
> Subject: [aur-general] Corrected package ekeyd ready for AUR
>
> Hello,
>
> I am using the entropy key from Simtec and I found the ekeyd package on
> AUR - unfortunately there are some problems with it, as outlined.
>
> Changes I have done to the original tarball:
> * Fixed the problem compiling with host/lstate.c.
> * Added a systemd unit egd-linux.service.
>
> Source package is attached for your review, guys, this is my very first
> one, so please bear with me...
>
>
> Regards
>
> Thomas
Patching/sed should be done in a separate prepare function.
Does the make install need those _make_flags? If not, it would make more sense
to not define a new variable, just include them in the make in the build
function. For that matter, the _base_distro variable doesn't really do
anything, but I can understand that so that it's easier to change.
Please quote all path that contain $srcdir or $pkgdir. You don't know if they
contain spaces or not.
No reason to use "${srcdir}/../egd-linux.service",
"${srcdir}/egd-linux.service" is just fine.
Not a big deal, but the variable at the top are usually defined in a specific
order. It works fine as is, just a little jarring. See
https://wiki.archlinux.org/index.php/Pkgbuild
[aur-general] Corrected package ekeyd ready for AUR
Hello, I am using the entropy key from Simtec and I found the ekeyd package on AUR - unfortunately there are some problems with it, as outlined. Changes I have done to the original tarball: * Fixed the problem compiling with host/lstate.c. * Added a systemd unit egd-linux.service. Source package is attached for your review, guys, this is my very first one, so please bear with me... Regards Thomas -- www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415 GPG Fingerprint: CCBD 153A D257 CA7E A217 FDF7 5928 03D1 7588 9415 ekeyd-1.1.4-6.src.tar.gz Description: Binary data
Re: [aur-general] Merge request
On 12/12/13 09:12, Hugo Osvaldo Barrera wrote: Hi, Can we merge lightning-bin into thunderbird-lightning-bin? Thanks! I would prefer to see it merged the other way around... -- Thanks, John D Jones III UNIX Zealot; Perl Lover unixgeek1...@gmail.com jnbek1...@gmail.com http://zoelife4u.org/
Re: [aur-general] 'provides' info in AUR
On 2013-12-12 01:39, Xyne wrote:
> On 2013-12-11 22:57 +
> Jerome Leclanche wrote:
>
> >These are all issues that can easily be fixed. Sources/checksums can
> >be added, extra architectures can be generated, and split packages can
> >be described in sections. (.conf aka .ini file format would be a
> >perfect fit here and would be forwards-compatible with the current
> >format but pretty much anything with sections would do.)
> >
> >Just to be clear, I'm not advocating to specifically use .PKGINFO;
> >just to use a compiled, parseable file (such as the .SRCINFO that was
> >talked about).. and it seems the consensus is that this is the best
> >solution. Am I wrong? What are the issues with .SRCINFO?
>
> My response is not directly at you in particular. I'm reply to the thread as a
> whole.
>
> The real problem is that we are attacking this from the wrong end. We should
> no be trying to excavate machine-parsable metadata from Bash. We should be
> thinking of ways to encapsulate the metadata in a flexible way that can be
> used
> to generate Bash.
>
> This would solve all of these problems and open the doors for numerous
> packaging tools (graph generators, metadata miners, fully automated repo
> generators, etc.).
>
> I've played around a bit with encoding package metadata in JSON. All of the
> packages on my site are autogenerated from JSON files with associated Bash
> stubs containing functions. My own approach is customized to my release
> scripts
> and not immediately generalizable, but the idea itself is workable.
>
> The key selling point of Bash is flexibility due to it being a full scripting
> language, but for the metadata itself we don't need the full flexibility. I
> think the following would suffice:
>
> 1) A convention for expressing per-package namespace for split packages, with
> a
>way to inherit and override from other namespaces to avoid redundancies.
>This can be done with sub-objects and a little syntax, e.g.
>{
> "python-foo" : {
> ...
> },
> "python2-foo < python-foo" : {
>"depends" : ["python2", ...]",
>...
> }
>
> 2) Variables for convenience. A top-level field to specify a delimiter would
>suffice, e.g. {"variable delimiter" : "$", ...} and then later {..., "url"
> :
>"http://example.com/$pkgname$-$version$.tar.gz";, ...}. The file could be
>safely interpolated. Interpolation requires some thought but it should be
>easy to do in all sane cases.
>
> 3) The build, package, prepare and version functions would obviously still be
>written in Bash, but they would be kept in a separate file and devoid of
>metadata.
>
> 4) If truly necessary, syntax for inserting command output could be added as
>well, again with a top-level limiter for the command. This would allow
>parsers to decide exactly which commands to run, if any. The use of such
>commands would be restricted to cases in which they are absolutely
> necessary
>(if there are any).
>
> Overall, it is not much more verbose than current PKGBUILDS:
>
> "powerpill": {
> "pkgdesc": "Pacman wrapper for parallel and segmented downloads.",
> "pkgrel": 1,
> "pkgver": "2013.5.13",
> "arch": "any",
> "backup": [
> "etc/powerpill/powerpill.json"
> ],
> "depends": [
> "python3",
> "pyalpm",
> "pm2ml>2012.12.12",
> "reflector",
> "aria2"
> ],
> "optdepends": {
> "python3-threaded_servers": "internal Pacserve support",
> "rsync": "Rsync download support"
> },
> "md5sums": [
> "0f0d4c0096bd60287ab923038c3bbc47",
> "f58432feaaeb339e5d6b3692d3cecf17"
> ],
> ...
>
>
> As soon as I have some time I will provide a proof-of-principle implementation
> and post a RFC.
>
> Regards,
> Xyne
I'm very much in favour of this (I'd even though of something slightly
similar at some point). We need a PKGBUILD2.0 format that can overcome
of our current limitations.
The downside is flexibility. What if the sources are complete different
for each architecture. At the moment, we can have an "if" in place. The
same applies for depends that vary according to architecture. Would we
just have a bunch of differently named-fields?
Before you post an RFC, a complete example of a really complex package
(with wierd sources, depends and stuff) would be great! :D
Anyway, if this becomes a reality, feel free to CC me; I'd be willing
to help the development of tools for this format! :D
--
Hugo Osvaldo Barrera
pgpxAn4sLSDKZ.pgp
Description: PGP signature
[aur-general] Merge request
Hi, Can we merge lightning-bin into thunderbird-lightning-bin? Thanks! -- Hugo Osvaldo Barrera pgpS3QycYr6wA.pgp Description: PGP signature
Re: [aur-general] AUR Registration
On Thu, Dec 12, 2013 at 12:06 PM, Daazed McFarland wrote: > Not really sure if I am going about this the correct way. > I have attempted to register in the AUR and I still have not received > a confirmation email. I think I registered about 2 days ago. Did you check your spam folder?
[aur-general] AUR Registration
Not really sure if I am going about this the correct way. I have attempted to register in the AUR and I still have not received a confirmation email. I think I registered about 2 days ago.
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 1 new package in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 5 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 (1 total) == * dokuwiki-20131208-1 (any) == Incomplete signoffs for [community] (5 total) == * dokuwiki-20131208-1 (any) 0/2 signoffs * 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. allan - 10 signoffs 2. thomas - 2 signoffs 3. djgera - 2 signoffs
