Re: [aur-general] Away until July 1st

[Anatol Pomozov via aur-general]

Hey Jerome

On Mon, Mar 23, 2020 at 1:37 PM Jerome Leclanche  wrote:
>
> I'm not the sole maintainer on most of these, I try to make sure of that; in 
> any event, yes please feel free to update any of the flagged ones until I 
> return.

Thank you for clarifying it.

Re: [aur-general] Away until July 1st

[Anatol Pomozov via aur-general]

Stay safe Jerome! The whole world is in "interesting" state right now.

What is your position on updating packages you own [1]? Would it be OK
if other Arch fellows update/improve these packages?

[1] https://www.archlinux.org/packages/?sort=&q=&maintainer=jleclanche&flagged=

On Wed, Mar 18, 2020 at 1:04 PM Jerome Leclanche  wrote:
>
> Hi list,
>
> I was already pretty tight on time, but with the latest cross-platform
> virus going around, I'm focusing on different projects right now so
> I'm just going to mark myself as away until things calm down a little.
>
> Be safe, folks.
>
> J. Leclanche

Re: [aur-general] Dropping official gitlab packages

[Anatol Pomozov via aur-general]

Hi

Per discussion with Sven-Hendrik I am going to become maintainer for
these packages.

Aaand the first batch of changes (switching gitlab to ruby 2.6) has
landed [community-testing]. Please give it a try and send feedback if
you see any issues.

Re: [aur-general] Dropping official gitlab packages

[Anatol Pomozov via aur-general]

Hi

On Fri, Dec 27, 2019 at 4:19 AM Sven-Hendrik Haase  wrote:
>
>
>
> On Fri, Dec 27, 2019, 09:26 Anatol Pomozov  wrote:
>>
>> Hello Sven-Hendrik
>>
>> On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase  
>> wrote:
>> > On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer  wrote:
>> >>
>> >> On Thu, 2019-12-26 at 01:51 +0100, Sven-Hendrik Haase via aur-general 
>> >> wrote:
>> >> > On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov <
>> >> > Because Docker+EE works flawlessly and reliably while upstream breaks 
>> >> > the
>> >> > packages we have every other release. Upstream _needs_ their Docker EE
>> >> > image to work as there's tons of money to be lost there but they don't 
>> >> > care
>> >> > about our downstream packages. Also, I didn't see any way to package 
>> >> > their
>> >> > EE at the time. I lost too much time maintaining these fruitless 
>> >> > packages
>> >> > and it's time to cut those losses.
>> >>
>> >> Hello,
>> >>
>> >> Both Docker images work flawlessly since years (they are officially 
>> >> supported).
>> >> I guess the question was more about EE vs CE.
>> >> I recently noticed than well known opensource distro now use the CE.
>> >>
>> >> Regards,
>> >>
>> >> Sébastien "Seblu" Luttringer
>> >
>> > Let's not go further in this direction please. This thread is about 
>> > dropping/passing on maintenance of the gitlab packages. Hopefully some 
>> > other TU can show these packages some love.
>>
>> I think that the question of maintaining 'gitlab' package in
>> [community] is relevant to our future plans. If we want to go with
>> gitlab to manage our repos then I propose to use the Arch package
>> instead of a Docker image. The advantage of using the Arch package is:
>>  - we show that we trust our own packaging abilities
>>  - we put ourselves into our user's shoes. Using 'gitlab' package at
>> our server will help us understand how other users deal with such
>> systems. What are their pain points. Maybe it will force us to rethink
>> how do we manage ruby releases or maybe we come up with better bundler
>> integration or something else.
>>
>> So we need to decide whether we want to use the Arch package or the
>> docker image. If Arch package is the preferable option then it should
>> stay in the repo.
>
>
> The whole point of this is that we don't trust our gitlab packages. I 
> wouldn't build our arch code hosting on those packages from what I've seen in 
> the past. In fact, even if those packages found a maintainer again, I'd be 
> opposed to actually using them ourselves in the short term.
>
> One example of why I don't trust them: sometimes gitlab tags a security 
> release which would in theory need to be released quickly but then fails to 
> build so it stays vulnerable for a few days until I can get the build fixed. 
> This doesn't happen with the docker images.
>
> I think the docker image is by far the preferable option for the time being.

Got it.

Sven-Hendrik, I am actually interested to learn more about gitlab
product and its internals. I see that our package uses the old version
of ruby. Updating the package to ruby-2.6/2.7 and fixing some of the
bugs you mentioned will be a great opportunity for me to learn gitlab
and help community at the same time.

But as we do not plan to use this package at out site then I do not
want to invest too much time into it. What do you think if I take the
ownership over the packages you mentioned then port it to newer ruby
and later (around spring 2020) drop it to AUR?

Re: [aur-general] Dropping official gitlab packages

[Anatol Pomozov via aur-general]

Hello Sven-Hendrik

On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase  wrote:
> On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer  wrote:
>>
>> On Thu, 2019-12-26 at 01:51 +0100, Sven-Hendrik Haase via aur-general wrote:
>> > On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov <
>> > Because Docker+EE works flawlessly and reliably while upstream breaks the
>> > packages we have every other release. Upstream _needs_ their Docker EE
>> > image to work as there's tons of money to be lost there but they don't care
>> > about our downstream packages. Also, I didn't see any way to package their
>> > EE at the time. I lost too much time maintaining these fruitless packages
>> > and it's time to cut those losses.
>>
>> Hello,
>>
>> Both Docker images work flawlessly since years (they are officially 
>> supported).
>> I guess the question was more about EE vs CE.
>> I recently noticed than well known opensource distro now use the CE.
>>
>> Regards,
>>
>> Sébastien "Seblu" Luttringer
>
> Let's not go further in this direction please. This thread is about 
> dropping/passing on maintenance of the gitlab packages. Hopefully some other 
> TU can show these packages some love.

I think that the question of maintaining 'gitlab' package in
[community] is relevant to our future plans. If we want to go with
gitlab to manage our repos then I propose to use the Arch package
instead of a Docker image. The advantage of using the Arch package is:
 - we show that we trust our own packaging abilities
 - we put ourselves into our user's shoes. Using 'gitlab' package at
our server will help us understand how other users deal with such
systems. What are their pain points. Maybe it will force us to rethink
how do we manage ruby releases or maybe we come up with better bundler
integration or something else.

So we need to decide whether we want to use the Arch package or the
docker image. If Arch package is the preferable option then it should
stay in the repo.

Re: [aur-general] Dropping official gitlab packages

[Anatol Pomozov via aur-general]

Thanks for the reply.

On Wed, Dec 25, 2019 at 2:20 PM Sven-Hendrik Haase  wrote:
>> > I maintain the official gitlab packages gitlab, gitlab-gitaly,
>> > gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of
>> > these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
>> > gitlab-workhorse because they are way too much work to maintain and I can't
>> > keep up and the result isn't great.
>>
>> I remember discussions about using gitlab to manage our (future) git
>> repos. If we want to go this route then we need to keep gitlab in our
>> repos.
>
>
> That is entirely orthogonal because we're using Docker for that currently 
> anyway as we'll use their Enterprise Edition offering which we didn't package.

I probably missed this discussion so I am out of context. But what is
the reason we prefer Docker+EE versus using a plain Arch package for
GitLab community edition?

Re: [aur-general] Dropping official gitlab packages

[Anatol Pomozov via aur-general]

Hi

On Tue, Dec 24, 2019 at 11:00 PM Sven-Hendrik Haase via aur-general
 wrote:
>
> Hi guys,
>
> I maintain the official gitlab packages gitlab, gitlab-gitaly,
> gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of
> these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
> gitlab-workhorse because they are way too much work to maintain and I can't
> keep up and the result isn't great.

I remember discussions about using gitlab to manage our (future) git
repos. If we want to go this route then we need to keep gitlab in our
repos.

Re: [aur-general] TU application for Eli Schwartz

[Anatol Pomozov via aur-general]

Hi Eli

Welcome to the TU team!

It's been pleasure for me to work with you before. And now when you
officially became TU there are more possibilities for you to bring
your knowledge and passion to Arch Linux. Congrats, Eli!


On Mon, Dec 25, 2017 at 1:54 PM, Sébastien Luttringer  wrote:
> On Mon, 2017-12-25 at 22:34 +0100, Bartłomiej Piotrowski via aur-general 
> wrote:
>> On 2017-12-18 16:07, Bartłomiej Piotrowski via aur-general wrote:
>> > On 2017-12-13 14:52, Bartłomiej Piotrowski via aur-general wrote:
>> > > On 2017-12-13 13:57, Eli Schwartz via aur-general wrote:
>> > > > Hello, all. :)
>> > > >
>> > > > My name is Eli Schwartz, better known as eschwartz on the forums[1],
>> > > > AUR[2], bugtracker[3], wiki[4] general mailing lists, IRC, and
>> > > > generally
>> > > > everywhere I can stick my nose in. With the aid of Bartłomiej
>> > > > Piotrowski, I am applying today to become a TU.
>> > > >
>> > > > I'm 24 years old, and currently studying Computer Science in the United
>> > > > States.
>> > > >
>> > > > I've been interested in Linux ever since I was first introduced to it
>> > > > in
>> > > > high school, when I asked "what would be the best Linux distro to
>> > > > install if I really want to learn how things work", and I was
>> > > > recommended to try out Arch Linux. It's a choice I haven't regretted
>> > > > since!
>> > > > Outside of Linux my main hobby is books/ebooks (primarily SF&F of all
>> > > > sorts). I have leveraged this nicely to feed back into software which
>> > > > deals with ebooks. :)
>> > > >
>> > > > ...
>> > > >
>> > > > I've now been an active member of the Arch Linux community for
>> > > > approximately 3.5 years, and in that time I've become a member of the
>> > > > Arch Bug Wranglers team, given an Arch Classroom tutorial[5],
>> > > > contributed a few small patches to various Arch projects, mainly
>> > > > pacman[6], and generally hung out on the forums and in IRC, trying to
>> > > > be
>> > > > helpful. Recently I've been doing a bit of general helping out in
>> > > > #archlinux-reproducible[7] as well.
>> > > >
>> > > > I've always been especially interested in packaging for Arch Linux, and
>> > > > have reviewed many PKGBUILDs on this mailing list as well as in the AUR
>> > > > Issues, Discussion & PKGBUILD Requests subforum and in #archlinux-aur,
>> > > > written a popular script for maintaining AUR packages[8], and featured
>> > > > the topic of packaging for Arch Linux in the above-mentioned Arch
>> > > > Classroom tutorial. I anticipate doing all^W^W^Wmost of this in a
>> > > > somewhat more formal role. :)
>> > > >
>> > > > I would like to become a TU in order to contribute more to Arch Linux
>> > > > in
>> > > > general (because it would be a shame to miss out on one particular
>> > > > angle
>> > > > I guess). It would also give me more scope to help fix simple packaging
>> > > > bugs that come up on the bugtracker, help resolve some policy TODOs[9],
>> > > > fix packages which no longer build due to e.g. missing sources (many
>> > > > such packages have been discovered in part due to the valiant efforts
>> > > > of
>> > > > Reproducible Arch Linux and Arch Linux 32), and of course to bring some
>> > > > packages to [community] that I feel would do well there.
>> > > >
>> > > > If given the opportunity, I would consider bringing the following
>> > > > packages to community:
>> > > > - firefox-extension-https-everywhere (I conmaintain this)
>> > > > - fanficfare (I maintain this)
>> > > > - git-crypt
>> > > > - advancecomp
>> > > > - llpp
>> > > > - wikicurses
>> > > > - ghi
>> > > > - dtrx
>> > > > - checkbashisms
>> > > >
>> > > > I would adopt the cinnamon desktop packages, as faidoc is not very
>> > > > active currently and arojas, who currently builds them, says he'd
>> > > > prefer
>> > > > someone who actually uses it to do so.
>> > > > I've also received permission to comaintain sigil and qbittorrent, as
>> > > > well as calibre and its dependencies (I maintain the -git packages for
>> > > > all three in the AUR, and have contributed most of the calibre PKGBUILD
>> > > > as well).
>> > > >
>> > > > [1] https://bbs.archlinux.org/profile.php?id=84187
>> > > > [2] https://aur.archlinux.org/packages/?SeB=M&SB=n&K=Eschwartz
>> > > > [3] https://bugs.archlinux.org/?project=0&do=user&id=19965
>> > > > [4] https://wiki.archlinux.org/index.php/Special:Contributions/Eschwart
>> > > > z
>> > > > [5] https://wiki.archlinux.org/index.php/Classroom#Previous_classes
>> > > > [6] https://github.com/eli-schwartz/pacman/commits/queue?author=eli-sch
>> > > > wartz
>> > > > [7] https://tests.reproducible-builds.org/archlinux/archlinux.html
>> > > > [8] https://github.com/eli-schwartz/pkgbuilds
>> > > > [9] https://www.archlinux.org/todo/
>> > > >
>> > >
>> > > I'm happy to confirm that I do sponsor Eli's application. Happy
>> > > discussing!
>> > >
>> > > Bartłomiej
>> > >
>> >
>> > Discussion period is over, time for the vote.
>> >
>> > Link for the lazy: https://aur

[aur-general] Resigning from my TU position

[Anatol Pomozov via aur-general]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello folks

Currently I am both an Arch developer and TU. I spend most of my time with
Arch packaging and don't do much of TU/AUR activity nowdays.
I would like to resign from my TU position and free space for new folks
who want to become TU.

