Re: [aur-general] TU removal: Ray Rashif

[Ray Rashif via aur-general]

Sorry folks, I should have probably sent in a resignation for this. I
have also made unfulfilled promises as a developer and never sent in
an inactivity declaration in the hopes of getting back to Arch/Linux
once I have a new computer. As funny as it sounds my undeclared
inactivity is as long as this current machine ~3-4 years and a
purchase has been pending since last year but keeps getting
down-prioritized due to $$ requirements elsewhere in RL.

On Wed, 16 Oct 2019 at 22:30, David Runge  wrote:
>
> On 2019-10-11 14:44:27 (+0200), David Runge wrote:
> > In accordance to the bylaws a vote has now been started:
> > https://aur.archlinux.org/tu/?id=120
>
> The results are in:
>
> Yes: 36
> No: 7
> Abstain: 6
> Total: 49
> Participation: 87.50%
>
> The quorum of 66% has been reached with a larger number of "Yes", than
> "No" votes.
>
> This means Ray Rashif is no longer a Trusted User.
>
> On behalf of the team I would like to thank Ray for his dedication
> towards the community and distribution over the years.
>
> I hope that his time permits further involvement in the future. :)
>
> Bests,
> David
>
> --
> https://sleepmap.de



-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Application: David Runge

[Ray Rashif via aur-general]

On 24 October 2017 at 22:54, Giancarlo Razzolini
 wrote:
> Em outubro 24, 2017 14:43 Rashif Ray Rahman escreveu:
>>
>> On 18 October 2017 at 18:40, Rashif Ray Rahman 
>> wrote:
>>>
>>> The discussion begins now and will last until 23 October, after which
>>> the voting period will begin on 24 October. Good luck David!
>>
>>
>> The formal discussion period is over, please cast your votes! The
>> voting period will last until 31 October.
>>
>> I do have one thing to say to David: please do think about the time
>> commitment associated with this. If you think that you won't be able
>> to commit much starting out, then it will be quite sad moving forward.
>>
>> Otherwise, I say again that David's proposal has followed standard
>> procedure, including a holistic review by myself the sponsor. Some
>> issues were raised based on automated tool reports, which I think
>> David will be able to resolve.
>>
>> Good luck!
>>
>
> The link to the vote for the lazy: https://aur.archlinux.org/tu/?id=97

Results are in:

Yes   No  Abstain  Total   Participation
  25 68  39   82.98%

Congratulations, David, you are now an Arch Linux Trusted User!

What's more:

- I have updated your account on AUR;
- I see you have two usernames on our bugtracker, let us know which
username to upgrade.

Enjoy!


-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Application: David Runge

[Ray Rashif via aur-general]

On 25 October 2017 at 06:12, Eli Schwartz  wrote:
> On 10/24/2017 12:43 PM, Rashif Ray Rahman wrote:
>> Some issues were raised based on automated tool reports, which I
>> think David will be able to resolve.
>
> Excuse me? I am hardly an "automated tool report". :p You seem to have
> derived that conclusion out of thin air.

Ahh, crap. Before I get to that, automated tool or not, I forgot to thank you
for providing your feedback for David.

Now, about that automated tool thing: I did a search for 'xxarhtna' in my
archives and got some lines indicating an execution of a script. So,
it was not really out of thin air, but most likely my misinterpration.
It's likely my absence from IRC that's causing this faux pas.

But again, even if it were an automated tool report, it would have been
"issues based on automated tool reports", which is feedback nevertheless.
And for that one must be thanked.

> The reason I never got around to remarking on his packages until very
> nearly the last day of the discussion period was not just because I was
> expecting anthraxx to do so first -- I also spent no little time reading
> every single PKGBUILD of his in the AUR, and cloning the sources for
> perusal for several of them too.

No, of course, it's not wrong to not be able to commit to anything here.
If you choose to provide feedback that means you went out of your way.
And in this case you definitely went out of your way to support the
applicant's sponsor in raising concerns he did not, which is healthy.

> I've seen a lot of PKGBUILDs, and many/most of the simple mistakes or
> general style failures that people tend to make; I have a list of things
> to raise red flags over. But that still doesn't mean I can review a
> PKGBUILD without even looking at it! Maybe one day...

Again, that comment of mine was not really meant to say nobody did
anything. I really just wanted to say "issues were raised" or "feedback
was given". Me being a wordy person, sometimes extra words get added for free!

But yes, if there are indeed red flags that make the applicant
look totally incapable or untrustworthy, we should know, and
raise hell ourselves.


--
GPG/PGP ID: C0711BF1

Re: [aur-general] TU inactivity

[Ray Rashif]

On 31 July 2012 05:03, Kyle  wrote:
> Thanks for all you do to keep Arch talking. See you next week.

Yes, Chris, I just want to say you're an awesome guy (note: he was my
awesome TU sponsor) especially for creating and maintaing TalkingArch
and in general making awesome computing accessible. Take care and
enjoy!


--
GPG/PGP ID: C0711BF1

Re: [aur-general] orphaned community packages (intel-tbb, arpack, libmatio, xml-rpc and aspell-pt)

[Ray Rashif]

On 4 January 2012 08:23, Eduardo Martins Lopes  wrote:
> Actually the question regarding the names is about creating an aur package
> with the same name of the orphaned ones since the aur is where i can
> maintain those packages.

Oh no you can't do that. You have to use a different name. For
packages that are out of date it is better to provide the maintainer
(via email or other means) with updated scripts or patches. If they
are not responsive then bring the matter up with everyone. One of us
can at least help to apply the changes verbatim.

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] orphaned community packages (intel-tbb, arpack, libmatio, xml-rpc and aspell-pt)

[Ray Rashif]

On 3 January 2012 07:39, Eduardo Martins Lopes  wrote:
> Hello guys,
> I have an aur package 
> (opencv-tbb https://aur.archlinux.org/packages.php?ID=42121) that depends on 
> intel-tbb, but this one is an orphaned community package and i would like to 
> maintain it. Can i upload a pkbuild to the AUR (perhaps with the same name) ? 
> There a few other orphans that would like to adopt, if it's possible:
>        * libmatio - http://www.archlinux.org/packages/community/i686/libmatio/
>        * arpack  - http://www.archlinux.org/packages/community/i686/arpack/
>        * xmlrpc-c - http://www.archlinux.org/packages/community/i686/xmlrpc-c/
>        * aspell-pt - http://www.archlinux.org/packages/extra/i686/aspell-pt/
> Although i do not use the last ones (except for the dictionary), they fall 
> within the scope of my interests.

Hello

I was supposed to bring intel-tbb to extra and build opencv against
it. I will do that soon, so you don't have to worry about that one
anymore and opencv from repos will have intel-tbb improvement.

As for the others, it depends on the maintainer, the package
popularity, whether it is in use as a make or optional dependency etc.


--
GPG/PGP ID: C0711BF1

Re: [aur-general] Merry Christmas!

[Ray Rashif]

On 24 December 2011 22:28, Jesse Jaara  wrote:
> Merry christmas for every christian people. I hope people from another
> religion don't mind us wishing merry Christmas.

If they do, their at a loss - 'tis the season to be jolly ;p

Merry Christmas and happy holidays!


--
GPG/PGP ID: C0711BF1

Re: [aur-general] Christmas Cleanup of [community] - Stage 2

[Ray Rashif]

On 14 December 2011 21:55, Alexander Rødseth  wrote:

> Oh, and please update the table at
>
> https://wiki.archlinux.org/index.php/Christmas_Cleanup#Orphaned_community_packages_that_should_be_moved_to_unsupported
> once packages have been moved.
>
> Thanks. :)
>
> --
> Sincerely,
>  Alexander Rødseth
>  Arch Linux Trusted User
>  (xyproto on IRC, trontonic on AUR)
>

Thanks, adopted cwiid which I forgot about :P

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] [PATCH] Added handling of ctrl-c

[Ray Rashif]

On 9 December 2011 19:27, Alexander Rødseth  wrote:
> Hi,
>
> 2011/12/9 Angel Velásquez :
>> HAHA don't you realize that you're sending this thread to aur-general
>> right?
>>
>> pwned. Glasses are good, you know? ahahaha
>
> I know, I wrote that the wiki "also had it wrong", admitting my mistake.

At that time there was no projects mailing list to send patches, and
arch-general was this avenue until just recently. So that's not really
wrong.

Anyway, not a big issue. Send to the correct list again.

--
GPG/PGP ID: C0711BF1

Re: [aur-general] GPG Key Signing

[Ray Rashif]

On 1 December 2011 23:36, Peter Lewis  wrote:

> On Thursday 01 Dec 2011 09:08:39 Thomas Dziedzic wrote:
> > I do find it kind of abnormal that a TU does want to retain his real
> name.
>
> To be fair that are loads of potential reasons why someone wouldn't want
> their
> actual identity disclosed in a place where discussions are archived on the
> web
> with timestamps and everything. He could be doing all this in a place where
> free use of the Internet is forbidden, could be on a witness protection
> programme, could be doing it while at work and slacking off and not
> wanting to
> get caught, could actually be Kim Jong Il in his spare time. Seriously, we
> have no way to judge reasons or not. And this isn't specific to Xyne, or
> anyone else.
>
> My real name is actually Robert Parks.
>
> Perhaps.
>
> :-p
>
>
> > There may be legitimate reasons for doing this or not, I don't know.
> > But I also have to agree with Thomas on this one.
> > I don't think anyone has actually verified that any of the given names
> > are real names.
> > What's important is that you're verified that you use the key to sign
> > your packages in case someone does get compromised or decides to go
> > rogue, then we will have a way to easily track which packages should
> > become void.
>
> Absolutely. Let's not turn into Google+ over this one...
>
> Pete.
>

I am in full agreement with Thomas as well. There are many valid reasons
for not using your real name on the Internet. Genius people hide behind
screen names and yet we benefit from their work. So there is no reason we
should say "you there, you genius kid. what's yo name? no name? get outta
here we don't need yo charity."

But of course I'm not assuming Xyne is a genius, or a kid.

--
GPG/PGP ID: C0711BF1

Re: [aur-general] "install" recursive?

[Ray Rashif]

On 1 December 2011 01:25, Piotr Rogoża  wrote:

> On 28.11.2011 21:38, Jonathan Steel wrote:
> > Hi,
> >
> > I was told it was best practice to use "install" rather than "mkdir"
> > and "cp" in a PKGBUILD, but how can you copy a directory and its
> > contents (recursively) using "install"?
> >
> > If you cannot, with a folder with lots of files, is it best practice
> > to list every file to copy with "install", or use one command to "cp"
> > the whole folder?
>
> Hi,
>
> Maybe tar? E.g.:
> tar -c ./ | tar -x -C ${pkgdir}/...
>
> --
> Piotr Rogoża
>

I think this is where we say "enough" :)

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] TU Application - Timothy Redaelli

[Ray Rashif]

On 30 November 2011 03:47, Timothy Redaelli wrote:

> Hi,
> I'm sorry that I took too much inspiration from the presentation of
> Massimilano.
> It was not my intention to disrespect anyone. I've never been good at
> describing myself and I was looking for a starting point, but I think
> I overdid it.
> I hope I can prove worthy of trust, despite this incident.
>

Your English is perfect (you may have asked someone for help here but
that's out of the point).

I took a look at both applications, and it is evident that the older one
has been used as a template here. A template, nothing less, nothing more.
Keep in mind that both of these applicants are from the same community (I
presume), so one may think it's alright to do a little copying from the
person before him.

I believe there is no harm, because unique information has been
appropriately inserted as and where needed.

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] [arch-dev-public] Developer/TU key signing

[Ray Rashif]

On 25 November 2011 21:27, Ionut Biru  wrote:
> Hi,
>
> my arch master key is available [1] with fingerprint 44D4 A033 AC14 0143
> 9273  97D4 7EFD 567D 4C7E A887.
>
> Every packager please do:
>
> 1) reply this email in the mailing list, include gerolde/sigurd username
> and sign your reply using your gpg key.
> 2) name at least one package you already signed.
>
> [1] https://dev.archlinux.org/~ibiru/ionut_AT_master-key.archlinux.org
>
>
> --
> Ionuț
>
>

gerolde username: schivsigurd username: schiv
Package(s) already signed with key:
* extra/libffado
-- 
GPG/PGP ID: C0711BF1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

/home/schiv/.gnupg/pubring.gpg
- --
pub   2048R/C0711BF1 2011-10-31
  Key fingerprint = D921 CABE D130 A569 0EF1  896E 81AF 739E C071 1BF1
uid  Rashif Rahman (Ray) 
sub   2048R/D1998B5D 2011-10-31

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJOyB75AAoJEIGvc57AcRvx9QIH/2YLLoPjKeCblhni8HDOyBZS
h00P5KdRionmBD2h04LKhL8kp1OD7TW77JKE3uWusgkR2QCJjv2Goo+4tOsLv9+u
5fNVLZFF1K9jKp88t9qWwvtr2tzAYArnUQHdkS175smoYkUIzkStkesiT0apLcqB
c3Wx0hm94YA6GB9MbXz/qY2IRDhb1ammDYfOAnFS9rHJT8mKRBKJTDdiWB9xM+Oo
BmTRSfWfq25OMW0IPtGlbo/z1Pwb9g7MnOfY+9o0/BImsDp/RUT/xtLAwscrTIKU
AarC5UZi5MZvJ2Hn2KjzrJ0pHi5bZVmi0dS6HscOyj8rx4JllKQieKK94EpLFFQ=
=LqPw
-END PGP SIGNATURE-

Re: [aur-general] TU Resignation

[Ray Rashif]

On 21 November 2011 00:10, Jelle van der Waa  wrote:
> On 19/11/11 19:44, Thomas S Hatch wrote:
>>
>> I have a lot of regret doing this, and I have been working hard to find
>> the
>> time to keep up with my TU duties, but every day I have less and less time
>> because work is continually ramping up, and what free time I have left
>> ends
>> up going to Salt (http://saltstack.org).
>>
>> So, very sadly, I need to resign from my position as an Arch Linux TU. I
>> hope I can be of assistance to Arch in the future and I am still planning
>> on maintaining the Varch project: https://github.com/thatch45/varch
>>
>> So with deep regret, I must resign my brief stint as a TU, it was fun, and
>> I greatly appreciate the opportunity, but it is very unfair of me to not
>> be
>> maintaining my packages.
>>
>>
>> Thanks
>>
>> -Thomas S Hatch
>
> Sad to see you leave, good luck with Salt!
>
> --
> Jelle van der Waa
>

One awesome person less :(

Good luck with everything else!

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Resigning as a TU

[Ray Rashif]

On 21 November 2011 02:17, Thorsten Töpper  wrote:
> On Sun, 20 Nov 2011 16:02:58 +0100
> Stefan Husmann  wrote:
>
>> Hello,
>>
>> I want to resign as a TU. I do not have the time anymore to fulfill
>> my TU duties and to handle the new package signing stuff.
>>
>> By the way I suggest to remove the package scilab and maybe also the
>> dependencies from the repos. There are long open bug reports, and they
>> are unsolvable.
>>
>> Regards Stefan
>
> Makes me sad to read this, but I hope you have a good time. Thank
> you, I owe you a lot. :-)
>
> --
> Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/
> Key: 295AFBF4     FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
>

Yes, Stefan, thank you for all your work. Good luck in everything!

-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Update request for supertuxkart

[Ray Rashif]

On 20 November 2011 03:29, Laurent Carlier  wrote:
> One solution should be to embed an irrlicht svn snapshot in supertuxkart
> package.

That is for upstream to do, if they're so dependent on devel versions
of software.


-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Inactive / past TU

[Ray Rashif]

On 8 November 2011 23:38, Karol Blazewicz  wrote:
> Brad Fanella resigned two weeks ago [1] but he is still listed as an
> active TU - is that OK? Should I move him to inactive TUs or to past
> ones? I've e-mailed him on this mater two days after his resignation
> but got no response.
>
> [1] 
> http://mailman.archlinux.org/pipermail/aur-general/2011-October/016228.html
> [2] https://wiki.archlinux.org/index.php/Trusted_Users
>

Past ones.


-- 
GPG/PGP ID: C0711BF1

Re: [aur-general] Request to add a rule

[Ray Rashif]

On 29 October 2011 06:14, Ray Rashif  wrote:
> * Uploading a "Microsoft Office 2011 Demo" PKGBUID that retrieves an
> official *non-redistributable* archive containing clean executables is
> WRONG.

Ammendment to this part:

* Uploading a "Microsoft Office 2011 Demo" PKGBUILD that retrieves
*from a third-party site* an official *non-redistributable* archive
containing clean executables is WRONG.

* Uploading a "Microsoft Office 2011 Demo" PKGBUILD that retrieves
*from the official site* an official *non-redistributable* archive
containing clean executables is RIGHT, *unless linking from
third-party sites is explicitly forbidden*.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Request to add a rule

[Ray Rashif]

On 28 October 2011 23:55, Peter Lewis  wrote:
> On Fri, 28 Oct 2011, Christopher luna wrote:
>> Im not even asking you to agree with me, Im asking you to vote and decide if
>> including urls to warez on pkgbuilds that are on AUR is OFFICIALY ok, or not.
>>
>> again is not about they being propietary software or about providing
>> installers. Is ONLY about urls to warez. they are ok or not?
>
> I think this is a legitimate question. But to be honest, despite what any of 
> us
> think, it should probably be answered by whoever "legally is" Archlinux.  
> Aaron,
> perhaps?

No need. Because...

* Uploading a "Microsoft Office 2011 Retail" PKGBUILD that retrieves
an archive containing cracked executables is WRONG.

* Uploading a "Microsoft Office 2011 Retail" PKGBUILD that does not
retrieve anything but has the file name of the archive containing
cracked executables as a source is WRONG.

* Uploading a "Microsoft Office 2011 Runtime" PKGBUILD that retrieves
an official *redistributable* archive containing clean executables is
RIGHT.

* Uploading a "Microsoft Office 2011 Demo" PKGBUID that retrieves an
official *non-redistributable* archive containing clean executables is
WRONG.

* Uploading a "Microsoft Office 2011 Demo" PKGBUILD that does not
retrieve anything but has the file name of the official
*non-redistributable* archive containing clean executables as source
is RIGHT.

Think of the these as a template checklist for your next AUR
restricted contribution, i.e apply where applicable.

Abandonware is nothing special. Some may be redistributed freely, some
not. When not, don't. Simple.

I agree that we need to have some sort of black and white on this, so
I've made a simple addition to the FAQ:

https://wiki.archlinux.org/index.php/Arch_User_Repository#Q:_What_kind_of_packages_are_permitted_on_the_AUR.3F


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Resignation

[Ray Rashif]

On 25 October 2011 12:47, Brad Fanella  wrote:
> p.s. there were some personal issues as well, but I don't really feel the
> need to get into those here ~ we can let Xyne speculate with one of his
> riveting stories

Sorry to hear about this especially. Anyway, thanks for all your work.
Take care and good luck!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] berlios is dying

[Ray Rashif]

On 14 October 2011 06:00, Andrea Scarpino  wrote:
> On Friday 14 October 2011 05:56:59 Ray Rashif wrote:
>> Yes, I agree. This is important. Glad it's been brought up, I wasn't
>> aware of this.
> I was, but we cannot do anything about. We've just to wait for upstream to
> move and, if they don't, on 31th December we'll put the old sources on al.org.
> IMHO.

Some of them should have alternate locations, so AL.org should be the
last resort (bandwidth is capped at around 512Kbps).


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] berlios is dying

[Ray Rashif]

On 14 October 2011 05:49, Sergej Pupykin  wrote:
> On 14.10.2011 00:26, Stefan Husmann wrote:
>>
>> Hello,
>>
>> this is merly an upstream issue, but it might be good to be aware of it:
>>
>> berlios will be closed with the end of this year. See
>> http://www.berlios.de/
>> Projects hosted there will have to move elsewhere.
>>
>> In the repos the following packages will be affected:
>
> Hello,
>
> May be it would be better to add TODO on dev website so we can track status?

Yes, I agree. This is important. Glad it's been brought up, I wasn't
aware of this.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Application - Massimiliano Torromeo

[Ray Rashif]

On 3 October 2011 23:56, Massimiliano Torromeo
 wrote:
> - ttf-ubuntu-font-family
> - e4rat
> - vdfuse
> - vbox-runner

Looking forward to those :)

Good luck!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Vote on Alexander Rødseth's (trontonic) TU application

[Ray Rashif]

On 17 September 2011 20:22, Evangelos Foutras  wrote:
> On 09/09/11 16:26, Evangelos Foutras wrote:
>> Dear TUs,
>>
>> The discussion period for Alexander's TU application has ended.
>>
>> Please hop onto the web interface to vote:
>>
>> https://aur.archlinux.org/tu.php?id=49
>
> The voting period has ended, and the results are:
>
> Yes: 16
> No: 0
> Abstain: 3
>
> 19 of the 28 TUs voted, quorum has been met, and Alexander is now a TU!

Welcome aboard, Alexander!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Kate Plugins Group

[Ray Rashif]

On 10 September 2011 02:04, Daniel Poulin  wrote:
> Hi everyone,
>
> I'm writing a PKGBUILD for a kate plugin and noticed there are a few other
> kate plugins in AUR.  I also maintain a libreoffice plugin and noticed they
> are all part of a group (libreoffice-extensions). Should all of us kate
> plugin maintainers add the same group to our packages? Perhaps
> kdesdk-kate-plugins or simply kate-plugins?

I don't see why not :)


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Merge request: ttf-ubuntu-font-family and ttf-ubuntu

[Ray Rashif]

On 7 September 2011 10:02, Jekyll Wu  wrote:
> ttf-ubuntu-font-family[1] and ttf-ubuntu[2] are essentially the same, except
> that the latter provides an outdated version.
>
> Please merge [2] into [1].
>
> [1] https://aur.archlinux.org/packages.php?ID=41465
> [2] https://aur.archlinux.org/packages.php?ID=47336

