You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
2006 |
Jan
(33) |
Feb
(65) |
Mar
(54) |
Apr
(59) |
May
(42) |
Jun
(25) |
Jul
(85) |
Aug
(67) |
Sep
(61) |
Oct
(52) |
Nov
(16) |
Dec
(12) |
2007 |
Jan
(28) |
Feb
(16) |
Mar
(20) |
Apr
(2) |
May
(17) |
Jun
|
Jul
(18) |
Aug
(16) |
Sep
(13) |
Oct
(21) |
Nov
(5) |
Dec
(27) |
2008 |
Jan
(12) |
Feb
(14) |
Mar
(17) |
Apr
(6) |
May
(30) |
Jun
(34) |
Jul
(31) |
Aug
(65) |
Sep
(3) |
Oct
(62) |
Nov
(15) |
Dec
(3) |
2009 |
Jan
(17) |
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2010 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(15) |
Jun
(24) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(32) |
Oct
|
Nov
|
Dec
|
From: Jim D. <Jim...@ac...> - 2016-09-20 21:41:57
|
On Mon, Sep 19, 2016 at 23:19 (+0200), Jehan wrote: > Hi, > Le 2016-09-18 22:56, Jim Diamond a écrit : >> Hi, >> I used to use materm and liked it a lot, but eventually the lack of >> UTF support made it unusable for me. >> IIRC the current effort is heading in that direction, and that is >> great. > I just want to make things clear: as far as I know (i.e. unless someone else > is working on a local branch and not merging), there is no "current effort". My mistake. I thought I saw a message indicating that someone was going to pick up the ball and run with it, but I may have mixed up this and another project whose mailing list I receive. Mea culpa. (Induced by wishful thinking.) Jim |
From: Jehan <je...@ze...> - 2016-09-20 01:44:09
|
Hi all! So for those who followed previous threads, here is the summary: the repository has been converted to a git repository and is now hosted on gitlab at: https://gitlab.com/Jehan_ZeMarmot/mrxvt So this is to be considered as the new upstream for the code. GI is still maintainer there (role "master" on gitlab) with me. I can give commit rights to anyone who already had these on subversion, and in particular, I will also give maintainer rights to Jimmy if you ask (just give me a gitlab account name). Personally my goal is only to revive it enough for someone to take over it. And I felt in previous emails that GI and Jimmy feel the same. I'd like that if you wish to be the new maintainer, you should send a few patches first though. I will gladly review patches in the meantime. I made a small post about this, just to raise some awareness: http://girinstud.io/news/2016/09/mrxvt-looking-for-maintainers/ See you! Jehan P.S.: GI, could we change this small text there (http://materm.sourceforge.net/) to redirect to the gitlab repo? Of course, we can still keep a link to the old read-only wiki, but I feel it should not be the main link anymore. Same here: https://sourceforge.net/projects/materm/ Thanks! -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Andy M. <and...@gm...> - 2016-09-19 21:12:28
|
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...@ze...> 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 <and...@gm...> >> 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 >>>> >>> <and...@gm...> >>> >>>> 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...@ze...> 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 >>> <and...@gm...> >>> 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 >>> <and...@gm...> >>> 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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >>> <and...@gm...> >>> 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...@ze...> 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, <gi...@gm...> 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...@ze... >> email: je...@ze... >> 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...@ze... >> email: je...@ze... >> 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...@ze... > email: je...@ze... > http://girinstud.io > http://film.zemarmot.net > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > |
From: Jehan <je...@ze...> - 2016-09-19 21:11:42
|
Hi, Le 2016-09-18 22:56, Jim Diamond a écrit : > Hi, > > I used to use materm and liked it a lot, but eventually the lack of > UTF support made it unusable for me. > > IIRC the current effort is heading in that direction, and that is > great. I just want to make things clear: as far as I know (i.e. unless someone else is working on a local branch and not merging), there is no "current effort". There was an effort, indeed by myself, to have actual support for UTF-* (or to be more accurate to be any-encoding-friendly). But this effort strike is long gone. Since then, I went on a years-long wandering around the world and had to stop active contributions to FLOSS. Now I started again, but mrxvt is not my priority project anymore. And I have to be clear: since for me as well, UTF-8 is mandatory (as I said, year-long wandering. In the meantime, I lived in Japan, Korea and crossed many other countries), I don't use mrxvt as my main terminal anymore either. I'd love to, and I'd love to have the time to work on better encoding support again, but I just can't make the time. I'm not even sure of the quality of my code on this UTF-8 branch anymore. That was years ago, and the first thing I'd do if I were to work on this again would be to check what I had been doing and where I was hoping to go with this. So don't hold your breath waiting for UTF support. That's what I want to say. Now I keep love for mrxvt and I'd rather it not go completely to waste, which is why I take the time to keep it afloat, but hoping that someone will come up and take over. The first steps would be to make contributions (we regularly have people asking to take over without even showing any code. I'd like the opposite: show us some patches that we accept, and then we will gladly give ownership). > I realize there are things to be said for "one thing at a time", but > if there is a wish-list available, I'd like to add this. It looks like there is no much development effort in mrxvt, only maintenance effort (we fix bugs and merge external contributions). So the wish-list is just a wish itself. Let the word out though: if anyone wants to work on mxvt and make development alive again, we are really interested! Jehan > The last time I used mrxvt, it did not use X resources. I found this > to be a major pain, given the number of systems I use (with different > screen sizes and resolutions) on a daily basis. Playing around with > keeping different config files up to date in different places was some > sort of shell game for me, and much more difficult than doing it the > standard X way. Any chance of having the new and improved materm use > X resources? > > Thanks. > > Jim > > > ------------------------------------------------------------------------------ > _______________________________________________ > Materm-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/materm-devel > mrxvt home page: http://materm.sourceforge.net -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Jehan <je...@ze...> - 2016-09-19 20:52:16
|
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 <and...@gm...> > 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 >> <and...@gm...> >>> 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...@ze...> 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 >> <and...@gm...> >> 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 >> <and...@gm...> >> 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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >> <and...@gm...> >> 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...@ze...> 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, <gi...@gm...> 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...@ze... > email: je...@ze... > 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...@ze... > email: je...@ze... > 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...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Andy M. <and...@gm...> - 2016-09-19 20:47:30
|
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 <and...@gm...> 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 < > and...@gm...> > > 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...@ze...> 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 < >> and...@gm...> >> 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 <and...@gm...> >>> 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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >>>> <and...@gm...> >>>> 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...@ze...> 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, <gi...@gm...> 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...@ze... >>> email: je...@ze... >>> 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...@ze... >> email: je...@ze... >> http://girinstud.io >> http://film.zemarmot.net >> Patreon: https://patreon.com/zemarmot >> Tipeee: https://www.tipeee.com/zemarmot >> > > |
From: Dan S. <str...@gm...> - 2016-09-18 23:15:38
|
On Sun, Sep 18, 2016 at 4:05 PM, <gi...@gm...> wrote: > On Sun, Sep 18, 2016 at 09:55:26PM +0200, Andy Mender wrote: > > > 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 :). > > This is pretty hard. Jehan made quite a bit of progress on the UTF8 > branch, but it is still unstable. > > There are, however, a few tricks that allow you to work with UTF-8 in > the stable version of mrxvt. I wrote them up here a while back if you're > interested: > I guess adding UTF-8 would be a good thing, but please don't totally remove the ability to do plain old 8 bit character sets. I find that with UTF-8 aware terminal emulators, it's quite possible to cut and paste something that looks like a valid bash command from your e-mail/chat/web browser/etcetera app into a UTF-8 aware terminal emulator, and only discover after much hair pulling that the things that look like quotes aren't really quotes to bash. Now if bash were UTF-8 aware too, that might work better. Not sure about that. It worries me a little, but at least then it'd be a matched set. -- Dan Stromberg |
From: Dan S. <str...@gm...> - 2016-09-18 23:10:44
|
On Sun, Sep 18, 2016 at 3:59 PM, <gi...@gm...> wrote: > On Sun, Sep 18, 2016 at 05:56:19PM -0300, Jim Diamond wrote: > > > The last time I used mrxvt, it did not use X resources. I found this > > to be a major pain, given the number of systems I use (with different > > screen sizes and resolutions) on a daily basis. Playing around with > > keeping different config files up to date in different places was some > > sort of shell game for me, and much more difficult than doing it the > > standard X way. Any chance of having the new and improved materm use > > X resources? > > Oh no... I remember "removing" this feature 10 years ago for reasons I > can't completely remember now (I think it interfered with the macro > syntax, and/or was hard to test configurations). > > I don't see myself adding it back... but I would certainly merge a patch > that doesn't break anything on my system :) > I don't like X resources; they're pretty complicated for what you get. I'd rather configure things on the command line using a small shell script that wraps xdpyinfo, using the display resolution and font size to compute a decent initial terminal size. EG: http://stromberg.dnsalias.org/svn/hcm/trunk/terminal-window http://stromberg.dnsalias.org/svn/hcm/trunk/xterm-col-row HTH -- Dan Stromberg |
From: <gi...@gm...> - 2016-09-18 23:05:29
|
On Sun, Sep 18, 2016 at 09:55:26PM +0200, Andy Mender wrote: > 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 :). This is pretty hard. Jehan made quite a bit of progress on the UTF8 branch, but it is still unstable. There are, however, a few tricks that allow you to work with UTF-8 in the stable version of mrxvt. I wrote them up here a while back if you're interested: http://www.math.cmu.edu/~gautam/sj/blog/20140914-utf8.html GI -- 'Boat' -- A hole in the water surrounded by wood into which one pours money. |
From: <gi...@gm...> - 2016-09-18 23:00:04
|
On Sun, Sep 18, 2016 at 05:56:19PM -0300, Jim Diamond wrote: > The last time I used mrxvt, it did not use X resources. I found this > to be a major pain, given the number of systems I use (with different > screen sizes and resolutions) on a daily basis. Playing around with > keeping different config files up to date in different places was some > sort of shell game for me, and much more difficult than doing it the > standard X way. Any chance of having the new and improved materm use > X resources? Oh no... I remember "removing" this feature 10 years ago for reasons I can't completely remember now (I think it interfered with the macro syntax, and/or was hard to test configurations). I don't see myself adding it back... but I would certainly merge a patch that doesn't break anything on my system :) GI -- The system requirements said 'Requires Windows 95 or better', so I bought a Mac. |
From: Jim D. <Jim...@ac...> - 2016-09-18 22:29:22
|
Hi, I used to use materm and liked it a lot, but eventually the lack of UTF support made it unusable for me. IIRC the current effort is heading in that direction, and that is great. I realize there are things to be said for "one thing at a time", but if there is a wish-list available, I'd like to add this. The last time I used mrxvt, it did not use X resources. I found this to be a major pain, given the number of systems I use (with different screen sizes and resolutions) on a daily basis. Playing around with keeping different config files up to date in different places was some sort of shell game for me, and much more difficult than doing it the standard X way. Any chance of having the new and improved materm use X resources? Thanks. Jim |
From: Andy M. <and...@gm...> - 2016-09-18 19:55:38
|
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 < and...@gm...> > 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...@ze...> 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 < > and...@gm...> > 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 <and...@gm...> >> 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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >>> <and...@gm...> >>> 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...@ze...> 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, <gi...@gm...> 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...@ze... >> email: je...@ze... >> 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...@ze... > email: je...@ze... > http://girinstud.io > http://film.zemarmot.net > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > |
From: Jehan <je...@ze...> - 2016-09-18 19:45:31
|
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 <and...@gm...> 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 <and...@gm...> > 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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >> <and...@gm...> >> 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...@ze...> 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, <gi...@gm...> 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...@ze... > email: je...@ze... > 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...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Andy M. <and...@gm...> - 2016-09-18 19:32:27
|
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.* Also, the configure.ac 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 file to remove that "needless clutter". Best of luck! Andy Mender On 11 September 2016 at 22:44, Andy Mender <and...@gm...> 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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >>>> <and...@gm...> >>>> 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...@ze...> 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, <gi...@gm...> 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...@ze... >> email: je...@ze... >> http://girinstud.io >> http://film.zemarmot.net >> Patreon: https://patreon.com/zemarmot >> Tipeee: https://www.tipeee.com/zemarmot >> >> > |
From: <gi...@gm...> - 2016-09-14 19:38:07
|
On Sun, Sep 11, 2016 at 05:18:59PM +0200, Jehan wrote: > Ok you know what? I realized I never even made an account on > gitlab.com. So I did one and tried a bit today. Looks cool actually. > So I decided to move mrxvt there to see a little more of Gitlab. Let's > make the official mxvt repository there instead. Great. I'm on board! (Delete github to avoid confusion.) > GI, I added you with role "master" (basically you can do anything as > well). I will delete the mrxvt repository on github, but will let a > few days hanging if anyone has any objection on the usage of one or > the others. For the website and the source hosting on Sourceforge, I'm > not sure exactly how we should do things. Should we delete the > accounts? Can we have them redirect to the new repository? Well, SF has a few patches and tickers and mailing lists. Perhaps we should leave everything as is, and just post a notice on the website? It would be nice if the SF code could point to the GitLab repo. But it might not be possible. Maybe we can just put an empty repo on SF saying "Code is now at http://gitlab..." GI -- 'Atheist' -- Someone with no invisible means of support. |
From: Andy M. <and...@gm...> - 2016-09-11 20:44:18
|
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...@ze...> 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...@ze...> 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...@ze...> 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...@ze...> 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 >>> <and...@gm...> >>> 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...@ze...> 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, <gi...@gm...> 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...@ze... > email: je...@ze... > http://girinstud.io > http://film.zemarmot.net > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > > |
From: Jehan <je...@ze...> - 2016-09-11 15:11:05
|
Hi, Le 2016-09-11 09:05, gi...@gm... a écrit : > On Sat, Sep 10, 2016 at 05:44:00PM +0200, Jehan wrote: > >>> Jehan, This sounds great! My github login is also "gi1242". (Same on >>> gitlab if you change your mind.) >> >> Added. > > Great thanks! I have push access now. > >> As for github vs gitlab, maybe gitlab is actually better in line for a >> Free Software. Now that the repo is created, it's just super-easy to >> move it here or there, but we may as well do this now rather than >> changing every few years. Does anyone have a strong preference for >> gitlab over github? (or the opposite) > > It really makes no difference to me. I never use the web interface, and > do everything from the git client. So changing the remote URL to gitlab > or github makes no difference to me. (I usually also push to my own > public git server, just in case something evil happens to one of the > free services.) > > Since you did the work, just go with whatever you prefer and I will > follow. Ok you know what? I realized I never even made an account on gitlab.com. So I did one and tried a bit today. Looks cool actually. So I decided to move mrxvt there to see a little more of Gitlab. Let's make the official mxvt repository there instead. GI, I added you with role "master" (basically you can do anything as well). I will delete the mrxvt repository on github, but will let a few days hanging if anyone has any objection on the usage of one or the others. For the website and the source hosting on Sourceforge, I'm not sure exactly how we should do things. Should we delete the accounts? Can we have them redirect to the new repository? Thanks! Jehan > GI -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Jehan <je...@ze...> - 2016-09-11 11:05:56
|
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...@ze...> 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] >> >>> 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...@ze...> 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] [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] [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 >> <and...@gm...> >> 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...@ze...> 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] [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] > >> [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, <gi...@gm...> 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 >>> >>> -- >>> <LIFE><!----Insert boring stuff here----></LIFE> >> >> Links: >> ------ >> [1] https://github.com/AndyMender/mrxvt [4] [3] [1] > > ------------------------------------------------------------------------------ > >> _______________________________________________ >> Materm-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/materm-devel [5] [5] >> [3] >> mrxvt home page: http://materm.sourceforge.net [6] [6] [4] > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io [8] [7] [5] > http://film.zemarmot.net [9] [8] [6] > Patreon: https://patreon.com/zemarmot [10] [9] [7] > Tipeee: https://www.tipeee.com/zemarmot [11] [10] [8] > > Links: > ------ > [1] https://github.com/AndyMender/mrxvt [4] [3] > [2] > https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git > [7] > [4] > [3] https://lists.sourceforge.net/lists/listinfo/materm-devel [5] > [5] > [4] http://materm.sourceforge.net [6] [6] > [5] http://girinstud.io [8] [7] > [6] http://film.zemarmot.net [9] [8] > [7] https://patreon.com/zemarmot [10] [9] > [8] https://www.tipeee.com/zemarmot [11] [10] > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Materm-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/materm-devel [5] [5] > mrxvt home page: http://materm.sourceforge.net [6] [6] > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io [8] [7] > http://film.zemarmot.net [9] [8] > Patreon: https://patreon.com/zemarmot [10] [9] > Tipeee: https://www.tipeee.com/zemarmot [11] [10] > > Links: > ------ > [1] https://github.com/Jehan/mrxvt [2] > [2] http://configure.ac [3] > [3] https://github.com/AndyMender/mrxvt [4] > [4] > https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git > [7] > [5] https://lists.sourceforge.net/lists/listinfo/materm-devel [5] > [6] http://materm.sourceforge.net [6] > [7] http://girinstud.io [8] > [8] http://film.zemarmot.net [9] > [9] https://patreon.com/zemarmot [10] > [10] https://www.tipeee.com/zemarmot [11] > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Materm-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/materm-devel [5] > mrxvt home page: http://materm.sourceforge.net [6] > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io [8] > http://film.zemarmot.net [9] > Patreon: https://patreon.com/zemarmot [10] > Tipeee: https://www.tipeee.com/zemarmot [11] > > > > 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://lists.sourceforge.net/lists/listinfo/materm-devel > [6] http://materm.sourceforge.net > [7] > https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git > [8] http://girinstud.io > [9] http://film.zemarmot.net > [10] https://patreon.com/zemarmot > [11] https://www.tipeee.com/zemarmot -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Andy M. <and...@gm...> - 2016-09-11 08:33:43
|
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. Any ideas? :( I managed to circumvent the need for a tarball for my purposes, but there are those differences that prevent me from doing a local "configure make make install" chain. Best regards, Andy On 10 September 2016 at 14:38, Jehan <je...@ze...> 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 > > 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...@ze...> 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 [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 [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 >>> <and...@gm...> >>> 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...@ze...> 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 [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 >> >>> [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, <gi...@gm...> 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 >>>> >>>> -- >>>> <LIFE><!----Insert boring stuff here----></LIFE> >>>> >>> >>> Links: >>> ------ >>> [1] https://github.com/AndyMender/mrxvt [3] [1] >>> >> ----------------------------------------------------------- >> ------------------- >> >> _______________________________________________ >>> Materm-devel mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/materm-devel [5] [3] >>> mrxvt home page: http://materm.sourceforge.net [6] [4] >>> >> >> -- >> Que la Sainte Marmotte soit avec moi! >> Pour me contacter: >> IM: je...@ze... >> email: je...@ze... >> http://girinstud.io [7] [5] >> http://film.zemarmot.net [8] [6] >> Patreon: https://patreon.com/zemarmot [9] [7] >> Tipeee: https://www.tipeee.com/zemarmot [10] [8] >> >> Links: >> ------ >> [1] https://github.com/AndyMender/mrxvt [3] >> [2] >> https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git >> [4] >> [3] https://lists.sourceforge.net/lists/listinfo/materm-devel [5] >> [4] http://materm.sourceforge.net [6] >> [5] http://girinstud.io [7] >> [6] http://film.zemarmot.net [8] >> [7] https://patreon.com/zemarmot [9] >> [8] https://www.tipeee.com/zemarmot [10] >> >> ----------------------------------------------------------- >> ------------------- >> >> _______________________________________________ >> Materm-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/materm-devel [5] >> mrxvt home page: http://materm.sourceforge.net [6] >> >> -- >> Que la Sainte Marmotte soit avec moi! >> Pour me contacter: >> IM: je...@ze... >> email: je...@ze... >> http://girinstud.io [7] >> http://film.zemarmot.net [8] >> Patreon: https://patreon.com/zemarmot [9] >> Tipeee: https://www.tipeee.com/zemarmot [10] >> >> >> >> Links: >> ------ >> [1] https://github.com/Jehan/mrxvt >> [2] http://configure.ac >> [3] https://github.com/AndyMender/mrxvt >> [4] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git >> [5] https://lists.sourceforge.net/lists/listinfo/materm-devel >> [6] http://materm.sourceforge.net >> [7] http://girinstud.io >> [8] http://film.zemarmot.net >> [9] https://patreon.com/zemarmot >> [10] https://www.tipeee.com/zemarmot >> >> ------------------------------------------------------------ >> ------------------ >> >> _______________________________________________ >> Materm-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/materm-devel >> mrxvt home page: http://materm.sourceforge.net >> > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io > http://film.zemarmot.net > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > |
From: <gi...@gm...> - 2016-09-11 07:05:41
|
On Sat, Sep 10, 2016 at 05:44:00PM +0200, Jehan wrote: >> Jehan, This sounds great! My github login is also "gi1242". (Same on >> gitlab if you change your mind.) > > Added. Great thanks! I have push access now. > As for github vs gitlab, maybe gitlab is actually better in line for a > Free Software. Now that the repo is created, it's just super-easy to > move it here or there, but we may as well do this now rather than > changing every few years. Does anyone have a strong preference for > gitlab over github? (or the opposite) It really makes no difference to me. I never use the web interface, and do everything from the git client. So changing the remote URL to gitlab or github makes no difference to me. (I usually also push to my own public git server, just in case something evil happens to one of the free services.) Since you did the work, just go with whatever you prefer and I will follow. GI -- 'Blamestorming' -- Sitting around in a group discussing why a deadline was missed or a project failed and who was responsible. |
From: Jehan <je...@ze...> - 2016-09-10 15:36:05
|
Hi, Le 2016-09-09 15:50, gi...@gm... a écrit : > On Fri, Sep 09, 2016 at 04:14:09AM +0200, Jehan wrote: > >> How does that sound? > > Jehan, This sounds great! My github login is also "gi1242". (Same on > gitlab if you change your mind.) Added. As for github vs gitlab, maybe gitlab is actually better in line for a Free Software. Now that the repo is created, it's just super-easy to move it here or there, but we may as well do this now rather than changing every few years. Does anyone have a strong preference for gitlab over github? (or the opposite) Jehan > I will also be happy to review / merge pull requests as time permits. > > Thanks for migrating it! > > GI -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: Jehan <je...@ze...> - 2016-09-10 12:30:09
|
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 > 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...@ze...> 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 [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 [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 >> <and...@gm...> >> 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...@ze...> 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 [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 >> [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, <gi...@gm...> 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 >>> >>> -- >>> <LIFE><!----Insert boring stuff here----></LIFE> >> >> Links: >> ------ >> [1] https://github.com/AndyMender/mrxvt [3] [1] > > ------------------------------------------------------------------------------ > >> _______________________________________________ >> Materm-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/materm-devel [5] [3] >> mrxvt home page: http://materm.sourceforge.net [6] [4] > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io [7] [5] > http://film.zemarmot.net [8] [6] > Patreon: https://patreon.com/zemarmot [9] [7] > Tipeee: https://www.tipeee.com/zemarmot [10] [8] > > Links: > ------ > [1] https://github.com/AndyMender/mrxvt [3] > [2] > https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git > [4] > [3] https://lists.sourceforge.net/lists/listinfo/materm-devel [5] > [4] http://materm.sourceforge.net [6] > [5] http://girinstud.io [7] > [6] http://film.zemarmot.net [8] > [7] https://patreon.com/zemarmot [9] > [8] https://www.tipeee.com/zemarmot [10] > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Materm-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/materm-devel [5] > mrxvt home page: http://materm.sourceforge.net [6] > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io [7] > http://film.zemarmot.net [8] > Patreon: https://patreon.com/zemarmot [9] > Tipeee: https://www.tipeee.com/zemarmot [10] > > > > Links: > ------ > [1] https://github.com/Jehan/mrxvt > [2] http://configure.ac > [3] https://github.com/AndyMender/mrxvt > [4] > https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git > [5] https://lists.sourceforge.net/lists/listinfo/materm-devel > [6] http://materm.sourceforge.net > [7] http://girinstud.io > [8] http://film.zemarmot.net > [9] https://patreon.com/zemarmot > [10] https://www.tipeee.com/zemarmot > > ------------------------------------------------------------------------------ > > _______________________________________________ > Materm-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/materm-devel > mrxvt home page: http://materm.sourceforge.net -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |
From: <gi...@gm...> - 2016-09-09 13:50:41
|
On Fri, Sep 09, 2016 at 04:14:09AM +0200, Jehan wrote: > How does that sound? Jehan, This sounds great! My github login is also "gi1242". (Same on gitlab if you change your mind.) I will also be happy to review / merge pull requests as time permits. Thanks for migrating it! GI -- TWELVE REASONS WHY GOD NEVER RECEIVED TENURE 4. The scientific community has had a hard time replicating his results. |
From: Andy M. <and...@gm...> - 2016-09-09 13:12:31
|
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. 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 will update the README and include a .desktop file accordingly. It's fine if both of those are in the build directory, right? The .desktop file would be added together with the rest of the files through "make install". Per my repository, I think I will rename it, restructure it and use it for hosting PKGBUILDs before they officially go to AUR. Nothing more. I think that's all for now :). Best regards, Andy On 9 September 2016 at 14:54, Jehan <je...@ze...> 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 > > 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. > 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 <and...@gm...> >> 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...@ze...> 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 [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 >> >>> [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, <gi...@gm...> 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 >>>> >>>> -- >>>> <LIFE><!----Insert boring stuff here----></LIFE> >>>> >>> >>> Links: >>> ------ >>> [1] https://github.com/AndyMender/mrxvt [1] >>> >>> >>> ------------------------------------------------------------ >> ------------------ >> >>> >>> _______________________________________________ >>> Materm-devel mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/materm-devel [3] >>> mrxvt home page: http://materm.sourceforge.net [4] >>> >> >> -- >> Que la Sainte Marmotte soit avec moi! >> Pour me contacter: >> IM: je...@ze... >> email: je...@ze... >> http://girinstud.io [5] >> http://film.zemarmot.net [6] >> Patreon: https://patreon.com/zemarmot [7] >> Tipeee: https://www.tipeee.com/zemarmot [8] >> >> >> >> Links: >> ------ >> [1] https://github.com/AndyMender/mrxvt >> [2] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git >> [3] https://lists.sourceforge.net/lists/listinfo/materm-devel >> [4] http://materm.sourceforge.net >> [5] http://girinstud.io >> [6] http://film.zemarmot.net >> [7] https://patreon.com/zemarmot >> [8] https://www.tipeee.com/zemarmot >> >> ------------------------------------------------------------ >> ------------------ >> >> _______________________________________________ >> Materm-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/materm-devel >> mrxvt home page: http://materm.sourceforge.net >> > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io > http://film.zemarmot.net > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > > |
From: Jehan <je...@ze...> - 2016-09-09 12:46:56
|
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 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. 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 <and...@gm...> > 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...@ze...> 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 [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 >> [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, <gi...@gm...> 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 >>> >>> -- >>> <LIFE><!----Insert boring stuff here----></LIFE> >> >> Links: >> ------ >> [1] https://github.com/AndyMender/mrxvt [1] >> >> > ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Materm-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/materm-devel [3] >> mrxvt home page: http://materm.sourceforge.net [4] > > -- > Que la Sainte Marmotte soit avec moi! > Pour me contacter: > IM: je...@ze... > email: je...@ze... > http://girinstud.io [5] > http://film.zemarmot.net [6] > Patreon: https://patreon.com/zemarmot [7] > Tipeee: https://www.tipeee.com/zemarmot [8] > > > > Links: > ------ > [1] https://github.com/AndyMender/mrxvt > [2] > https://git-scm.com/book/en/v2/Git-and-Other-Systems-Migrating-to-Git > [3] https://lists.sourceforge.net/lists/listinfo/materm-devel > [4] http://materm.sourceforge.net > [5] http://girinstud.io > [6] http://film.zemarmot.net > [7] https://patreon.com/zemarmot > [8] https://www.tipeee.com/zemarmot > > ------------------------------------------------------------------------------ > > _______________________________________________ > Materm-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/materm-devel > mrxvt home page: http://materm.sourceforge.net -- Que la Sainte Marmotte soit avec moi! Pour me contacter: IM: je...@ze... email: je...@ze... http://girinstud.io http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot |