Re: [aur-general] [arch-general] Sha256sum unexpected behaviour

[WorMzy Tykashi via aur-general]

On 10 January 2020 08:27:11 GMT, Leonidas Spyropoulos via arch-general 
 wrote:
>Hello,
>
>I got a weird issue with sha256sum behaviour. When creating the package
>with makepkg --geninteg I get a hash and when trying to build it with
>makepkg the hash fails. The interesting bit is --ptintsrcinfo comes up
>with a different hash.
>
>Anyone got some idea why this might happen?
>
>See below some debugging info
>
>~/linux-gc$ makepkg --geninteg
>==> Retrieving sources...
>  -> Found linux-v5.4.10-arch1.tar.gz
>  -> Found config
>  -> Found 0001_bmq_v5.4-r1.patch
>  -> Found 0002_enable_additional_cpu_optimizations-20190822.tar.gz
>==> Generating checksums for source files...
>sha256sums=('bd51016d038277d2edd4e6d6def53b0ba24e0b238662d404a07a7d706ad2b5d3'
> 'aa77f7e3b611787f734c7e7d7503d3debf9af86ac999e8bccf533c5a854ec15b'
> '0b770209a72171dfd46401d67d13204a767eb1749ef522df7ea7292b83046537'
>'8c11086809864b5cef7d079f930bd40da8d0869c091965fa62e95de9a0fe13b5')
>
>~/linux-gc$ makepkg --printsrcinfo
>pkgbase = linux-gc
>pkgdesc = Linux
>pkgver = 5.4.10
>pkgrel = 1
>url = https://cchalpha.blogspot.co.uk/
>arch = x86_64
>license = GPL2
>makedepends = bc
>makedepends = kmod
>makedepends = libelf
>makedepends = xmlto
>makedepends = python-sphinx
>makedepends = python-sphinx_rtd_theme
>makedepends = graphviz
>makedepends = imagemagick
>makedepends = git
>options = !strip
>source =
>linux-v5.4.10-arch1.tar.gz::https://git.archlinux.org/linux.git/snapshot/linux-v5.4.10-arch1.tar.gz
>source = config
>source =
>0001_bmq_v5.4-r1.patch::https://gitlab.com/alfredchen/bmq/raw/master/5.4/bmq_v5.4-r1.patch
>source =
>0002_enable_additional_cpu_optimizations-20190822.tar.gz::https://github.com/graysky2/kernel_gcc_patch/archive/20190822.tar.gz
>validpgpkeys = ABAF11C65A2970B130ABE3C479BE3E4300411886
>validpgpkeys = 647F28654894E3BD457199BE38DBBDC86092693E
>validpgpkeys = 8218F88849AAC522E94CF470A5E9288C4FA415FA
>sha256sums =
>1fda6369ec7038c9ca1fe7aa6206977c5b8983c77e9d74e4ba458a4d042d1d31
>sha256sums =
>aa77f7e3b611787f734c7e7d7503d3debf9af86ac999e8bccf533c5a854ec15b
>sha256sums =
>0b770209a72171dfd46401d67d13204a767eb1749ef522df7ea7292b83046537
>sha256sums =
>8c11086809864b5cef7d079f930bd40da8d0869c091965fa62e95de9a0fe13b5
>
>pkgname = linux-gc
>  pkgdesc = The Linux kernel and modules with the BMQ CPU scheduler
>depends = coreutils
>depends = kmod
>depends = initramfs
>optdepends = crda: to set the correct wireless channels of your country
>   optdepends = linux-firmware: firmware images needed for some devices
>provides = linux-gc=5.4.10
>
>pkgname = linux-gc-headers
>pkgdesc = Headers and scripts for building modules for the Linux kernel
>depends = linux-gc
>provides = linux-gc-headers=5.4.10
>provides = linux-headers=5.4.10
>
>Thanks,

makepkg --geninteg doesn't change the PKGBUILD, I think you're looking for 
'updpkgsums'. 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[aur-general] Spam account: jennyhannb

[WorMzy Tykashi via aur-general]

Hi TUs, there's another spam account making the rounds:
https://aur.archlinux.org/account/jennyhannb/

Cheers,


WorMzy

[aur-general] Should co-maintainers get OOD notifications?

[WorMzy Tykashi]

Hey,

One of the packages I co-maintain on the AUR was flagged as out of
date today, but I didn't get a notification. Could someone confirm
whether this is normal/expected behaviour, or should I open a bug
report about it?

Cheers,


WorMzy

Re: [aur-general] Fwd: Re: [PRQ#4315] Deletion Request for python2-radicale

[WorMzy Tykashi]

On 13 November 2015 at 01:10, Johannes Löthberg  wrote:

>
> For some reason AUR user WorMzy had created an empty pkgbase without
> actually pushing a package

Yeah, my bad. Curiosity got the better of me after reading the thread,
so I checked out the package to see if it was still there, and what
state it was in; but then I couldn't find any way to disown without
pushing first and using the web interface, which I didn't want to do
because then I'd be listed as the submitter, which wouldn't be fair.
'ssh a...@aur.archlinux.org restore' didn't work: 'restore: package
base exists: python2-radicale'. Sorry for the inconvenience, Hugo.

It's a well written PKGBUILD, with one minor niggle -- arch should be
an array, not a string. I don't think you pushed your v1.0.1 update
before it was deleted though (or if you did, it wasn't part of the git
history).

Cheers,


WorMzy

Re: [aur-general] Out-of-date notifications

[WorMzy Tykashi]

I've noticed the same problem -- someone had flagged one of my
packages OOD four or five days ago, but I only just noticed today
after checking my packages on the web interface. My email is correct,
and I am still receiving comment notifications on the packages I am
subscribed to, I simply have no record of anyone flagging my package
out-of-date.

I had assumed that I must've unknowingly misclicked at some point, and
that you don't get notifications if you're the person who flags your
own package. If other people have had the same problem, then perhaps
there is a bug.

Cheers,


WorMzy

Re: [aur-general] Regarding Nessus AUR Package

[WorMzy Tykashi]

On 22 May 2015 at 06:55, Ivo Dopeadmin ivokatov...@gmail.com wrote:
 Hello Folks

 I was able to modify the PKGBUILD with the new version 6.3.6 and
 succesfully installed
 Nessus. I would like to keep maintaining the Nessus package.
 Tried submitting a new packaged but was not able to

 I.K.

That's because it already has a maintainer. File a request on the web
interface for the package to be disowned, and if the current
maintainer takes no action, in two weeks it will be disowned.

WorMzy

Re: [aur-general] Anonymous comments in the AUR

[WorMzy Tykashi]

On 27 June 2014 22:38, Karol Blazewicz karol.blazew...@gmail.com wrote:
 Are anonymous comments something new?

 Usually they're pretty old https://aur.archlinux.org/packages/lpairs/
 , the newest I stumbled upon is
 https://aur.archlinux.org/packages/hydrogen-drumkits/

 Were some users removed from the AUR db?

Yep, a while ago [1]. Although the initial email suggest ste comments
would be removed, this was revised later in the thread.

[1a] 
https://mailman.archlinux.org/pipermail/aur-general/2014-January/027030.html
[1b] 
https://mailman.archlinux.org/pipermail/aur-general/2014-February/027039.html

Re: [aur-general] Signoff report for [community-testing]

[WorMzy Tykashi]

On 21 June 2014 09:07, Arch Website Notification nob...@archlinux.org wrote:
 === Signoff report for [community-testing] ===
 https://www.archlinux.org/packages/signoffs/

 There are currently:
 * 0 new packages in last 24 hours
 * 0 known bad packages
 * 0 packages not accepting signoffs
 * 0 fully signed off packages
 * 1 package missing signoffs
 * 1 package 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.)



 == Incomplete signoffs for [community] (1 total) ==

 * waf-1.7.15-2 (any)
 1/2 signoffs


 == All packages in [community-testing] for more than 14 days (1 total) ==

 * waf-1.7.15-2 (any), since 2014-03-21


 == Top five in signoffs in last 24 hours ==



Poor waf-1.7.15-2, doomed to exist in that point between realities forever more.

Is there a reason for this? I couldn't find any active bug reports,
nor mailing list threads about it, and the whole pkgrel bump seems to
be a bump for the sake of bumping. Can someone shed some light on
this?

Cheers,


WorMzy

Re: [aur-general] Perl Upgrade, make test failures and you: The Hurt That Finds You First

[WorMzy Tykashi]