I think the older version is better according to some users so it remained.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [lmms] unmaintained

[Ray Rashif]

On 7 September 2011 19:48, Sven-Hendrik Haase  wrote:
> Actually updating doesn't seem so straight forward as compilation for the most
> recent version breaks.

That's because it was never built in a chroot before, and those
optdeps need to be makedeps as well. Either that, or least likely,
upstream has just changed their buildsystem to check for those deps
during buildtime.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [lmms] unmaintained

[Ray Rashif]

On 7 September 2011 17:18, Uli Armbruster  wrote:
> Lmms has been out of date for quite a while. It's been flagged out of date on 
> June 13th.
> I emailed the maintainer Mateusz Herych telling him that only the pkgver and 
> checksums
> have to be updated. He answered, that he's too busy in real life to take care 
> of it.

Yes, it can happen. The rest of us are here to help, and once you let
us know (if we are not aware already), we'll take care of it.

However, if that was his reply, then it should've been followed up by
a notification to let us know of his situation and to ask us for help
to keep his packages up-to-date, or at least those that are important.
By right, he should've marked himself busy/inactive.

Anyway, I've updated lmms for now and will keep on monitoring the
package since I'm familiar with it.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Merge request: yakuake-git and yakuake-qt4-svn

[Ray Rashif]

2011/9/6 Lukáš Jirkovský :
> On 6 September 2011 13:31, Ray Rashif  wrote:
>> On 6 September 2011 16:23, Jekyll Wu  wrote:
>>
>> There is a problem. [1] looks like a bad PKGBUILD to me, with a make
>> after cmake.
>
> That is correct.

Ahh crap, yes, I actually meant the opposite:

s/[1]/[2]/
s/with/without/


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Merge request: yakuake-git and yakuake-qt4-svn

[Ray Rashif]

On 6 September 2011 16:23, Jekyll Wu  wrote:
> yakuake-git[1] and yakuake-qt4-svn[2] are essentially the same. They both
> pull code from git://anongit.kde.org/yakuake.
>
> Since the upstream has switched from svn to git, I would suggest deleting
> the -svn package or merging it into the -git pakcage.
>
> [1] https://aur.archlinux.org/packages.php?ID=41530
> [2] https://aur.archlinux.org/packages.php?ID=30056

There is a problem. [1] looks like a bad PKGBUILD to me, with a make
after cmake. Also depends differ, so we need to know which is the
correct one to keep, or else the maintainer needs to update it.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Application

[Ray Rashif]

On 4 September 2011 05:14, Philipp Überbacher  wrote:
> Being an audio person I've had a look at the first audio app in the list
> (cheesetracker) and I'm not entirely happy with the PKGBUILD. There's
> the minor thing that 'jack-audio-connection-kit' is just 'jack' since a
> couple of months. While I'm happy that you seemingly managed to get
> cheesetracker to build and while the 'addinclude' method is probably
> easy for packagers it's a very weird way to do things. Firstly it's
> an additional dependency from AUR, secondly it depends on another
> language that isn't wide spread yet (GO) while the same effect could be
> had without anything special (patch). To me this looks very much like an
> unnecessary 'because I can'-thing that makes installing the package more
> complicated than it needs to be.

And I can see that Alexander may be the tracker type.

Well, I have to agree with Philipp, and as has been told for
generations, a patch is much cleaner and is what we like to see over
multiple sed lines or a non-standard tool like 'addinclude' or
'setconf'. I'd pick clean-and-consistent over convenience, and I
believe that is the Arch Way I speak for. Your way is, of course, not
_wrong_ per se, as you would only have an additional (buildtime)
dependency. One may or may not choose to follow standard practices,
suggestions or recommendations.

Otherwise, packages mostly look good, and whatever deficiency you
might have right now, I'm sure for the kind of person you are (like
most of us troo Archers; just maybe more awesome) you'll pick things
up as you go ;)

I have a recommendation TODO for you:

1. milkytracker (we lack a tracker in the repos and is the most
popular of the bunch)

2. shedskin (very useful)

Also, I would like to say 'pruss one awesome' to your application and
profile/background.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Securing the AUR website

[Ray Rashif]

On 5 September 2011 20:35, Pierre Schmitz  wrote:
> On Mon, 5 Sep 2011 13:55:38 +0200, Cédric Girard wrote:
>> Hi,
>>
>> On Mon, Sep 5, 2011 at 1:46 PM, Ray Rashif  wrote:
>>
>>> it slows down my inherently slow
>>> connection (think GPRS/EDGE/2G)
>>>
>>
>> Do you have any figures to support this? I would be interested to see what
>> the impact of HTTPS on the client side is.
>
> Me too. We'd need some numbers to back this argument. I also wonder how
> many are really affected by having such a slow connection that this
> would actually matter. I wouldn't be surprised if this number is really
> low.

It just feels slower. I think the amount of data transferred does not
look that much bigger when you have at least a 512Kbps, but browsing
is indeed slower.

Take, for eg., GMail for Mobile on my phone has HTTPS disabled, and
when enabling it warns that "more data will be used". A 128Kbps
unstable connection eg. over the GSM network will struggle with an
SSL-encrypted website far away from the user's ISP/region due to the
inevitable added latency of that kind of network.

However, you are right, there is no empirical evidence until I log my
connection to one of the Arch Linux sites with and without SSL. I will
try and do this soon.

In the meantime, these are Google results that you might've already come across:

http://support.microsoft.com/kb/150031
http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
http://serverfault.com/questions/43692/how-much-of-a-performance-hit-for-https-vs-http-for-apache


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Securing the AUR website

[Ray Rashif]

On 3 September 2011 23:49, Gordon JC Pearce  wrote:
> One is that https is painfully slow over slow or unreliable connections (GPRS 
> springs to mind; 3G service is patchy here).
> The other is that switching to https has left AUR in a fundamentally broken 
> state.  If you search for a package on AUR with any of the significant search 
> engines, they return an http link.  You can't do anything with this, though, 
> because *even if you're logged in* you get the "ZOMG OH NOES YOU AREN'T USING 
> HTTPS AND HTTPS IS TEH AWSUM11!!11!" message.
> Now, if clicking on that took you *to the same page but with https* that 
> would be fine, but it doesn't.  It unceremoniously dumps you on the index 
> page for AUR, with no way to get back to the package that you googled.
>
> So, the only way to use AUR from (say) Google is to search for a package, 
> click on it, copy the address from the bar, click on the https login link, 
> log in (since even if you're logged in, visiting the http page seems to log 
> you out), then paste the address you got from the search engine into the 
> address bar, edit it to go to https, then hit return.  This is hardly a 
> seamless user experience, but it ought to be trivial to fix.
>
> Sort it the fuck out.
>
> If you want me to put my money where my mouth is and contribute some code, 
> then just ask.

You may want to file a bug report against the AUR project (or the
entire site) at http://bugs.archlinux.org/

If I just want to browse a domain or subdomain as a guest I wouldn't
want to deal with httpS because (1) it slows down my inherently slow
connection (think GPRS/EDGE/2G) and (2) I'm not even logged in to want
to protect any kind of credential.

As it is currently, the Arch Linux sites are enforcing HTTPS and so
even if I don't want SECURE, I have to deal with it. I didn't speak up
against this before because (1) I wasn't surfing around much and (2) I
didn't think my opinion/case would matter and (3) I don't even have
the sufficient technical knowledge to debate this sort of thing.

At the end of the day, though, SECURE for logins is definitely good,
but a lot of sites give the user an option to either disable or enable
httpS, eg. Google (GMail; GMail for Mobile) and WordPress. I also know
some sites where they only redirect "paying" or "deluxe" users to
HTTPS after/during login.

So even if you don't care about your password, it's good to have
HTTPS, just to be safe.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Securing the AUR website

[Ray Rashif]

On 3 September 2011 09:29, Gordon JC Pearce  wrote:
> On Thu, 1 Sep 2011 20:36:34 +0200
> Cédric Girard  wrote:
>
>> > What happens if you *don't want to use https*?
>> >
>>
>> I still have difficulties to understand why people would like to purposely
>> avoid using https.
>
> I still have difficulties understanding why people would purposely use 
> https...
> What's the benefit?

I personally don't like "https everywhere" because its overhead is
significant for slow connections which I have to deal with. However,
I'm all for "https logins" because I wouldn't want my information to
be intercepted easily.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] TU Resignation

[Ray Rashif]

On 31 August 2011 09:11, Loui Chang  wrote:
> Hello everyone!
>
> I haven't been very involved with the AUR for a long while, and I don't
> really see that changing much. Since I only have a few packages I think
> it's time for me to resign as a TU. I may still throw a few patches
> around if I find the time. I've asked Lukas Fleischer to assume my duty
> of adding new TUs.
>
> It was a pleasure to work with you folks. See you around!

Although this is sad news, I wish you the best of luck in everything
else! You were instrumental in shaping the AUR and a figure I've seen
around from as far back as I can remember, so lots of thanks and
kudos!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Python packaging newbie

[Ray Rashif]

On 23 August 2011 07:03, Fabien Devaux  wrote:
> Hi!
> I'm new to arch & his packaging techniques and I have some questions on how
> things should be for python2/3 and build() vs package() things as well...
> Is this the good place to ask ?

If that is all your questions then this is the wrong place to ask. In
fact, it would then be wrong to even ask. It is only correct to read:

https://wiki.archlinux.org/index.php/Python_Package_Guidelines


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] OK! changing a PKG's name and retaining votes/comments

[Ray Rashif]

On 11 August 2011 22:25, Lukas Fleischer  wrote:
> On Sun, Jul 31, 2011 at 07:09:44PM +0200, Lukas Fleischer wrote:
>> On Fri, Jul 22, 2011 at 05:35:00PM +0200, Lukas Fleischer wrote:
>> > On Fri, Jul 22, 2011 at 10:52:54AM -0400, member graysky wrote:
>> > > Crap... I thought it was a done deal :(
>> >
>> > This is still on my TODO list. I'll probably implement this once my
>> > development box is up again (it died some days ago). Further details
>> > should be discussed on aur-dev, please.
>>
>> Just sent a patch set to aur-dev [1], [2], [3].
>
> Pushed to master [1], [2].

...aand it works great!

So guys, spread the word, the feature is there, so if your package
needs a rename, please mention it so the TU merges the packages.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Private mailing list for TUs?

[Ray Rashif]

On 12 August 2011 23:18, Florian Pritz  wrote:
> Hi,
>
> I think it would be nice if we had a closed mailing list for TUs only
> (and maybe devs if they want to) so we can move more important stuff
> from IRC to mail because not everyone uses IRC or is online all the time.
>
> Keep in mind that it will likely be low traffic.
>
> Any hard feelings on that?

I have no strong opinions either way. However, I do feel there should
be an equal alternative to the IRC channel , which is private.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] SuperCollider CleanUp 2

[Ray Rashif]