Please remove me from the list of Arch TUs. Note that I still stay
an Arch developer.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEjhmSFnRl21+wRVV8sChU7XU+Dx8FAlm2y9oACgkQsChU7XU+
Dx843Q/+KugEUvz7NR1Cl8J1/Hur3o89yUfYZ/LDnPkVQhWgwmJ6pWDB0DWD2nBB
ARZ6o4UXLXJHCgcnZmffGCyXcQl4XIY0YNkZzHN6F+Wl0RWRHbFakouXf1xQ/IDZ
exfJkvlJ6Ogp+10N1ezjofmi2RSjz6Ur0/p2umFFD/9g3ziyCn4mYhqssnFr3hUU
B0jEjsFfNHgRpaWTYP/VosRvkjR06Z516gs5Z7b/+PGEJOfZzk+wZFK2u3MNrXOB
yCVytoOTlPLra7OfwXnIO2OH/Oh6KTisQD/oX74GnInG7QyQdWC7qEKqLqQUGmH8
zCpJEwHJ/WU2jIRvhFrHwkbZrn2/rocGV6LZ++r8Msyfdeicirz/oOfQfm5AGZL8
yPnKzm/FoezfFN9/1eJe+w5I67gQhVgMe7QPZYC0etlw11shUJ92L9dJBGa3bU+R
Qh9G0zjwdL3O4SqrzrGv6eZ5RdQN4H17YsO7mYDbZd1GzPt+fF2aaJ3LN9S7T+oe
ex/VftW9cMHc+j0rAg/ZSkBqVEessTNQFpTOHlTDU3F8LBDCFQBtIk8JFKUFKlx8
98AY31zhT897dB8sucpOR544FsSZGNytV2qjOBL61ObjKzxewYVbmNnWgLwPeXO7
9iST0c2bJXXc0O4ELfrg1nSlXWY+EYfnSfRFw2zdWbZRdrtvusw=
=hD0f
-END PGP SIGNATURE-

Re: [aur-general] RFC: PKGBUILD for tensorflow-git

[Anatol Pomozov]

Hi


> Yes you are right, it seems the bazel versions do match but for some reason
> the one from AUR didn't work for me. Could be easily solved with a
> makedepends entry for bazel.

Yes, please move bazel to makedepends list. Avoid duplication, reuse!
There is no need to build the same bazel binaries again.

Could you please post the error logs here?

> So, best not to upload to AUR? I'm okay with that, I learned something when
> making the PKGBUILD and now I have a clean bleeding edge package :).

Actually other way - go ahead and add your package to AUR. People
start using it, you'll get feedback and gradually improve the
PKGBUILD. And you get a lot of experience with package development.

Re: [aur-general] TU application: Pierre Neidhardt

[Anatol Pomozov]

Hi Pierre

On Tue, Oct 13, 2015 at 1:59 AM, Pierre Neidhardt  wrote:
> Great, I'm very happy to read this!
> Thank you very much and see you around! :)

Welcome to the club. Herding Arch packages is a fun and interesting activity.

Re: [aur-general] Merging ruby-jekyll into a single package

[Anatol Pomozov]

Hi

On Sat, May 16, 2015 at 1:29 PM, Hugo Osvaldo Barrera  wrote:
> Hi there!
>
> Jekyll is currently a bit of a mess on the AUR. There's packages for several
> "plugins", like ruby-jekyll-pagination, and several others.
>
> However, these are not plugins in the traditional sense of the word: jekyll
> won't run if they're not installed, so they're more like libraries. Libraries
> that are only used inside jekyll and are not designed to be used 
> independently.
>
> So there's very strong codependency. ruby-jekyll-pagination and ruby-jekyll
> end up depending on each other mutually. Again, "-pagination" is merely an
> example, there's plenty of these.
>
> Someone suggested merging these into a single package: they're diferente
> upstream gems, but only work in unison, and are useless separately, so I'm
> inclined to simplify this on our side (KISS, right?).
>
> Would this course of action be deemed appropriate? Is it acceptable? I know we
> usually don't bundle stuff like this in AUR, but this seems like a strong
> exception, since we're talking about packages with mutual codependency.
>
> Thoughts? Opinions?

The simplest and the most logical way to handle it is to follow
upstream packaging. It means keep gems in its separate arch packages
and avoid bundling.