On 9 June 2014 21:53, John D Jones III unixgeek1...@gmail.com wrote:
 All:
 In my quest to begin getting my packages updated for the recent Perl 5.20
 release. I have run into a number of problems with tests failing on most of
 the pkgbuilds, even stable pkgbuilds like perl-moose or perl-moo. These test
 errors primarily smell like this:

Hi,

You've probably thought of this, but have you checked your hardware is
okay? If I was experiencing the behaviour you describe, I'd leave a
memtest86+ going for several passes and see if it finds any faults.
Or is it generally accepted that perl's tests fail periodically for no
obvious reason?

Cheers,


WorMzy

P.S. Perl sucks.
(Everyone should have a good laugh every so often) :P

Re: [aur-general] .AURINFO

[WorMzy Tykashi]

On 8 June 2014 21:55, Aaron Mueller m...@aaron-mueller.de wrote:
 Hi!

 With the support for base packages and the .AURINFO, I need someone who do a
 review on my package (roccat-tools). Is this the way it is intended?  Please 
 let
 me know if I miss(understand) something or other things I can optimize.

 Thanks!
   Aaron
Hi,

The AUR now has proper support for split packages, so the old true
 hack is no longer needed. The roccat-tools package looks like
it'd be empty, in which case you can drop that (just rename your
initial pkgver=roccat-tools to pkgbase=roccat-tools).

Other than that, I think your PKGBUILD is fine.

Cheers,


WorMzy

Re: [aur-general] pkgversion() not working

[WorMzy Tykashi]

On 7 June 2014 17:04, Storm Dragon stormdragon2...@gmail.com wrote:
 Hi,
 I was trying to update my PKGBUILD for talking-clock to get the version from
 git, but it keeps failing and saying the directory doesn't exist. When I
 check though, the directory does exist. Can someone please take a look and
 tell me what I have done wrong?
 Thanks
 Storm
 --

 --
 Registered Linux user number 508465:
 https://linuxcounter.net/user/508465.html
 My blog, Thoughts of a Dragon: http://www.stormdragon.us/
 get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193
 My Blackberry is Broken: http://is.gd/my_blackberry_is_broken
 gimme gimme shock treatment! I wanna wanna shock treatment!
 Ramones - Gimme Gimme Shock Treatment

Hi,

You're using an ancient PKGBUILD template. Rewrite it to conform to
the the current standards[1] first (e.g. get rid of the manual
git-cloning), then see if you still have a problem.

Cheers,


WorMzy

[1] https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

Re: [aur-general] [Orphan Request] carddavmate

[WorMzy Tykashi]

On 28 May 2014 07:56, Stefan Tatschner rumpels...@sevenbyte.org wrote:
 This package [1] has been updated almost three years ago. I would like
 to adopt it. Could someone orphan it? Thanks!

 Stefan

 [1] https://aur.archlinux.org/packages/carddavmate


To add on to this, most of his packages haven't been updated in over
two years, and over half are flagged as out of date. I suspect he has
moved on from Arch, or has lost interest in maintaining his packages.
I've CC'd him into the conversation, and if he has no objections, I'm
requesting that all his packages be disowned.

Cheers,


WorMzy

Re: [aur-general] [Orphan Request] carddavmate

[WorMzy Tykashi]

On 28 May 2014 10:40, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:
 On 28 May 2014 07:56, Stefan Tatschner rumpels...@sevenbyte.org wrote:
 This package [1] has been updated almost three years ago. I would like
 to adopt it. Could someone orphan it? Thanks!

 Stefan

 [1] https://aur.archlinux.org/packages/carddavmate


 To add on to this, most of his packages haven't been updated in over
 two years, and over half are flagged as out of date. I suspect he has
 moved on from Arch, or has lost interest in maintaining his packages.
 I've CC'd him into the conversation, and if he has no objections, I'm
 requesting that all his packages be disowned.

 Cheers,


 WorMzy

Hi Stefan,

Either awayand himself, or a TU has disowned the package you were
asking about (and the others that were flagged out-of-date), so you
can adopt it now if you like.

Cheers,


WorMzy

[aur-general] Removal request - talesofmajeyal

[WorMzy Tykashi]

Hi TUs,

Please remove my package talesofmajeyal [1]. It is a duplicate of
tome4[2], a package that I didn't notice until just now.

Thanks,


WorMzy

[1] https://aur.archlinux.org/packages/talesofmajeyal/
[2] https://aur.archlinux.org/packages/tome4/

Re: [aur-general] Notify by e-mail when PKGBUILD updated by maintainer?

[WorMzy Tykashi]

On 8 May 2014 17:09, Nowaker enwuk...@gmail.com wrote:
 3) I think commenting about update will involve more people and bring
 awareness that the AUR package is active and not orphaned.


 This is true, but should not be implemented like that. That's good it has
 been reverted.

 AUR could keep track of the updates, e.g. have a new field named Updates
 that would list all versions and their release dates. It could be expandable
 with a single click, so it doesn't clutter the interface.

This seems like a pointless feature to me. As a user I'm only
interested in two things: 1) what version have I got installed now,
and 2) what version is available on the AUR now. Perhaps I am in a
minority here though.

A function that sends a notification to subscribers when a new
src.tar.gz is uploaded seems like the best way of fulfilling the
original request. Though perhaps a new option to subscribe to update
notifications would be preferable to sending them to people who just
want to be informed when a package is removed/merged.

Cheers,


WorMzy


 --
 Kind regards,
 Damian Nowak
 StratusHost
 www.AtlasHost.eu

Re: [aur-general] AUR 3.0.0-rc1 released

[WorMzy Tykashi]

On 1 May 2014 02:30, Doug Newgard scim...@archlinux.info wrote:


 Yep, that was the concern exactly. Nothing insurmountable, just wanting to
 clarify how it works upfront.

I share this concern. I've just uploaded slim-git [1] to the aur-dev:

  pkgbase=slim-git
  pkgname=('slim-git' 'slimlock-git')

If I now wanted to change the pkgbase to something more encompassing, e.g.

  pkgbase=slim-git_slimlock-git

I get the following error when I try to upload the aurball

  You are not allowed to overwrite the slim-git package.

I assume this is because my updated PKGBUILD provides slim-git (and
slimlock-git), but is in essence a completely different package,
because of the different pkgbase value. In this situation, I cannot
upload the PKGBUILD and have the old one merged into it, due to the
conflict.

As I understand it, my options are to either upload the new PKGBUILD
with different/temporary pkgnames, request to have the packages
merged, then undo the rename and upload the updated PKGBUILD again,
with the original pkgnames.

The other option, as Dave has suggested, is to submit the updated
PKGBUILD along with the merge request. Is this ideal, or would a patch
that can be applied directly onto the existing PKGBUILD be a better
idea? (or in this case, where a patch would be overkill, is it
preferable to just ask a TU to make the changes directly to the
PKGBUILD?)

Or alternatively, should pkgbase changes be disallowed completely,
except where it's really necessary?

Cheers,


WorMzy

[1] https://aur-dev.archlinux.org/pkgbase/slim-git/

Re: [aur-general] AUR 3.0.0-rc1 released

[WorMzy Tykashi]

On 1 May 2014 13:29, Dave Reisner d...@falconindy.com wrote:
 On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
 On 1 May 2014 02:30, Doug Newgard scim...@archlinux.info wrote:
 
 
  Yep, that was the concern exactly. Nothing insurmountable, just wanting to
  clarify how it works upfront.

 I share this concern. I've just uploaded slim-git [1] to the aur-dev:

   pkgbase=slim-git
   pkgname=('slim-git' 'slimlock-git')

 If I now wanted to change the pkgbase to something more encompassing, e.g.

   pkgbase=slim-git_slimlock-git


 I don't get it. pkgbase is intended to be no different from what it is
 in the binary repositories, e.g.:

 linux - linux linux-headers linux-docs
 pacman - pacman pacman-contrib

 What you're proposing here makes no sense.


Of course not, I'm an end user. ;)

This is just an example of something someone may try to do for
whatever reason. It fails, and quite rightly so, you can't have two
different pkgbases providing the same packages as each other. The
question remains whether people should be able to alter the pkgbase of
a split package. If not, that's fine. But if they are, how are they
supposed to do so? Does it/should it require TU intervention?

 I get the following error when I try to upload the aurball

   You are not allowed to overwrite the slim-git package.

 I assume this is because my updated PKGBUILD provides slim-git (and
 slimlock-git), but is in essence a completely different package,
 because of the different pkgbase value. In this situation, I cannot
 upload the PKGBUILD and have the old one merged into it, due to the
 conflict.

 And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
 provide 'libfoo', then what does the URI fragment '/packages/libfoo'
 point to? The basic unit of upload and download has essentially changed
 to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
 constraint between package names.