On 29 July 2011 22:35, Bernardo Barros  wrote:
> supercollider-with-extras-git
> http://aur.archlinux.org/packages.php?ID=48934
>
> supercollider-git-with-plugins-git
> http://aur.archlinux.org/packages.php?ID=44413

Deleted.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Deletion Request: old SuperCollider packages

[Ray Rashif]

On 29 July 2011 07:03, Bernardo Barros  wrote:
> old packages (sc uses git now):
> ---
>
> + sc3-plugins-svn
>  http://aur.archlinux.org/packages.php?ID=36602
>
> + sced-svn
>  http://aur.archlinux.org/packages.php?ID=29285
>
> + scvim-svn
>  http://aur.archlinux.org/packages.php?ID=35130
>
> merged with sc3-plugins:
> ---
>
> + supercollider-dfm
>  http://aur.archlinux.org/packages.php?ID=45931

Done!


--
GPG/PGP ID: 8AADBB10

[aur-general] Realtime kernel package name for 3.0

[Ray Rashif]

On 23 July 2011 09:49, Bernardo Barros  wrote:
> -- Forwarded message --
> From: Thomas Gleixner 
> Date: 2011/7/22
> Subject: [ANNOUNCE] 3.0-rt1
> To: LKML 
> Cc: linux-rt-users 
>
>
> Dear RT Folks,
>
> I'm pleased to announce the 3.0-rt1 release.
>
> Changes versus 3.0-rc7-rt0:
>
>  * Update to Linus final 3.0 release
>
>  * RTC bugfixes (scheduled for mainline/stable)
>
>  * Long standing (rt only) timer_list bug (see
>    timers-avoid-the-base-null-otptimization-on-rt.patch in the split
>    out quilt queue)
>
>  * Minor non exciting fixes all over the place
>
> Known issues:
>
>  * Some weird "console=..." commandline + config dependent
>    interactions which have been not yet investigated down to their
>    root cause. Result in a boot hang. YMMV
>
> Patch against 3.0 can be found here:
>
>  http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt1.patch.bz2
>
> The split quilt queue is available at:
>
>  http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt1.tar.bz2


This calls for a new package name. The standard kernel will be named
"linux", so the obvious options are "linux-rt" and "linux-realtime".
Tell us which you would prefer or suggest a different suffix.


--
GPG/PGP ID: D90FA77D

Re: [aur-general] PCSX2 Plugins folder - suggestion?

[Ray Rashif]

On 15 July 2011 16:35, Ray Rashif  wrote:
> On 15 July 2011 10:32, rafael ff1  wrote:
>> If the plugins are 32-bit, it's logical to put them in /usr/lib/pcsx2
>> in 32-bit system. But in 64-bit system, I'm not sure if they whether I
>> should put them in /usr/lib or /usrlib32/ (inside "pcsx2" folder, of
>> course).
>
> 32-bit libs-related stuff belong in /usr/lib32 on Arch64, nowhere else.

See file list of
http://www.archlinux.org/packages/multilib/x86_64/lib32-alsa-plugins/


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] PCSX2 Plugins folder - suggestion?

[Ray Rashif]

On 15 July 2011 10:32, rafael ff1  wrote:
> If the plugins are 32-bit, it's logical to put them in /usr/lib/pcsx2
> in 32-bit system. But in 64-bit system, I'm not sure if they whether I
> should put them in /usr/lib or /usrlib32/ (inside "pcsx2" folder, of
> course).

32-bit libs-related stuff belong in /usr/lib32 on Arch64, nowhere else.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Cleaning up wine packages

[Ray Rashif]

On 13 July 2011 16:31, Sven-Hendrik Haase  wrote:
> Neither is makeable. wine-doors misses source and its functionality now
> mostly exists in winetricks. kwine requires kwine-base which doesn't even
> exist. Also, KDE integration with wine is already a given anyway.

Ahh OK. To the trash with these, then!


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Cleaning up wine packages

[Ray Rashif]

On 13 July 2011 15:47, Sven-Hendrik Haase  wrote:
> There are many wine packages in AUR and many of them are fairly old and/or
> obsolete, too.
>
> I'd like to clean that up. Here are the candidates:
>
> ...
>
> kwine (https://aur.archlinux.org/packages.php?ID=6498)
> Reason: Extremely old (2007), obsolete, dead upstream
>
> ...
>
> wine-doors (https://aur.archlinux.org/packages.php?ID=11823)
> Reason: Very old, dead upstream, dead source

Don't they still work? Are there alternatives to these two?


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] zynaddsubfx-lash removal

[Ray Rashif]

On 11 July 2011 16:52, Daniele Paolella  wrote:
> Please remove zynaddsubfx-lash
> , the same compilation
> options are now included in zynaddsubfx
> . Many thanks.

Done.


-- 
GPG/PGP ID: 8AADBB10

Re: [aur-general] VCS Packaging Guidelines

[Ray Rashif]

On 2 July 2011 23:39, Mark Foxwell  wrote:
> I think that any _official_ view (even if it's 'either way is fine')
> should be added to the VCS PKGBUILD Guidelines wiki page [2].

Done:

https://wiki.archlinux.org/index.php?title=VCS_PKGBUILD_Guidelines&action=historysubmit&diff=148014&oldid=144799


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] python renaming

[Ray Rashif]

On 19 June 2011 21:09, Bernardo Barros  wrote:
> I think the solution is to be *very* consistent with packages names
> whatever the situation of the python3 version is right now.
> In other words: pick a guideline and stick to it. If
> python2-X/python-X is the way to go, no matter there is a python3
> package or not, use this convention...

Correct. However, with a previous discussion [1] and a bug report [2]
lingering I think most of us are hesitant to make a move. Maybe we're
just hoping for someone to step up with a mighty roar and set the
record straight.

[1] 
http://mailman.archlinux.org/pipermail/arch-dev-public/2011-April/019958.html
[2] https://bugs.archlinux.org/task/23139


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] python renaming

[Ray Rashif]

On 19 June 2011 21:09, Bernardo Barros  wrote:
> I think the solution is to be *very* consistent with packages names
> whatever the situation of the python3 version is right now.
> In other words: pick a guideline and stick to it. If
> python2-X/python-X is the way to go, no matter there is a python3
> package or not, use this convention...

Correct. However, with a previous discussion [1] and a bug report [2]
lingering I think most of us are hesitant to make any moves. Maybe
we're just hoping for someone to step up with a mighty roar and set
the record straight.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] removal of pidgin-gtalkinvisible

[Ray Rashif]

On 17 June 2011 20:56, Martti Kühne  wrote:
> On Fri, Jun 17, 2011 at 9:00 AM, Oon-Ee Ng  wrote:
> 
>> Actually, after some consideration his naming is more appropriate,
>> since that's the name of the source tarball is gtalk-shared-status. I
>> would like my package renamed to that name, though I would not object
>> to deleting my package and leaving his one, as long as he can maintain
>> it.
>>
>
> Ng, I'm not actually using the package. If you are, it's a much better
> deal if you maintain it, unless you're too busy with the rest of the
> universe.

That's great. You can disown for Ng to pick it up. When that happens,
let us know and we'll remove the other package.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] removal of pidgin-gtalkinvisible

[Ray Rashif]

On 17 June 2011 10:34, Thomas Dziedzic  wrote:
> On Thu, Jun 16, 2011 at 7:45 PM, Martti Kühne  wrote:
>
>> please delete pidgin-gtalkinvisible [1], I'm the maintainer and
>> announced deprecation in favor of pidgin-gtalk-shared-status [2] a
>> month ago.
>>
>> cheers! mar77i
>>
>> [1] https://aur.archlinux.org/packages.php?ID=30136
>> [2] https://aur.archlinux.org/packages.php?ID=48997
>>
>
> terminated

Hey Martti and everyone

We see that Ng had uploaded the same thing before:
http://aur.archlinux.org/packages.php?ID=38551
And this is Martti's new upload: http://aur.archlinux.org/packages.php?ID=48997

1. pidgin-gtalksharedstatus
2. pidgin-gtalk-shared-status

Usually the new one would not be honoured, but Ng, do you think you
would want to rename your package? I think a better name is following
the $client-$protocol-$addon format which neither does, i.e
'pidgin-gtalk-sharedstatus'.

Otherwise, if the name is not important, we'll have to remove Martti's
version of the package.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Putting android development packages into [community]

[Ray Rashif]

On 10 June 2011 04:56, Ray Rashif  wrote:
> 3. android-{1.5,1.6,2.1,2.2,2.3,2.3.3,3.0,3.1)

I think this is a bit too much. This is better:

3. android-{1.5,2.1,2.2,2.3)

1.5 == to target a larger range of devices
2.1,2.2,2.3 (or 2.3.3 or 2.3.4 if those exist as separate archives) ==
current popular platforms

As noted from: 
http://en.wikipedia.org/wiki/Android_(operating_system)#Usage_share



--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Putting android development packages into [community]

[Ray Rashif]

On 10 June 2011 04:19, Sven-Hendrik Haase  wrote:
> Hi,
>
> I'm playing with the idea of pulling the android packages into [community].
> They seem to be in strong demand but so far their maintenance track in AUR
> has been fairly inconsistent.
>
> I'd like opinions on this because they have a rather large amount of votes.
> There have been license concerns about this endeavor but I think they are
> unfounded as all Android stuff (not including externals) is Apache license
> and thus ok to redistribute.
> Also, I'd like to know whether anybody thinks that instead of just
> repackaging the binaries, building from source would be preferable.

I'm a big proponent of this, so +1. I was hesitant about the
redistribution because I did not come across any distro redistributing
the suite on their repos. However, a quick e-mail to Google would
solve this.

Building from source would be useless and too cumbersome. Remember
that all this suite is about is (1) the SDK, (2) accompanying platform
libraries (currently 8 of them), (3) some accompanying tools (like
plug-ins for Eclipse).

I would like to propose an 'android-development' group (alongside
other probable android groups that may include stuff for end-users
like gmote-server), which would comprise:

1. android-sdk
2. android-sdk-platform-tools
3. android-{1.5,1.6,2.1,2.2,2.3,2.3.3,3.0,3.1)
4. eclipse-android
5. udev-android-rules (not sure if this is really needed)
6. android-ndk

Plus accompanying platform docs and examples. And anything else I
might've missed. Basically, one group to start developing for Android.

One may argue that there is no need to include the platforms, their
docs and examples, as they can be downloaded with the AVD Manager.
However, I say that it makes life for the developer on Arch Linux much
easier. You can pacman -S everything and start Eclipse, put in the
Android path, configure the AVD, and you're all set. Also, this way,
the setup is very portable since you can deploy this same environment
on another Arch Linux system very quickly when you have the packages
cached. In short, I'm thinking "offline setup".


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [AUR] Orphan all old packages flagged as out-of-date

[Ray Rashif]

On 8 June 2011 12:13, Allan McRae  wrote:
> On 08/06/11 14:01, Thorsten Töpper wrote:
>>
>> On Wed, 8 Jun 2011 05:05:22 +0800
>> Ray Rashif  wrote:
>>>
>>> On 7 June 2011 18:14, Andrea Scarpino  wrote:
>>>>
>>>> Hi TUs,
>>>> I'd like to orphan all packages in AUR flagged as out-of-date
>>>> before February 2011 (for example, I think 3 months are enough).
>>>
>>> I find 3 months are not enough (for a busy person). 6 is a nicer
>>> number, i.e half a year, plenty of time for short bursts of free time
>>> (for a busy person).
>>
>> I agree, 3 months is a too short span of time.
>>
>
> Seriously?  If someone can not find the time to update a package in 3
> months, there will be other people who can do a better job.  If we waited 6
> months for updates, we might as well be using Ubunutu.

Hmm..I suppose that'd be a bit too lenient.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [AUR] Orphan all old packages flagged as out-of-date

[Ray Rashif]

On 7 June 2011 18:14, Andrea Scarpino  wrote:
> Hi TUs,
> I'd like to orphan all packages in AUR flagged as out-of-date before February
> 2011 (for example, I think 3 months are enough).

I find 3 months are not enough (for a busy person). 6 is a nicer
number, i.e half a year, plenty of time for short bursts of free time
(for a busy person).


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] [PATCH 1/1] TUs can change package names

[Ray Rashif]

On 1 June 2011 23:36, Jakob Gruber  wrote:
> On 06/01/2011 05:26 PM, D. Can Celasun wrote:
>>
>> Actually, it is still possible. Here's how it'd work:
>>
>> - TU changes package name from foo to bar.
>> - This automatically triggers an out-of-date notification (and an
>> explanation comment) for all packages that depend on foo.
>> - Everyone updates their packages to reflect the changes.
>>
>> Now all votes, comments and even notification lists are preserved without
>> doing a single database query. I really don't think it gets more KISS than
>> that.
>
> I beg to differ. The way it is right now is way more KISS.
> So far, my favorite suggestion is either 1) creating a way to transfer votes
> and comments or 2) keeping everything as it is.

How about marking a checkbox upon upload where it would present a text
box to rename from an older package to the current one?

x Rename package from ||

If this from field MATCHES the pkgname being submitted then as usual
nothing would be done (submission as usual as if nothing had been
marked; package would be created if it does not exist).

If it does NOT MATCH, then a rename function (such as the one this
patch demonstrates) would be applied to that older pkg and then the
submission continues. Of course, the older package must be owned by
the currently logged in user. If the older pkg entered does not exist
in the db then the submission fails. If a package gets wrongly renamed
then the user can go through the same steps to rename that. No TU
involvement here.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] The Unarchiver and provides field

[Ray Rashif]

2011/5/23 Cédric Girard :
> As this application provides an unrar functionnality, does it make sense to
> add a "provides=('unrar')" field in the PKGBUILD? The Unarchiver is not a
> drop-in replacement for the "unrar" command. The binary are not the same and
> the syntax is different.

Absolutely no point in a provision, then.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] optional dependencies that require explicit installation

[Ray Rashif]

On 17 May 2011 18:14, Michael Schubert  wrote:
> 2011/5/17 Ray Rashif 
>
>>
>> That's the way it's done. You have those optdeps as makedeps so you
>> can finish building the package.
>>
>
> Sorry if I was a bit unclear earlier. The make process does not need all
> binding languages as dependencies as cmake and configure take care of
> preventing those from being built. So the make works fine with no optional
> dependencies installed.

When you're distributing any modular package that, when installed with
all usable dependencies, would provide full software functionality,
someone (the builder/packager) has to initially configure and build
the software with everything in place.

* So, you first install all usable deps, build it, then remove the
unimportant deps (thus making them makedeps + optdeps).

If a dep cannot be removed (when a particular part of the software
complains about something missing or does not work as expected), then
it cannot be an optional dependency. Sometimes, in order to appease
everyone, you must build and depend on deps that not everyone would
need, because those deps are link-level or hardcoded once used (to
build).
.
You don't have to build multiple packages just because of this, unless
we're talking about a rather large software compilation/bundle.

But yes, you may split the package in the end. If it is easier for you
then build as many times within the PKGBUILD as needed, to for example
a different directory each time. Then you can package separately and
the result is a split package. Do this only if building in the
optional support actually leads to unwanted bulk for those not needing
the optional functionality.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] optional dependencies that require explicit installation

[Ray Rashif]

On 17 May 2011 05:20, Michael Schubert  wrote:
> 2011/5/16 jesse jaara 
>
>> Put them as make and optional deps :-)
>>
>
> But make doesn't depend on them. Also, I wouldn't want to install  weird programming language> in order to get the package to build.

That's the way it's done. You have those optdeps as makedeps so you
can finish building the package. These deps will be installed as deps,
so a -Qdt would show them as orphans. There is --rmdeps that takes
care of this; makepkg -sr.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Aurphan in community

[Ray Rashif]

On 6 May 2011 21:13, keenerd  wrote:
> On 5/6/11, Ray Rashif  wrote:
>> Let me just confirm this: it is the first of its kind, in that it
>> "communicates" with the AUR. There is no other tool in the repos that
>> makes a connection to the AUR, right?
>
> Well that depends.  Do you count community/arch-firefox-search, which
> does a full search of the AUR?  (On an unrelated note, why is
> searching the AUR in a GUI officially supported but searching it from
> the CLI a mortal sin?)

Yes, I'd count that.

Now, on the unrelated note: the search engine is for a web browser,
and is in line with the AUR web interface. This interaction with the
AUR is "indirect". That is why it is _not_ on a grey area.

A tool searching from the CLI (with which one has "direct" access), is
on a grey area. That is IMO; no consensus has been reached with
regards to whether searching can be accepted/supported (officially) -
only discussions.

> Aurphan does not search the AUR, it organizes info about the AUR
> packages you already have installed.  It does not imply AUR packages
> are supported, it asks you to volunteer support for them.

Yes, it initiates a connection to the AUR, that is all. I have nothing
against this myself, so +1.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Aurphan in community

[Ray Rashif]

On 30 April 2011 17:48, Stefan Husmann  wrote:
> Am 30.04.2011 10:10, schrieb Allan McRae:
>>
>> On 30/04/11 17:36, Loui Chang wrote:
>>>
>>> On Sat 30 Apr 2011 16:12 +1000, Allan McRae wrote:

 On 30/04/11 12:25, Loui Chang wrote:
>
> On Fri 29 Apr 2011 21:49 -0400, keenerd wrote:
>>
>> I would like to move Aurphan into community. I've added a number of
>> features to it lately, and it has become an automated means of
>> answering "what can I do to help Arch", parsing and summarizing the
>> todo list, the bugtracker and the orphans. The one random dev I've
>> asked seems cool with it, however he thought a wider consensus should
>> be found. It has enough votes but
>>
>> Aurphan could be considered an AUR helper. By default it searches the
>> AUR for AUR packages you already have installed. It does not download
>> anything.
>>
>> I will change it so the default behavior does not search the AUR.
>> (New default would display the --help) I won't change the name, on
>> account of it being cute.
>
>> aur page: http://aur.archlinux.org/packages.php?ID=43726
>> project page: http://kmkeen.com/aurphan/
>
> This script seems like a really nice idea, but if it deals with
> unsupported packages it should remain in that domain. Maybe move the
> functionality that deals with unsupported into an add-on that you can
> install separately?

 We should also drop wget, curl and firefox from the repos as they can be
 used to download unsupported packages... In fact, this script is safer
 because it does not even do that.
>>>
>>> Allan, I appreciate your work but you completely missed the point.
>>> wget, curl and firefox do not contain functionality to specifically
>>> access the unsupported packages. They are general network programs.
>>>
>>> I guess it depends on what your vision is. If you want more people
>>> expecting support for unsupported packages, then put these scripts into
>>> extra or community. I can't stop you, I'm just a lowly nobody and you're
>>> a big bad dev.
>>
>> My point was that (as far as I can tell) this software does nothing with
>> AUR packages other than collates a bit of information. It does not allow
>> downloading or building packages. I find it difficult to see how this could
>> be seen as supporting AUR packages.
>>
>> Allan
>>
>>
> I think aurphan does not support aur packages but it eases to have better
> quality of the AUR as such, in recruiting more maintainers and having less
> orphaned packages there. We should support this. So go for it, Kyle!

Let me just confirm this: it is the first of its kind, in that it
"communicates" with the AUR. There is no other tool in the repos that
makes a connection to the AUR, right?


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Package Removal Request: some Faenza packages

[Ray Rashif]

On 3 May 2011 23:37, Kwpolska  wrote:
> faenza-k... hxxp://aur.archlinux.org/packages.php?ID=47201 (still not sure!)

And what prompted you to think it _might_ need deletion?


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Leave of absence

[Ray Rashif]

On 23 April 2011 13:48, Thomas S Hatch  wrote:
> I will be unavailable for a few days next week. Last year I had a surgery
> which left my left vocal chord paralyzed. Unfortunately my vocal chord has
> not healed and I am going to have to get a silicone implant in my voice box
> so that I can talk again. My surgery is on Monday the 25th and I will be
> resting up for a few days afterward before resuming regular TU work.
>
> As for my fellow TUs, if my packages are out of date please feel free to
> update them, but I will be back soon!
>
> If you are interested here is a link describing the procedure:
>
> http://www.evmsent.org/uvfi_treat.asp

Get well soon! Awesome people should not be away for too long.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] VCS dupes in the AUR

[Ray Rashif]

On 11 April 2011 18:15, Lukas Fleischer  wrote:
> * schismtracker-cvs https://aur.archlinux.org/packages.php?ID=19499
> * scikits-audiolab-svn https://aur.archlinux.org/packages.php?ID=21018
> * supercollider-git-with-plugins-svn 
> https://aur.archlinux.org/packages.php?ID=43637
> * qjackctl-cvs https://aur.archlinux.org/packages.php?ID=26766

Deleted.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Web-client for emails: [WAS:Reflector]

[Ray Rashif]

On 5 April 2011 18:00, Oon-Ee Ng  wrote:
> Gmail's web interface has THE best approach to threading. Ever. If you
> have any other suggestion (web client or linux desktop client) which
> comes anywhere close please let me know. Evolution's threading just
> doesn't cut it, thunderbird's new one is close, but thunderbird is
> basically a mouse-only interface, the keyboard shortcuts are so
> horrific (and muttator is an abortion of a project AFAICS).
>
> I've spent quite some time exploring the options, and settled on this.
> Ideas always welcome, of course.

+1

Exactly why I haven't had an offline e-mail client for some time.
Except for mutt which I keep around for the rainy day.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] When should pkgrel be updated?

[Ray Rashif]

