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