I understand this, and aren't trying to argue against it.

 As I understand it, my options are to either upload the new PKGBUILD
 with different/temporary pkgnames, request to have the packages
 merged, then undo the rename and upload the updated PKGBUILD again,
 with the original pkgnames.

 The other option, as Dave has suggested, is to submit the updated
 PKGBUILD along with the merge request. Is this ideal, or would a patch
 that can be applied directly onto the existing PKGBUILD be a better
 idea? (or in this case, where a patch would be overkill, is it
 preferable to just ask a TU to make the changes directly to the
 PKGBUILD?)

 Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
 a matter of procedure should never happen. This isn't secure at all.


I must have misinterpreted what you said earlier about sending the
PKGBUILD with the merger request. I assumed TUs had this capability. I
agree that it's not secure.

 Or alternatively, should pkgbase changes be disallowed completely,
 except where it's really necessary?

 Not sure what this accomplishes. If there's no pkgbase, it's just
 assumed to be whatever ${pkgname[0]} expands to. This is a carryover
 from makepkg.


I know this. I'm meaning in regards to split packages specifically.

 Cheers,


 WorMzy

 [1] https://aur-dev.archlinux.org/pkgbase/slim-git/

[aur-general] Removal request - redirfs package cleanup

[WorMzy Tykashi]

Hi TUs,

Please could you remove the following packages:

redirfs-bin [1] and redirfs-lib [2]. Neither have been updated since
2009, and both have no maintainer, any votes, and depend a
non-existent redirfs-modules package.

Cheers,


WorMzy

[1] https://aur.archlinux.org/packages/redirfs-bin/
[2] https://aur.archlinux.org/packages/redirfs-lib/

[aur-general] Disown Diego's packages

[WorMzy Tykashi]

Hi TUs,

I've got a bit of a strange request this time.

AUR user Diego [1] has been inactive and unresponsive [2] for a
while now. His last post to the mailing list was in September [3], and
he hasn't responded to a query I sent two weeks ago R.E. the slimlock
package [4].

Therefore, I am requesting that all of his packages [5] be disowned
(possibly after a two week grace period to give him a chance to
respond -- I've CC'd him in). I would also like to request that [4] be
disowned now, so I can update it.

I'm hoping he does respond, if only to confirm that he's inactive;
casual stalking shows that he hasn't updated his g+ or youtube in a
while either, which is worrying..

Cheers,


WorMzy

[1] https://aur.archlinux.org/account/Diego
[2a] 
https://mailman.archlinux.org/pipermail/aur-general/2014-January/026717.html
[2b] 
https://mailman.archlinux.org/pipermail/aur-general/2014-February/027148.html
[3] 
https://mailman.archlinux.org/pipermail/aur-general/2013-September/025197.html
[4] https://aur.archlinux.org/packages/slimlock/
[5] https://aur.archlinux.org/packages/?SeB=mK=diego

Re: [aur-general] Disown Diego's packages

[WorMzy Tykashi]

On 2 April 2014 11:20, Diego Principe cdprinc...@gmail.com wrote:
 2014-04-02 12:18 GMT+02:00 Diego Principe cdprinc...@gmail.com:

 Sorry but i've broken my laptop and my financial situation does not allow
 me to buy a computer.
 Of course, during this time I have access to the Internet only
 occasionally.
 Today is a new day for my packages in aur... all disowned
 Diego

 Diego


 2014-04-02 12:10 GMT+02:00 WorMzy Tykashi wormzy.tyka...@gmail.com:

 Hi TUs,


 I've got a bit of a strange request this time.

 AUR user Diego [1] has been inactive and unresponsive [2] for a
 while now. His last post to the mailing list was in September [3], and
 he hasn't responded to a query I sent two weeks ago R.E. the slimlock
 package [4].

 Therefore, I am requesting that all of his packages [5] be disowned
 (possibly after a two week grace period to give him a chance to
 respond -- I've CC'd him in). I would also like to request that [4] be
 disowned now, so I can update it.

 I'm hoping he does respond, if only to confirm that he's inactive;
 casual stalking shows that he hasn't updated his g+ or youtube in a
 while either, which is worrying..

 Cheers,


 WorMzy

 [1] https://aur.archlinux.org/account/Diego
 [2a]
 https://mailman.archlinux.org/pipermail/aur-general/2014-January/026717.html
 [2b]
 https://mailman.archlinux.org/pipermail/aur-general/2014-February/027148.html
 [3]
 https://mailman.archlinux.org/pipermail/aur-general/2013-September/025197.html
 [4] https://aur.archlinux.org/packages/slimlock/
 [5] https://aur.archlinux.org/packages/?SeB=mK=diego


 Sorry, I've topposted :P
 Diego

Hi Diego,

Thanks for the response! Sorry to hear about your laptop, but I'm glad
it wasn't anything more serious.

Thanks for maintaining these packages for so long, hopefully you will
be back once you can afford to replace your laptop. If you want to
take back the slimlock package at that time, just let me know. :)

Cheers,


WorMzy

Re: [aur-general] Move vagrant and ceph to [community]?

[WorMzy Tykashi]

I notice that the AUR ceph package installs non-systemd initscripts,
would moving this package to community upset some of the anti-systemd
users, or would the non-systemd initscripts be kept as a part of the
package or split off to an independent AUR package?

In any case, I'd like to see ceph re-uploaded with devtools-friendly
files (i.e. 644 permissions instead of 600). The inclusion into
community/ would be nice, if only because ceph takes a relatively long
time to compile.

Cheers,


WorMzy

[aur-general] html5lib package cleanup

[WorMzy Tykashi]

Hi,

Please remove the following packages:

 * python2-html5lib-hg [1] -- Development relocated to github, zero
votes, outdated PKGBUILD, orphaned
 * py-html5lib [2] -- Outdated duplicate of community/python2-html5lib, orphaned

Cheers,


WorMzy


[1] https://aur.archlinux.org/packages/python2-html5lib-hg/
[2] https://aur.archlinux.org/packages/py-html5lib/

Re: [aur-general] Package works before the compression, not after

[WorMzy Tykashi]

On 4 Mar 2014 07:19, Johannes Löthberg johan...@kyriasis.com wrote:

 On 03/03, WorMzy Tykashi wrote:

 If this package relies on a non-standard php.ini, bundle in a basic
 php.ini with the changes necessary, and use php's -c flag to use it
 instead of the system php.ini (dunno if this is possible with composer
 or php-box -- never used them).


 And/or include a .install file that tells you what you need to do.

 --
 Sincerely,
  Johannes Löthberg
  PGP Key ID: 3A9D0BB5

That is advisable for post-installation, but doesn't really help with the
build problem.

Cheers,

WorMzy

Re: [aur-general] Package works before the compression, not after

[WorMzy Tykashi]

On 5 March 2014 00:20, Attila Bukor r1pp3rj...@w4it.eu wrote:
 On 03/04/2014 10:53 AM, WorMzy Tykashi wrote:

 On 4 Mar 2014 07:19, Johannes Löthberg johan...@kyriasis.com wrote:


 On 03/03, WorMzy Tykashi wrote:


 If this package relies on a non-standard php.ini, bundle in a basic
 php.ini with the changes necessary, and use php's -c flag to use it
 instead of the system php.ini (dunno if this is possible with composer
 or php-box -- never used them).


 And/or include a .install file that tells you what you need to do.

 --
 Sincerely,
   Johannes Löthberg
   PGP Key ID: 3A9D0BB5


 That is advisable for post-installation, but doesn't really help with the
 build problem.

 Cheers,

 WorMzy


 Hey,

 I've changed the build as per your suggestions here:
 https://github.com/gushphp/gush-archlinux/commit/c41a9f9e10761d4fb9b2d061686eb0b06f61ff5c

 Also added the install warnings in the next commit:
 https://github.com/gushphp/gush-archlinux/commit/aa8acbcd4447a54f6fad81d3cabbc0e6c11f7f16

 Finally, sorry for the typo in your name :/

 Thank you all very much!

 Cheers,

 Attila

Hi,

No worries, I've seen worse. :P

I think you can afford to cut down that php.ini a lot more. I think
that php will resort to the compiled-in defaults if it can't find a
configuration value, so you should just need to include the phar
module configuration. I'm not a php expert though, so maybe php
complains if you remove anything else?