On 1 April 2011 23:48, Thomas S Hatch  wrote:
> On Fri, Apr 1, 2011 at 9:39 AM, Dave Reisner  wrote:
>
>> On Fri, Apr 01, 2011 at 05:31:34PM +0200, Jelle van der Waa wrote:
>> > On Fri, 2011-04-01 at 12:21 -0300, Denis A. Altoé Falqueto wrote:
>> > > On Fri, Apr 1, 2011 at 4:12 AM, Ray Rashif 
>> wrote:
>> > > > On 1 April 2011 08:12, Oon-Ee Ng  wrote:
>> > > >> I've seen (in the past) various packages on the AUR which jumped by
>> 3
>> > > >> or 4 pkgrels in a very short period of time. Sometimes it happens
>> like
>> > > >> this:-
>> > > >>
>> > > >> 1. Maintainer changes something and breaks the package with pkgrel=2
>> > > >> 2. Bug reported on comments. Maintainer reverts changand makes
>> pkgrel=3
>> > > >
>> > > > It's really very simple - you only need to remember this:
>> > > >
>> > > > Whenever the resulting binary changes (in an important way) for the
>> > > > user, you bump pkgrel.
>> > > >
>> > > > Examples:
>> > > >
>> > > > * Changing pkgdesc -> do NOT bump (unless it's severely wrong or
>> something)
>> > > >
>> > > > * Changing deps -> bump
>> > > >
>> > > > * Changing makedeps -> do NOT bump, ever
>> > > >
>> > > > * Changing optdeps -> do NOT bump (unless very important
>> functionality provided)
>> > > >
>> > > > * Changing build stuff (i.e changing PKGBUILD but no change to
>> > > > resulting binary) -> do NOT bump
>> > >
>> > > Are you sure about that? I would bump pkgrel in all your examples,
>> > > except the first. Even though they may not change the resulting
>> > > binary, they change how they are built. I always thought of pkgrel as
>> > > a way to differentiate between versions of PKGBUILDs.
>> > >
>> >
>> > a Makedep isn't that important so i wouldn't bump there, just like the
>> > build stuff. And if someone used ABS the makedep fix would be already
>> > there in svn ;)
>> >
>> > --
>> > Jelle van der Waa
>> >
>>
>> A change in makedeps might fix a broken build, or it might enable a new
>> feature that's conditionally linked in based on the presence of the dep.
>> Definitely seems worthy of a pkgrel bump.
>>
>> dave
>>
>>
> When packaging it is critical to ensure that the resulting package is
> consistent regardless of the build environment, this means the build can
> change based on what deps are installed, for instance I have seen many
> PKGBUILDS create different packages because software to facilitate language
> bindings were not present.
> This would mean that the makedeps need to fulfill the configuration of the
> package source, and adding/changing makedeps can have direct influence on
> the resulting binary.
>
> I would recommend that the only time one should not bump the pkgrel is if
> the changes are menial and completely contained in the PKGBUILD, and that if
> the packager is unsure, bump the pkgrel.

Changing makedeps that affect the resulting binary is considered
changing deps. So that's different, and you must bump.

The bottomline is that if only the build scripting changes, but not
the package itself, there is no need to bump. If you want to make your
changes show up in ABS, just release the buildscripts. Otherwise, you
can tell users to checkout from svn.

It's the same for AUR users. If a build breaks, just update your
PKGBUILD without a pkgrel bump. Old users will keep on running the
software undisturbed, new users will get the new PKGBUILD. A broken
build does not affect those who already have the package installed.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] When should pkgrel be updated?

[Ray Rashif]

On 1 April 2011 08:12, Oon-Ee Ng  wrote:
> I've seen (in the past) various packages on the AUR which jumped by 3
> or 4 pkgrels in a very short period of time. Sometimes it happens like
> this:-
>
> 1. Maintainer changes something and breaks the package with pkgrel=2
> 2. Bug reported on comments. Maintainer reverts change and makes pkgrel=3

It's really very simple - you only need to remember this:

Whenever the resulting binary changes (in an important way) for the
user, you bump pkgrel.

Examples:

* Changing pkgdesc -> do NOT bump (unless it's severely wrong or something)

* Changing deps -> bump

* Changing makedeps -> do NOT bump, ever

* Changing optdeps -> do NOT bump (unless very important functionality provided)

* Changing build stuff (i.e changing PKGBUILD but no change to
resulting binary) -> do NOT bump

If in doubt about more scenarios, please describe them.


--
GPG/PGP ID: 8AADBB10

Re: [aur-general] Dropping multiget

[Ray Rashif]

On 29 March 2011 15:09, Stefan Husmann  wrote:
> Hello,
>
> I would like to drop the multiget package from [community] for the following 
> reasons.
>
> - the tarball does not build. The error consist in a missing header file and
> was reported twice on upstream bugtracker without an answer
>
> - the latest svn-checkout builds, but the revision number is still low, it is 
> 3.
>
> So what do you think? Should I upload a svn-based PKGBUILD or drop the 
> package?
> In svn there is a desktop file, which never made it to the tarball. This
> would at least allow me to remove multiget from the list in FS#23387.

Upload an svn-based PKGBUILD. multiget is one of the very few download
managers that can be compared to stuff like IDM, FDM. In fact, other
than fatrat, I think it's the only other one. I say we should try and
keep this maintained if it's not too troublesome.

Re: [aur-general] Packaging with DKMS support

[Ray Rashif]

On 24 March 2011 09:16, Jason Melton  wrote:
> Hello,
>
> Over on the rtl8192se package[1], we have been discussing how to best
> support DKMS in packaging (at the AUR level), and I would like to ask
> for wider and more experienced comments. I have put my thoughts here
> and in more detail on my personal Arch wiki page[2].

Good job. I personally have no objections to standardising this. All
it would require is for packagers to incorporate a bit more typing for
module packages only. If we have a library system in place for
makepkg/pacman this could've been templated for use with one-liners.

Re: [aur-general] svn tweak

[Ray Rashif]

On 21 March 2011 17:15, Peter Lewis  wrote:
> I have to admit (and I don't intend to offend anyone) that I found it a little
> confusing at first, though the "how to be a packager" page appears to have
> become a little clearer recently :-)

IMO it would be less confusing if there were one whole article just
about packaging workflow; it should not be TU/community- or
dev/extra-specific.

Re: [aur-general] svn tweak

[Ray Rashif]

On 21 March 2011 00:18, keenerd  wrote:
> It seems accidentally commiting package binaries is an easy error
> among new TUs.

Never heard of this accident. New TUs should always clear things up
before jumping in. One or two mistakes are fine.

Is the packaging workflow not clear enough from the guidelines? Two
distinct steps for PKGBUILDs and binaries respectively:

* SVN (commit) for buildscripts
** SVN (archrelease) to "finalise"

* SSH (scp) for packages
** SSH (db-update) to "distribute"

Now, if you accidentally make the addition after a build, and then
commit, you have to change your habit. Make the addition, then do the
build, then commit (using devtools).

Re: [aur-general] How should *-devel packages generally be handled?

[Ray Rashif]

2011/3/16 Ng Oon-Ee :
> So let's say foo is at version 4.0 (stable), should foo-devel stay at
> 3.9 (the last beta/rc/unstable release) or update to 4.0?

Stay at the last unstable release.

Re: [aur-general] AUR 1.8.1 - Can No Longer Upload Packages

[Ray Rashif]

On 14 March 2011 10:32, Heiko Baums  wrote:
> Could the reason be some syntax errors?
> There are a lot of quotation marks too much. And the settings of your
> quotation marks seem to be quite inconsistent.

It would be funny if the AUR rejected PKGBUILDs due to syntax "errors"
or inconsistency [1], especially this one where curly braces and
double quotes merely dictate whether the build succeeds - not whether
it is a valid PKGBUILD.

On 14 March 2011 11:44, Tony C  wrote:
> Apologies for the noise. AUR does not reject my package now after first
> creating the directory name for the package I have. I do not ever
> remember needing to create a special directory before. So I simply did
> mkdir package-name and tar'd that up containing my source files.

That does not tally with what you confirmed with us earlier - that you
had tried 'makepkg --source'.

[1] 
http://mailman.archlinux.org/pipermail/arch-general/2010-February/011272.html

Re: [aur-general] package submission

[Ray Rashif]

On 4 March 2011 01:01, Bernardo Barros  wrote:
> Yes, maybe more like "tags" not categories. We from pro audio miss a
> more specific category too, like "pro audio", since multimedia is much
> to much to much broad!!

Not really. It is still under "Multimedia", generally. Only in
technical circles does it get more cognitive and/or disciplined
relationships, like "Electronics" and "Engineering". As far as we're
talking about software, it's all just multimedia :)

Re: [aur-general] [arch-general] Adding AUR packages to [community] packages' provides

[Ray Rashif]

On 26 February 2011 17:40, Allan McRae  wrote:
> On 26/02/11 19:22, Ray Rashif wrote:
>
>> * Bump pkgrel OR force (I vote for force) for the first time (eg. so
>> users get the repo versions and not report bugs many days later while
>> still using the AUR package)
>
> Forces is crap (and dead in the future pacman-3.5).  Bumping the pkgrel
> should not be an issue given the package probably is frequently updated if
> it is worth bring to the repos, so it will have a pkgrel of 1 again soon.

Ahh right..force -> epoch.

There have been a few cases where the AUR package is pkgrel=n and the
repo is pkgrel=k, and the package on the system is not updated along
with the move because k=1 or k<=n. Then someone files a bug, which
later turns out to be applicable only to the AUR package. So here I
would start out with k=n+1, at least until we have a better way.

Re: [aur-general] [arch-general] Adding AUR packages to [community] packages' provides

[Ray Rashif]

On 25 February 2011 19:12, Lukas Fleischer  wrote:
> Seriously, we should be consistent here.

I agree.

* Provide/replace/conflict as necessary when promoting a package from
AUR (eg. when renaming the package)

* Bump pkgrel OR force (I vote for force) for the first time (eg. so
users get the repo versions and not report bugs many days later while
still using the AUR package)

* Do NOT provide/conflict/replace just because of a FR for a package
in AUR (unless the request is to provide for a package name that is
aknowledged by many)

Re: [aur-general] Upgraded AUR to 1.8.0

[Ray Rashif]

On 22 February 2011 02:06, Lukas Fleischer  wrote:
> On Tue, Feb 22, 2011 at 02:03:38AM +0800, Ray Rashif wrote:
>> On 21 February 2011 18:08, Dieter Plaetinck  wrote:
>> > On Mon, 21 Feb 2011 10:47:50 +0100
>> > Lukas Fleischer  wrote:
>> >
>> >> The official Arch Linux AUR setup has been upgraded to 1.8.0. For a
>> >> short list of changes, read [1].
>> >>
>> >> Please report any issues on the AUR bug tracker [2].
>> >>
>> >> [1]
>> >> http://mailman.archlinux.org/pipermail/aur-dev/2011-February/001433.html
>> >> [2] https://bugs.archlinux.org/index.php?project=2
>> >
>> > what's the reasoning behind no longer showing all files in the "source
>> > package"? I found this feature quite useful.
>>
>> I've _always_ used this, almost on every package I came across. I
>> don't want to be downloading anything I just want to take a rough look
>> at. Would be good to have this back in some way or another.
>> Brainstorm!
>
> Did you read all my replies on this topic? If you still think that this
> should be implemented no matter what, you'd better open a feature
> request on the bug tracker.

You do not really address this issue aside from shrugging it off as an
unneeded feature that costs one or two vulnerabilities. If it was
really that useless it would not have been implemented in the first
place. The loopholes are real, but the feature should not be
forgotten.

I will leave it up to the community to file a request to have this
back, because with that we can really see whether it actually is as
useful as a few of us claim :)