There is a tool called gem2arch (https://github.com/anatol/gem2arch)
that automatically updates PKGBUILD files, generates new packages if
needed. Managing gem dependencies is hard and gem2arch was implemented
to make the package management automatic.

Re: [aur-general] Fwd: New category: Security

[Anatol Pomozov]

Hi

On Wed, Feb 25, 2015 at 7:26 AM, Ľubomír Kučera  wrote:
> Hello.
>
> I hoped you would add a new category to AUR called "Security". I thought it
> would be more suitable for those packages which target computer security.
> For example, some of my packages which would fit better to Security
> category are bully  or oclhashcat
> .

I propose to remove "category" section completely. For several years
of using AUR I personally did not find any use for it.

Re: [aur-general] VCS guidelines for svn-packages

[Anatol Pomozov]

Hi

On Wed, Dec 31, 2014 at 4:18 PM, Stefan Husmann
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Am 01.01.2015 um 00:59 schrieb Karol Blazewicz:
>> On Thu, Jan 1, 2015 at 12:42 AM, Stefan Husmann
>>  wrote:
>>> I know of at least two PKGBUILDs in AUR where the new makepkg puts an "M" 
>>> behind the pkgver
>>> after last pacman upgrade. Is ther any advice how to handle this?
>>
>> How exactly are the pkgver created? Which PKGBUILDs are you talking about?
>>
>>
> Hello,
>
> sorry for the noise. I just encountered that they both use
>
> pkgver() {
>   cd "$srcdir/ccl"
>   svnversion
> }
>
> which was a version formerly recommended in the Wiki.
>
> With
>
> pkgver() {
>   cd "$srcdir/ccl"
>   local ver="$(svnversion)"
>   printf "%s" "${ver//[[:alpha:]]}"

I would like to point to importance of using revision number delimiter
(by convention we use letter "r"). This delimiter allows avoid
problems in case if upstream decides to make first release or uses
versions with different number of components.

e.g. if at revision "455" upstream decides to release version 0.1 then
the revision delimiter preserves version monotonicity:
0.1.r456 > r454
without delimiter monotonicity fails:
0.1.456 < 454

This is true for other VCS as well.

Re: [aur-general] [PRQ#1089] Orphan Request for mingw-w64-readline

[Anatol Pomozov]

Hi

On Mon, Oct 13, 2014 at 8:22 AM, xantares 09  wrote:
>
>
>> To: aur-reque...@archlinux.org
>> Subject: [PRQ#1089] Orphan Request for mingw-w64-readline
>> CC: pingp...@foxmail.com; xantare...@hotmail.com
>> From: not...@aur.archlinux.org
>> Date: Mon, 13 Oct 2014 14:04:53 +
>>
>> pingplug [1] filed a orphan request for mingw-w64-readline [2]:
>>
>> readline has not been updated for a long time.
>>
>> [1] https://aur.archlinux.org/account/pingplug/
>> [2] https://aur.archlinux.org/pkgbase/mingw-w64-readline/
>>
>
> @pingplug: you could have dropped me a mail, I tend to answer it
>
> @tus, since when "has not been updated for a long time" is a valid reason for 
> orphaning ?

Yes, long out-of-date package is a perfect reason for orphaning. There
are of course valid reasons like newer version is completely broken
and upstream did not provide fix, but in this case maintainer should
tell it on AUR package page.

Package maintenance is a responsibility not a privilege. The
maintainer suppose to follow Arch packaging best practices. Some of
these practices are react on reported issues, keep package file simple
and clean, keep it up-to-date. If current maintainer fails to follow
these practices then it is ok for others to file an orphan request.

> ps: I know this one is not up to date, i did not update it because this one 
> is rather sensitive and I prefered to get same version as mingw-readline from 
> fedora.

Arch is not Fedora. Why would you want to keep there same version?

Re: [aur-general] Supported Architectures

[Anatol Pomozov]

Hi

On Mon, Oct 6, 2014 at 6:03 AM, Jameson  wrote:
> I know that officially Arch only supports i686 and x86_64, but what
> about AUR? I occasionally have people request that I add ARM
> architectures to my PKGBUILDs in the AUR. Is it more appropriate for
> me to tell them that it is an unsupported architecture, or just add it
> so they don't have to modify it prior to building?

AUR arch should contain either i686 or x86_64 as these are only
architectures supported by Arch.

All non-Intel users (like those who install Arch on arm) should use
'makepkg --ignorearch' flag.

Re: [aur-general] Merge ronn into ruby-ronn

[Anatol Pomozov]

Hi

On Mon, Jun 2, 2014 at 9:28 PM, Allen Li  wrote:
> Please merge ronn into ruby-ronn.
>
> [1]: https://aur.archlinux.org/packages/ronn/
> [2]: https://aur.archlinux.org/packages/ruby-ronn/

Done

Re: [aur-general] Packaging a Ruby application (veewee) with embedded gems (no dependency on Arch ruby-* packages)

[Anatol Pomozov]

Hi

On Thu, Apr 10, 2014 at 11:42 AM, Bertrand Bonnefoy-Claudet
 wrote:
> Hello,
>
> veewee [1] is a great tool for building vagrant boxes. Unfortunately, it
> depends on many other gems. I've already built a package ruby-veewee [2]
> using Arch packages as dependencies and there is a git version,
> veewee-git [3], but I find them unsatisfactory because of how difficult
> they are to package with the right version for each gem.

Managing the ruby dependencies manually is difficult indeed. Use tools
(e.g. gem2arch) to generate and update packages.

 $ gem2arch veewee
and it will generate the PKGBUILD.

> vagrant has recently been accepted in community and has a PKGBUILD that
> I find peculiar. It seems like it uses some embedded directory to store
> gems it depends on. Sorry, I'm not very familiar with Ruby and gems.
>
> What I would like to achieve is similar. How can I package veewee-git so
> that required gems are built to and loaded from /opt/veewee/gems ? I
> have tried several combinations with "gem install" and bundler but
> without success.

Using bundle like this is wrong IMHO. It goes against idea of package
management and library reuse. An application should not bundle its
dependencies - it should use system libraries as much as possible.

Re: [aur-general] Out of date: clasp, gringo

[Anatol Pomozov]

Hi

On Wed, Mar 26, 2014 at 10:48 AM, Zack Buhman  wrote:
> On Wed, Mar 26, 2014 at 09:52:17AM -0400, Anatol Pomozov wrote:
>> On Wed, Mar 26, 2014 at 9:45 AM, Vincent B.  wrote:
>> > Hi,
>> >
>> > I am the packager of aspcud and aspcud-svn, an important dependency
>> > solver for the OPAM OCaml package manager.
>> >
>> > Two dependencies, clasp and gringo, have been already packaged in AUR,
>>
>> Disowned. Adopt and keep improving it!
>
> This is what package-hijacking looks like.

I see that Vincent asked to update the package via comments 26 days
ago https://aur.archlinux.org/packages/clasp/ I have no reason don't
trust him about "can't reach the current packager".

Re: [aur-general] Out of date: clasp, gringo

[Anatol Pomozov]

Hi

On Wed, Mar 26, 2014 at 9:45 AM, Vincent B.  wrote:
> Hi,
>
> I am the packager of aspcud and aspcud-svn, an important dependency
> solver for the OPAM OCaml package manager.
>
> Two dependencies, clasp and gringo, have been already packaged in AUR,

Disowned. Adopt and keep improving it!

> but are out of date, and I can't reach the current packager (Mails get
> unanswered).
>
> Therefore I ask for those two packages to be orphaned, I would maintain
> them myself.
>
> Cheers,
>
> Vincent

Re: [aur-general] AUR package-database

[Anatol Pomozov]

Hi

On Mon, Mar 3, 2014 at 10:28 AM, oliver  wrote:
> Hello,
>
> is there a direct way to download / access the AUR-package database (as file
> maybe)?
>
> Or is it necessary to go through
>   https://aur.archlinux.org/packages/ ?

An alternative is to use json aur interface
https://wiki.archlinux.org/index.php/AurJson to access information
about the packages.

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

[Anatol Pomozov]

Hi

On Fri, Feb 21, 2014 at 9:51 AM, Ido Rosen  wrote:
> Hi,
>
> I maintain vagrant package in AUR.  I believe vagrant is a very useful tool
> for ArchLinux users.  I am happy to continue maintaining it in AUR;
> however, for the good of the community, it would be great if one of you TUs
> could move vagrant into [community] as soon as possible so it could get
> wider exposure.  It currently has ~147 votes.  Releases are infrequent, so
> it has been very easy to maintain overall.
>
> AUR package: https://aur.archlinux.org/packages/vagrant/
> Upstream distribution website: http://www.vagrantup.com/
>
> Also, if you'd like to make changes to the PKGBUILD in AUR, you can submit
> a pull request on GitHub: https://github.com/ido/packages-archlinux  (under
> the aur/vagrant directory).

I see that it uses *.rpm file as a source. Does this project have source repo?

Is ruby-vagrant aur package (built from sources) the same as your package?

Re: [aur-general] Removal - poppler-qt3 0.16.7-1 - no longer needed (no kdemod3)

[Anatol Pomozov]

Hi

On Thu, Feb 20, 2014 at 12:28 PM, David C. Rankin
 wrote:
> Guys,
>
>   Reviewing my AUR packages, the poppler-qt3 0.16.7-1 needs to be removed from
> AUR. This package was used with the old kdemod3 build from Chakra. It is no
> longer needed by anything. TDE provides its own version: see:
>
> https://wiki.archlinux.org/index.php/Trinity
>
>   So pursuant to the Arch User Repository wiki (under 6.3 Other requests), 
> could
> you all review it and remove it. It's not worth disowning.

Deleted. Next time please include link to the package.

Re: [aur-general] Voting results

[Anatol Pomozov]

Hi

On 2/16/14, 5:37 AM, Sébastien Luttringer wrote:
> On 16/02/2014 00:54, Lukas Fleischer wrote:
>> On Sat, 08 Feb 2014 at 18:14:21, Lukas Fleischer wrote:
>>> On Mon, 03 Feb 2014 at 20:26:22, Anatol Pomozov wrote:
>>>> Hi everyone
>>>>
>>>> I would like to apply for a Arch Trusted User position. It is
>>>> sponsored by my co-worker and bright engineer David Reisner.
>>>> [...]
>>>
>>> You can now cast your votes [1]. The voting period ends on 2014-02-15.
>>> Note that intermediate voting results are no longer visible due to a
>>> recent AUR patch.
> 
> Welcome.

Thanks.

I was following the AUR TODO list [1] and found that it is slightly
out-of-date. Per [2] PGP key signing requires filing a bug to "Keyring"
but I do not see such project at http://bugs.archlinux.org . I believe I
need a special status at bugs website but there is no information in
TODO how I suppose to change the status.

So my question is who/how to update my status at http://bugs.archlinux.org?


[1]
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users
[2]
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html




signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Voting results

[Anatol Pomozov]

Hi

On 2/16/14, 5:37 AM, Sébastien Luttringer wrote:
> On 16/02/2014 00:54, Lukas Fleischer wrote:
>> On Sat, 08 Feb 2014 at 18:14:21, Lukas Fleischer wrote:
>>> On Mon, 03 Feb 2014 at 20:26:22, Anatol Pomozov wrote:
>>>> Hi everyone
>>>>
>>>> I would like to apply for a Arch Trusted User position. It is
>>>> sponsored by my co-worker and bright engineer David Reisner.
>>>> [...]
>>>
>>> You can now cast your votes [1]. The voting period ends on 2014-02-15.
>>> Note that intermediate voting results are no longer visible due to a
>>> recent AUR patch.
>>
>> Results:
>>
>> * Yes: 25
>> * No: 3
>> * Abstain: 2
>>
>
> Welcome.

Thanks everyone! Glad to be part of the Arch TU brotherhood.

Once I am done with TU todo list I'll start looking at tasks mentioned
in my application.

Re: [aur-general] Code review request: new PKGBUILD "omodoro"

[Anatol Pomozov]

Hi

On Sun, Feb 9, 2014 at 9:08 PM, David Phillips  wrote:
> Related to (4): I've got a PKGBUILD
> (https://aur.archlinux.org/packages/pa/passgen/PKGBUILD) which points
> to a git repo, but *not* using a "git://xyz.git" url. Instead, I'm
> using the format
> "https://github.com/phillid/passgen/archive/master.zip"; - should this
> package have -git appended?

Yes, it should. The "-git" suffix indicates that the package is built
from VCS. "master.zip" source file *also* comes from VCS, from git
repo and means "current HEAD of master branch". The main point of VCS
package is that the source is moving target and it changes
independently from package maintainer. And it differs from 'versioned'
package where sources are changed only when maintainer updates
PKGBUILD.

Using "master.zip" is a bad idea because:
 - Once master.zip downloaded it is cached in the local directory. If
you run makepkg again nothing will be redownloaded even if upstream
repository has changed.
 - Updating local git repository is more effective as it fetches only
the latest changes. Thus package rebuild is faster.


So what you want for passgen:
 - rename it to passgen-git
 - use git repository for sources=() instead of 'master.zip'
 - add 'git' to makedepends
 - add proper pkgver()
 - use 'SKIP' for sha1sum as project head can change at any moment


> I'm thinking it doesn't need the -git
> suffix because it's pulled over HTTP and doesn't need git... What's
> the convention on this?
>
> Cheers.
>
> On 10/02/2014, Doug Newgard  wrote:
>> 
>>> Date: Mon, 10 Feb 2014 00:15:55 +0100
>>> From: okra...@arcor.de
>>> To: aur-general@archlinux.org
>>> Subject: [aur-general] Code review request: new PKGBUILD "omodoro"
>>>
>>> Hello trusty Arch people,
>>>
>>> i just created my first PKGBUILD for the little python script "omodoro"
>>> i wrote. It would be nice if you guys could do a code review to approve
>>> the PKGBUILD i wrote for the AUR.
>>>
>>> The PKGBUILD is here:
>>>
>>> http://www.okraits.de/upload/omodoro/PKGBUILD
>>>
>>> Any feedback/criticism is appreciated!
>>>
>>> Greetings,
>>>
>>> Oliver
>>
>> 1. Your pkgver function doesn't work. pkgver should not be random, it should
>> increase with each commit to the repo.
>> 2. Don't have it depend on an old, replaced package (python3). You just want
>> 'python'.
>> 3. Please quote paths that contain a variable like $pkgdir.
>> 4. You should append -git to the pkgname when you're pulling from git
>> master.
>> 5. Why bother to define _gitname if it's the same as pkgname? Since you
>> should be changing pkgname, _gitname can make sense or you can just do
>> ${pkgname%-git} and get the same thing without having to use an extra
>> variable.
>>
>> Those are my suggestions, nothing too serious.
>
>
> --
> David Phillips

Re: [aur-general] TU application sponsored by David Reisner

[Anatol Pomozov]

Hi

On 2/4/14, 5:27 PM, Sébastien Luttringer wrote:
> On 05/02/2014 00:34, Xyne wrote:
>> Lukas Fleischer wrote:
>>
>>> Technically, that is correct. However, I am sure there are many other
>>> TUs volunteering to be the sponsor after having read the application and
>>> the discussion (me, for example). So I don't think it is a problem. If
>>> it makes feel anyone better, please run
>>>
>>>sed 's/David Reisner/Lukas Fleischer/g'
>>>
>>> on your inbox (the misspelling of Dave's name comes in useful here!)
>>
>> I'm not opposed to the application (it looks very promising to me). I just
>> wanted to mention this issue because there is no point in having by-laws if 
>> we
>> ignore them every time we assume that there is a tacit consensus to do so. 
>>
> 
> I strongly support that we follow our by-laws.
> 
> If Anatol agrees, Lukas will become his new sponsor and we will continue
> to discuss this new promising application.

I am fine with this.

I still need to understand why Arch community is split into two groups
'developers' and 'trusted users'. They seems have similar
responsibilities: maintaining packages and developing Arch toolset.

> Although it's not strictly recommended (we lack of official
> recommendation?), this way works in all cases.

Ok, I've updated 14 packages where I found relative path usage. PTAL.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application sponsored by David Reisner

[Anatol Pomozov]

Hi

On 2/4/14, 5:27 PM, Sébastien Luttringer wrote:
> On 05/02/2014 00:34, Xyne wrote:
>> Lukas Fleischer wrote:
>>
>>> Technically, that is correct. However, I am sure there are many other
>>> TUs volunteering to be the sponsor after having read the application and
>>> the discussion (me, for example). So I don't think it is a problem. If
>>> it makes feel anyone better, please run
>>>
>>>sed 's/David Reisner/Lukas Fleischer/g'
>>>
>>> on your inbox (the misspelling of Dave's name comes in useful here!)
>>
>> I'm not opposed to the application (it looks very promising to me). I just
>> wanted to mention this issue because there is no point in having by-laws if 
>> we
>> ignore them every time we assume that there is a tacit consensus to do so. 
>>
> 
> I strongly support that we follow our by-laws.
> 
> If Anatol agrees, Lukas will become his new sponsor and we will continue
> to discuss this new promising application.

I am fine with this.

> Although it's not strictly recommended (we lack of official
> recommendation?), this way works in all cases.

Ok, I've updated 14 packages where I found relative path usage. PTAL.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application sponsored by David Reisner

[Anatol Pomozov]

Hi

On 2/3/14, 9:29 PM, Anatol Pomozov wrote:
> Hi
> 
> On Mon, Feb 3, 2014 at 11:26 AM, Anatol Pomozov
>  wrote:
> 
>> Hi everyone
> 
>> I would like to apply for a Arch Trusted User position. It is
>> sponsored by my co-worker and bright engineer David Reisner.
> 
>> My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I
>> am an open-source enthusiast who uses Linux since about 2005. I've
>> been using several distros mostly Debian based. About 2.5 years ago,
>> when Ubuntu in-place upgrade killed my system once again, I've decided
>> to give a try to a rolling-release distro.
> 
>> I had heard that Arch was difficult to use and unstable so I've been
>> skeptical that Arch would survive at my computers for a long time. At
>> my surprise Arch installation was easy and system was fast and stable.
>> Documentation is clean and very helpful. And package manager is
>> *FAST*! Yeah!  I fell in love with Arch from the very first day. A few
>> months later all my home computers were moved to Arch. And despite
>> that I usually do crazy experiments at my home machines I've never had
>> serious problems with Arch. Well, the only problem with Arch was in
>> systemd-207 that prevented my btrfs-root machine from booting.
> 
>> About a year ago I started playing more active role in Arch community.
>> I adopted a lot of broken and out-of-date packages. Currently I own
>> 350+ packages [1]. A lot of packages are for ruby gems that previously
>> were out-of-date or had broken dependencies. I improved existing
>> gem2arch tool [2] and it helps me with ruby packages herding.
> 
> 
>> At my day job I work on Linux kernel development/support at a large
>> server farm. My daily activity includes a lot of debugging,
>> performance profiling, code archaeology both for linux kernel and
>> in-house userspace code. Some of my linux changes went upstream, here
>> are few of them:
> 
>> https://lkml.org/lkml/2013/4/12/391
>> http://marc.info/?l=linux-fsdevel&m=134750749009884&w=2
>> https://lkml.org/lkml/2013/4/1/171
> 
>> Google Chromebook developers reported that my last patch fixed one of
>> their top kernel crashes!
> 
>> Recently me and my 6 y/o son started learning microelectronics and
>> digital design. Maybe some day we'll create MIPS-like CPU.
> 
> 
>> Why do I want to become a TU? I like Arch and would like to keep it
>> improving. It means making packages better, participate in important
>> discussions that define where the distro moves.
> 
>> The short/mid terms plans for me are:
>>  - move some of my aur packages to community: rethinkdb, codespell,
>> tup, mldonkey, v8. There are some other aur packages that I use and
>> would also like to see in [community]: fatsort, digital design related
>> tools, ...
>>  - add android-sdk-* packages. Current AUR packages download binaries
>> and install binaries to /opt/bin. The binaries are 32-bit. Instead we
>> should build SDK from sources and provide proper 64/32-bit binaries.
>> This might be tricky as Android build system is complicated.
>>  - request moving Apache to [community] and finally update this package to 
>> 2.4
> 
>> I can help with linux kernel issues, especially if they are related to
>> storage/block subsystem.
> 
>> I also have experience with Ruby. This is my favorite scripting
>> language that I use for 10 years now and I'll be glad to help with
>> Ruby in Arch as well.
> 
>> [1] aur.archlinux.org/packages/?SeB=m&K=anatolik
>> [2] https://github.com/anatol/gem2arch
> 
> Dave asked me to share my public GPG key.
> Here it is http://pgp.mit.edu/pks/lookup?op=get&search=0xB02854ED753E0F1F
> The key is 753E0F1F
> 

D'oh, gmail web UI ate my gpg signature. Let me sign it once again, this
time with Thunderbird.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application sponsored by David Reisner

[Anatol Pomozov]

Hi

On 2/4/14, 12:54 AM, Ike Devolder wrote:
> On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote:
>> Hi everyone
>>
>> I would like to apply for a Arch Trusted User position. It is
>> sponsored by my co-worker and bright engineer David Reisner.
>>
>> My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I
>> am an open-source enthusiast who uses Linux since about 2005. I've
>> been using several distros mostly Debian based. About 2.5 years ago,
>> when Ubuntu in-place upgrade killed my system once again, I've decided
>> to give a try to a rolling-release distro.
>>
>> I had heard that Arch was difficult to use and unstable so I've been
>> skeptical that Arch would survive at my computers for a long time. At
>> my surprise Arch installation was easy and system was fast and stable.
>> Documentation is clean and very helpful. And package manager is
>> *FAST*! Yeah!  I fell in love with Arch from the very first day. A few
>> months later all my home computers were moved to Arch. And despite
>> that I usually do crazy experiments at my home machines I've never had
>> serious problems with Arch. Well, the only problem with Arch was in
>> systemd-207 that prevented my btrfs-root machine from booting.
>>
>> About a year ago I started playing more active role in Arch community.
>> I adopted a lot of broken and out-of-date packages. Currently I own
>> 350+ packages [1]. A lot of packages are for ruby gems that previously
>> were out-of-date or had broken dependencies. I improved existing
>> gem2arch tool [2] and it helps me with ruby packages herding.
>>
>>
>> At my day job I work on Linux kernel development/support at a large
>> server farm. My daily activity includes a lot of debugging,
>> performance profiling, code archaeology both for linux kernel and
>> in-house userspace code. Some of my linux changes went upstream, here
>> are few of them:
>>
>> https://lkml.org/lkml/2013/4/12/391
>> http://marc.info/?l=linux-fsdevel&m=134750749009884&w=2
>> https://lkml.org/lkml/2013/4/1/171
>>
>> Google Chromebook developers reported that my last patch fixed one of
>> their top kernel crashes!
>>
>> Recently me and my 6 y/o son started learning microelectronics and
>> digital design. Maybe some day we'll create MIPS-like CPU.
>>
>>
>> Why do I want to become a TU? I like Arch and would like to keep it
>> improving. It means making packages better, participate in important
>> discussions that define where the distro moves.
>>
>> The short/mid terms plans for me are:
>>  - move some of my aur packages to community: rethinkdb, codespell,
>> tup, mldonkey, v8. There are some other aur packages that I use and
>> would also like to see in [community]: fatsort, digital design related
>> tools, ...
>>  - add android-sdk-* packages. Current AUR packages download binaries
>> and install binaries to /opt/bin. The binaries are 32-bit. Instead we
>> should build SDK from sources and provide proper 64/32-bit binaries.
>> This might be tricky as Android build system is complicated.
>>  - request moving Apache to [community] and finally update this package to 
>> 2.4
>>
>> I can help with linux kernel issues, especially if they are related to
>> storage/block subsystem.
>>
>> I also have experience with Ruby. This is my favorite scripting
>> language that I use for 10 years now and I'll be glad to help with
>> Ruby in Arch as well.
>>
>> [1] aur.archlinux.org/packages/?SeB=m&K=anatolik
>> [2] https://github.com/anatol/gem2arch
> 
> WOW, many packages :)
> 
> I just found something somewhat fishy in your subtle package:
> patch -p1 < ../do_not_relink_binaries_on_install.diff
> 
> I'm not entirely sure i can break the build but i think it would be best
> practice to do "$srcdir/do_not_relink_binaries_on_install.diff"


The only thing that comes to my mind is if the folder where we 'cd'
before doing 'patch' is a symlink. In this case '..' will differ from
$srcdir. But unpacked source directory can't be a symlink, is it?

I do not mind to change it to the longer version "$srcdir/foo" if this
is a recommended way to do, but first I want to know why it is recommended.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application sponsored by David Reisner

[Anatol Pomozov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi

On Mon, Feb 3, 2014 at 11:26 AM, Anatol Pomozov
 wrote:
>
> Hi everyone
>
> I would like to apply for a Arch Trusted User position. It is
> sponsored by my co-worker and bright engineer David Reisner.
>
> My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I
> am an open-source enthusiast who uses Linux since about 2005. I've
> been using several distros mostly Debian based. About 2.5 years ago,
> when Ubuntu in-place upgrade killed my system once again, I've decided
> to give a try to a rolling-release distro.
>
> I had heard that Arch was difficult to use and unstable so I've been
> skeptical that Arch would survive at my computers for a long time. At
> my surprise Arch installation was easy and system was fast and stable.
> Documentation is clean and very helpful. And package manager is
> *FAST*! Yeah!  I fell in love with Arch from the very first day. A few
> months later all my home computers were moved to Arch. And despite
> that I usually do crazy experiments at my home machines I've never had
> serious problems with Arch. Well, the only problem with Arch was in
> systemd-207 that prevented my btrfs-root machine from booting.
>
> About a year ago I started playing more active role in Arch community.
> I adopted a lot of broken and out-of-date packages. Currently I own
> 350+ packages [1]. A lot of packages are for ruby gems that previously
> were out-of-date or had broken dependencies. I improved existing
> gem2arch tool [2] and it helps me with ruby packages herding.
>
>
> At my day job I work on Linux kernel development/support at a large
> server farm. My daily activity includes a lot of debugging,
> performance profiling, code archaeology both for linux kernel and
> in-house userspace code. Some of my linux changes went upstream, here
> are few of them:
>
> https://lkml.org/lkml/2013/4/12/391
> http://marc.info/?l=linux-fsdevel&m=134750749009884&w=2
> https://lkml.org/lkml/2013/4/1/171
>
> Google Chromebook developers reported that my last patch fixed one of
> their top kernel crashes!
>
> Recently me and my 6 y/o son started learning microelectronics and
> digital design. Maybe some day we'll create MIPS-like CPU.
>
>
> Why do I want to become a TU? I like Arch and would like to keep it
> improving. It means making packages better, participate in important
> discussions that define where the distro moves.
>
> The short/mid terms plans for me are:
>  - move some of my aur packages to community: rethinkdb, codespell,
> tup, mldonkey, v8. There are some other aur packages that I use and
> would also like to see in [community]: fatsort, digital design related
> tools, ...
>  - add android-sdk-* packages. Current AUR packages download binaries
> and install binaries to /opt/bin. The binaries are 32-bit. Instead we
> should build SDK from sources and provide proper 64/32-bit binaries.
> This might be tricky as Android build system is complicated.
>  - request moving Apache to [community] and finally update this package to 2.4
>
> I can help with linux kernel issues, especially if they are related to
> storage/block subsystem.
>
> I also have experience with Ruby. This is my favorite scripting
> language that I use for 10 years now and I'll be glad to help with
> Ruby in Arch as well.
>
> [1] aur.archlinux.org/packages/?SeB=m&K=anatolik
> [2] https://github.com/anatol/gem2arch

Dave asked me to share my public GPG key.
Here it is http://pgp.mit.edu/pks/lookup?op=get&search=0xB02854ED753E0F1F
The key is 753E0F1F




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJS8HrXAAoJELAoVO11Pg8f9pIP/2ZHDY5Dpu3bMBb48uqxOB++
SCpqR6nJ5WXRlnLrjZJMSssOhqGungTc7Pw1O1fg5hT72siZXYv40rPFXkF1/HrN
T6WrM8CClPCMnWvBsJ2UWDLRkstHJncm4yrFtkbz26RBiTpzVK3bIC4BDvW6FrXM
HqLsGwQmSYP+WqmWIyCjpyxx+MX+NxPGsTVHsNaSjGWsRaLK6A5ele+XNBr+T3Z5
S/PZAz4A7pKOL1n0bNBEtGuIm//fPXneC4xe5W4sVsSWD+lVdHfbQ6ewTXDLshQQ
mdAEJVB/NHdMG9pZeNyu6FXm/znm3r5lhKZoSVmRmxkaLHgAR+KoODgVsE8m3Az0
YLzoY7BpBR/1E2LxudFrYvI1JASyi4/XZ4XUMoFBc8uCa7qtE1jw8G1MwbM1xP1M
GoEPQLzDelV/oPUpw3uBPk8GRDY/H/f2kyMfyZJQF7cwYIazc2SfvKqzmuDlI0Pp
WcsPiCmigh8RHFXklkKz+Q5OgYUZ9GBKvh0q6jZZfNEZHNlqXbAxxjGpH2qbmoGS
hTtt1ebcWUtFwtYkATuyR32muZzPpTqImvSLDRYUQmF8KrQEibx11FInb99y2tEq
5plWSo1tmNxjOy9vjLibUxvTsO6KZVkYSoMMhwKeO+KZweRmldTilG0CjA7ZiSuI
t/8Z4WFCdPKO7RljKVVu
=3GwC
-END PGP SIGNATURE-

[aur-general] TU application sponsored by David Reisner

[Anatol Pomozov]

Hi everyone

I would like to apply for a Arch Trusted User position. It is
sponsored by my co-worker and bright engineer David Reisner.

My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I
am an open-source enthusiast who uses Linux since about 2005. I've
been using several distros mostly Debian based. About 2.5 years ago,
when Ubuntu in-place upgrade killed my system once again, I've decided
to give a try to a rolling-release distro.

I had heard that Arch was difficult to use and unstable so I've been
skeptical that Arch would survive at my computers for a long time. At
my surprise Arch installation was easy and system was fast and stable.
Documentation is clean and very helpful. And package manager is
*FAST*! Yeah!  I fell in love with Arch from the very first day. A few
months later all my home computers were moved to Arch. And despite
that I usually do crazy experiments at my home machines I've never had
serious problems with Arch. Well, the only problem with Arch was in
systemd-207 that prevented my btrfs-root machine from booting.

About a year ago I started playing more active role in Arch community.
I adopted a lot of broken and out-of-date packages. Currently I own
350+ packages [1]. A lot of packages are for ruby gems that previously
were out-of-date or had broken dependencies. I improved existing
gem2arch tool [2] and it helps me with ruby packages herding.


At my day job I work on Linux kernel development/support at a large
server farm. My daily activity includes a lot of debugging,
performance profiling, code archaeology both for linux kernel and
in-house userspace code. Some of my linux changes went upstream, here
are few of them:

https://lkml.org/lkml/2013/4/12/391
http://marc.info/?l=linux-fsdevel&m=134750749009884&w=2
https://lkml.org/lkml/2013/4/1/171

Google Chromebook developers reported that my last patch fixed one of
their top kernel crashes!

Recently me and my 6 y/o son started learning microelectronics and
digital design. Maybe some day we'll create MIPS-like CPU.


Why do I want to become a TU? I like Arch and would like to keep it
improving. It means making packages better, participate in important
discussions that define where the distro moves.

The short/mid terms plans for me are:
 - move some of my aur packages to community: rethinkdb, codespell,
tup, mldonkey, v8. There are some other aur packages that I use and
would also like to see in [community]: fatsort, digital design related
tools, ...
 - add android-sdk-* packages. Current AUR packages download binaries
and install binaries to /opt/bin. The binaries are 32-bit. Instead we
should build SDK from sources and provide proper 64/32-bit binaries.
This might be tricky as Android build system is complicated.
 - request moving Apache to [community] and finally update this package to 2.4

I can help with linux kernel issues, especially if they are related to
storage/block subsystem.

I also have experience with Ruby. This is my favorite scripting
language that I use for 10 years now and I'll be glad to help with
Ruby in Arch as well.

[1] aur.archlinux.org/packages/?SeB=m&K=anatolik
[2] https://github.com/anatol/gem2arch

Re: [aur-general] Rename request

[Anatol Pomozov]

Hi

On Wed, Jan 29, 2014 at 2:12 AM, Omid Nikta  wrote:
> Hi everybody,
> Could you please rename my package qtmind to QtMind?


I do not think AUR allows to create packages with UpperCase letters.

Re: [aur-general] Please remove unused versioned ruby packages

[Anatol Pomozov]

Hi

On Thu, Jan 23, 2014 at 9:29 AM, Evgeniy Alekseev  wrote:
> On Thursday 23 January 2014 09:21:48 Anatol Pomozov wrote:
>> Following versioned packages are obsolete. Please remove them.
>>
>> https://aur.archlinux.org/packages/ruby-excon-0.25/
>> https://aur.archlinux.org/packages/ruby-fog-1.15.0/
>> https://aur.archlinux.org/packages/ruby-memoizable-0.2/
>> https://aur.archlinux.org/packages/ruby-msgpack-0.4/
>
> ruby-fog-1.15 [1] depends on ruby-excon-0.25. And ruby-fog-1.15 is dependence
> of ruby-knife-ec2 [2]. Will you update ruby-fog-1.15?
>
> [1] https://aur.archlinux.org/packages/ruby-fog-1.15/
> [2] https://aur.archlinux.org/packages/ruby-knife-ec2/

D'oh. Sorry then. ruby-excon-0.25 should stay. Please remove only
following 3 packages:

https://aur.archlinux.org/packages/ruby-fog-1.15.0/
https://aur.archlinux.org/packages/ruby-memoizable-0.2/
https://aur.archlinux.org/packages/ruby-msgpack-0.4/

[aur-general] Please remove unused versioned ruby packages

[Anatol Pomozov]

Hi,

Following versioned packages are obsolete. Please remove them.

https://aur.archlinux.org/packages/ruby-excon-0.25/
https://aur.archlinux.org/packages/ruby-fog-1.15.0/
https://aur.archlinux.org/packages/ruby-memoizable-0.2/
https://aur.archlinux.org/packages/ruby-msgpack-0.4/

Re: [aur-general] Remove a few packages

[Anatol Pomozov]

Hi

On Mon, Jan 20, 2014 at 7:06 AM, Maxime Gauduin  wrote:
> On Mon, Jan 20, 2014 at 4:02 PM, Maxime Gauduin  wrote:
>
>>
>>
>>
>> On Mon, Jan 20, 2014 at 3:31 PM, Nowaker  wrote:
>>
>>> Hey,
>>>
>>>
>>>  The gemname is 'rubysdl' http://rubygems.org/gems/rubysdl, the package
> name should be 'ruby-$gemname'. The question should go to upstream
> developers - why do they use "ruby" prefix in their gem names if the
> gems are for ruby only anyway.
>

>>>  Well, sometimes upstream is wrong, it does not mean we should follow them
 blindly.

>>>
>>> The project name is "Ruby/SDL", and gem name is "rubysdl". We should not
>>> say the upstream is wrong - there's no place to be right or wrong here.
>>> It's how they named the library and we should respect this.
>>>
>>> There is no "sdl" gem in rubygems.org repo, so anyone can upload a gem
>>> by that name at any time. "ruby-sdl" in AUR should be reserved to "sdl" gem
>>> only, so I agree with anatolik (OP).
>>>
>>> But this is just an ideological argument... Practically, anatolik is a
>>> maintainer of ruby-sdl and his gems in AUR follow his own guideline of
>>> ruby-$gemname. [1] This is also an official guideline. [2] Although these
>>> guidelines have recently been edited by anatolik, the very first version of
>>> these guidelines [2] also say the naming convention is ruby-$gemname.
>>> Therefore, anatolik shouldn't be denied the package rename/merge regardless
>>> of anyone finding the package name silly. ;-)
>>>
>>> [1]: https://aur.archlinux.org/packages/?K=anatolik&SeB=m&O=250&PP=50
>>> [2]: https://wiki.archlinux.org/index.php/Ruby_Gem_Package_Guidelines
>>> [3]: https://wiki.archlinux.org/index.php?title=Ruby_Gem_
>>> Package_Guidelines&diff=64416&oldid=64415
>>>
>>> --
>>> Kind regards,
>>> Damian Nowak
>>> StratusHost
>>> www.AtlasHost.eu
>>>
>>
>> This is no ideological argument, just common sense. Say you have a dog,
>> would you call it dog-doggy? Sounds ridiculous right? Why would you call a
>> ruby package ruby-rubylib then?
>>
>> FYI, other distros offering this package call it 'ruby-sdl' [1].
>>
>> You also seem to forget that the AUR is managed by TUs and they have the
>> final say. Mind you, I'm not abusing my status here, if other TU think I'm
>> in the wrong, I'll gladly sit by idly and ignore atrocious names like
>> ruby-ruby-protocol-buffers (from the wiki page). I for one do not approve
>> of the naming guideline, 'ruby-' should only be prepended to libraries when
>> it makes sense, and versions should be appended without the leading hyphen,
>> as you can find in the official repos [2].
>>
>>
>> [1] http://pkgs.org/search/?query=ruby-sdl&type=smart
>> [2] https://www.archlinux.org/packages/extra/x86_64/wxgtk2.8/
>>
>> --
>> Maxime
>>
>
> Oh, as for someone uploading a sdl gem, although higly unlikely, could be a
> rewrite of the current implementation. Then, and only then, 'ruby-rubysdl'
> could be justified.

I created a thread called "Ruby gem packages in Arch" please continue
discussion there. I've put my arguments in the first message
1) avoid name collisions
2) make ruby packages maintenance more scriptable