Cheers,


WorMzy

Re: [aur-general] Package works before the compression, not after

[WorMzy Tykashi]

On 3 March 2014 23:17, Attila Bukor r1pp3rj...@w4it.eu wrote:
 On 03/03/2014 10:35 PM, Nowaker wrote:

 I've submitted this package: https://aur.archlinux.org/packages/gush/


 I'd love to test it out and diff the two files, but I am not able to
 build this package with yaourt. You are probably missing some
 makedepends that prevent me from building.

 == Starting build()...
 PHP Fatal error:  Class 'Phar' not found in
 /usr/share/webapps/bin/composer.phar on line 13
 == ERROR: A failure occurred in build().

 Hey,

 Thanks for trying to help. You need to include phar.so in your php.ini for
 this. I don't think it's possible to mark this as a dependency - at least I
 have no idea how.

 Now that you mentioned diffing, I realized that I forgot to write that I
 tried it and diff said binary files /path1/gush.phar and /path/gush.phar
 differ. As I wanted to include this in my reply, I double checked it and
 to my surprise now it indicated they don't!

 So I started to investigate... Tried running both. The installed version
 didn't run, the non-installed one did. Tried diffing again, they differed. I
 figured the first run must alter it some way - no idea why - so I run chmod
 777 on it - and it worked!

 Well, as I couldn't just leave it that way, I decided to try something
 else and run ./gush.phar --version at the end of build(). It worked, so now
 it's finally fixed. That shouldn't be too annoying, fixes the issue and is
 only a minor black magic. I think I'll blog about this weird issue and
 fix...

 Now it's online and it works! In case you wonder what's happening, just
 remove lines 28 and 29 and the issue will come back.

 Thanks for your help again!

 Cheers,
 Attila


Hi,

Don't use patch -p0 ../../blah.patch, use 'patch -p0
$srcdir/blah.patch, or patch -p0 ../blah.patch. The point I'm
trying to make, is that you should never try to break out of
$srcdir.

If this package relies on a non-standard php.ini, bundle in a basic
php.ini with the changes necessary, and use php's -c flag to use it
instead of the system php.ini (dunno if this is possible with composer
or php-box -- never used them).

You should also enclose all instances of $srcdir and $pkgdir in
double-quotes, in case they have a space in their path.

Cheers,


WorMzy

Re: [aur-general] Plymouth packaging suggestions requested from TUs

[WorMzy Tykashi]

On 25 February 2014 10:44, Padfoot padf...@exemail.com.au wrote:
 Hi,

 I am the current maintainer of the AUR packages:

 plymouth-release https://aur.archlinux.org/packages/plymouth-release/
 plymouth-git https://aur.archlinux.org/packages/plymouth-git/

 plymouth-release is at version 0.8.8 on
 http://www.freedesktop.org/software/plymouth/releases/ and is working
 plymouth-git at http://cgit.freedesktop.org/cgit/plymouth/ is currently
 broken

 While investigation the plymouth-git breakage, I found source for
 plymouth-0.8.9 in Fedora Rawhide nightlies.
 0.8.9 builds and works correctly, but as it is from the Fedora Rawhide
 nightlies, the source is subject to frequent changes.

 I am seeking suggestions of what I could/could not should/should not do with
 the 0.8.9 package.

 I could update plymouth-release to this package, but it is not an official
 release.
 I could temporarily replace plymouth-git with this package until git is
 working, but it's not really a git source.
 I could upload a new plymouth-rawhide package, but I don't want to spam the
 AUR with yet another version unnecessarily.

 FInally I could just do nothing and wait until the official update to the
 source on http://www.freedesktop.org/software/plymouth/releases/

 Bear in mind, as the sources are from Fedora Rawhide nightlies, I have
 embeded the source archive in the package to prevent breakage from frequent
 updates. The package size including the source is 1.2MB.

 Of course, I would like to share this updated (as of Feb 2014) source with
 the Arch community, but under the circumstances, I think advice on how to
 proceed from the TUs is warranted.

 Thanks.
 Lachlan.



plymouth-git builds here in a clean-chroot, so I assume that upstream
already addressed the breakage, or your build failure is a result of
your system configuration.

Personally, I'd leave the situation as it is, plymouth = stable,
plymouth-git = unstable/testing. There's little point packaging 0.8.9
in the interim, people that switch to it will (presumably) have to
switch back once it goes official.


WorMzy

[aur-general] Linux-mainline + related package cleanup

[WorMzy Tykashi]

Hi,

I believe that the following packages should be removed:

linux-mainline-ux31e [1] -- last updated in early 2012, orphaned, only
three votes.
broadcom-wl-mainline [2] -- last updated in late 2012, orphaned, zero
votes, source gone, and apparently doesn't build anyway.

There's a third package which appears to be semi-active:
linux-mainline-dellxps [3], I've asked the maintainer whether the
package still has any point, as she/he has said that the
linux-mainline package works fine for them, so it may be worth keeping
an eye on the comments.

Cheers,


WorMzy

[1] https://aur.archlinux.org/packages/linux-mainline-ux31e/
[2] https://aur.archlinux.org/packages/broadcom-wl-mainline/
[3] https://aur.archlinux.org/packages/linux-mainline-dellxps/

Re: [aur-general] Need to delete AUR package

[WorMzy Tykashi]

On 6 February 2014 22:02, Argyrios Deligiannidis
a.deligianni...@gmail.com wrote:
 I need https://aur.archlinux.org/packages/nitr … -kde-
 dark/[1] to be deleted from AUR, because I did not notice
 that the company that created the Nitrux icon theme has a
 proprietary black theme.
 Thank you.

 
 [1] https://aur.archlinux.org/packages/nitrux-icons-kde-dark/
Related forum thread [1], turns out the theme maker's license doesn't
allow modifications, and there's already an unmodified theme in the
AUR [2] (albeit out of date)

[1] https://bbs.archlinux.org/viewtopic.php?id=176832
[2] https://aur.archlinux.org/packages/nitrux-icons-kde/

[aur-general] Removal request - bitcoind

[WorMzy Tykashi]

Hi,

Please remove bitcoind [1], it is provided by community/bitcoin-daemon.

Cheers,


WorMzy


[1] https://aur.archlinux.org/packages/bitcoind/

Re: [aur-general] Package of Questionable Legality

[WorMzy Tykashi]

On 1 February 2014 23:05, Rob Til Freedmen rob.til.freed...@gmail.com wrote:
 [...] so i created this 27 line program to do it for me and it
 automatically adds the torrent to my torrent client.

 This package is not and doesn't do any illegal!

 Though, if you download (via torrent) something your country deems is
 illegal you're responsible -
 and if you download (via torrent) something your country doesn't care
 of, you will be happy using it.

 It really depends on where you live
I think it depends more on where the AUR is hosted. Lets not forget
that the MPAA, seems to think that they can sue anyone, anywhere, for
anything they feel adversely affects their profit margins.

When somebody markets their software/script/whatever as a pirate
movie downloader, I think we should probably avoid packaging it.



WorMzy

Re: [aur-general] Rename request

[WorMzy Tykashi]

On 29 January 2014 10:12, Omid Nikta omidni...@gmail.com wrote:
 Hi everybody,
 Could you please rename my package qtmind to QtMind?

 https://aur.archlinux.org/packages/qtmind/

 Thanks
You should rename the package to qtmind-git, and make use of the
pacman 4.1 VCS templates [1] (i.e. put the git repo URL in the sources
array, write a pkgver function, and don't manually clone/make a build
directory).

You should also surround every $srcdir and $pkgdir with double quotes.
You also might want to check whether the Makefile has a install
recipe, rather than manually installing the files.

I don't know why you want to use capital letters everywhere. The
description is grating enough without $pkgname doing it too.

Cheers,


WorMzy

[1] https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines

Re: [aur-general] Delete request: python2-mavlink

[WorMzy Tykashi]

On 19 January 2014 19:01, Thomas Gubler thomasgub...@gmail.com wrote:
 Please delete python2-mavlink. The package is now called python2-mavlink-git.

 Thanks.

Hi Thomas,

Is there any reason why you're not using 4.1 VCS PKGBUILD
standards[1]? I don't think they're mandatory, but they're much
cleaner than the old hacky way of cloning VCS sources in the build
function.

[1] https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#VCS_sources

Re: [aur-general] Bundled applications policy?

[WorMzy Tykashi]

Hi,

Bump.