Re: [aur-general] Upgraded AUR to 1.8.0

[Ray Rashif]

On 21 February 2011 18:08, Dieter Plaetinck  wrote:
> On Mon, 21 Feb 2011 10:47:50 +0100
> Lukas Fleischer  wrote:
>
>> The official Arch Linux AUR setup has been upgraded to 1.8.0. For a
>> short list of changes, read [1].
>>
>> Please report any issues on the AUR bug tracker [2].
>>
>> [1]
>> http://mailman.archlinux.org/pipermail/aur-dev/2011-February/001433.html
>> [2] https://bugs.archlinux.org/index.php?project=2
>
> what's the reasoning behind no longer showing all files in the "source
> package"? I found this feature quite useful.

I've _always_ used this, almost on every package I came across. I
don't want to be downloading anything I just want to take a rough look
at. Would be good to have this back in some way or another.
Brainstorm!

Re: [aur-general] Request: Package Revision

[Ray Rashif]

On 14 February 2011 01:19, Bernardo Barros  wrote:
> Hum,
>
> Maybe just create a symlink in /usr/share/java/Eisenkraut/jar poiting
> to /usr/share/eisenkraut/Eisenkraut.jar ?
>
> Sorry if that too obvious, but I don't do java.

Take a look at jsampler [1]. For many java redistributions, they don't
have their sources or don't need to be built. You can often skip the
ant step and just put the jars in proper places, followed by a script
to call the jar (like what you have already done).

[1] 
http://projects.archlinux.org/svntogit/community.git/tree/jsampler/trunk/PKGBUILD

Re: [aur-general] Request: Package Revision

[Ray Rashif]

On 14 February 2011 01:09, Philipp Überbacher  wrote:
> Excerpts from Bernardo Barros's message of 2011-02-13 16:56:09 +0100:
>> Hi all,
>>
>> I don't know much about Java.. but I wanted to package this one
>> because of SuperCollider and it seems a good sound editor anyway.
>> Please people with experience with Java and Java packages revise this
>> one:
>>
>>      http://aur.archlinux.org/packages.php?ID=46459
>>
>> thanks!
>> Bernardo
>
> I don't have java-specific packaging experience, but I seriously wonder
> what this is supposed to achieve:
>  cat << EOF >> "$pkgdir/usr/bin/${pkgname}"
>  #!/bin/bash
>  cd /usr/share/$pkgname && java -jar Eisenkraut.jar
>  EOF

This is a shortcut to create an executable for the java binary. Not illegal :)

Re: [aur-general] AUR & Copyright

[Ray Rashif]

On 8 February 2011 03:47, Michael Witten  wrote:
> On Mon, Feb 7, 2011 at 09:29, Kaiting Chen  wrote:
>> On Mon, Feb 7, 2011 at 9:28 AM, Michael Witten  wrote:
>>
>>> See my gcc-svn PKGBUILD:
>>>
>>>    http://aur.archlinux.org/packages.php?ID=24849
>>>
>>> Nobody likes it anyway, so who cares! :-)
>>>
>>
>> Dude please don't try to make any policy decisions on your own. We still
>> haven't decided what the policy will be regarding PKGBUILD licenses uploaded
>> to the AUR. --Kaiting.
>
> I made that decision nearly 2 years ago, long before any of you even
> thought of starting this discussion.
>
> Besides, I was merely providing a counterexample to Ray Rashif's
> statement: 'First of all, we've never
> had people claiming "rights" to PKGBUILDs.'

But you kept quiet, you see. That's the point.

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 8 February 2011 03:23, Thomas Dziedzic  wrote:
> Side note:
> Although TUs are a great bunch, I don't think that's the main reason
> why people use the AUR. :)

As much as I'd like for this thread to die, because the main issue was
settled very many replies ago (we all agree that it's bad and we'll
make sure it doesn't happen again), I'd also like to stress the fact
that often times discussions veer off-topic and change in tone due to
a cultural and language barrier. So, chill out :)

Re: [aur-general] AUR & Copyright

[Ray Rashif]

2011/2/7 Lukáš Jirkovský :
> I don't think it matters whether PKGBUILDs are software or not.

It never did, but now it does :)

> That sounds to me like saying "all bash scripts have to be under GPL,
> because BASH is licensed under GPL".

If you want to look at it that way, then sure.

Re: [aur-general] AUR & Copyright

[Ray Rashif]

2011/2/7 Lukáš Jirkovský :
> I think most PKGBUILDs are too simple to be considered software.

Simple or not, PKGBUILDs are scripts, and hence software. IMNSHO if
you must apply a license to PKGBUILDs, it should be that of makepkg's
OR the distribution's (for another distribution using makepkg and
similar buildscripts they will have the copyright).

Magnus Therming mentioned this on another thread, and I believe he
makes a valid statement when he says the buildscripts are assumed to
inherit GPL and so need no mention of it.

Re: [aur-general] AUR & Copyright

[Ray Rashif]

On 7 February 2011 07:21, Xyne  wrote:
> Ray Rashif wrote:
>
>> Sorry, bad comparison, then. I'm not really sure what to compare it
>> with. We've never had to talk about things like this before (so
>> probably the time has come you would say). First of all, we've never
>> had people claiming "rights" to PKGBUILDs.
>
> I agree that it is unlikely to be a problem, but the best thing to do is
> deal with the eventuality rather than continue with naive optimism.
>
> What needs to be done, imo:
> * decide on a permissive license or public domain for submitted files
> * add a clearly visible notification
> * add a note concerning the submission of files that cannot be redistributed,
>  e.g. a copyrighted icon included in the upload
> * hope that no previous author ever shows up to claim copyright before the
>  addition of the notice

Here is what Gentoo does for all their official ebuilds [1]:

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

This also appears in all third-party ebuilds [2], so I would assume
one written by an individual and distributed by itself would contain
this same license note.

In order for something like this to work for Arch, aside from official
and third-party repositories, the AUR needs to (1) reject PKGBUILDs
without the license header, (2) inject the header to every submitted
PKGBUILD, or (3) display a note and assume contributors will take the
initiative. None of those appeal to me, personally, but as far as this
subject is concerned I abstain :)

[1] http://gentoo-portage.com/
[2] http://en.gentoo-wiki.com/wiki/List_of_overlays

Re: [aur-general] AUR & Copyright

[Ray Rashif]

2011/2/7 Cédric Girard :
> On Sun, Feb 6, 2011 at 8:47 PM, Ray Rashif  wrote:
>
>> Err..it is as relaxed as the wiki. I don't see why any question about
>> ownership should arise. If someone wants to claim ownership and not be
>> willing to share then so be it (don't even upload to AUR then). She
>> will have a bad reputation, not our problem.
>>
>
> You can't say that. If someone decide to claim ownership to the PKGBUILD he
> wrote and nothing has been done to clear the ownership issue before, the
> reputation of this guy would be the last thing to worry about for Arch
> Linux.
>
> Considering the wiki, it is clearly stated as being under the GNU Free
> Documentation License 1.2.

Sorry, bad comparison, then. I'm not really sure what to compare it
with. We've never had to talk about things like this before (so
probably the time has come you would say). First of all, we've never
had people claiming "rights" to PKGBUILDs.

Re: [aur-general] AUR & Copyright

[Ray Rashif]

On 7 February 2011 02:38, Thomas S Hatch  wrote:
> You raise a good point, I would think that we would need to post something
> on the submit page stating the copyright nature. My brothers are lawyers, I
> will check with them as to what the right thing to do is.
>
> -Thomas S Hatch
> On Feb 6, 2011 10:49 AM, "Xyne"  wrote:
>> Eric Waller wrote:
>>
>>> I am not a lawyer and I generally tune out all license flame wars.
>>> That said, PKGBUILDS generally do not contain copyright or license
>>> declarations. Unless I am mistaken, that means someone who comes into
>>> possession of a PKGBUILD does not have the right to republish it.
>>>
>>> As a minimum, I think Arch should get a nod from the creator of a
>>> PKGBUILD prior to absorbing it into the colective -- It might help
>>> avoid any misunderstandings.
>>
>> What is the legal status of files submitted to the AUR? I have always
> assumed
>> that anything uploaded to the AUR is automatically licensed under the GPL
> or
>> something similar, in the same way that content contributed to the wiki
> is.
>>
>> I can't find anything that states this on the AUR site, which is a
> potentially
>> calamitous legal oversight.
>>
>> The legal issue should be cleared up. If we needed to obtain explicit
>> permission from every contributor then the AUR would cease to be useful.
> You
>> would not be able to adopt and update PKGBUILDs without permission, and
> you
>> would need to enable users to delete their own PKGBUILDs when they decide
> to
>> withdraw permission.
>>
>

