Dear Jehan,

I input the new url to my PKGBUILD. It builds perfectly fine as before.
Thanks for the update! ;)
I will see whether it's possible to promote the project a bit and submit it
properly to AUR. I would like people to recognize your hard work. Is that
OK?

Best regards,
Andy

On 19 September 2016 at 23:00, Jehan <je...@zemarmot.net> wrote:

> Hi,
>
> Le 2016-09-19 22:47, Andy Mender a écrit :
>
>> Dear Developers,
>>
>> Due to Fedora's quite clunky development process I went back to
>> Manjaro/Arch Linux as producing PKGBUILDs is just way simpler.
>> I wanted to test a new, cleaned up build and noticed that
>> https://github.com/Jehan/mrxvt.git [6] no longer exists. What's the
>> url to the new repository? Is it on GitLab?
>>
>
> Yes, that was in an earlier discussion. I decided to try out gitlab
> instead and I remove the github repo to make sure there is no
> misunderstanding.
> So that's the right repo: https://gitlab.com/Jehan_ZeMarmot/mrxvt
>
> And now it won't change (well until we get someone who can take over as
> new upstream).
> Sorry for the small hiccup.
>
> Jehan
>
> Best regards,
>> Andy
>>
>> On 18 September 2016 at 21:55, Andy Mender <andymenderu...@gmail.com>
>> wrote:
>>
>> 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 [1]. 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 [1] [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 [1] [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 [2] [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 [3] [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 [1] [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] [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]
>>> [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 [7] [6]
>>   http://film.zemarmot.net [8] [7]
>>   Patreon: https://patreon.com/zemarmot [9] [8]
>>   Tipeee: https://www.tipeee.com/zemarmot [10] [9]
>>
>>  Links:
>>  ------
>>  [1] https://github.com/Jehan/mrxvt/releases [2]
>>  [2] https://github.com/Jehan/mrxvt [3]
>>  [3] http://configure.ac [1]
>>  [4] https://github.com/AndyMender/mrxvt [4]
>>  [5]
>> https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
>> [5]
>>  [6] http://girinstud.io [7]
>>  [7] http://film.zemarmot.net [8]
>>  [8] https://patreon.com/zemarmot [9]
>>  [9] https://www.tipeee.com/zemarmot [10]
>>
>>  --
>>  Que la Sainte Marmotte soit avec moi!
>>  Pour me contacter:
>>  IM: je...@zemarmot.net
>>  email: je...@zemarmot.net
>>  http://girinstud.io [7]
>>  http://film.zemarmot.net [8]
>>  Patreon: https://patreon.com/zemarmot [9]
>>  Tipeee: https://www.tipeee.com/zemarmot [10]
>>
>>
>>
>> Links:
>> ------
>> [1] http://configure.ac
>> [2] https://github.com/Jehan/mrxvt/releases
>> [3] https://github.com/Jehan/mrxvt
>> [4] https://github.com/AndyMender/mrxvt
>> [5] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git
>> [6] https://github.com/Jehan/mrxvt.git
>> [7] http://girinstud.io
>> [8] http://film.zemarmot.net
>> [9] https://patreon.com/zemarmot
>> [10] 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