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 no longer exists. What's the url to the new repository? Is it on GitLab?
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. 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 [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-Migrati >>> ng-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