If nobody wants to merge 'ruby-sdl' then I am fine, I'll just disown
it and let somebody else maintain it.

Re: [aur-general] Deletion request: fluentd

[Anatol Pomozov]

Hi

On Mon, Jan 20, 2014 at 7:15 AM, Maxime Gauduin  wrote:
> On Mon, Jan 20, 2014 at 3:14 PM, Alexandre Filgueira <
> alexfilgue...@cinnarch.com> wrote:
>
>> Done, thank you
>>
>>
>> 2014/1/20 Shohei Kusakata 
>>
>> > Hello,
>> >
>> > Please delete this package: fluentd
>> > https://aur.archlinux.org/packages/fluentd/
>> > because I renamed this to the right name: ruby-fluentd
>> > https://aur.archlinux.org/packages/ruby-fluentd/
>> >
>> > Thank you.
>> >
>>
>
> This is an application, the right name was fluentd, not ruby-fluentd.
> Please reupload fluentd, then i'll delete ruby-fluentd.

Like any gem in ruby this could be used as library as well.

Re: [aur-general] Remove a few packages

[Anatol Pomozov]

Hi

On Mon, Jan 20, 2014 at 3:58 AM, Maxime Gauduin  wrote:
> On Mon, Jan 20, 2014 at 12:40 PM, Anatol Pomozov
> wrote:
>
>> Hi,
>>
>> Please remove a number of unused versioned packages:
>>
>> https://aur.archlinux.org/packages/ruby-fog-1.15/
>> https://aur.archlinux.org/packages/ruby-celluloid-0.14.1/
>> https://aur.archlinux.org/packages/ruby-celluloid-io-0.14.1/
>> https://aur.archlinux.org/packages/ruby-coderay-1.0.5/
>> https://aur.archlinux.org/packages/ruby-equalizer-0.0.7/
>> https://aur.archlinux.org/packages/ruby-excon-0.25.0/
>> https://aur.archlinux.org/packages/ruby-github_api-0.10.1/
>> https://aur.archlinux.org/packages/ruby-gssapi-1.0.0/
>> https://aur.archlinux.org/packages/ruby-httpi-0.9.0/
>> https://aur.archlinux.org/packages/ruby-mime-types-1.16/
>> https://aur.archlinux.org/packages/ruby-minitar-0.5.4/
>> https://aur.archlinux.org/packages/ruby-mixlib-config-1.1.2/
>> https://aur.archlinux.org/packages/ruby-moneta-0.6.0/
>> https://aur.archlinux.org/packages/ruby-multipart-post-1.2.0/
>> https://aur.archlinux.org/packages/ruby-net-ssh-multi-1.1.2/
>> https://aur.archlinux.org/packages/ruby-nori-1.0.0/
>> https://aur.archlinux.org/packages/ruby-puma-1.6.3/
>> https://aur.archlinux.org/packages/ruby-ridley-1.5.3/
>> https://aur.archlinux.org/packages/ruby-rubyntlm-0.1.1/
>> https://aur.archlinux.org/packages/ruby-wasabi-1.0.0/
>>
>> Incorrectly named packages that should be removed as well:
>>
>> https://aur.archlinux.org/packages/ruby-digital-ocean/
>> https://aur.archlinux.org/packages/ruby-exception-notification/
>>
>> All nuked.

