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
