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