Thanks. A few more that I missed

https://aur.archlinux.org/packages/ruby-excon-0.25/
https://aur.archlinux.org/packages/ruby-fog-1.15.0/
https://aur.archlinux.org/packages/ruby-memoizable-0.2/

>> please merge
>> https://aur.archlinux.org/packages/ruby-sdl/
>> into
>> https://aur.archlinux.org/packages/ruby-rubysdl/
>>
>
> What's the rationale behind this change? ruby-sdl is perfectly fine,
> ruby-rubysdl is just silly imho.

The gemname is 'rubysdl' http://rubygems.org/gems/rubysdl, the package
name should be 'ruby-$gemname'. The question should go to upstream
developers - why do they use "ruby" prefix in their gem names if the
gems are for ruby only anyway.

[aur-general] Remove a few packages

[Anatol Pomozov]

Hi,

Please remove a number of unused versioned packages:

https://aur.archlinux.org/packages/ruby-fog-1.15/
https://aur.archlinux.org/packages/ruby-celluloid-0.14.1/
https://aur.archlinux.org/packages/ruby-celluloid-io-0.14.1/
https://aur.archlinux.org/packages/ruby-coderay-1.0.5/
https://aur.archlinux.org/packages/ruby-equalizer-0.0.7/
https://aur.archlinux.org/packages/ruby-excon-0.25.0/
https://aur.archlinux.org/packages/ruby-github_api-0.10.1/
https://aur.archlinux.org/packages/ruby-gssapi-1.0.0/
https://aur.archlinux.org/packages/ruby-httpi-0.9.0/
https://aur.archlinux.org/packages/ruby-mime-types-1.16/
https://aur.archlinux.org/packages/ruby-minitar-0.5.4/
https://aur.archlinux.org/packages/ruby-mixlib-config-1.1.2/
https://aur.archlinux.org/packages/ruby-moneta-0.6.0/
https://aur.archlinux.org/packages/ruby-multipart-post-1.2.0/
https://aur.archlinux.org/packages/ruby-net-ssh-multi-1.1.2/
https://aur.archlinux.org/packages/ruby-nori-1.0.0/
https://aur.archlinux.org/packages/ruby-puma-1.6.3/
https://aur.archlinux.org/packages/ruby-ridley-1.5.3/
https://aur.archlinux.org/packages/ruby-rubyntlm-0.1.1/
https://aur.archlinux.org/packages/ruby-wasabi-1.0.0/

Incorrectly named packages that should be removed as well:

https://aur.archlinux.org/packages/ruby-digital-ocean/
https://aur.archlinux.org/packages/ruby-exception-notification/

please merge
https://aur.archlinux.org/packages/ruby-sdl/
into
https://aur.archlinux.org/packages/ruby-rubysdl/

Re: [aur-general] Looking for adopters.

[Anatol Pomozov]

Hi Alfredo

On Wed, Jan 15, 2014 at 7:42 PM, Alfredo Palhares
 wrote:
> I maintain a series of rubygems on the AUR. I've know moved to rbenv
> and do not use them anymore.
>
> Please if you want to maintain a package please send me the name and
> I will disown it.

Please disown them. I am ready to take them over.

Re: [aur-general] Looking for adopters.

[Anatol Pomozov]

Hi, Alfredo

On Wed, Jan 15, 2014 at 7:42 PM, Alfredo Palhares
 wrote:
> I maintain a series of rubygems on the AUR. I've know moved to rbenv
> and do not use them anymore.
>
> Please if you want to maintain a package please send me the name and
> I will disown it.
>
> Since they are too many to enlist by hand, here is the list on the
> AUR[1].
>
> Please note that this is for my ruby-* packages only, I will keep
> mainating the non ruby packages. Also you can checp my git repository[2]
> if you want access to the history.

I own ~230 ruby packages [1] and can take care of yours as well. If
you don't mind I'll spend a few days converting your PKGBUILD files to
style I use for gem packages. Once I done with it you can mass disown
the packages.

Thanks.

[1] https://github.com/anatol/archpackages

Re: [aur-general] PKGBUILD review request

[Anatol Pomozov]

Hi

On Fri, Jan 10, 2014 at 4:32 PM, Jason St. John  wrote:
> You should quote the link in the source array and any string that
> includes a Bash variable (e.g. use `install -Dm 755
> "$pkgname-go-$pkgver" "$pkgdir/usr/bin/$pkgname-go"`).

Could you please please explain it? Why bash variables need quotes?

Well, $srcdir/$destdir need double-quotes because they might contain
spaces (although creating dirs with white-spaces on UNIX is a dumb
idea). What about other variables like $pkgver? The same question
applied to other parts of PKGBUILD - why quotes are needed for
dependencies, license, arch, sources...?

Re: [aur-general] Disown a number of ruby-* packages

[Anatol Pomozov]

Hi,

Please disown more ruby packages for other users.

blinki. He has a number of out-of-date ruby packages, I contacted hime
about month ago and asked the packages ownership. He disowned about a
half of the packages (I already adopted and updated them). He has
other packages that I would like to take care. I asked to disown the
rest but he did not reply.

https://aur.archlinux.org/packages/ruby-cocaine/
https://aur.archlinux.org/packages/ruby-coffee-script/
https://aur.archlinux.org/packages/ruby-exception-notification/
https://aur.archlinux.org/packages/ruby-jquery-rails/
https://aur.archlinux.org/packages/ruby-mysql2/
https://aur.archlinux.org/packages/ruby-paperclip/
https://aur.archlinux.org/packages/ruby-riddle/
https://aur.archlinux.org/packages/ruby-sass-rails/
https://aur.archlinux.org/packages/ruby-thinking-sphinx/
https://aur.archlinux.org/packages/ruby-uglifier/

User 'unexist'. I contacted him about 2 weeks ago to disown his ruby
packages (they are all out-of-date). He did not reply.

https://aur.archlinux.org/packages/ruby-curb/
https://aur.archlinux.org/packages/ruby-ffi/
https://aur.archlinux.org/packages/ruby-minitar/

Thanks.

Re: [aur-general] Merge and disown request

[Anatol Pomozov]

Hi

On Sun, Dec 29, 2013 at 3:31 PM, Armin K.  wrote:
> On 12/28/2013 10:29 AM, Evgeniy Alekseev wrote:
>> On Tuesday 24 December 2013 14:02:43 Armin K. wrote:
>>> I've contacted the maintainers of clang-svn two weeks ago (see comments)
>>> but he didn't responded yet. I'd like you to disown clang-svn so someone
>>> else can step up maintaining, but since I've asked maintainer of
>>> llvm-svn (which you can also see in comments of llvm-svn package) to
>>> merge clang-svn into it, you can go ahead and merge it instead of
>>> disowning it first, then merging it later.
>>>
>>> https://aur.archlinux.org/packages/clang-svn into
>>> https://aur.archlinux.org/packages/llvm-svn
>>
>> Hi.
>> First, our rules assume communication with the maintainer via e-mail [1, the
>> third paragraph], because some people disable notifications about new
>> comments. And this package isn't marked as out-of-date.
>
> I'll contact maintainer via e-mail then, but I might wait a week before
> doing that, since it's holidays time.
>
>> Second, I don't think merging clang into llvm is a good idea. I believe that
>> packages in AUR must not contain several different packages (as clang and
>> llvm), because it creates difficulties when creating a dependency tree and
>> finding a needed package.
>>

These 2 packages are different. llvm is a library and clang is a C
frontend for it. llvm is used by many other projects.

> clang package already contains llvm, since clang is built as part of
> llvm but is built differently than llvm and they conflict with each
> other in this case but they should belong with each other.

These packages should not conflict. llvm-svn should install only llvm
specific files and clang-svn should install only clang specific files.
I quickly looked at package() in clang-svn and it makes me believe
that it installs llvm files also.

Here is what clang-svn does
https://aur.archlinux.org/packages/cl/clang-svn/PKGBUILD:

cd "$srcdir/$_svnmod-build/build"
make DESTDIR=$pkgdir install


And it differs from package_clang() function in
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/llvm

cd "$srcdir/llvm-$pkgver.src/tools/clang"
make DESTDIR="$pkgdir" install


I believe clang-svn should do something similar, i.e. install only
clang specific files.


> As you can see in the pkgbuild, clang clones llvm source and everything
> from that source is built.

This is a problem of build system used by upstream project (in this case clang).

On *nix, projects usually split its codebases into small pieces and if
it requires additional dependencies (like headers/libraries) then they
are installed as system packages. On systems that do not have good
package managers (windows/osx) the only reasonable way to build the
project is to pull all dependencies sources and build them as well,
there is no other way to get those dependencies.

That is why clang and many other projects pull dependencies sources
and build them. Instead, on Linux, they should use system libraries. I
filed a ticket for similar issue in liblikely
https://github.com/biometrics/likely/issues/39

I think the best way to resolve the clang issue is to ask clang/llvm
community to split the codebases, let clang to be built separately and
let it use llvm system libraries/headers (at least as a build time
option).

Re: [aur-general] Remove Request

[Anatol Pomozov]

Hi

On Sat, Dec 21, 2013 at 7:29 PM, Guten  wrote:
> https://aur.archlinux.org/packages/ruby-tagen/
> https://aur.archlinux.org/packages/ruby-retort/
> https://aur.archlinux.org/packages/ruby-niceogiri/
> https://aur.archlinux.org/packages/ruby-girl_friday/
> https://aur.archlinux.org/packages/ruby-blather/
>
> I created all these packages at first place, but now I don't use and
> maintaince  them for a long time, please clean them up.

Just disown them and all other packages you do not want to maintain.
Somebody might take it.

Re: [aur-general] Disown a number of ruby-* packages

[Anatol Pomozov]

Hi

On Sun, Dec 15, 2013 at 11:52 PM, Felix Yan  wrote:
> On Sunday, December 15, 2013 23:24:34 Anatol Pomozov wrote:
> 
>> Meanwhile I mostly cleaned the recent gem packages and ready to take
>> more. Please disown following packages from kidoz (the same person as
>> before):
>>
>> https://aur.archlinux.org/packages/ruby-gruff/
>> https://aur.archlinux.org/packages/ruby-irc/
>> https://aur.archlinux.org/packages/ruby-journey/
>> https://aur.archlinux.org/packages/ruby-kramdown/
>> https://aur.archlinux.org/packages/ruby-mkrf/
>> https://aur.archlinux.org/packages/ruby-opengl/
>> https://aur.archlinux.org/packages/ruby-rack-cache/
>> https://aur.archlinux.org/packages/ruby-rack-mount/
>> https://aur.archlinux.org/packages/ruby-rack-ssl/
>> https://aur.archlinux.org/packages/ruby-rake-compiler/
>> https://aur.archlinux.org/packages/ruby-ronn/
>> https://aur.archlinux.org/packages/ruby-rubyforge/
>> https://aur.archlinux.org/packages/ruby-sdl/
>> https://aur.archlinux.org/packages/ruby-webgen/
>> https://aur.archlinux.org/packages/ruby-xmpp4r/


Updated and properly constructed/named rails-2 packages have been
added, please merge outdated kidoz' packages:

https://aur.archlinux.org/packages/ruby-actionmailer2xx/
into
https://aur.archlinux.org/packages/ruby-actionmailer-2/


https://aur.archlinux.org/packages/ruby-actionpack2xx/
into
https://aur.archlinux.org/packages/ruby-actionpack-2/

https://aur.archlinux.org/packages/ruby-activerecord2xx/
into
https://aur.archlinux.org/packages/ruby-activerecord-2/

https://aur.archlinux.org/packages/ruby-activeresource2xx/
into
https://aur.archlinux.org/packages/ruby-activeresource-2/

https://aur.archlinux.org/packages/ruby-activesupport2xx/
into
https://aur.archlinux.org/packages/ruby-activesupport-2/

https://aur.archlinux.org/packages/ruby-rack110/
https://aur.archlinux.org/packages/ruby-rack1xx/
both merge into
https://aur.archlinux.org/packages/ruby-rack-1.1/


https://aur.archlinux.org/packages/ruby-rails2xx/
https://aur.archlinux.org/packages/ruby-rails2xx-aio/
both merge into
https://aur.archlinux.org/packages/ruby-rails-2/



Thanks!

Re: [aur-general] Disown ruby-minitar

[Anatol Pomozov]

Hi

On Wed, Dec 18, 2013 at 6:35 PM, Alfredo Palhares
 wrote:
> Hello fellow archers,
>
> Can you please disown ruby-minitar[1] the package is out of date and
> the owner did not respond to any email.
>
>
> [1] https://aur.archlinux.org/packages/ruby-minitar/

If this user is inactive then it worth disowning his other 2
out-of-date ruby packages. I am willing to take ownership over them

https://aur.archlinux.org/packages/ruby-curb/
https://aur.archlinux.org/packages/ruby-ffi/

Re: [aur-general] Disown a number of ruby-* packages

[Anatol Pomozov]

Hi

