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 > >
------------------------------------------------------------------------------
_______________________________________________ Materm-devel mailing list Materm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/materm-devel mrxvt home page: http://materm.sourceforge.net
