Dear All,

Sorry for the long delay, but I was busy switching from legacy (rpmbuild)
to modern (fedpkg) Fedora packaging tools and it took me some time to get
used to them.

I sketched a simple, yet workable mrxvt.desktop shortcut, which should go
to /usr/share/applications. I'm assuming that in the source directory it's
simply ./share/applications/. My problem is that I don't know which of the
many Makefile.am and other files should contain information on how to add
additional files during the "make install" process. I can do it via
Fedora's tools, but then the "upstream" (as in, you ;)) would not get those
changes :(.

*For now I'm simply attaching the .desktop file.*
Also, the configure.ac file mentions a lot of different UNIX architectures
that are perhaps obsolete or even dead. If it's fine with you, I'll prune
the configure.ac file to remove that "needless clutter".

Best of luck!
Andy Mender

On 11 September 2016 at 22:44, Andy Mender <andymenderu...@gmail.com> wrote:

> Good Evening,
>
> Yes, I think I remember that in one of your former e-mails you mentioned
> GitLab,
> though then I assumed it was idea not a concrete plan ;). Sorry!
>
> I'll remember about "git format-patch origin/master" as well and will
> deliver the patches that way.
>
> Of course I need to read about autotools a bit more, too! ;)
>
> Right now my plan is to deliver mrxvt to Fedora. The Arch Linux PKGBUILD
> was simple and worked,
> but Fedora has possibly a bigger user base so more potential users and
> testers of mrxvt.
>
> Hope for the best!
>
> Best regards,
> Andy
>
> On 11 September 2016 at 20:22, Jehan <je...@zemarmot.net> wrote:
>
>> Le 2016-09-11 19:42, Andy Mender a écrit :
>>
>>> Hello,
>>>
>>> Ah, I didn't know one has to bootstrap the build area first. As you
>>> said, running "./bootstrap.sh" solved the problem.
>>> I tested everything locally (within the repository) and generated an
>>> Arch Linux PKGBUILD. Both worked.
>>>
>>> Finally, I tested "make distcheck". I like this automatic tarball
>>> generation. Is this a standard practice or something you deviced?
>>>
>>
>> Pure standard. This is not even a "practice" but a default feature which
>> comes along with the autotools (you don't have to do anything, we have no
>> code for this in mrxvt. Just using the autotools gives the feature).
>>
>> Usually, when I download projects as tarballs, the standard procedure
>>> of "./configure && make && make install" applies.
>>> Is that because they were built for distribution via "make checkdist"?
>>>
>>
>> Usually it should be. This is the proper procedure. Yet in reality many
>> developer are not aware of the full autotools process and will either
>> generate the configure and other build scripts before making a tarball, or
>> indeed save these in the repository along the source.
>> But yeah, when you do it well, that's how things are done. :-)
>>
>> Finally, I added the .desktop file locally and some minor improvements
>>> to the README. I think the procedure you explained to me could be
>>> added to the git README.md so that users are instantly aware of how to
>>> deal with the files they download from you. How would we make
>>> the addition of my commits more flexible? For now I only know how to
>>> "git push" and "git pull". Maybe a secondary "staging" branch to
>>> which I could commit and push would be useful? That could be later
>>> merged back to the master branch after reviewing the commits by you
>>> :).
>>>
>>
>> The proper procedure is that you do some local commits, then run:
>>
>> $ git format-patch origin/master
>>
>> It will generate as many patch files as you have new commits. Just sent
>> them.
>> By the way, did you see the other email? We are going to move to gitlab
>> finally. But that won't change much for you. You don't have to clone a new
>> repo. I'll explain later when we are 100% sure. Just work with the github
>> repo for now. :-)
>>
>> Jehan
>>
>> Best regards,
>>> Andy
>>>
>>> On 11 September 2016 at 13:13, Jehan <je...@zemarmot.net> wrote:
>>>
>>> Hi Andy,
>>>>
>>>> Le 2016-09-11 10:33, Andy Mender a écrit :
>>>>
>>>> Hello,
>>>>>
>>>>> So I cloned the new git repository and started working on the
>>>>> files
>>>>> locally.
>>>>> Thus far I added the optional depends to the README and generated
>>>>> a
>>>>> .patch file.
>>>>>
>>>>> However, there are some major differences between the last
>>>>> tarball
>>>>> from Sourceforge
>>>>>
>>>>> and the content of the git repository. For instance, the
>>>>> "configure"
>>>>> script is missing
>>>>>
>>>>> entirely.
>>>>>
>>>>
>>>> This is normal. The configure script is a generated file. Run
>>>> `./bootstrap` to create configure and all other necessary files from
>>>> the build system.
>>>>
>>>> Any ideas? :(
>>>>>
>>>>> I managed to circumvent the need for a tarball for my purposes,
>>>>> but
>>>>> there are those
>>>>>
>>>>
>>>> Actually creating a tarball directly from the source is not the
>>>> right way (and for this specific reason, tarballs automatically
>>>> created by github are wrong. Even though they are OK for developers,
>>>> they are not right for final delivery). The right way is running
>>>> (after a normal build) the command:
>>>>
>>>> $ make distcheck
>>>>
>>>> This not only makes a tarball adding all the necessary build files
>>>> (like configure), but even test it by uncompressing it and building
>>>> from the new files to make sure nothing is forgotten. Finally it
>>>> runs a `make check` by itself with any unit test a project may have
>>>> (note that I don't think we have any in the case of mrxvt).
>>>>
>>>> differences that prevent me from doing a local "configure make
>>>>> make
>>>>> install" chain.
>>>>>
>>>>
>>>> So I summarize, run:
>>>>
>>>> $ ./bootstrap
>>>> $ ./configure [--with --whatever --options]
>>>> $ make && make install
>>>> Test if all looks ok.
>>>> $ make distcheck
>>>> You will find a tarball named "mrxvt-0.5.5.tar.gz" in your
>>>> directory. If the `make distcheck` ended as a success, it means
>>>> mrxvt extracted from this tarball at least compiles fine and is
>>>> ready for release.
>>>>
>>>> Have fun!
>>>>
>>>> Jehan
>>>>
>>>> Best regards,
>>>>
>>>> Andy
>>>>
>>>> On 10 September 2016 at 14:38, Jehan <je...@zemarmot.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Le 2016-09-09 15:12, Andy Mender a écrit :
>>>>
>>>> Greetings,
>>>>
>>>> Truth be told, I received your e-mail some time after issuing
>>>> mine. In
>>>> fact, together with the digest.
>>>> Sorry about that!
>>>>
>>>> So that we're both on the same page, I will fork your repository
>>>> (fork
>>>> to my GitHub account or simply clone it locally?)
>>>> and work with your files not to duplicate things. Then as you
>>>> suggested, issue pull requests.
>>>>
>>>> You can do whatever you want. The usual github logic is indeed
>>>> "forking", working on your fork and making a "pull request". I
>>>> think
>>>> this is messy and a terrible usage of git, but that's what github
>>>> pushes people to do so I will obviously accept this.
>>>>
>>>> The simpler way is just a locale clone, then generating forks as
>>>> patches (use `git format-patch origin/master`, which creates as
>>>> many
>>>> well-formatted patches as commits in a single command), which you
>>>> can simply send us. I will obviously accept this as well.
>>>>
>>>> I understand the thing with tarballs. I know I should not put them
>>>> to
>>>> a git repo and I will not do so from now on.
>>>> I figured out a way of building a package for Arch Linux without
>>>> a
>>>> need for the tarball, which I think is much cleaner anyhow.
>>>>
>>>> I don't know how Arch Linux packages are done. And I am not telling
>>>> you necessarily not to have tarballs. I can't say what's best for
>>>> your use case. I'm just saying that tarballs should not be in the
>>>> *source* repository. ;-)
>>>>
>>>> We can have release tarballs in a download area. And as I was
>>>> saying, github even automatically generate tarballs when you tag
>>>> your tree. See mrxvt auto-generated release tarballs:
>>>> https://github.com/Jehan/mrxvt/releases [1] [1]
>>>>
>>>>
>>>> I will update the README and include a .desktop file accordingly.
>>>> It's
>>>> fine if both of those are in the build directory, right?
>>>>
>>>> Yes, .desktop files are often in root in most projects, though I
>>>> see we have a share/ directory in mrxvt. In this case, it probably
>>>> makes more sense to add it under share/.
>>>>
>>>> The .desktop file would be added together with the rest of the
>>>> files
>>>> through "make install".
>>>>
>>>> Obviously. You are welcome to update share/Makefile.am for this.
>>>>
>>>> Per my repository, I think I will rename it, restructure it and
>>>> use it
>>>> for hosting PKGBUILDs before they officially go to AUR.
>>>>
>>>> Very good idea.
>>>>
>>>> Nothing more.
>>>>
>>>> I think that's all for now :).
>>>>
>>>> Perfect. We've got a plan! :-)
>>>>
>>>> Jehan
>>>>
>>>> Best regards,
>>>> Andy
>>>>
>>>> On 9 September 2016 at 14:54, Jehan <je...@zemarmot.net> wrote:
>>>>
>>>> Hi Andy,
>>>>
>>>> Le 2016-09-09 14:23, Andy Mender a écrit :
>>>>
>>>> Hello,
>>>>
>>>> I was successful in building an mrxvt package for Arch Linux. If
>>>> it's
>>>> OK,
>>>> I would like to submit it to the Arch User Repository (AUR). To
>>>> that
>>>> end I would also like
>>>> to add a .desktop file to the tarball as many desktops and window
>>>> managers use them.
>>>>
>>>> Haven't you received my next email where I explained I created a
>>>> proper git repository with the while history from our subversion
>>>> repo (i.e. each SVN commit is now a git commit, and releases are
>>>> now
>>>> git tags, and the branches are there too)?
>>>> Please make a "fork" of this repository and make pull requests from
>>>> there: https://github.com/Jehan/mrxvt [2] [2] [1]
>>>>
>>>> Yes we would definitely welcome a .desktop file. :-)
>>>>
>>>> I would then upload the modified tarball to the git repository I
>>>> created thus far.
>>>>
>>>> I don't understand. Why do you save tarballs in the repository? As
>>>> I said earlier, you should not do this. A source repository is
>>>> there
>>>> only to save sources. Tarballs should be saved in a download area.
>>>> By the way, github creates tarball automatically for projects from
>>>> tags. So uploading tarball is actually not even necessary at all.
>>>>
>>>> I also need to know what are the depends and build-depends of
>>>> mrxvt. I
>>>> haven't seen
>>>>
>>>> this anywhere in the README. Should I assume they're the same as
>>>> those
>>>> of rxvt?
>>>>
>>>> You should be able to get the list of dependency by investigating
>>>> the contents of the configure.ac [3] [3] [2].
>>>>
>>>>
>>>> Then we would welcome a pull request to update README with your
>>>> findings. :-)
>>>>
>>>> Of course, I can also do it, but I cannot promise to do it in a
>>>> timely manner.
>>>>
>>>> Are the above points OK with you? :)
>>>>
>>>> Yes, for .desktop file and README update. But please work from my
>>>> mrxvt git repository for now.
>>>> Thanks!
>>>>
>>>> Jehan
>>>>
>>>> Best regards,
>>>>
>>>> Andy Mender
>>>>
>>>> On 9 September 2016 at 07:02, Andy Mender
>>>> <andymenderu...@gmail.com>
>>>> wrote:
>>>>
>>>> Greetings,
>>>>
>>>> 1. I'm sorry for instantly creating a git repository from all of
>>>> the
>>>> files. I am still new to git
>>>> and I'm not 100% accustomed to creating PKGBUILDs out of git
>>>> repositories.
>>>>
>>>> 2. I have nothing against SourceForge or SVN. I used the latter
>>>> shortly for getting FreeBSD
>>>> kernel source tree snapshots.
>>>>
>>>> 3. I would be very happy if you could help me out with migrating
>>>> the
>>>> project from SVN to git.
>>>> From the link you attached I read that it's not trivial.
>>>>
>>>> 4. For now, I cleaned up the entire repository and moved both the
>>>> patch file and tarball
>>>> to a separate directory so that I can still build the PKGBUILD for
>>>> Arch Linux.
>>>>
>>>> I'm awaiting your further assistance ;).
>>>>
>>>> Best regards,
>>>> Andy Mender
>>>>
>>>> On 9 September 2016 at 01:12, Jehan <je...@zemarmot.net> wrote:
>>>> Hi Andy,
>>>>
>>>> Le 2016-09-08 23:29, Andy Mender a écrit :
>>>> Thank you kindly for your response. I set myself a git repository
>>>> on
>>>> GitHub at: https://github.com/AndyMender/mrxvt [4] [4] [3] [1] [1]
>>>>
>>>>
>>>> Please if the goal is actually to take maintainership of the
>>>> project, you should keep its history pristine. So the git commit
>>>> must reflect the SVN commits. Also the SVN branches should be moved
>>>> as git branches. Same for tags.
>>>> See:
>>>>
>>>
>>> https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
>>> [7]
>>>  [7]
>>>
>>> [4]
>>>>
>>>> [2]
>>>>
>>>> If something is not in order, please do let me know. I still have
>>>> much
>>>>
>>>> to learn in terms of GIT usage. Meanwhile, I shall proceed with
>>>> building
>>>> the AUR package(s).
>>>>
>>>> Best regards,
>>>> Andy Mender
>>>>
>>>> On 8 September 2016 at 15:30, <gi1...@gmail.com> wrote:
>>>>
>>>> On Thu, Sep 08, 2016 at 03:13:12PM +0200, Andy Mender wrote:
>>>>
>>>> I am in the process of preparing a PKGBUILD for Arch Linux to add
>>>> mrxvt to AUR. I noticed that active development of this terminal
>>>> emulator has somewhat ceased. Would it be possible for me to join
>>>> development or fork the project to a git repository? I am far
>>>> more
>>>> familiar with git than with SourceForge.
>>>>
>>>> That's Free Software, so there is no need to ask for forking.
>>>> Though
>>>> it's always cool to say it of course. ;-)
>>>> But if you mean rather to do a rebirth of the project (i.e.
>>>> keeping
>>>> the name and simply moving the upstream to a new repository), then
>>>> that's worth discussing.
>>>> I am in favor to say that we should see after a few commits at
>>>> least,
>>>> and then if it looks like you are really giving a second life to
>>>> mrxvt, we should go for it and officially give maintainership.
>>>>
>>>> Dear Andy,
>>>>
>>>> I use mrxvt as my only terminal emulator on about 5 different
>>>> systems
>>>> (all Debian). I've also completely run out of free time, so I
>>>> will
>>>> only
>>>> ever fix bugs that affect me!
>>>>
>>>> I would love it if we moved from SVN to git! Sourceforge has git,
>>>> so we
>>>> needn't move away from SourceForge. But can move if the person
>>>> doing the
>>>> work chooses.
>>>>
>>>
>>>     I would prefer not staying on Sourceforge after the unfortunate
>>>    events which happened (even though it changed ownership since
>>> then).
>>>    Anyway I see that you chose Github above.
>>>
>>> If you want admin access so you can udpate the website / tracker
>>>>> let me
>>>>> know. (I think Jehan volunteered to move everything to GitLab
>>>>> sometime ago but he ran out of time as well...).
>>>>>
>>>>
>>>     Yes I am very sorry for this. I really wanted to keep hacking
>>>  mrxvt,
>>>    and really wanted to finish someday my work rather than keeping
>>> this
>>>    unfinished feeling. But now I see that I don't think I can make the
>>>    time for this anymore. It is not my main priority nowadays.
>>>
>>>     So it is better if someone takes the baby from us.
>>>
>>>     Since you seem a little unfamiliar with all git arcanes, I can at
>>>    least take the time to rewrite the history into a git repository on
>>>    github, then you can simply "fork" from it. Would you want this?
>>> But
>>>    please don't work from a broken history. It just won't do it!
>>>
>>>     Also why did you add release tarball and patch files directly into
>>>    the tree root?
>>>     I see also you have committed a lot of generated files. Do not
>>>   commit
>>>    generated files (sometimes there are acceptable reasons for some
>>>    generated files, but here this is not the case for all the build
>>>   files
>>>    you added).
>>>
>>>     If you could please fix all these issues first? :-)
>>>     Thanks.
>>>
>>>     Jehan
>>>
>>> GI
>>>>>
>>>>
>> --
>> Que la Sainte Marmotte soit avec moi!
>> Pour me contacter:
>> IM: je...@zemarmot.net
>> email: je...@zemarmot.net
>> http://girinstud.io
>> http://film.zemarmot.net
>> Patreon: https://patreon.com/zemarmot
>> Tipeee: https://www.tipeee.com/zemarmot
>>
>>
>

Attachment: mrxvt.desktop
Description: application/desktop

------------------------------------------------------------------------------
_______________________________________________
Materm-devel mailing list
Materm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/materm-devel
mrxvt home page: http://materm.sourceforge.net

Reply via email to