On Sat, Dec 14, 2013 at 3:15 PM, Jeremy Audet  wrote:
>> For the last one, I think we can ignore the prefix as we already did for
>> python packages (like python-dateutil and python2-memcached, they both
> have a
>> "python-" prefix on pypi index). But... as you wish :)
>
> I also interpret those naming rules with a grain of salt. For example, the
> vim-a [1] and vim-mark [2] packages refer to scripts named vim.a and
> vim.mark, respectively. (the latter script is my own)

Later I will describe my experience with herding the ruby packages.
And include this naming question as well.

Meanwhile I mostly cleaned the recent gem packages and ready to take
more. Please disown following packages from kidoz (the same person as
before):

https://aur.archlinux.org/packages/ruby-gruff/
https://aur.archlinux.org/packages/ruby-irc/
https://aur.archlinux.org/packages/ruby-journey/
https://aur.archlinux.org/packages/ruby-kramdown/
https://aur.archlinux.org/packages/ruby-mkrf/
https://aur.archlinux.org/packages/ruby-opengl/
https://aur.archlinux.org/packages/ruby-rack-cache/
https://aur.archlinux.org/packages/ruby-rack-mount/
https://aur.archlinux.org/packages/ruby-rack-ssl/
https://aur.archlinux.org/packages/ruby-rake-compiler/
https://aur.archlinux.org/packages/ruby-ronn/
https://aur.archlinux.org/packages/ruby-rubyforge/
https://aur.archlinux.org/packages/ruby-sdl/
https://aur.archlinux.org/packages/ruby-webgen/
https://aur.archlinux.org/packages/ruby-xmpp4r/


Also almost 2 weeks ago I contacted Synthead about disowning his
out-of-date packages, but he did not reply. 'ruby-unicorn' is not
updated since May. I believe Synthead is inactive. So please disown:

https://aur.archlinux.org/packages/ruby-unicorn/
https://aur.archlinux.org/packages/ruby-kgio/
https://aur.archlinux.org/packages/ruby-raindrops/

> But whatever. The more important thing is that Anatol is maintaining
> packages. Thank you.

Thanks. I glad to make ruby more useful on Arch.

>
> [1] https://www.archlinux.org/packages/community/any/vim-a/
> [2] https://aur.archlinux.org/packages/vim-mark/
>
> --Jeremy

Re: [aur-general] Disown a number of ruby-* packages

[Anatol Pomozov]

Thanks Felix

May I have a few more of kidoz' out-of-date packages:

https://aur.archlinux.org/packages/ruby-rack-protection/
https://aur.archlinux.org/packages/ruby-uuidtools/
https://aur.archlinux.org/packages/ruby-cmdparse/

Re: [aur-general] Disown a number of ruby-* packages

[Anatol Pomozov]

Great thank you.

The packages are adopted and updated. Now everyone can enjoy
ruby-4.0.2 from AUR. I tested it on a few simple rails apps and
everything seems fine.




An additional cleanup requests:

Please merge old "bundle" rails into the correct one
https://aur.archlinux.org/packages/ruby-rails-aio/
https://aur.archlinux.org/packages/rails/
into
https://aur.archlinux.org/packages/ruby-rails/

The bundle packages install several *.gem files at once. The correct
way is to to have one package-per-gem.


Merge
https://aur.archlinux.org/packages/ruby-rmagick2/
into
https://aur.archlinux.org/packages/ruby-rmagick/

these are duplicated packages

Merge
https://aur.archlinux.org/packages/sqlite3-ruby/
into
https://aur.archlinux.org/packages/ruby-sqlite3/

These are duplicated packages. sqlite3-ruby actually belongs to
'kidoz' but he is inactive.


Merge
https://aur.archlinux.org/packages/ruby-protocol-buffers/
into
https://aur.archlinux.org/packages/ruby-ruby-protocol-buffers/

Although ruby-ruby-protocol-buffers is uglier package name it is the
correct one (the gem name is ruby-protocol-buffers)

[aur-general] Disown a number of ruby-* packages

[Anatol Pomozov]

Hi

I have a dream to make rails from packages work on Arch again.

Currently rails and many of its dependencies are out-of-date with
broken dependencies. I would like to get ownership on many of the
'kidoz' user ruby-* packages. I emailed kidoz 10 days ago about
transferring his out-of-date (or even all) ruby packages to me. He did
not reply. Taking into account that many of his packages are
out-of-date (some of them ~4months now) I consider kidoz inactive.

Some of the packages need to be merged, some of them deleted, but
let's talk about it later.

Ok, could you please disown following packages:

https://aur.archlinux.org/packages/ruby-columnize/
https://aur.archlinux.org/packages/ruby-erubis/
https://aur.archlinux.org/packages/ruby-hike/
https://aur.archlinux.org/packages/ruby-hoe/
https://aur.archlinux.org/packages/ruby-hpricot/
https://aur.archlinux.org/packages/ruby-i18n/
https://aur.archlinux.org/packages/ruby-multi_json/
https://aur.archlinux.org/packages/ruby-rack-test/
https://aur.archlinux.org/packages/ruby-rails-aio/
https://aur.archlinux.org/packages/ruby-railties/
https://aur.archlinux.org/packages/ruby-rdoc/
https://aur.archlinux.org/packages/ruby-rmagick/
https://aur.archlinux.org/packages/ruby-rmagick2/
https://aur.archlinux.org/packages/ruby-sinatra/
https://aur.archlinux.org/packages/ruby-sprockets/
https://aur.archlinux.org/packages/ruby-thor/
https://aur.archlinux.org/packages/ruby-tilt/
https://aur.archlinux.org/packages/ruby-actionmailer/
https://aur.archlinux.org/packages/ruby-actionpack/
https://aur.archlinux.org/packages/ruby-activemodel/
https://aur.archlinux.org/packages/ruby-activerecord/
https://aur.archlinux.org/packages/ruby-activeresource/
https://aur.archlinux.org/packages/ruby-arel/
https://aur.archlinux.org/packages/ruby-bundler/
https://aur.archlinux.org/packages/rails/

Re: [aur-general] Cleanup arch2gem mess

[Anatol Pomozov]

Hi,

Thanks.

I repacked and cleaned gem2arch. Could you please merge

https://aur.archlinux.org/packages/gem2arch-ruby/

into

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

On Fri, Dec 6, 2013 at 12:34 AM, Evgeniy Alekseev  wrote:
> On Thursday 05 December 2013 22:04:53 Anatol Pomozov wrote:
>> I own several packages with the same functionality.
>>
>> packages
>> https://aur.archlinux.org/packages/gem2arch/
>> https://aur.archlinux.org/packages/gem2arch-git/
>>
>> should be removed as their upstream project is dead. In fact its
>> functionality superseded by gem2arch-ruby. I am going to rename the
>> *-ruby package to gem2arch later.
>>
>> https://aur.archlinux.org/packages/gem2arch-ruby-enterprise/
>>
>> should also be removed.
>>
>> Bottom line. Please merge following packages:
>> https://aur.archlinux.org/packages/gem2arch/
>> https://aur.archlinux.org/packages/gem2arch-git/
>> https://aur.archlinux.org/packages/gem2arch-ruby-enterprise/
>>
>> into
>> https://aur.archlinux.org/packages/gem2arch-ruby/
>
> All done, tnx.
> --
> С уважением, Е.Алексеев.
> Sincerely yours, E.Alekseev.
>
> e-mail: darkarca...@mail.ru
> ICQ: 407-398-235
> Jabber: arca...@jabber.ru

[aur-general] Cleanup arch2gem mess

[Anatol Pomozov]

I own several packages with the same functionality.

packages
https://aur.archlinux.org/packages/gem2arch/
https://aur.archlinux.org/packages/gem2arch-git/

should be removed as their upstream project is dead. In fact its
functionality superseded by gem2arch-ruby. I am going to rename the
*-ruby package to gem2arch later.

https://aur.archlinux.org/packages/gem2arch-ruby-enterprise/

should also be removed.

Bottom line. Please merge following packages:
https://aur.archlinux.org/packages/gem2arch/
https://aur.archlinux.org/packages/gem2arch-git/
https://aur.archlinux.org/packages/gem2arch-ruby-enterprise/

into
https://aur.archlinux.org/packages/gem2arch-ruby/

[aur-general] Long check() function in AUR packages

[Anatol Pomozov]

Hi,

I am a big proponent of using automation testing. Tests saved me many
times at my $dayjob projects. That is why I strongly believe that
every arch package should have check() function - it is better find a
problem at build time, rather than get a crash while running the
application.

But some projects have quite large test suites. v8,rethinkdb,tup-git
are examples - their tests take 10 minutes or even more. Some AUR
users complain that it is too long. Even worse - there can be flaky
tests that work fine for me but fail for some users.

What is the best practices in this situation? I see a few possible answers:
1) Tell users relax and enjoy running tests. Tests are for their own good.
2) Tell users to disable (!check) option in /etc/makepkg.conf
3) Maybe AUR install scripts (like yaourt) should not run tests at
installation time? Or at least make it configurable?

What do you think is the best option?

Re: [aur-general] Delete request: bison27

[Anatol Pomozov]

Hi

On Tue, Nov 19, 2013 at 4:56 PM, Rob McCathie  wrote:
> Hi,
>
> I have re-uploaded bison27 to AUR and disowned the package.
>
> Sorry, if i'd known it had been used anywhere other than wine-stable
> obviously i'd have just disowned it and left it.
>
> Sadly when another packages references your package as a makedepends (not
> depends) is doesn't show up in that "Require by" section.

Arch website tracks build time dependencies between packages. Check
for example 'bison' package
https://www.archlinux.org/packages/core/x86_64/bison/

AUR website should do the same. Could you please file a bug against AUR project?

[aur-general] libhugetlbfs: transfer of ownership

[Anatol Pomozov]

Hi

I would like get ownership of libhugetlbfs AUR package. The owner
email does not exist, and the package is out-of-date.

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


-- Forwarded message --
From: Anatol Pomozov 
Date: Sun, Nov 3, 2013 at 9:30 PM
Subject: libhugetlbfs: transfer of ownership
To: uergen@gmail.com


Hi,

I see that you are the maintainer of this package
https://aur.archlinux.org/packages/libhugetlbfs/

I would like to get the ownership and keep improving/fix and update it.

Re: [aur-general] Revise VCS packages versioning

[Anatol Pomozov]

Hi

> The sha1 is useful to people who need to quickly tell developers which
> version they are running when they're from git. Removing it is a bad
> idea.

You can get the commit from the version number even without the SHA1,
something like:

git log --oneline $VERSION..$BRANCH | tail -n $REVISION | head -n 1

Where $BRANCH is the one used in PKGBUILD (usually it is HEAD).


Anyway VCS-package users suppose to follow HEAD version closely. In
those rare cases when a user sees problem in no-release non-HEAD
version and tries to contact upstream developers I bet the first
question from the developers will be "Could you please update to HEAD
and see if the problem still exists?".

> The main issue with -git versioning is the inconsistency. The proto
> file for it is terribly out of date, not everyone respects whatever
> flavour of the recommended way is current, and not every git
> repository has tags (creating a need for two different functions, the
> need of which cannot be told until build time). A further issue arises
> from that, which is that repositories without tags may get tags later
> on and the package maintainer may not know about that (leaving the old
> versioning in), or using the new versioning may break versioning for
> other packages.
>
> I'm not suggesting we drop the pkgver function (nobody is). I'm saying
> we need a standardized pkgver script that outputs consistent,
> compatible results between tagged and non-tagged git repos, and
> recommend that as the proto. To that end, I liked the proposal of
> 0.7.r19.ge4e6e20 vs 0.r19.ge4e6e20.
>
> J. Leclanche

Re: [aur-general] Revise VCS packages versioning

[Anatol Pomozov]

Hi

On Wed, Oct 30, 2013 at 10:47 PM, William Giokas <1007...@gmail.com> wrote:
> On Wed, Oct 30, 2013 at 09:49:11PM -0700, Anatol Pomozov wrote:
>> Hi
>>
>> On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche  wrote:
>> > As someone who maintains a lot of git packages, I wish, I really wish
>> > there was a *standardized* way of writing a pkgver that would output
>> > the appropriate format whether there are tags pushed upstream or not.
>>
>> That is what I intended to propose next.
>>
>> As the regexp become more complicated it is better if makepkg will
>> take care of generating the package version. I think makepkg should
>> have a shell function, something like 'generate_pkgver_vcs()' that
>> user can use in pkgver().
>>
>> e.g.
>>
>> pkgver() {
>>   cd repo
>>   generate_pkgver_vcs()
>> }
>>
>> This function will
>> 1) Find what VCS is used
>> 2) Generate appropriate VCS version
>>
>
> I would urge you to look at one of the newer features of pacman,
> makepkg-template. You can do such things as this very easily. I already
> maintain a small and probably awful repository[1]/package[2] with a few
> VCS pkgver functions that you can use. Mostly they have been taken from
> the wiki, though I do have a nice, long sed expression that does the
> 'r' prefixing (I wrote that talk article).
>
> [1]: http://git.kaictl.net/wgiokas/makepkg-templates.git/
> [2]: https://aur.archlinux.org/packages/makepkg-templates-ks-git/
>
> --SNIP--
>> >> Another issue is a repo that has no tags. Here is a recommendation
>> >> from the wiki page:
>> >>
>> >> printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short 
>> >> HEAD)"
>> >>
>> >> that will use number of commits (a large number e.g. 3000). The
>> >> problem arises when the project creates first tag e.g. 0.1. I suggest
>> >> to fix this problem by using "0" as a tag version (and add prefix 'r'
>> >> like in the previous item). This makes sure that non-tagged version is
>> >> always less that a tagged version.
>> >>
>> >> So pkgver() will look like:
>> >>
>> >> printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short 
>> >> HEAD)"
>> >>
>> >> Let me know if you have any objections. If not then I'll update the wiki 
>> >> page.
>
> This is not needed at all. If the project starts using tags, use an
> epoch= to set all versions from then on to be greater than the original
> versions with rev-list.

Personally I do not like using epoch for such cases as it uglifies the
version number.

I see 2 options for non-tagged versions:

1) With "0." prefix. e.g. "0.r453". So beginning of the project
history acts as a "release number zero" that is lower than any tagged
version.

2) Without the prefix. e.g. "r453", it also works fine and makes the
version a little bit shorter.

$ vercmp 0.1 r543
1