Err..it is as relaxed as the wiki. I don't see why any question about
ownership should arise. If someone wants to claim ownership and not be
willing to share then so be it (don't even upload to AUR then). She
will have a bad reputation, not our problem.

Re: [aur-general] Errors on submission: Invalid name: only lowercase letters are allowed

[Ray Rashif]

On 6 February 2011 14:27, andrew thomas  wrote:
> I tried adopted this package (kernel26-yi)
>
> http://aur.archlinux.org/packages.php?ID=37895
>
> But when I tried to upload an updated PKGBUILD. I got rejected with
> "Invalid name: only lowercase letters are allowed"
> I used makepkg --source to generate a file named
> kernel26-yi-2.6.37-1.src.tar.gz.
>
> Why am I receiving this error?

Please pastebin the updated PKGBUILD. And have you disowned it again?
Else, please remember to adopt using the button - you don't adopt a
PKGBUILD by just submitting it.

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 6 February 2011 06:01, Thomas S Hatch  wrote:
> I don't think that Hilton was trolling you Maxime, just poking a little fun
> at Jelle.

He was so engrossed with moving a package (think about the excitement
he must have had) that he forgot about the formalities involved.

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 6 February 2011 03:35, Ionuț Bîru  wrote:
> I moved a lot of packages from AUR in community/extra and every time i did
> sent a "thank you" note. From that amount of messages i sent, only once i
> got a reply. ONCE.
>
> Should i be dissapointed? I guess yes. I am? No.

No need. The first comment from you about moving already counts as closure.

What I do is allow for a grace period before (1) uploading the package
to repo and (2) deleting the package from AUR. I notify (via comments)
at least a day before uploading, and delete the package a day after
uploading. So that's a three-day process.

Now, I just remembered a good example where we appear to have not
bothered with adopting a package into the repositories: q7z [1]

But really, the AUR maintainer can keep working on the PKGBUILD even
if someone brings it in. The difference is you don't submit the
PKGBUILD - you send an e-mail with it attached.

And while we like to joke about making Arch greater and/or kicking
butts, there isn't really anything of that sort. We just help each
other out to fulfill our needs, and the distribution grows along with
us. Humbly.

[1] http://aur.archlinux.org/packages.php?ID=12822

Re: [aur-general] Moving packages to Community

[Ray Rashif]

On 6 February 2011 02:31, Gergely Imreh  wrote:
> Hi,
>
> Recently a couple of my packages have been moved to Community but the
> process feels a little uneasy to me.

This has come up a couple of times before, and we all know it is very
wrong to move a package from [unsupported] _without prior notice_. We
have since been reminding each other, but it looks like the word
hasn't reached some of us.

Perhaps it is time to put this in the guidelines? We cannot just
assume that everyone would be in the know, although I expect that the
individuals we (s)elect to take care of the AUR have at least this
much understanding. But I don't think that's the main issue here,
which brings me to:

> My proposition is: could it be a policy to check with the maintainer
> first before initiating a move? If someone wants to keep a package
> then they should be able to, especially since they could not have been
> doing such a a bad job if their package has become popular.

Now, this is something I find very strange. I wish I had the previous
discussions to link to, so you could better understand what I am about
to mention.

You have to understand that the AUR started out with a purpose, a
purpose which has not, and will not for the foreseeable future,
change. It serves as a platform for proposing packages for
redistribution, and not a platform for competition. Imagine:

* Jane needs package foobar
* Jane cannot find package foobar in the repositories
* Jane creates package foobar for her own use
* Jane now wants to share package foobar so this cycle does not repeat

When you upload a PKGBUILD, you are _sharing_ that PKGBUILD. If a
Trusted User wants to adopt it, that's a good thing for the community.
You don't have to feel challenged, because we are all users, one and
the same, TU or not. You can continue providing assistance if you see
the need, by communicating with the TU.

When I myself started out contributing PKGBUILDs to [unsupported], I
did it hoping one day they will receive enough votes and be adopted by
a TU, enabling the packages to be redistributed to the masses in
binary form, easily accessible with the package manager. I believe
this is the true spirit, the Arch Spirit.

Of course, it is not wrong to want to keep maintaining a package
yourself. It just does not make sense to me. If you really have a
problem, report the packages affected and we can drop them for you.

Re: [aur-general] [community], [unsupported] and AUR

[Ray Rashif]

On 3 February 2011 11:14, Xyne  wrote:
> Hi,
>
> A post on the forum[1] brought my attention to the Official Repositories wiki
> page[2].
>
> A recent note by Louipc states: "Technically, both the [community] and
> [unsupported] repos make up the AUR.".
>
> Is this really still true? The AUR website is completely independent of
> [community] now and I believe that all technical ties between [community] and
> [unsupported] have been severed.
>
> AUR pages on the wiki clearly refer to [unsupported] in many contexts, e.g. 
> the
> main AUR article[3] contains the following snippets:
>
> "The Arch User Repository (AUR) is a community-driven repository for Arch
> users. It contains package descriptions (PKGBUILDs) that allow you to compile 
> a
> package from source with makepkg and then install it via pacman."
>
> "[community], unlike AUR, contains binary packages"
>
> I also believe that most users immediately think of [unsupported] and only
> [unsupported] when speaking of the AUR.
>
> Furthermore, both are repositories in their own right, so it is a misnomer to
> refer to them as a singular "Arch User Repository".
>
>
> What is the point of claiming that [community] is part of AUR? It seems like 
> an
> unnecessarily confusing vestige of [community]'s origins.

Clearly, the move to devtools has decoupled the binary repository from
the AUR web, but I don't think it has decoupled the repository from
its purpose.

Re: [aur-general] Add pyopencl to [community]

[Ray Rashif]

On 4 February 2011 04:21, Andrea Scarpino  wrote:
> On Thursday 03 February 2011 13:49:26 Stéphane Gaudreault wrote:
>> * Add pyopencl to [community] (I will use a better name, something like
>> python2-pyopencl)
> python2-opencl sounds better IMHO.

It's all good but one thing: there either needs to be a provision for
pyopencl or inclusion of the upstream module name in the description,
so that the package naming doesn't hamper searches and common
knowledge (i.e people would know 'pyopencl' only). I see the same
issue with pyqt. Didn't we already have some discussion about the
module naming convention during the major python transition?

Re: [aur-general] poppler 0.16 rebuild

[Ray Rashif]

On 31 January 2011 23:30, Jelle van der Waa  wrote:
> On Mon, 2011-01-31 at 15:50 +0200, Ionuț Bîru wrote:
>> Hi,
>>
>> the rebuilding is almost over and was already moved from staging to
>> testing in the morning, the only package that doesn't build is
>> openscenegraph and is not related to poppler api breakage.
>>
>> Sergej can you look at it and try to fix it?
>>
>
> Openscenegraph  has some funny ffmeg errors, http://dpaste.org/wOAB/
> I'll check it tonight if i find some time

OK it's not what I thought it was:

bugs.gentoo.org/show_bug.cgi?id=347481

A chat on #openscenegraph reveals an ffmpeg build with
-D__STDC_CONSTANT_MACROS from december 2010 worked.

You have to disable ffmpeg for now if anyone wants this rebuilt. And
it's not like it's that affected by poppler. Just remove it from the
TODO.

Re: [aur-general] Temporary Inactivity

[Ray Rashif]

On 29 January 2011 06:36, Jonathan Conder  wrote:
> Hi everyone,
>
> I'm off to the beach again and won't be back until Monday. This time there
> is something on my todo list, which is to move the mythplugins-* packages
> from community-testing into community once libmysqlclient is updated. If
> this happens while I'm away it would be great if someone could do that for
> me. If not, it doesn't matter that much because the only package it will
> break is mythplugins-mythzoneminder, which I doubt is used by many people.

OK, we'll keep tabs on that.

Re: [aur-general] [arch-general] Please settle 'base' in 'depends' for all

[Ray Rashif]

On 19 January 2011 22:23, Stéphane Gaudreault  wrote:
> As the maintainer of A, it is not your job to track dependencies of B and D.
>
> Again, look at the problem from a different point of view. If tomorrow
> dependencies of B change to
>
> B -> C F (direct dependecies)
>
> does it mean that A (and **all** other pkgs that depends on B) should be
> updated to include a dependecy on F ? What if dependency on E is removed from
> C PKGBUILD ? Maintaining a package with such rules will be a nightmare.

If A depends on B AND C while B depends on C, then it is correct to
list both B and C as dependencies of A. That is as proper as it gets,
and this most of us do not practise currently. Aside from any
technical disadvantage, it is just clutter to my eyes.

It is also correct to list only B as a dependency of A, since B would
pull in C, but this correctness is only assumed correctness, provided
link-level dependency has not been checked. This, most of us do
currently. PKGBUILDs and pacman dependency lists are easy to look at.

I don't see a need to 'settle' this one. You may not list glibc
because it simply makes no sense to not have it at the time of
installation. It can be as far deep down as F, but ultimately it is
the packagers' (and community's) responsibility to incorporate
dependency changes. As a community, changes like this are hard to
miss. C getting out of B's dependency chain does not happen a lot.
When it does, someone can report it. So we (should) stick to the
simple(r) way - the current way.

Re: [aur-general] Anybody want apvlv?

[Ray Rashif]

On 11 January 2011 05:10, Brad Fanella  wrote:
> On Mon, Jan 10, 2011 at 12:05 AM, Ray Rashif  wrote:
>> On 9 January 2011 03:27, Brad Fanella  wrote:
>>> So with the recent release of apvlv 0.1.0, I have decided to drop
>>> maintaining it.
>>>
>>> I believe it now supports UMD file reading of some sort, and this
>>> requires the whole the PSP toolchain to be packaged and submitted to
>>> the repo, which is something I have no interest in doing whatsoever,
>>> as I haven't even used the software in months.
>>
>> What exactly is this "PSP toolchain"? Are the tools available from AUR?
>>
>
> Think of it as something similar to, say, the AVR toolchain. It is
> simply packages that are patched/modified for a certain architecture,
> which is the PSP (PlayStation Portable) in this case.
>
> You can check out:
> http://svn.ps2dev.org/listing.php?repname=psp&path=/trunk/&rev=0&sc=0
>
> I couldn't find any PSP/UMD-related packages in the official repos, nor the 
> AUR.

An entire toolchain for a viewer? Either abandon the software
altogether or build it without this "feature".

Re: [aur-general] Anybody want apvlv?

[Ray Rashif]

On 9 January 2011 03:27, Brad Fanella  wrote:
> So with the recent release of apvlv 0.1.0, I have decided to drop
> maintaining it.
>
> I believe it now supports UMD file reading of some sort, and this
> requires the whole the PSP toolchain to be packaged and submitted to
> the repo, which is something I have no interest in doing whatsoever,
> as I haven't even used the software in months.

What exactly is this "PSP toolchain"? Are the tools available from AUR?

Re: [aur-general] Time to Step Down

[Ray Rashif]

On 8 January 2011 08:28, Aaron Bull Schaefer  wrote:
> Fellow Trusted Users,
>
> After almost 4 years of being a TU, I've had less and less time to
> dedicate toward maintaining my packages, and so I think it's finally
> time for me to step down. Arch users definitely deserve a better
> response time than what I've been able to provide lately, and
> unfortunately, my priorities have shifted elsewhere.

It happens - you're not alone :) Anyway, best of luck to you in whatever you do!

Re: [aur-general] Audio plug-ins name convention

[Ray Rashif]

On 4 January 2011 21:54, Bernardo Barros  wrote:
> Hi all!
>
> I'm packaging some audio plug-ins and I wanted to know if there is any
> naming convention to this, as with fonts.

Nope.

> Since there are different formats (LADSPA, LV2,  DSSI and VST), if we
> follow the convention used with fonts (like ttf-x), we will get:
>
>  lv2-x
>  dssi-x
>  ladspa-x
>  vst-x
>
> It makes sense?

It makes sense, no doubt about that. Remember to also provide the
general name of the plugin. An example:

'lv2awesome' is a set of LV2 plug-ins. To fit in with the naming
convention, you can name it lv2-awesome, but have:

provides=('lv2awesome')

If that doesn't conflict with anything. Strip 'plugins' and the type
from the name (for the package, not the provision) and try to be as
short as possible, but still make sure people know what it is from one
glance. A real example:

inavada-studio-plugins -> ladspa-invada
  provides: 'invada-studio-plugins'
  groups: 'ladspa-plugins'
  desc: "A set of LADSPA audio effect plug-ins ported from VST by
Invada Records"

invada-studio-plugins-lv2 -> lv2-invada
  provides: 'invada-studio-plugins-lv2'
  groups: 'lv2-plugins'
  desc: "A set of LV2 audio effect plug-ins ported from VST by Invada Records"

For stuff that are apps by their own rights, like calf, skip the
convention. Strictly use the (proposed) convention for plugins-only
packages.

For VST, use the following:

linuxvst-*
win32vst-*

To be honest, conventions only "appear" when in use in the
repositories. We don't yet have that many plugins in extra/community
to warrant use of a convention.