Maintainer has abandoned the package in the meantime, so please remove
the package (link for convenience:
https://aur.archlinux.org/packages/manarchy/ ).

Cheers,


WorMzy

On 26 December 2013 16:43, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:
 Hi,

 I posted a message on the package, but the maintainer has not
 responded yet. Their email is also not a recognised email address (I
 have tried to contact them regarding my suggestions)

 I should have clarified in my last mail that this package is not my
 own, but one that was brought to my attention on the Arch forums by a
 new user seeking assistance with it.

 Since the owner is unreachable, would it be possible to remove the
 package now (despite the two week rule). If preferred, I'll write a
 PKGBUILD for the beta aircrack-ng package and update the theharvester
 PKGBUILD so that the AUR status quo is maintained. I'll immediately
 aurphan these packages so that someone else can maintain them,
 however, as I have no interest in these tools..

 Please let me know what your thoughts are, and how we should best proceed.

 Happy holidays,


 WorMzy

 On 20 December 2013 13:35, Rashif Ray Rahman sc...@archlinux.org wrote:
 On 20 December 2013 04:20, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:
 On 19 December 2013 18:44, Rashif Ray Rahman sc...@archlinux.org wrote:
 Just provide for and conflict with the relevant packages and you don't
 give anyone any trouble.

 It's halfway there, it doesn't conflict with or provide theharvester
 package, though that's something I was going to mention when I comment
 about some changes they should make to the PKGBUILD (shouldn't be an
 'any' package, binaries shouldn't be in /usr/sbin, etc.). I just
 wanted to check that such packages are allowed before prompting them
 to fix it up.

 But if this whole thing is a package of a real
 software collection (and not just a mash-up by a packager) then I see
 no problem.

 It's the latter, the package pulls from two different, unrelated
 sources and merges them into one package. The only thing is, neither
 source is otherwise available on the AUR or official repositories (as
 far as I can tell).

 A better way to rephrase what I meant is this: if it's a useful bundle
 that people will use (if some people find the beta dep better), then
 there is no problem. The Arch way would be to provide a separate
 package for the beta dep instead, but you can tell if your idea (of
 bundling) is working if nobody says anything about that.


 --
 GPG/PGP ID: C0711BF1

Re: [aur-general] Bundled applications policy?

[WorMzy Tykashi]

Apologies for top posting.

[aur-general] tint2 packages cleanup

[WorMzy Tykashi]

Hi,

Please remove (or merge with [1]) the following packages:

tint2-svn-gnome-shell [2] -- using an archaic PKGBUILD template,
relies on patches not included in the source array.

tint2-graph [3] -- is incorrectly named (uses svn), uses old PKGBUILD
template, is orphaned, and is redundant (tint2-svn applies the same
patch).

Cheers,

WorMzy

[1] https://aur.archlinux.org/packages/tint2-svn/
[2] https://aur.archlinux.org/packages/tint2-svn-gnome-shell/
[3] https://aur.archlinux.org/packages/tint2-graph/

Re: [aur-general] Bundled applications policy?

[WorMzy Tykashi]

Hi,

I posted a message on the package, but the maintainer has not
responded yet. Their email is also not a recognised email address (I
have tried to contact them regarding my suggestions)

I should have clarified in my last mail that this package is not my
own, but one that was brought to my attention on the Arch forums by a
new user seeking assistance with it.

Since the owner is unreachable, would it be possible to remove the
package now (despite the two week rule). If preferred, I'll write a
PKGBUILD for the beta aircrack-ng package and update the theharvester
PKGBUILD so that the AUR status quo is maintained. I'll immediately
aurphan these packages so that someone else can maintain them,
however, as I have no interest in these tools..

Please let me know what your thoughts are, and how we should best proceed.

Happy holidays,


WorMzy

On 20 December 2013 13:35, Rashif Ray Rahman sc...@archlinux.org wrote:
 On 20 December 2013 04:20, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:
 On 19 December 2013 18:44, Rashif Ray Rahman sc...@archlinux.org wrote:
 Just provide for and conflict with the relevant packages and you don't
 give anyone any trouble.

 It's halfway there, it doesn't conflict with or provide theharvester
 package, though that's something I was going to mention when I comment
 about some changes they should make to the PKGBUILD (shouldn't be an
 'any' package, binaries shouldn't be in /usr/sbin, etc.). I just
 wanted to check that such packages are allowed before prompting them
 to fix it up.

 But if this whole thing is a package of a real
 software collection (and not just a mash-up by a packager) then I see
 no problem.

 It's the latter, the package pulls from two different, unrelated
 sources and merges them into one package. The only thing is, neither
 source is otherwise available on the AUR or official repositories (as
 far as I can tell).

 A better way to rephrase what I meant is this: if it's a useful bundle
 that people will use (if some people find the beta dep better), then
 there is no problem. The Arch way would be to provide a separate
 package for the beta dep instead, but you can tell if your idea (of
 bundling) is working if nobody says anything about that.


 --
 GPG/PGP ID: C0711BF1

[aur-general] Bundled applications policy?

[WorMzy Tykashi]

Hi,

What is the policy regarding collection/amalgamation packages?
'manarchy' [1] is just a recent beta version of aircrack-ng (stable
version in community) and an updated version of 'theharvester' [2]
bundled together.

Should [1] be removed/merged into [2], or should it split up into
individual packages, or is it perfectly acceptable to have packages
like this?

Cheers,


WorMzy


[1] https://aur.archlinux.org/packages/manarchy/
[2] https://aur.archlinux.org/packages/theharvester/

Re: [aur-general] Bundled applications policy?

[WorMzy Tykashi]

On 19 December 2013 18:44, Rashif Ray Rahman sc...@archlinux.org wrote:
 Just provide for and conflict with the relevant packages and you don't
 give anyone any trouble.

It's halfway there, it doesn't conflict with or provide theharvester
package, though that's something I was going to mention when I comment
about some changes they should make to the PKGBUILD (shouldn't be an
'any' package, binaries shouldn't be in /usr/sbin, etc.). I just
wanted to check that such packages are allowed before prompting them
to fix it up.

 But if this whole thing is a package of a real
 software collection (and not just a mash-up by a packager) then I see
 no problem.

It's the latter, the package pulls from two different, unrelated
sources and merges them into one package. The only thing is, neither
source is otherwise available on the AUR or official repositories (as
far as I can tell).


WorMzy

Re: [aur-general] Merge request: openarena-data

[WorMzy Tykashi]

On 9 December 2013 01:51, speps sp...@gmx.com wrote:

 On Mon, 09 Dec 2013 02:18:08 +0100
 Nowaker enwuk...@gmail.com wrote:

  I am new a maintainer of openarena and openarena-data. I decided to ship
  OpenArena from a binary distribution provided by OpenArena developers.
  Thus it's making openarena-data package no longer needed.

 Since Open Arena can be built from source [1], the
 openarena package should provide the compiled version.

 If you want to use the pre-built binary you may better upload a new
 openarena-bin package that would provide and conflict with
 openarena and openarena-data.

 [1] http://openarena.ws/page.php?14


 - speps -


In addition to this, if you don't want to maintain the from-source package
any more, please disown it so that someone who does can take over
maintaining it.

Cheers,


WorMzy

Re: [aur-general] Merge request: openarena-data

[WorMzy Tykashi]

On 9 December 2013 17:28, Nowaker enwuk...@gmail.com wrote:

 In addition to this, if you don't want to maintain the from-source package
 any more, please disown it so that someone who does can take over
 maintaining it.


 This package was dropped from community to AUR 2 months ago, and nobody
 was interested in it for 1.5 months before I adopted it. So if I'm to
 reupload this package as openarena-bin, I don't see any reason to leave the
 old openarena as is. If anyone ever thinks it's reasonable to provide
 source-compiled openarena, they will just create a new package. The name
 will be free to take at any time. Does it sound good?

 Thanks for your answers.


 --
 Kind regards,
 Damian Nowak
 StratusHost
 www.AtlasHost.eu


Well the comments and the votes are for the source-built package,
transferring those to a binary package seems wrong to me, but then again,
I'm not a TU, so it's not up to me.

Does the source package still build? If so, I see no problems leaving it as
an orphan. Someone who uses it might pick up maintaining it.


WorMzy

Re: [aur-general] staticlibs in PKGBUILD?

[WorMzy Tykashi]

On 18 November 2013 20:45, oliver oli...@first.in-berlin.de wrote:

 Hello,

 some people mourned on AUR that a package that I maintain
 (adopted from other peoples) does not use staticlibs option.

 before they mentioned it I didn't knew about it.

 Is this a new PKGBUILD-option, or did I just have not seen it before?

 What does this option do?

 I found the description for the option, it says:

 staticlibs - Leave static library (.a) files in packages

 Will static libs be only part of the package, if this option
 is set?
 So, without it, only shared libs will be put into the install package
 and static libs will be leftout?

 Can somebody please explain me this option?

 Ciao,
Oliver

 Static libs aren't supported in official arch packages, but several
packages still shipped with them due to staticlibs being the default in
makepkg. The pacman devs decided to switch to !staticlibs being the default
to bring the few remaining packages with static libs into line with the
policy. So no, staticlibs is not new, it was just enable by default
previously. Now you have to explicitly enable staticlibs to package the .a
static libraries, something that individuals can do themselves by modifying
the PKGBUILD, or by changing makepkg.conf.

It's up to you, as a maintainer of an unsupported package, whether you want
to enable the static libs for everyone (modify the PKGBUILD options array),
or leave it up to individuals who want the staticlibs to enable them
themselves. Personally, I prefer the latter.

Relevant arch-dev threads:
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024552.html
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/025002.html
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-September/025454.html
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-October/025542.html

WorMzy

Re: [aur-general] Disown request - slim-git

[WorMzy Tykashi]

On 13 November 2013 13:12, Maxime Gauduin aluc...@gmail.com wrote:

 On Wed, Nov 13, 2013 at 1:48 PM, WorMzy Tykashi wormzy.tyka...@gmail.com
 wrote:

  On 10 November 2013 11:35, WorMzy Tykashi wormzy.tyka...@gmail.com
  wrote:
 
   Hi,
  
   I emailed the current maintainer two weeks ago about updating
   slim-git's[1] PKGBUILD, but haven't had any response. I'd like to take
  over
   ownership, and merge slimlock-git[2] into it, since these two projects
  have
   merged upstream.
  
   If it's not too much trouble, could a TU please
  
   1) merge slimlock-git into slim-git
   and
   2) disown the resultant slim-git
  
   Thank you.
  
   [1] https://aur.archlinux.org/packages/slim-git/
   [2] https://aur.archlinux.org/packages/slimlock-git/
  
 
  I think this might have been overlooked. :)
 
  I've still had no response from the maintainer of slim-git. Could
 somebody
  have a look for me?
 
  Thanks.
 

 slim-git belongs to a fellow TU. I poked him on IRC about 2 days ago but
 got no answer so I'm CCing this mail to him. To be clear though, does the
 slim-git PKGBUILD need modifications or does it already provide slimlock
 functionnality? If no changes to the PKGBUILD are needed I'll just merge
 slimlock-git immediately and leave slim-git in cinelli's hands, otherwise
 let's wait another week, after that I'll do the merge and disown slim-git.

 Cheers,
 --
 Maxime


I'd just like to let you know that the situation is now resolved. I assume
you managed to contact Cinelli on IRC, or else he saw one of the emails or
this ML thread.

In any case, thanks to both of you.


WorMzy

Re: [aur-general] Disown request - slim-git

[WorMzy Tykashi]

On 10 November 2013 11:35, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:

 Hi,

 I emailed the current maintainer two weeks ago about updating
 slim-git's[1] PKGBUILD, but haven't had any response. I'd like to take over
 ownership, and merge slimlock-git[2] into it, since these two projects have
 merged upstream.

 If it's not too much trouble, could a TU please

 1) merge slimlock-git into slim-git
 and
 2) disown the resultant slim-git

 Thank you.

 [1] https://aur.archlinux.org/packages/slim-git/
 [2] https://aur.archlinux.org/packages/slimlock-git/