I prefer option #1 as it makes version more consistent between tagged
and non-tagged versions, but I can live with #2 as well.




BTW Most of the -git packages add 'short SHA1 of the HEAD'  as suffix
e.g. '2.2.r9.g6c8d8ae-1'. In fact this SHA1 (g6c8d8ae in this example)
is not used in the version comparison and not needed. I suggest to
drop the SHA1 from recommended -git version and leave only the 'rXXX'
part, e.g.

0.r32.gfoobar => 0.r31
2.2.r4.g23423234 => 2.2.r4

This makes versions shorter and nicer, and makes it more consistent
with other VCS.

Re: [aur-general] Revise VCS packages versioning

[Anatol Pomozov]

Hi

On Wed, Oct 30, 2013 at 10:15 PM, Doug Newgard  wrote:
> 
>> Date: Wed, 30 Oct 2013 22:09:21 -0700
>> From: anatol.pomo...@gmail.com
>> To: aur-general@archlinux.org
>> Subject: Re: [aur-general] Revise VCS packages versioning
>>
>> Hi
>>
>> On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard  wrote:
>>> 
 Date: Wed, 30 Oct 2013 21:49:11 -0700
 From: anatol.pomo...@gmail.com
 To: aur-general@archlinux.org
 Subject: Re: [aur-general] Revise VCS packages versioning

 Hi

 On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche  
 wrote:
> As someone who maintains a lot of git packages, I wish, I really wish
> there was a *standardized* way of writing a pkgver that would output
> the appropriate format whether there are tags pushed upstream or not.

 That is what I intended to propose next.

 As the regexp become more complicated it is better if makepkg will
 take care of generating the package version. I think makepkg should
 have a shell function, something like 'generate_pkgver_vcs()' that
 user can use in pkgver().

 e.g.

 pkgver() {
 cd repo
 generate_pkgver_vcs()
 }

 This function will
 1) Find what VCS is used
 2) Generate appropriate VCS version

>>>
>>> Very, very bad idea. Every repo is different, the flexibility of the pkgver 
>>> function lets the maintainer adapt to that. This was one of the major new 
>>> features in pacman/makepkg 4.1.
>>
>> I do not propose to remove pkgver(). What I say is that vcs version
>> generator becomes non-trivial and many people use different and
>> inconsistent VCS versions. It indicates that there should be some
>> standard way to generate version. If you don't want to use the
>> standard generator you can use your own command to generate the
>> version.
>>
>> But at least the standard generator will show how version should look
>> like (e.g. "r" prefix or not, what delimiter should be used, etc)
>
> If you want the "r", add it. If not, don't. I don't see the problem.
>
>>
>>> To be very blunt, if you can't figure out basic scripting enough to write a 
>>> coherent pkgver function, you don't really have any> business maintaining 
>>> PKGBUILDs.
>>
>> Please more respect, this is a public discussion.
>
> I'm well aware that it's a public discussion, but I'm not going to sugar coat 
> things to protect other's feelings. Bash can be complex, but basic scripting 
> isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of 
> the basics, you're being set up to fail from the get go.

Dude, before doing these statements I suggest to look at your own
packages. The versions of *your* packages (as well as many others) are
inconsistent and this discussion tries to improve the situation.

Anyway let's return to the original question about version generators.
Are these "r" prefixes and the proposed "sed" good enough to make it
standard?

Re: [aur-general] Revise VCS packages versioning

[Anatol Pomozov]

Hi

On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard  wrote:
> 
>> Date: Wed, 30 Oct 2013 21:49:11 -0700
>> From: anatol.pomo...@gmail.com
>> To: aur-general@archlinux.org
>> Subject: Re: [aur-general] Revise VCS packages versioning
>>
>> Hi
>>
>> On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche  wrote:
>>> As someone who maintains a lot of git packages, I wish, I really wish
>>> there was a *standardized* way of writing a pkgver that would output
>>> the appropriate format whether there are tags pushed upstream or not.
>>
>> That is what I intended to propose next.
>>
>> As the regexp become more complicated it is better if makepkg will
>> take care of generating the package version. I think makepkg should
>> have a shell function, something like 'generate_pkgver_vcs()' that
>> user can use in pkgver().
>>
>> e.g.
>>
>> pkgver() {
>> cd repo
>> generate_pkgver_vcs()
>> }
>>
>> This function will
>> 1) Find what VCS is used
>> 2) Generate appropriate VCS version
>>
>
> Very, very bad idea. Every repo is different, the flexibility of the pkgver 
> function lets the maintainer adapt to that. This was one of the major new 
> features in pacman/makepkg 4.1.

I do not propose to remove pkgver(). What I say is that vcs version
generator becomes non-trivial and many people use different and
inconsistent VCS versions. It indicates that there should be some
standard way to generate version. If you don't want to use the
standard generator you can use your own command to generate the
version.

But at least the standard generator will show how version should look
like (e.g. "r" prefix or not, what delimiter should be used, etc)

>  To be very blunt, if you can't figure out basic scripting enough to write a 
> coherent pkgver function, you don't really have any > business maintaining 
> PKGBUILDs.

Please more respect, this is a public discussion.

Re: [aur-general] Revise VCS packages versioning

[Anatol Pomozov]

Hi

On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche  wrote:
> As someone who maintains a lot of git packages, I wish, I really wish
> there was a *standardized* way of writing a pkgver that would output
> the appropriate format whether there are tags pushed upstream or not.

That is what I intended to propose next.

As the regexp become more complicated it is better if makepkg will
take care of generating the package version. I think makepkg should
have a shell function, something like 'generate_pkgver_vcs()' that
user can use in pkgver().

e.g.

pkgver() {
  cd repo
  generate_pkgver_vcs()
}

This function will
1) Find what VCS is used
2) Generate appropriate VCS version

> I like this proposal a lot.
> J. Leclanche
>
>
> On Thu, Oct 31, 2013 at 3:37 AM, Anatol Pomozov
>  wrote:
>> Hi
>>
>> I would like to discuss VCS package versioning that is described here
>> https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines
>>
>> I am looking at the -git packages but it also applicable to other VCS.
>> Here is the suggested way to create the version
>>
>> local ver="$(git describe --tags)"
>> echo "${ver//-/.}"
>>
>> so
>> 0.7-19-ge4e6e20
>> will turn into
>> 0.7.19.ge4e6e20
>>
>> The problem is that the revision number (19 in this case) looks like
>> 3rd component in the version. Now imagine upstream project releases
>> version 0.7.1. The generated version becomes 0.7.1 (and then
>> 0.7.1.1.gfoobar). With the new tag the generated version becomes
>> smaller (0.7.1.1 < 0.7.19). That is the real problem that I had with
>> tup-git package - upstream uses both 2 and 3 component versions.
>>
>> We should recommend a way that works this case. There is a discussion
>> in the comments and the best recommendation is to use following
>> recipe:
>>
>> git describe | sed -E 's/([^-]*-g)/r\1/;s/-/./g'
>>
>> The idea is to find the commit number and start it with "r"
>> (revision). "r" is smaller than a number so it will help in our case.
>>
>> 0.7-19-ge4e6e20 => 0.7.r19.ge4e6e20
>>
>> Another issue is a repo that has no tags. Here is a recommendation
>> from the wiki page:
>>
>> printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
>>
>> that will use number of commits (a large number e.g. 3000). The
>> problem arises when the project creates first tag e.g. 0.1. I suggest
>> to fix this problem by using "0" as a tag version (and add prefix 'r'
>> like in the previous item). This makes sure that non-tagged version is
>> always less that a tagged version.
>>
>> So pkgver() will look like:
>>
>> printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short 
>> HEAD)"
>>
>> Let me know if you have any objections. If not then I'll update the wiki 
>> page.

[aur-general] Revise VCS packages versioning

[Anatol Pomozov]

Hi

I would like to discuss VCS package versioning that is described here
https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

I am looking at the -git packages but it also applicable to other VCS.
Here is the suggested way to create the version

local ver="$(git describe --tags)"
echo "${ver//-/.}"

so
0.7-19-ge4e6e20
will turn into
0.7.19.ge4e6e20

The problem is that the revision number (19 in this case) looks like
3rd component in the version. Now imagine upstream project releases
version 0.7.1. The generated version becomes 0.7.1 (and then
0.7.1.1.gfoobar). With the new tag the generated version becomes
smaller (0.7.1.1 < 0.7.19). That is the real problem that I had with
tup-git package - upstream uses both 2 and 3 component versions.

We should recommend a way that works this case. There is a discussion
in the comments and the best recommendation is to use following
recipe:

git describe | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

The idea is to find the commit number and start it with "r"
(revision). "r" is smaller than a number so it will help in our case.

0.7-19-ge4e6e20 => 0.7.r19.ge4e6e20

Another issue is a repo that has no tags. Here is a recommendation
from the wiki page:

printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

that will use number of commits (a large number e.g. 3000). The
problem arises when the project creates first tag e.g. 0.1. I suggest
to fix this problem by using "0" as a tag version (and add prefix 'r'
like in the previous item). This makes sure that non-tagged version is
always less that a tagged version.

So pkgver() will look like:

printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

Let me know if you have any objections. If not then I'll update the wiki page.

Re: [aur-general] Request remove:

[Anatol Pomozov]

Hi,

On Sat, Oct 5, 2013 at 1:59 PM, SpinFlo  wrote:
> hi
>
> please remove v8-dev: https://aur.archlinux.org/packages/v8-dev/
>
>
> this package no longer need because superseded by v8 package (
> https://aur.archlinux.org/packages/v8/)

Note that I deployed latest version of v8 (3.22) but I realized that
it is development version of the package so I need to downgrade it to
3.21 (or whatever the stable version is).

It means while currently v8 package provides development version it
will not be true in the future.


> and no longer used by chromium-dev
> package anymore
>
> greetings

Re: [aur-general] LTS kernel moved to 3.10.x - module rebuilds

[Anatol Pomozov]

Hi

On Tue, Sep 17, 2013 at 5:26 AM, Pedro Alejandro López-Valencia
 wrote:
> On Mon, Sep 16, 2013 at 8:59 PM, Brian F. G. Bidulock
>  wrote:
>
>> If you look at https://www.kernel.org/category/releases.html
>> you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x
>> is EOL Sept, 2015.  (Obviously 3.0.x is EOL Oct 2013, next
>> month, so some change is necessary.)
>
>> When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header
>> files needed a minimum kernel above 2.6.34.  I was wondering whether
>> there was a similar technical reason for the 3.10.x choice over
>> 3.2.x, or whether I can just as easily run a 3.2.x kernel on an
>> otherwise Plain Jane and current Arch Linux build?
>
> Off the top of my head, the discussion in arch-dev-public went about
> two main points: 1:) Arch is a distribution that prides itself in
> being on the bleeding edge of technology. If there is a new LTS kernel
> since now and September 2015, be sure it will replace the present
> version unless there are apocalyptic reasons not to do it. 2.) The
> 3.10 kernel has much better hardware support and gives access to a lot
> of newer technology that LTS users might want to use.
>
> On my side, I can see a very important and beneficial side effect of
> using 3.10 as LTS kernel: It is very well integrated with systemd. In
> fact it has already part of the work that supports the new
> hirearchical cgroups world, therefore it will be more compatible with
> future systemd versions. Furthermore, the technological advance in
> file-systems, virtualization and graphics support from 3.2 to 3.10 is
> not something to ignore.
>
> Perhaps I ought to point out that a kernel.org LTS is a bug-fix only
> affair unless there is an obvious need to correct a glaring mistake,
> new features are not added lightly. That's not the case with vendor
> kernels. They choose to add the support and backport the features they
> want, that is: those kernels are Frankenstein monsters. A RHEL 5
> 2.6.17 kernel is really made out of the corpses of all kernels up to
> 3.8 at this time ---taking an educated guess--- and that is without
> taking into consideration all the out-of-tree additions that are not
> either in Torvald's nor linux-next trees.

I would suggest to rename linux-lts to linux-lts-3.2 and keep it in
the repo for a while. This is the way how Arch can keep old version of
the package.

So people who does not want to rush with kernel upgrade can use that
package. Later (in ~12 months) this package can be removed or moved to
AUR.

Re: [aur-general] About orphaning all packages of inactive users

[Anatol Pomozov]

Hi

On Fri, Jul 19, 2013 at 11:16 AM, Lukas Jirkovsky  wrote:
> On 19 July 2013 15:39, Anatol Pomozov  wrote:
>> Hi
>>
>> In this case the maintainer should unmark the package and clearly
>> explain in comments why the package cannot be upgraded to the new
>> version. Ideally maintainer should also work with upstream on
>> resolving the issues. But silently leave the package in "out-of-date"
>> state forever is not the best solution neither.
>
> The problem is that the users don't read. It's happening all the time.
> I had a package once or twice that couldn't be updated but even though
> I stated it in the comments people were still marking it out of date.
> BTW, leaving the package as out of date is a good reminder that the
> maintainer should check if the problem was fixed every now and then.
>
>
> On 19 July 2013 15:45, Doug Newgard  wrote:
>> 
>>
>> Do you consider clicking a link twice (once to unflag, again to reflag) 
>> every 6 months or so overly burdensome?
>
> It's simple to forget about that

And that is what email notifications for.

> and it's nonsense to do it just to
> keep your package. I don't think it's any better than the current
> approach with emailing the maintainer first.
>
> As I mentioned earlier, I don't have anything against mass orphaning
> if the maintainer is clearly inactive

I don't think that *manual* mass orphaning is a good idea. There
should be an automatic way to do this.

But if you think that "package was not fixed for 6 months" is a bad
indicator of user inactivity what would be a good indicator then?

> and his package has problems,
> but this automatic approach doesn't take that into account.

Re: [aur-general] About orphaning all packages of inactive users

[Anatol Pomozov]

Hi

On Thu, Jul 18, 2013 at 11:40 PM, Lukas Jirkovsky  wrote:
> I'm strongly against the idea of automatic orphaning. Sometimes the
> package may be outdated simply because the new version doesn't work or
> has some serious issues.

In this case the maintainer should unmark the package and clearly
explain in comments why the package cannot be upgraded to the new
version. Ideally maintainer should also work with upstream on
resolving the issues. But silently leave the package in "out-of-date"
state forever is not the best solution neither.

Re: [aur-general] About orphaning all packages of inactive users

[Anatol Pomozov]

Hi

