[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail: ChangeLog claws-mail-3.9.1.ebuild
Michał Górny posted on Tue, 14 May 2013 05:22:49 +0200 as excerpted: On Mon, 13 May 2013 23:33:59 +0200 Christian Faulhammer fa...@gentoo.org wrote: Samuli Suominen ssuomi...@gentoo.org: On 13/05/13 07:46, Christian Faulhammer (fauli) wrote: fauli 13/05/13 04:46:01 Modified: ChangeLog claws-mail-3.9.1.ebuild Log: move libnotify usage over to notification, forgotten in last commit -$(use_enable libnotify notification-plugin) +$(use_enable notification notification-plugin) Why deviate from every other ebuild in Portage? From global to local :-/ libnotify is only a fraction of the supported notification means of said plugin in Claws. Is the remaining fraction usable without libnotify on Gentoo? Yes. http://www.claws-mail.org/plugin.php?plugin=notification As mentioned in an earlier thread, the formerly separate plugins are now being combined into the main ebuild, based on a similar upstream move. These new flags control building the formerly separate plugins. The notification plugin, as described in the link above, has all sorts of notification possibilities, including even a separate LCD display via the LCDproc deamon (tho I've no idea if that particular one is available on gentoo, but I wouldn't know why not...), as well as a screen-scroller, all configurable, naturally. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Making systemd more accessible to normal users
On 05/10/2013 09:45 AM, Ralph Sennhauser wrote: [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files What if openrc/upstart/runit devs start harassing upstream in the same way? Strategically is great, but isn't exactly something nice to do. Probably people caring about alternatives should start bothering upstreams likewise and we'll see how it goes. I'm sure that *everybody* would be delighted to provide those 4-5 different initscripts because one distribution or the other wants others do the work for them... I'm saying again that trying to get a good intermediate representation and have a generator (eselect based maybe) provide the init-specific file would be much better. In the end initscripts are usually distribution dependent since they are an integration step. lu
Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
On Sun, May 12, 2013 at 3:18 PM, sascha...@babbelbox.org wrote: - It supports Merge Requests, which are almost the same as PRs on Github, which allows user contributions to be reviewed quite easily. So, out of curiosity I set this up on a VM and started playing with it. It seemed like the UI for merge requests was limited to merges between branches on the same repository. Github lets you make pull requests between repositories. Logistically that is a BIG difference. With a Github-like model users don't need write access of any kind to the repository (they do their work in their own forks), but with Gitlab you'd need to give write access (not sure if you can limit that to only an incoming branch of some kind, which would be a free-for-all area (which might also create problems as this is essentially an arbitrary file hosting area)). I could be missing something though - seems like a useful tool but it might be more appropriate to closed teams than for public contribution. If somebody knows of something I missed by all means chime in. Gerrit also requires letting the public push, but those pushes go to a contained area and each commit is isolated. Again, let me know if I missed something. Rich
Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
Rich Freeman wrote: Gerrit also requires letting the public push, but those pushes go to a contained area and each commit is isolated. Hm, how do you mean isolated? Gerrit introduces the convention to create a unique identifier for a change the first time a commit is created. If later iterations of that same logical change (e.g. a second commit after review) keep the Change-Id line from the original commit message then Gerrit knows that this commit is a new version of the old one as opposed to an all new change. Pushing to Gerrit looks and feels like pushing to a git repository but in fact the push goes into Gerrit's own database (contained area) where it can be reviewed, iterated by pushing again as described above, submitted (output into the project's (readonly) git repo) or rejected. The real beauty of Gerrit is that anything can be accepted into it without affecting the project's real git repo at all, and that only an OpenID is required for pushing. Verification (testing) can be made a requirement before a commit can be submitted in Gerrit, meaning that some test suite needs to pass before a commit can enter the git repo. Some of this can be orchestrated with multiple repositories and lots of hooks, but Gerrit packages it all up quite nicely. While Gerrit is probably most often used as a web application, it's possible to perform most operations, including review, submit and reject, via SSH. The only thing missing from the SSH interface is doing inline review. The web interface allows writing review comments per line in the commit, this is unfortunately not possible via SSH. //Peter
Re: [gentoo-dev] GitLab Feature-Set / Was: devmanual moved to github
On Tue, May 14, 2013 at 10:19 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: Gerrit also requires letting the public push, but those pushes go to a contained area and each commit is isolated. Hm, how do you mean isolated? Gerrit introduces the convention to create a unique identifier for a change the first time a commit is created. If later iterations of that same logical change (e.g. a second commit after review) keep the Change-Id line from the original commit message then Gerrit knows that this commit is a new version of the old one as opposed to an all new change. Suppose master is Gentoo Portage. I clone it, make a change to package foo, and push that commit to gerrit. You clone it, make a change to package bar, and push that commit to gerrit. Those two commits go into two different requests and don't interfere (well, they might when merged if they contain conflicts - no avoiding that). If at that point somebody else clones the repo they get the official repo without either of our changes, until at some point our changes get merged. It is true that revisions of commits do update each other, but this is generally desirable. What is important is that each logical change stays isolated. The only way to do this with branching is to have a branch per change (which could be merged and deleted of course). Gitlab doesn't seem to support this though - I don't think there is any safe way to allow random public users to create branches, and of course if anybody does this they are published to the world. Gerrit keeps changes more tucked away, so that everybody is working off the official repo. If you just have everybody share one public branch then it will be a hodge-podge of commits that require a lot of cherry-picking to work with. The public branch itself might not even work, or it might need constant cleanup. It might even contain trojans so cloning it would be at your own risk (it would be safer to clone master and push to public, which means that everybody is stepping on each other's toes). Branches do make sense if you have groups working together on a single change. I'd encourage them for this use. However, in the case of isolated patches the Gerrit model seems better. Again, I could be missing some Gitlab feature. While Gerrit is probably most often used as a web application, it's possible to perform most operations, including review, submit and reject, via SSH. The only thing missing from the SSH interface is doing inline review. The web interface allows writing review comments per line in the commit, this is unfortunately not possible via SSH. I know a lot of projects like Gerrit (Cyanogenmod comes to mind). Sure, it is Java, but I'd think it could be reasonably well-contained in a VM/etc. It could even be hosted - as long as we have backups/etc and can recover to our own infra I'd consider that pretty low-risk. Rich
Re: [gentoo-dev] Re: devmanual moved to github
On Sun, May 12, 2013 at 12:08:21PM -0400, Rich Freeman wrote: On Sun, May 12, 2013 at 11:54 AM, Markos Chandras hwoar...@gentoo.org wrote: This is the kind of policies that kill user contributions. I am very sad to witness this once again. I have mixed feelings for this very reason. The concept of accepting contributions on github is an EXCELLENT one. The problem is that it is proprietary, which creates division, and could potentially create problems down the road (no way to know - the sorts of things that can happen anytime you depend on proprietary software). If github were to go down, all you would have to do is use a command similar to the one given in the first message of this thread to switch upstream to another location. I would argue that there really isn't a hard dependency on github in the same way there would be if they were using some centralized vcs such as svn. I think this is a pretty weak argument for systems that use distributed vcs's like git. I will take care of the github mirroring myself. For those who will merge pull requests on github, please take extra care to resolve the merges properly. So, first, THANK YOU! If we are going to take this stance, should we consider removing all packages from the tree that have their upstream on github? William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: devmanual moved to github
On Mon, May 13, 2013 at 12:21:06AM +0200, Peter Stuge wrote: Alexander Berntsen wrote: [GitHub] enforces some particular workflow You keep saying this. What do you mean? I'll clarify! A lot of projects (including Linux) just use GitHub for hosting and nothing else. I don't see the problem. There is no problem if github is only used for hosting, but if it is the primary point of contact, or if pull requests are accepted, then github is also writing to repositories, and merge commits are enforced for all external contributions. That does not scale at all. (It works of course, but the repo history ends up looking horrible.) You can use git remotes on a github-based repository the same way you would on any git repository, and you can rebase branches before you merge them into master so you get only fast-forward merges. So, I do not see how the history is going to look horrible or how merge commits are enforced for all external contributions. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail: ChangeLog claws-mail-3.9.1.ebuild
On Tue, 14 May 2013 06:48:39 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Michał Górny posted on Tue, 14 May 2013 05:22:49 +0200 as excerpted: On Mon, 13 May 2013 23:33:59 +0200 Christian Faulhammer fa...@gentoo.org wrote: Samuli Suominen ssuomi...@gentoo.org: On 13/05/13 07:46, Christian Faulhammer (fauli) wrote: fauli 13/05/13 04:46:01 Modified: ChangeLog claws-mail-3.9.1.ebuild Log:move libnotify usage over to notification, forgotten in last commit - $(use_enable libnotify notification-plugin) + $(use_enable notification notification-plugin) Why deviate from every other ebuild in Portage? From global to local :-/ libnotify is only a fraction of the supported notification means of said plugin in Claws. Is the remaining fraction usable without libnotify on Gentoo? Yes. Oh, the pasted snippet confused me. But I see now: notification? ( libnotify? ( x11-libs/libnotify ) libcanberra? ( media-libs/libcanberra[gtk] ) libindicate? ( dev-libs/libindicate:3[gtk] ) dev-libs/glib ) but no switch using libnotify. Isn't this an automagic dep then? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: devmanual moved to github
On Tue, May 14, 2013 at 11:44 AM, William Hubbs willi...@gentoo.org wrote: If we are going to take this stance, should we consider removing all packages from the tree that have their upstream on github? Considering that we allow even outright proprietary software in portage which isn't distributed at all (copy file from CD to distfiles), we're obviously not going to be concerned about upstreams on github. Gentoo's social contract is GENTOO'S social contract. It governs what we do, and it doesn't say that we don't accept proprietary software. It says that we won't DEPEND on proprietary software for our operations or for anything essential to using Gentoo. As I already said - I think Github is a gray area. I'd like to see us working on an internal workflow tool that is friendly to outsiders like Gerrit or whatever. I'd see Github as a useful alternative, or as an interim solution, but I'd really hate to establish it as the long-term repository for something that is part of Gentoo without actively pursuing plans to move it to an FOSS platform. That's just my personal opinion though - others really don't want to touch it at all, and I can't fault them too much since it is contrary to our social contract. I'm a pragmatist, but I am charged with helping to uphold the social contract as a Trustee, and right now there is no official FOSS long-term solution. On the list of threats to the org though, I think that getting our main repository onto git in the first place is a higher priority than adopting tools like Gerrit/Github/etc. Right now most of what is left on that project rests on infra, so I don't want to beat up on them over not wanting to take on Java/etc. Rich
[gentoo-dev] Package up for grabs: dev-libs/fcgi
Hi, I thought I already dropped maintainership of this package a long time ago, since I haven't been using fastcgi for ages, but a new bug today told me I forgot. I've done so now. Someone please pick this up if you still use fastcgi. dev-libs/fcgi https://bugs.gentoo.org/show_bug.cgi?id=469794 is the one open bug about the AM_CONFIG_HEADER macro. Hans
[gentoo-dev] readme.gentoo.eclass: Add a note informing people a file is being installed for future reference
As discussed at:
https://bugs.gentoo.org/show_bug.cgi?id=457598#c4
we need a way to inform users the ebuild is installing a README.gentoo
file with needed information for configuration tips and so. Attached
patch does it.
--- readme.gentoo.eclass~ 2013-03-05 23:31:15.0 +0100
+++ readme.gentoo.eclass 2013-05-14 20:31:11.0 +0200
@@ -97,6 +97,9 @@
die readme.gentoo_print_elog invoked without matching readme.gentoo_create_doc call!
elif ! [[ -n ${REPLACING_VERSIONS} ]] || [[ -n ${FORCE_PRINT_ELOG} ]]; then
echo -e ${README_GENTOO_DOC_VALUE} | while read -r ELINE; do elog ${ELINE}; done
+ elog (Note: Above message will only be printed the first time package
+ elog is installed. Please look at /usr/share/doc/${PF}/README.gentoo*
+ elog for future reference)
fi
}
Re: [gentoo-dev] readme.gentoo.eclass: Add a note informing people a file is being installed for future reference
On Tue, 14 May 2013, Pacho Ramos wrote: As discussed at: https://bugs.gentoo.org/show_bug.cgi?id=457598#c4 we need a way to inform users the ebuild is installing a README.gentoo file with needed information for configuration tips and so. Attached patch does it. Could the notice be separated from the preceding message by at least one empty line? Ulrich
Re: [gentoo-dev] readme.gentoo.eclass: Add a note informing people a file is being installed for future reference
El mar, 14-05-2013 a las 23:27 +0200, Ulrich Mueller escribió: On Tue, 14 May 2013, Pacho Ramos wrote: As discussed at: https://bugs.gentoo.org/show_bug.cgi?id=457598#c4 we need a way to inform users the ebuild is installing a README.gentoo file with needed information for configuration tips and so. Attached patch does it. Could the notice be separated from the preceding message by at least one empty line? Ulrich Sure, I was thinking on that also :)
[gentoo-dev] Re: GCC USE flag changes
On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: [...] This is pushed out now. I also ended up dropping LTO support for 4.5. If you're using LTO as shipped in 4.5 you are braver than anyone deserves to be. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Package up for grabs: dev-libs/fcgi
On Tue, May 14, 2013 at 3:06 PM, Hans de Graaff gra...@gentoo.org wrote: Hi, I thought I already dropped maintainership of this package a long time ago, since I haven't been using fastcgi for ages, but a new bug today told me I forgot. I've done so now. Someone please pick this up if you still use fastcgi. dev-libs/fcgi https://bugs.gentoo.org/show_bug.cgi?id=469794 is the one open bug about the AM_CONFIG_HEADER macro. Hans I'm still using it. will get it if nobody gets until tomorrow :) -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