I think this might have been overlooked. :)

I've still had no response from the maintainer of slim-git. Could somebody
have a look for me?

Thanks.

Re: [aur-general] Disown request - slim-git

[WorMzy Tykashi]

On 13 November 2013 13:12, Maxime Gauduin aluc...@gmail.com wrote:

 On Wed, Nov 13, 2013 at 1:48 PM, WorMzy Tykashi wormzy.tyka...@gmail.com
 wrote:

  On 10 November 2013 11:35, WorMzy Tykashi wormzy.tyka...@gmail.com
  wrote:
 
   Hi,
  
   I emailed the current maintainer two weeks ago about updating
   slim-git's[1] PKGBUILD, but haven't had any response. I'd like to take
  over
   ownership, and merge slimlock-git[2] into it, since these two projects
  have
   merged upstream.
  
   If it's not too much trouble, could a TU please
  
   1) merge slimlock-git into slim-git
   and
   2) disown the resultant slim-git
  
   Thank you.
  
   [1] https://aur.archlinux.org/packages/slim-git/
   [2] https://aur.archlinux.org/packages/slimlock-git/
  
 
  I think this might have been overlooked. :)
 
  I've still had no response from the maintainer of slim-git. Could
 somebody
  have a look for me?
 
  Thanks.
 

 slim-git belongs to a fellow TU. I poked him on IRC about 2 days ago but
 got no answer so I'm CCing this mail to him. To be clear though, does the
 slim-git PKGBUILD need modifications or does it already provide slimlock
 functionnality? If no changes to the PKGBUILD are needed I'll just merge
 slimlock-git immediately and leave slim-git in cinelli's hands, otherwise
 let's wait another week, after that I'll do the merge and disown slim-git.

 Cheers,
 --
 Maxime


Hi, thanks for letting me know.

The main problem is that slim-git is currently using a git repository of an
outdated fork of slim, which hasn't merged slimlock/pulled the changes from
upstream. The last commits were in March, and those were just changes to a
PKGBUILD hosted in the repository. The commit prior to that was in February
and simply merged a patch that Cinelli submitted. Development seems to have
dried up around November:
https://github.com/AeroNotix/slim-git/commits/master

I wasn't aware that Cinelli is a TU, I don't mind waiting another week if
you want to try contacting him on IRC.

Thanks.

[aur-general] Disown request - slim-git

[WorMzy Tykashi]

Hi,

I emailed the current maintainer two weeks ago about updating slim-git's[1]
PKGBUILD, but haven't had any response. I'd like to take over ownership,
and merge slimlock-git[2] into it, since these two projects have merged
upstream.

If it's not too much trouble, could a TU please

1) merge slimlock-git into slim-git
and
2) disown the resultant slim-git

Thank you.

[1] https://aur.archlinux.org/packages/slim-git/
[2] https://aur.archlinux.org/packages/slimlock-git/

Re: [aur-general] Backslash to split lines in `depends` array

[WorMzy Tykashi]

On 3 Nov 2013 13:44, Fabien Dubosson fabien.dubos...@gmail.com wrote:

 Thanks all for your replies, I posted a comment to `octave-hg` AUR page to
 ask to remove it.

In my opinion, it is not the maintainer's problem if $aurhelper cannot
parse the PKGBUILD. The only thing that the maintainer needs to make sure
can parse it, is makepkg.

Re: [aur-general] architecture question

[WorMzy Tykashi]

  is it okay to do it even though it's not officially supported?


Packages in the AUR are unsupported by definition. I can't see anyone
reaching for their pitchforks over the inclusion of an architecture in
someone's arch array. I'd feel a bit uncomfortable adding an architecture
that I can't test myself, but if endusers say it works, then that's good
enough in my opinion.

Re: [aur-general] Review request of PKGBUILD: einspline

[WorMzy Tykashi]

On 2 October 2013 19:42, wolfgang_ma...@brain-frog.de wrote:

 Dear list,

 I read that if one feels the need to get comments of a PKGBUILD, this is
 the
 place to ask. This is my first PKGBUILD.


 Source code to be package
 =
 homepage: http://einspline.sourceforge.net/

 From the homepage
 
 einspline is a C library for the creation and evaluation of interpolating
 cubic basis splines (B-splines) in 1, 2, and 3 dimensions.


 Output of namcap
 ==
 namcap PKGBUILD: clean

 If einspline package is not installed:
 namcap einspline-0.9.2-1-x86_64.pkg.tar.xz
einspline W: Referenced library 'libeinspline.so.0' is an uninstalled
dependency

 If einspline packages is installed:
 namcap einspline-0.9.2-1-x86_64.pkg.tar.xz: clean

 ldd is fine on all libeinspline*


 Stuff to do
 
 I am not sure if fftw is a build-only or a runtime dependency. I will
 figure
 that out.




 Is there anything in the PKGBUILD which is wrong?
 Can I upload thes PKGBUILD to the AUR?

 Thank you for your comments.
 Best,
 Wolfgang