On Thu, Jul 18, 2013 at 8:02 PM, Agustin Ferrario
 wrote:
> On 07/18/2013 11:39 PM, Anatol Pomozov wrote:
>> Hi
>>
>> Is there any style checker tool for PKGBUILD files? Something similar
>> to lint? If yes then it worth checking for style violations as well,
>> e.g. "PKGBUILD does not have package()" function. So bot can send a
>> note to owner and mark the package somehow e.g. "Needs improvements"
>> If no improvement has been done during some period then the package is
>> disowned.
>>
>>
> Namcap...

Yeah, namcap looks like what I kept in mind. I think there should be a
bot that nags about style violation + disowning if no improvements
were made during long period of time (e.g. 1 year). This should
improve AUR packages quality.

Re: [aur-general] About orphaning all packages of inactive users

[Anatol Pomozov]

Hi

On Thu, Jul 18, 2013 at 6:02 PM, Phillip Smith  wrote:
> On 19 July 2013 10:28, John D Jones III  wrote:
>> I like this... though I think 6 months would be better than 3 on the initial 
>> Orphaning. There should for sure be a final "DUDE!!! Fix your crap" Warning 
>> email sent to the maintainer, like above, perhaps a 7 day warning?
>
> A daily process to automatically disown abandoned packages would be
> great, but it needs to account for the last modified date too:
>
> 1. Find packages flagged out of date > 1 month and last modified > 1
> month == Send reminder email. (Package out of date, please update).
> 2. Find packages flagged out of date > 2 month and last modified > 1
> month == Send warning email. (Package still out of date, automatic
> disown in 1 month).
> 3. Find packages flagged out of date > 2.75 month and last modified >
> 1 month == Send warning email. (Last chance!).
> 4. Find packages flagged out of date > 3 month and last modified > 1
> month == Disown, send notification email, add comment so others who
> are subscribed to comments is aware it has been disowned (You lost
> it).

Is there any style checker tool for PKGBUILD files? Something similar
to lint? If yes then it worth checking for style violations as well,
e.g. "PKGBUILD does not have package()" function. So bot can send a
note to owner and mark the package somehow e.g. "Needs improvements"
If no improvement has been done during some period then the package is
disowned.

Re: [aur-general] About orphaning all packages of inactive users

[Anatol Pomozov]

Hi

On Thu, Jul 18, 2013 at 2:24 PM, Alexander Rødseth  wrote:
> Hi,
>
>
> Some of these packages are out of date and some have better PKGBUILDs
> in the comments:
> https://aur.archlinux.org/packages/?K=phi&SeB=m
>
> Last activity from the user was over two years ago: 2011-03-17 (the
> brother-hl2030 package)
>
> The two packages that are out of date has not been updated for three years.
>
> My plan is to orphan all his packages if nobody thinks that's a
> horribly bad idea.

As an Arch/AUR user I completely support your idea.

It will make easier for users to adopt and keep improving the
packages. Some users feel shy to ask maillist about disowning others
packages. Other users think that waiting weeks (i.e. email
notification) for disowning is too long - they want to fix the package
right here and right now.

IMHO Arch developers should be more proactive in disowning de-facto
orphaned packages. Something like "if a package is marked out-of-date
for more than 3 months then it disowns automatically". Similar rule
can be applied to all packages of inactive users.

> I'm also interested in comments about what should be done for similar
> situations in the future. I assume most users would be happy just to
> see the pacakges being updated instead of hoarded and would think it
> was fine if TUs just orphan them after a similar investigation of the
> situation.
>
> --
> Sincerely,
>   Alexander Rødseth
>   xyproto / TU

Re: [aur-general] Please delete projects

[Anatol Pomozov]

Hi,

On Sun, Jul 14, 2013 at 4:12 PM, Connor Behan  wrote:
> On 14/07/13 02:09 PM, Anatol Pomozov wrote:
>> Hi,
>>
>> Please delete my AUR project that are not needed anymore
>>
>> https://aur.archlinux.org/packages/tarantool/ - tarantool-git should
>> be used (upstream priject uses weird git tagging policy)
>>
>> https://aur.archlinux.org/packages/tup-lua-git/ lua branch has been
>> merged into master and available in tup-git now.
>
> Deleted, thanks.

Thanks a lot!

[aur-general] Please delete projects

[Anatol Pomozov]

Hi,

Please delete my AUR project that are not needed anymore

https://aur.archlinux.org/packages/tarantool/ - tarantool-git should
be used (upstream priject uses weird git tagging policy)

https://aur.archlinux.org/packages/tup-lua-git/ lua branch has been
merged into master and available in tup-git now.

Re: [aur-general] Please orphan uefivars-git

[Anatol Pomozov]

Hi

On Thu, Jun 20, 2013 at 7:37 AM, Maxime Gauduin  wrote:
> On Thu, 2013-06-20 at 06:45 -0700, Anatol Pomozov wrote:
>> Hi,
>>
>> uefivars-git https://aur.archlinux.org/packages/uefivars-git/ installs
>> packages into /usr/sbin that is not recommended with the new pacman
>> standard. I notified current maintainer 3 weeks ago and provided
>> fiexed/cleaned PKGBUILD file. The maintainer never responded.
>>
>> Please orphan it. I would like to become the package maintainer, fix
>> the issues and keep supporting the package.
>
> Did you send an email? People can have AUR notifications turned off.
> Protocol is to send an email and wait for 2 weeks before a package can
> be disowned.

No I did not send a personal email. I see that he has several packages
that are out-of-date for several months already and though that he is
inactive.

OK I just sent him email.

BTW his another package https://aur.archlinux.org/packages/thinkalert/
is also broken (no package() function). There is solution in comments.

[aur-general] Please orphan uefivars-git

[Anatol Pomozov]

Hi,

uefivars-git https://aur.archlinux.org/packages/uefivars-git/ installs
packages into /usr/sbin that is not recommended with the new pacman
standard. I notified current maintainer 3 weeks ago and provided
fiexed/cleaned PKGBUILD file. The maintainer never responded.

Please orphan it. I would like to become the package maintainer, fix
the issues and keep supporting the package.

Re: [aur-general] Need some help debugging a package

[Anatol Pomozov]

Hi

On Thu, May 23, 2013 at 8:10 PM, GSC  wrote:
> https://aur.archlinux.org/packages/hadoop/
>
> some users experience failure with cp: cannot create directory
> ‘/usr/lib/hadoop-1.1.2’: Permission denied. when packaging, while the
> maintainer tested on a fresh vm and turns out fine.
>
> I tried to debug but didn' t find why.

I believe you cannot use $pkgdir outside of package() function. Move
the definitions into package()

_usr_lib=$pkgdir/usr/lib/
_hadoop_real_home=$_usr_lib/$pkgname-$pkgver
_hadoop_link_home=$_usr_lib/$pkgname


also suggestions:

- change compile() name to build()

- move "sed -i " into prepare() function.

- you don't need to call "ant clean". Cleaning will be done by "makepkg"


>
> Please someone check this package and figure out what' s going on.

Re: [aur-general] Disown (or update) coffee-script package

[Anatol Pomozov]

Hi

On Wed, May 15, 2013 at 3:44 AM, Bartłomiej Piotrowski  
wrote:
> On 2013-05-14 08:21, Anatol Pomozov wrote:
>> Hi,
>>
>> https://aur.archlinux.org/packages/coffee-script package is broken
>> since 4.1 release. There is an update provided in comments more than 2
>> weeks ago, but current maintainer did not respond.
>>
>> Please either update the package or disown it, so I can update/improve
>> the PKGBUILD script by myself.
>>
>
> Sounds like a serious business. Orphaned.

Thanks. Adopted. I am going to update the package after I test my local changes.

Re: [aur-general] Disown (or update) coffee-script package

[Anatol Pomozov]

Hi,

On Mon, May 13, 2013 at 11:21 PM, Anatol Pomozov
 wrote:
> Hi,
>
> https://aur.archlinux.org/packages/coffee-script package is broken
> since 4.1 release. There is an update provided in comments more than 2
> weeks ago, but current maintainer did not respond.
>
> Please either update the package or disown it, so I can update/improve
> the PKGBUILD script by myself.

Could anybody disown the coffee-script package? I would like to take
ownership and fix it. Thanks!

[aur-general] Disown (or update) coffee-script package

[Anatol Pomozov]

Hi,

https://aur.archlinux.org/packages/coffee-script package is broken
since 4.1 release. There is an update provided in comments more than 2
weeks ago, but current maintainer did not respond.

Please either update the package or disown it, so I can update/improve
the PKGBUILD script by myself.

[aur-general] Disown 'rethinkdb' aur package

[Anatol Pomozov]

Hi,

rethinkdb is a great alternative to mongodb. There is an aur package for it
https://aur.archlinux.org/packages/rethinkdb

Unfortunately it is out-of-date for almost 2 months now. The current
maintainer does not respond to upgrade requests.

Please disown the package, I would like to become its maintainer and keep
it improving.

Thanks.

[aur-general] Please merge "mruby" into "mruby-git"

[Anatol Pomozov]

Hi,

according to PKGBUILD guidelines I renamed "mruby" into "mruby-git".
The mruby{-git} package is build from git HEAD.

Could you please mere votes of mruby into the new mruby-git and remove
the old AUR package?

Re: [aur-general] Make AUR notifier messages more visible

[Anatol Pomozov]

Hi

On Mon, Apr 15, 2013 at 4:00 PM, canyonknight  wrote:
> On Mon, Apr 15, 2013 at 4:47 PM, Allen Li  wrote:
>> On Mon, Apr 15, 2013 at 09:08:52AM -0700, Anatol Pomozov wrote:
>>> Hi,
>>>
>>> On Mon, Apr 15, 2013 at 8:50 AM, Chris “Kwpolska” Warrick
>>> >
>>> > Just do a goddamn filter in Gmail.
>>>
>>> Yes I am aware of filters (I worked in Gmail UI team btw). I already
>>> have 300+ filters and I hate to add more, especially for one-time
>>> notifications.
>>>
>>> Forcing everyone to create a filter for aur notifications sounds wrong
>>> to me. Most people just will not do this. And I think "invisible"
>>> message by default + people's laziness to create filters is the reason
>>> why it is more difficult to get a package maintainer response via
>>> comments rather than via personal email.
>>>
>>> Most web sites (such as forums) known to me send notifications "to:"
>>> user exactly for this reason - make these messages visible by default.
>>
>> I personally don't have any objections either way, but is there a reason
>> *not* to send notifications directly to the user?  Sure, there are ways
>> around it (filters for Gmail) , but why make it an issue in the first
>> place?
>
> AUR notifications are sent as a single e-mail to all subscribed users
> to avoid having to send each and every subscriber a separate e-mail.
> They are sent as a BCC to avoid having every subscribed user e-mail
> address in the "To" field. I believe the Arch bugtracker works the
> same way, so it's not something completely unique to the AUR.

Filed a task in case if somebody wants to take care of it
https://bugs.archlinux.org/task/34843

Re: [aur-general] Make AUR notifier messages more visible

[Anatol Pomozov]

Hi,

On Mon, Apr 15, 2013 at 8:50 AM, Chris “Kwpolska” Warrick
 wrote:
> On Mon, Apr 15, 2013 at 5:47 PM, Anatol Pomozov
>  wrote:
>> Hi
>>
>> I found that AUR comment emails are too invisible in my mailbox. The
>> reason is that notifier sends messages to aur-not...@archlinux.org and
>> hides my email in "bcc". Thus email clients (e.g. gmail) do not mark
>> those emails with ">" symbol and they lost in miriads of similar
>> emails from maillists.
>>
>> It would be better if these emails were sent "to" user email as it
>> makes such emails more visible.
>
> Just do a goddamn filter in Gmail.

Yes I am aware of filters (I worked in Gmail UI team btw). I already
have 300+ filters and I hate to add more, especially for one-time
notifications.

Forcing everyone to create a filter for aur notifications sounds wrong
to me. Most people just will not do this. And I think "invisible"
message by default + people's laziness to create filters is the reason
why it is more difficult to get a package maintainer response via
comments rather than via personal email.

Most web sites (such as forums) known to me send notifications "to:"
user exactly for this reason - make these messages visible by default.

> more button above the message (the
> last one) → filter messages like these → create filter with this
> search (bottom RIGHT corner of the window) → pick your poison.  I
> suggest labels, they are very helpful when you have many mails.
>
> --
> Kwpolska <http://kwpolska.tk> | GPG KEY: 5EAAEA16
> stop html mail| always bottom-post
> http://asciiribbon.org| http://caliburn.nl/topposting.html

[aur-general] Make AUR notifier messages more visible

[Anatol Pomozov]

Hi

I found that AUR comment emails are too invisible in my mailbox. The
reason is that notifier sends messages to aur-not...@archlinux.org and
hides my email in "bcc". Thus email clients (e.g. gmail) do not mark
those emails with ">" symbol and they lost in miriads of similar
emails from maillists.

It would be better if these emails were sent "to" user email as it
makes such emails more visible.

Re: [aur-general] Please transfer ownership of codespell package

[Anatol Pomozov]

Hi,

On Wed, Apr 10, 2013 at 6:37 AM, Felix Yan  wrote:
> On Wednesday, April 10, 2013 06:35:14 Anatol Pomozov wrote:
>> Hi,
>>
>> Could you please transfer the codespell package ownership to me
>> (id=anatolik)? https://aur.archlinux.org/packages/codespell/
>>
>> This package is broken for more than a year since last package update.
>> And the current maintainer did not fix it. The package is de-facto
>> abandoned. I tried to contacted current maintainer of the package
>> several times (first time I did it was in Dec 2012) but he never
>> replied.
>>
>> I would like to fix the package and keep improving it. I already
>> maintain other AUR package (tup-git) and have patches to some other
>> packages.
>
> Disowned, please go take it :)

Thanks. Done.
>
> Felix Yan
> Twitter: @felixonmars

[aur-general] Please transfer ownership of codespell package

[Anatol Pomozov]

Hi,

Could you please transfer the codespell package ownership to me
(id=anatolik)? https://aur.archlinux.org/packages/codespell/

This package is broken for more than a year since last package update.
And the current maintainer did not fix it. The package is de-facto
abandoned. I tried to contacted current maintainer of the package
several times (first time I did it was in Dec 2012) but he never
replied.

I would like to fix the package and keep improving it. I already
maintain other AUR package (tup-git) and have patches to some other
packages.