Dear Co-developers,

> Ok I'll take care of it. Thanks for the desktop file.
> For the commit name and email, I will use: Andy Mender <
andymenderu...@gmail.com>
> That's ok?

Yes, that's the official email I use per any development work (blog, git,
etc.).

> It would be interesting to have an appdata as well so that mrxvt can
appear in GNOME software (or other software center following the appdata
> spec). ;-)

I completely forgot about this! Yes, an appdata spec would be very useful
to my fellow Fedora folks, some of whom use GNOME. I'll see how can get to
this :).


> I guess I'll see what sort of cleaning you are proposing exactly, but
since I'm not sure what you refer to, I cannot promise I will include your
patch > there. mrxvt was meant as a light-weight terminal emulator,
therefore running on all sort of (maybe outdated, but possibly still out
there)
> machines.

> So even though I am using quite a typical x86-64 Linux desktop, I'm not
sure we will want to clean out anything which would have been meant for >
"obsolete architectures".
> Now maybe that's not what you meant.

By "cleaning" I meant removing support for additional legacy architectures
mentioned in configure.ac. However, I agree they should probably be kept as
used by at least some people. In the end, it's just a "cost" of several
additional lines of code, nothing major.

I was also thinking when could we consider adding unicode support to mrxvt.
This was planned at some point, correct? urxvt-unicode already has it so
the code is out there already :).

Best regards,
Andy Mender

On 18 September 2016 at 21:53, Jehan <je...@zemarmot.net> wrote:

> Hi,
>
> Le 2016-09-18 21:32, Andy Mender a écrit :
>
>> 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.
>>
>
> Ok I'll take care of it. Thanks for the desktop file.
> For the commit name and email, I will use: Andy Mender <
> andymenderu...@gmail.com>
> That's ok?
>
> It would be interesting to have an appdata as well so that mrxvt can
> appear in GNOME software (or other software center following the appdata
> spec). ;-)
>
> Also, the configure.ac [3] 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 [3] file to remove that
>> "needless clutter".
>>
>
> I guess I'll see what sort of cleaning you are proposing exactly, but
> since I'm not sure what you refer to, I cannot promise I will include your
> patch there. mrxvt was meant as a light-weight terminal emulator, therefore
> running on all sort of (maybe outdated, but possibly still out there)
> machines.
>
> So even though I am using quite a typical x86-64 Linux desktop, I'm not
> sure we will want to clean out anything which would have been meant for
> "obsolete architectures".
> Now maybe that's not what you meant.
>
> Jehan
>
> 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] [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] [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] [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] [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
>> [5]
>>
>>  [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 [6]
>>  http://film.zemarmot.net [7]
>>  Patreon: https://patreon.com/zemarmot [8]
>>  Tipeee: https://www.tipeee.com/zemarmot [9]
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/Jehan/mrxvt/releases
>> [2] https://github.com/Jehan/mrxvt
>> [3] http://configure.ac
>> [4] https://github.com/AndyMender/mrxvt
>> [5] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
>> [6] http://girinstud.io
>> [7] http://film.zemarmot.net
>> [8] https://patreon.com/zemarmot
>> [9] https://www.tipeee.com/zemarmot
>>
>
> --
> 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
>
------------------------------------------------------------------------------
_______________________________________________
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