You don't need to specify gcc, gcc-libs, or pkg-config, as these are
satisfied by base and base-devel groups that people are expected to have
installed when building AUR packages:

https://wiki.archlinux.org/index.php/AUR#Prerequisites

Other than that, looks good to me.

Re: [aur-general] btrfs-progs packages

[WorMzy Tykashi]

On 17 September 2013 16:06, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:

 On 17 September 2013 15:39, Sébastien Luttringer se...@seblu.net wrote:

 On Tue, Sep 17, 2013 at 1:23 PM, WorMzy Tykashi
 wormzy.tyka...@gmail.com wrote:
  As it stands, the new testing/btrfs-progs is building the same tools as
 the
  btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is
  still quite behind.
 
  Once the testing package hits extra, btrfs-progs-git will be redundant
 (at
  least until Chris pulls in more commits). I guess the worth of
  btrfs-progs-git depends on how often Tom is planning on updating the
 commit
  ref in the official PKGBUILD and/or how often Chris pulls in changes to
 his
  tree.
 In general, official and official-git packages have different purposes.

 btrfs-progs in official repos (testing/extra) should provides a
 released version.
 The btrfs-progs-git package is a _source_ package used to build a
 package with the _last_ git version (at the build time).
 At each release, the git package should ship the same content that the
 released one.

 Cheers,

 --
 Sébastien Seblu Luttringer
 https://www.seblu.net
 GPG: 0x2072D77A


 Oops, I always forget that gmail defaults to top posting. Apologies for
 that. Also, I meant core/, not extra/.


  In general, official and official-git packages have different purposes.

 This is true, but until btrfs-progs starts releasing tagged versions
 again, it seems that btrfs-progs{,-git} will be providing the same thing
 (again, depending on how often the Mason tree gets updated and Tom updates
 the PKGBUILD).

 I'd like to reiterate that I'm in favour of having all three packages in
 the AUR, as I feel they all have value. btrfs-progs-git's usefulness will
 (hopefully) be restored/increased once btrfs-progs hits v0.20 proper.


 WorMzy


Okay, it looks like development on the -next branch has dried up and the
latest dated snapshot is 16 commits ahead of it. Can someone remove
btrfs-progs-unstable-git [1] please, it no longer makes sense. Sorry for
the trouble.

Cheers,


WorMzy

[1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/

Re: [aur-general] btrfs-progs packages

[WorMzy Tykashi]

As it stands, the new testing/btrfs-progs is building the same tools as the
btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is
still quite behind.

Once the testing package hits extra, btrfs-progs-git will be redundant (at
least until Chris pulls in more commits). I guess the worth of
btrfs-progs-git depends on how often Tom is planning on updating the commit
ref in the official PKGBUILD and/or how often Chris pulls in changes to his
tree.


On 17 September 2013 10:55, Sébastien Luttringer se...@seblu.net wrote:

 On Mon, Sep 16, 2013 at 5:35 PM, WorMzy Tykashi
 wormzy.tyka...@gmail.com wrote:
  Hi, I've submitted two new btrfs packages to the AUR:
  btrfs-progs-unstable-integration [0] and
  btrfs-progs-unstable-integration-git [1], and I'd like opinions on the
  state of things:
 
  a) should btrfs-progs-git [2] should be merged with
  btrfs-progs-unstable-integration-git, given that the latter is more true
 to
  it's name as a -git package, and the former is more of a lagging stable
  version of the non-git integration branch
 
  or
 
  b) should the non-git, btrfs-progs-unstable-integration package be
 dropped
  in favour of the more stable btrfs-progs-git package
 
  or
 
  c) should all three packages remain
 
  or
 
  d) should the unstables be merged into one PKGBUILD with the option to
 let
  the user choose between stable and next by setting a variable in it?
 
  or
 
  e) something else?
 
  Personally, I'm happy maintaining all three packages, but I'm aware that
 I
  have just tripled the number of btrfs-progs packages in the AUR, which
 may
  cause some confusion with some users, and may be considered littering the
  AUR.
 
  Some further information which may be useful:
 
  btrfs-progs-git = stable, but stale (no commits since July 5th)
  btrfs-progs-unstable-integration = unstable, but known to build, snapshot
  of the integration-next (git) branch
  btrfs-progs-unstable-integration-git = most unstable, actively committed
  to, may not always build
 
  Thanks.
 
 
  [0] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration/
  [1]
 https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/
  [2] https://aur.archlinux.org/packages/btrfs-progs-git/

 I don't think we need more than a git package (with Mason tree).
 Our official package is already a git snapshot and Tom asked[1] to change
 that.

 [1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg26611.html

 --
 Sébastien Seblu Luttringer
 https://www.seblu.net
 GPG: 0x2072D77A

Re: [aur-general] btrfs-progs packages

[WorMzy Tykashi]

On 17 September 2013 15:39, Sébastien Luttringer se...@seblu.net wrote:

 On Tue, Sep 17, 2013 at 1:23 PM, WorMzy Tykashi
 wormzy.tyka...@gmail.com wrote:
  As it stands, the new testing/btrfs-progs is building the same tools as
 the
  btrfs-progs-git PKGBUILD (albeit with !staticlibs), extra/btrfs-progs is
  still quite behind.
 
  Once the testing package hits extra, btrfs-progs-git will be redundant
 (at
  least until Chris pulls in more commits). I guess the worth of
  btrfs-progs-git depends on how often Tom is planning on updating the
 commit
  ref in the official PKGBUILD and/or how often Chris pulls in changes to
 his
  tree.
 In general, official and official-git packages have different purposes.

 btrfs-progs in official repos (testing/extra) should provides a
 released version.
 The btrfs-progs-git package is a _source_ package used to build a
 package with the _last_ git version (at the build time).
 At each release, the git package should ship the same content that the
 released one.

 Cheers,

 --
 Sébastien Seblu Luttringer
 https://www.seblu.net
 GPG: 0x2072D77A


Oops, I always forget that gmail defaults to top posting. Apologies for
that. Also, I meant core/, not extra/.

 In general, official and official-git packages have different purposes.

This is true, but until btrfs-progs starts releasing tagged versions again,
it seems that btrfs-progs{,-git} will be providing the same thing (again,
depending on how often the Mason tree gets updated and Tom updates the
PKGBUILD).

I'd like to reiterate that I'm in favour of having all three packages in
the AUR, as I feel they all have value. btrfs-progs-git's usefulness will
(hopefully) be restored/increased once btrfs-progs hits v0.20 proper.


WorMzy

[aur-general] btrfs-progs packages

[WorMzy Tykashi]

Hi, I've submitted two new btrfs packages to the AUR:
btrfs-progs-unstable-integration [0] and
btrfs-progs-unstable-integration-git [1], and I'd like opinions on the
state of things:

a) should btrfs-progs-git [2] should be merged with
btrfs-progs-unstable-integration-git, given that the latter is more true to
it's name as a -git package, and the former is more of a lagging stable
version of the non-git integration branch

or

b) should the non-git, btrfs-progs-unstable-integration package be dropped
in favour of the more stable btrfs-progs-git package

or

c) should all three packages remain

or

d) should the unstables be merged into one PKGBUILD with the option to let
the user choose between stable and next by setting a variable in it?

or

e) something else?

Personally, I'm happy maintaining all three packages, but I'm aware that I
have just tripled the number of btrfs-progs packages in the AUR, which may
cause some confusion with some users, and may be considered littering the
AUR.

Some further information which may be useful:

btrfs-progs-git = stable, but stale (no commits since July 5th)
btrfs-progs-unstable-integration = unstable, but known to build, snapshot
of the integration-next (git) branch
btrfs-progs-unstable-integration-git = most unstable, actively committed
to, may not always build

Thanks.


[0] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration/
[1] https://aur.archlinux.org/packages/btrfs-progs-unstable-integration-git/
[2] https://aur.archlinux.org/packages/btrfs-progs-git/

Re: [aur-general] delete eclipse-php

[WorMzy Tykashi]

On 2 September 2013 19:33, Ike Devolder ike.devol...@gmail.com wrote:

 https://aur.archlinux.org/packages/eclipse-php/

 if no-one is interested i will delete this package.
 Zend is going nowhere with it

 --
 Ike


Looks like there's active development going on[1], and the source archive
is still present[2]..

If you're not interested in maintaining the package, just orphan it. I
don't see a need to delete it.

[1] https://code.google.com/p/zend-sdk/source/list
[2]
http://zend-sdk.googlecode.com/files/eclipse-php-3.0.2.v20120511142-x86.tar.gz

