On 6/16/2015 6:00 PM, Joost Bremmer wrote:
> Just init a fresh repo, then add your packages and run: git subtree
> add -P stenc aur:/stenc.git master Note that you'll have to make a
> bogus first commit (for git rev-parse as I understand it), just an
> empty README.md will do, you can even remove i
Not sure why exactly I had it using a subtree pull ( ) rather
than add, but I did fix this.
-- Eli Schwartz
.
On 17 June 2015 at 09:00, Joost Bremmer wrote:
> Just init a fresh repo, then add your packages and run:
>
> git subtree add -P stenc aur:/stenc.git master
That looks like the command I've been missing this whole time Thanks! :)
I have 50-odd packages, but a quick bash loop makes it less pain
On 16 June 2015 at 14:44, Phillip Smith wrote:
> On 16 June 2015 at 14:26, Eli Schwartz wrote:
> >
> > FWIW you can use filter-branch to run mksrcinfo on each folder in your
> > current aur-packages repo, then merge in my base branch and continue on
> as
> > before. Might have to resolve a confl
On 16 June 2015 at 14:26, Eli Schwartz wrote:
>
> FWIW you can use filter-branch to run mksrcinfo on each folder in your
> current aur-packages repo, then merge in my base branch and continue on as
> before. Might have to resolve a conflict between our .gitignores, (I may be
> biased but I prefer
On Mon, Jun 15, 2015 at 1:18 AM, Phillip Smith wrote:
> Rght! Gotcha! That makes a lot more sense -- I was assuming there
> was something required within the "umbrella" repo to setup/configure
> the child repos etc.
> Thanks, I'll go have a play :)
>
On the advice of Marcel Korpel I have fix
On 15 June 2015 at 15:25, Eli Schwartz wrote:
> Like I said, you should be able to pretend it is one vanilla repo,
> just like many people used to track their AUR3 packages. But .SRCINFO
> is required for this one, because each folder is *exported* to the
> AUR4.
Rght! Gotcha! That makes a lo
On 6/14/15, Phillip Smith wrote:
> I'm not seeing how that sets up subtrees? The only subtree command in
> the script is a "push" command.
subtrees are actually part of the repository. They are dynamically
created as needed (, which is why I added an option to split and
rejoin/save it to save tim
On 12 June 2015 at 12:54, Eli Schwartz wrote:
>
> Use the `./aurpublish` script. It controls everything. Today I added a
> "speedup" option to save the subtree (it duplicates all those commits
> though).
>
> My goal is that *everything* should be abstracted and just leave you with a
> simple repo
On Fri, Jun 12, 2015 at 8:01 AM, David Kaylor wrote:
> I just tweaked the language in the wiki a bit.
>
> My point is that if one of the objectives is to force more discipline among
> maintainers going forward, then there is no reason to hide that fact. I
> suspect it would be more accurate to sa
On Fri, Jun 12, 2015 at 4:34 AM, Lukas Fleischer
wrote:
> On Fri, 12 Jun 2015 at 01:42:41, Eli Schwartz wrote:
> > [...]
> > That still requires packagers to go through several new hoops.
> > [...]
>
> Which ones? Can't think of any apart from generating the key and adding
> it to the web interfa
On Fri, Jun 12, 2015 at 8:22 AM, Lukas Fleischer
wrote:
>
> "Culling the herd" (using your words, even though I dislike that
> metaphor) is something that always happens when you introduce a new
> system. Users need time to get used to it, some of them back out. Just
> to clarify: We don't want t
On Fri, 12 Jun 2015 at 12:42:30, David Kaylor wrote:
> On Fri, Jun 12, 2015 at 5:34 AM, Lukas Fleischer
> wrote:
> [...]
> > It is expected (and intended) that some (hopefully not too many) AUR
> > package maintainers back out due to the new system. It is also intended
> > that a huge number of pa
On Fri, Jun 12, 2015 at 5:34 AM, Lukas Fleischer
wrote:
>
> No. It also does not register a new AUR account or setup your Internet
> connection. It submits packages to the AUR. As I said before, generating
> and adding the key is a tiny one-time process and automating it doesn't
> pay off.
>
Agr
On Fri, 12 Jun 2015 at 01:42:41, Eli Schwartz wrote:
> [...]
> That still requires packagers to go through several new hoops.
> [...]
Which ones? Can't think of any apart from generating the key and adding
it to the web interface. It literally takes ~1 minute. You need to do
the same thing after c
On Thu, Jun 11, 2015 at 10:54 PM, Eli Schwartz
wrote:
>
>
> Use the `./aurpublish` script. It controls everything. Today I added a
> "speedup" option to save the subtree (it duplicates all those commits
> though).
>
> My goal is that *everything* should be abstracted and just leave you with a
> s
On Thu, Jun 11, 2015 at 9:28 PM, Phillip Smith wrote:
> I have already seen your work (thanks by the way, those hooks look
> great), but unless I'm missing something there, there's nothing to
> help me understand how to use subtrees etc in this scenario.
>
> I have Googled and read various blogs,
On Thu, Jun 11, 2015 at 10:03 PM, Eli Schwartz wrote:
> On Thu, Jun 11, 2015 at 8:44 PM, David Kaylor wrote:
>
>> I have so few packages to maintain, the burden to me is very low. And I'm
>> just taking it as oppurtunity to finally learn to use Git. But a tool for
>> submitting a tarball and havi
On Thu, Jun 11, 2015 at 10:03 PM, Eli Schwartz
wrote:
>
> Well, sure, git is fun. :)
>
> But tarball uploads means maintainers wouldn't have to go through any more
> hoops than they do already. Primarily, I am wondering what people who
> refuse to learn git *just* to contribute to the AUR might t
On 11 June 2015 at 14:49, Eli Schwartz wrote:
> Well, I have explained how I set it up in my personal repo at
> https://github.com/eli-schwartz/pkgbuilds/ and in a previous discussion on
> this mailing list. [1]
>
> I cannot promise to be simple enough for a 5-year-old, but I can try. :o
> I do th
On Thu, Jun 11, 2015 at 8:44 PM, David Kaylor wrote:
> I have so few packages to maintain, the burden to me is very low. And I'm
> just taking it as oppurtunity to finally learn to use Git. But a tool for
> submitting a tarball and having AUR4 do the conversion is a good one. Might
> help prreven
On Thu, Jun 11, 2015 at 7:42 PM, Eli Schwartz wrote:
>
> That still requires packagers to go through several new hoops.
>
> And I can see the benefit of allowing tarball uploads for the same reason
> that the AUR3 included a web interface for adding new packages (rather than
> having a hard requi
On Thu, Jun 11, 2015 at 4:01 PM, Lukas Fleischer
wrote:
> I am against adding anything that involves uploading a tarball. I am not
> averse to including a set of utilities to help with working with to AUR
> to [community], though (as long as there isn't anything similar to a
> package manager for
On Thu, 11 Jun 2015 at 21:39:52, Florian Bruhin wrote:
> * Joakim Hernberg [2015-06-11 21:03:50 +0200]:
> > On Thu, 11 Jun 2015 13:36:54 -0500
> > Eli Schwartz wrote:
> [...]
> > > The suggestion was made that perhaps a tarball upload could be added
> > > which would create automatic commits to t
* Joakim Hernberg [2015-06-11 21:03:50 +0200]:
> On Thu, 11 Jun 2015 13:36:54 -0500
> Eli Schwartz wrote:
>
> > On Thu, Jun 11, 2015 at 12:04 AM, David Kaylor
> > wrote:
> >
> > > How about a simpleton who has never pushed, pulled, or committed at
> > > all?
>
> > IIRC there was some discussi
On Thu, 11 Jun 2015 13:36:54 -0500
Eli Schwartz wrote:
> On Thu, Jun 11, 2015 at 12:04 AM, David Kaylor
> wrote:
>
> > How about a simpleton who has never pushed, pulled, or committed at
> > all?
> IIRC there was some discussion about this originally, and someone
> suggested that maintainers m
On Thu, Jun 11, 2015 at 12:04 AM, David Kaylor wrote:
> How about a simpleton who has never pushed, pulled, or committed at all? I
> maintain only two packages, both very simplistic, and not updated upstream
> very often. So a git repository of my PKGBUILDS was not something I thought
> was neces
On Thu, Jun 11, 2015 at 12:19 AM, Phillip Smith wrote:
> Has anyone written an ELI5 document for us simpletons who only know how to
> push, pull and commit, but would still like to be able to have a single
> repository of PKGBUILD's we are responsible for?
>
How about a simpleton who has never
On Wed, Jun 10, 2015 at 11:19 PM, Phillip Smith wrote:
> Has anyone written an ELI5 document for us simpletons who only know how to
> push, pull and commit, but would still like to be able to have a single
> repository of PKGBUILD's we are responsible for?
>
Well, I have explained how I set it u
Has anyone written an ELI5 document for us simpletons who only know how to
push, pull and commit, but would still like to be able to have a single
repository of PKGBUILD's we are responsible for?
30 matches
Mail list logo