Re: [aur-general] Original vlock sources

[WorMzy Tykashi]

On 29 July 2013 15:08, Rob Til Freedmen rob.til.freed...@gmail.com wrote:

 Try a debian server, eg.
 http://ftp.de.debian.org/debian/pool/main/v/vlock/vlock_2.2.2.orig.tar.gz


Latest version I have is 2.2.3. I've uploaded it to github:
https://github.com/WorMzy/vlock

Re: [aur-general] Removal request

[WorMzy Tykashi]

On 29 July 2013 23:54, Markus Unterwaditzer mar...@unterwaditzer.netwrote:

 Hello,

 I created a PKGBUILD for Tox-Qt

 https://github.com/nurupo/ProjectTox-Qt-GUI

 on

 https://aur.archlinux.org/packages/tox-qt/

 The developer contacted me and said he was not comfortable with the fact
 that
 his pre-alpha software is available as a package to endusers.

 So, please remove it i guess.

 -- Markus

Seems odd that the developer doesn't want people using it, but have made
the code publicly available.. Have you told them that the AUR doesn't
contain precompiled software packages, and that -git packages in particular
are well known for being unstable/developmental?

Re: [aur-general] ttf-google-webfonts{,-distilled,-git,-hg} mess

[WorMzy Tykashi]

 So, then the solution is for the -git maintainer to update / re-upload
 the PKGBUILD whenever there's a version bump to the git repo?
 --
 David J. Haines
 djhai...@gmx.com


No, the solution is for the users of the -git package to track upstream
changes and re-compile the package as and when they see fit.

Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?

[WorMzy Tykashi]

On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote:

 On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@gmail.com wrote:
  On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote:
   On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard girard.ced...@gmail.com
 wrote:
  
   Hello,
  
   I was wondering, as I am updating my PKGBUILDs to use the new VCS
   features of pacman, if this specific case need an epoch increase for
   those packages.
  
   Packages version were generated from the date (eg 20130401) and thus
   will probably be bigger than new versions from the tags (eg
   0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a
   correct behavior.
  
   But it seems most packagers are not increasing the epoch as they are
   switching to this new versionning scheme.
  
   Is there a recommendation on this?
  
   --
   Cédric Girard
  
   Yes, the correct thing to do would be bumping epoch for every new
 release
   of the PKGBUILD.
  I think you mean it just needs to be bumped this once, since the tag
  versions are going to be increasing from here onward... (unless, of
  course, the pkgver() function is changed in a way that this is not true).

 I'm sure an epoch is the correct way to handle this, but we have to
 remember this is the AUR, not the official repos. The officially supported
 way of building from the AUR is using makepkg then install with pacman, in
 which case the epoch won't make a difference. It will stop pacman from
 giving you a warning, and in return you're stuck with an epoch for the life
 of the package. If the maintainer wants to make it easier for AUR helpers,
 go ahead and add the epoch, but I don't see it as required in this case.



Is the new way of pkgver-ing VCS packages mandatory? The VCS Guidelines[0]
isn't clear, it just says that pkgver is more controllable, and lists a few
examples. Would it be wrong for me to continue using the date +%Y%m%d
versioning system, or is up to individual maintainers to choose which
system is more appropriate?

Re: [aur-general] VCS PKGBUILD and Pacman 4.1: increase epoch?

[WorMzy Tykashi]

On 5 April 2013 22:19, WorMzy Tykashi wormzy.tyka...@gmail.com wrote:

 On 5 April 2013 20:17, Doug Newgard scimmi...@outlook.com wrote:

 On Fri, 5 Apr 2013 15:11:40 -0400, luoli...@gmail.com wrote:
  On 04/05/2013 10:05 AM, Jan Alexander Steffens wrote:
   On Fri, Apr 5, 2013 at 4:02 PM, Cédric Girard 
 girard.ced...@gmail.comwrote:
  
   Hello,
  
   I was wondering, as I am updating my PKGBUILDs to use the new VCS
   features of pacman, if this specific case need an epoch increase for
   those packages.
  
   Packages version were generated from the date (eg 20130401) and thus
   will probably be bigger than new versions from the tags (eg
   0.3.1.32.gfb4117d). Thus an epoch increase should be needed to have a
   correct behavior.
  
   But it seems most packagers are not increasing the epoch as they are
   switching to this new versionning scheme.
  
   Is there a recommendation on this?
  
   --
   Cédric Girard
  
   Yes, the correct thing to do would be bumping epoch for every new
 release
   of the PKGBUILD.
  I think you mean it just needs to be bumped this once, since the tag
  versions are going to be increasing from here onward... (unless, of
  course, the pkgver() function is changed in a way that this is not
 true).

 I'm sure an epoch is the correct way to handle this, but we have to
 remember this is the AUR, not the official repos. The officially supported
 way of building from the AUR is using makepkg then install with pacman, in
 which case the epoch won't make a difference. It will stop pacman from
 giving you a warning, and in return you're stuck with an epoch for the life
 of the package. If the maintainer wants to make it easier for AUR helpers,
 go ahead and add the epoch, but I don't see it as required in this case.



 Is the new way of pkgver-ing VCS packages mandatory? The VCS Guidelines[0]
 isn't clear, it just says that pkgver is more controllable, and lists a few
 examples. Would it be wrong for me to continue using the date +%Y%m%d
 versioning system, or is up to individual maintainers to choose which
 system is more appropriate?

Oops. Forgot my reference.

[0]
https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines

Re: [aur-general] creating versioned packages from github

[WorMzy Tykashi]

I guess it's because you're using fancy formatted text, while others
(like myself) are using plain text. For some reason google's decided
that 1 formatted text linebreak == 3 unformatted text linebreaks. Or
something.

On 20 January 2012 15:02, Alper Kanat tu...@raptiye.org wrote:
 Well this is how it looks to me: http://cl.ly/DVV8

 I don't know what went wrong but sorry for any inconveniences.

 ---
 Quis custodiet ipsos custodes?


 On Fri, Jan 20, 2012 at 16:42, Jesse Juhani Jaara 
 jesse.ja...@gmail.comwrote:

 perjantai, 20. tammikuuta 2012 16:12:11 Alper Kanat kirjoitti:
  Hey There,
 
  ---
  Quis custodiet ipsos custodes?
 
  On Fri, Jan 20, 2012 at 14:13, Jesse Juhani Jaara
 jesse.ja...@gmail.comwrote:
   In the future please not use so too manu newlines
   If you do, I will confiscate your Enter keys
 
  I can't understand what you mean?
 I'm referring to this
 ###
 pkgname=django-grappelli



 pkgver=2.3.5



 pkgrel=1
 
 Those 3 empty newlines you have there make the thing a hell of lot harder
 to
 read. Many are also reading their mail on 3 screen of their smart phone.

 pkgname=django-grappelli
 pkgver=2.3.5
 pkgrel=1

 See, its not hard to read them eventought they are straight under each
 others.
 And saves a lot of key stokes if you edit that in console :D

[aur-general] Removal request (xscreensaver-arch)

[WorMzy Tykashi]

Package Name: xscreensaver-arch

URL: https://aur.archlinux.org/packages.php?ID=51264

Reason for deletion: Appears to an out-of-date orphaned duplicate of
xscreensaver-arch-logo
(https://aur.archlinux.org/packages.php?ID=26586).

Cheers,
WorMzy

Re: [aur-general] Merry Christmas!

[WorMzy Tykashi]

On Sat, 24 Dec 2011 17:37:22 +0800
郑文辉(Techlive Zheng) techlivezh...@gmail.com wrote:

 All Arch Linuxer,
 
 Merry Christmas,have a nice holiday!

Merry Christmas everyone!

May you all consume copious amounts of food and alcohol (within
reason!) and enjoy yourselves. :D

[aur-general] Removal of zsh-systemctl from AUR

[WorMzy Tykashi]

Package name: zsh-systemctl

URL: https://aur.archlinux.org/packages.php?ID=51900

Reason for deletion: Included in upstream zsh, which is available in
extra (http://www.archlinux.org/packages/extra/x86_64/zsh/)
I am the maintainer of the AUR package, and provided over six weeks
notice that this would likely be happening. The git repository
(https://github.com/foudfou/zsh-completion/) will apparently be removed
shortly too, so zsh-systemctl-git
(https://aur.archlinux.org/packages.php?ID=52097) should probably be
considered for removal too (I am not the maintainer for that package,
Feanor12 is).

Cheers,
WorMzy