Re: [gentoo-dev] RFC: kde5 and kde5-functions eclass
kde5.eclass
> case ${KDE_TEST} in
> false) ;;
> *)
> IUSE+=" test"
> DEPEND+=" test? ( dev-qt/qttest:5 )"
No >=${QT_MINIMAL} in this dep?
> else
> unpack ${A}
I think you can use `default`
> if ! in_iuse examples || ! use examples ; then
if ! use_if_iuse examples ; then
> if ! in_iuse test || ! use test ; then
ditto
> if [ -n "${DBUS_SESSION_BUS_PID}" ] ; then
Use [[ ]], and you can also omit quoting.
> dohtml -r ${P}-apidocs/html/*
docinto html
dodoc -r ${P}-apidocs/html/*
Or even shorter, dodoc -r ${P}-apidocs/html (without docinto)
Thanks,
Davide
[gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
Diamond wrote: > > There's no git cp command. > git mv is just git rm + git add. I think there is a misunderstanding about how git works. If you are used to e.g. svn (I suppose with CVS it is similar) then it makes an important difference whether you use "svn cp A B" or "/bin/cp A B", because svn is file-centric: The latter loses history and duplicates data in the repository, while the former de-duplicates. git, OTOH is "blob"-centric: It cares only about content of the file, not where this content comes from; the information that you copy A to B is not stored, and it does not need to be stored: De-duplication happens automatically. In other words, there is no way for git to "see" that B originally was a copy of A, and normally there is also no such need. If you think that this information is important enough to be stored in the history, you have to make a commit where B is completely identical to A before you make further modifications for B (identical files have the same checksum and thus are immediately identified). If you make no such commit, git can guess only by similarities of the content that B originally was as a copy of A; this, of course, needs slightly longer than omitting such comparisons. For this reason, there is absolutely no reason to use git for file operations like cp or mv (as long as you add/remove the corresponding files from the index before you commit, of course).
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
> On Fri, 19 Sep 2014, hasufell wrote: > There is no reason to roll back commits or do merge commits for the > keywords conflict use case. So I don't see what else needs > discussion here, except the proposal from ulm. About an optimised merge driver for ebuilds? Please don't see this as a blocker for the migration. Ulrich pgpVH2cxxftNs.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Ian Stakenvicius: > Git on the other hand will update the entire > tree and there's no way around that, right? Yeah, people have to understand that we cannot map the cvs workflow 1:1 to git. That's for a reason and that little inconvenience it causes is pretty minor compared to the breakage CVS allows (user syncs at a bad time and gets a broken tree, repoman gives bogus results etc.). There is no reason to roll back commits or do merge commits for the keywords conflict use case. So I don't see what else needs discussion here, except the proposal from ulm.
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/14 11:10 AM, Ian Stakenvicius wrote: > > I don't think there's any valid debate on whether git is more > efficient than cvs on fetching tree-wide updates :) > erm, that was worded wrong, let me try again: I don't think there's any valid debatable point against git being more efficient than cvs, when fetching updates tree-wide. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlQcSCoACgkQ2ugaI38ACPCU1QD8Dqy00yazdlXLphGYKx4e/Ec6 ci9AyvPI3ga+ilqmaJUA/RlsRM6ycPr6jXaW5WZtPTxjgfuz0qSrsw2cf+K7UjGK =p9XG -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/09/14 10:48 AM, Rich Freeman wrote: > On Fri, Sep 19, 2014 at 10:25 AM, hasufell > wrote: >> >> That is pretty easy and takes you ~20s for a keyword merge. >> What's the problem? >> > > Agree. Also, there was a comment that git pull is much slower than > cvs. While it is true that git does refresh the whole tree all the > time, it is FAR more efficient at doing this than CVS, since the > local and remote repositories can use a single hash to determine > where each stands relative to the other, and the COW mechanism > applies to directory trees so when making comparisons git does not > need to traverse the full depth of the tree for every branch. A > cvs update on the entire tree is basically an independent > synchronization of every file in the tree. Also, by refreshing the > entire tree you also catch any repoman errors that might result > from commits to other packages that you didn't have visibility to > when refreshing only a single package in cvs. > That wasn't really part of his argument, though -- when he's fixing keyword collisions, he's only working within one package, and CVS in that case -only- checks the subtree as of that package (ie, ./ and ./files/) when updating. Git on the other hand will update the entire tree and there's no way around that, right? (unless of course i missed something in hasufell's command list) I don't think there's any valid debate on whether git is more efficient than cvs on fetching tree-wide updates :) > I wonder if it would make sense to set up a practice git tree > somewhere so that people can try working together on workflows/etc. > We can clone a migrated tree (I have one from a few days ago on > github). Definitely. I'd volunteer for that (doing my updates to both git and cvs trees), and I expect others would as well. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlQcR1UACgkQ2ugaI38ACPA1ogEAmn9ZBr9nORFH02cxu4HML+9C OKyPystsxAaOdEnkzS8A/29mitUtED8jowJ+5Udh9YyYRjJApzx36hRMyyAsJUVc =B0E9 -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Fri, Sep 19, 2014 at 10:25 AM, hasufell wrote: > > That is pretty easy and takes you ~20s for a keyword merge. What's the > problem? > Agree. Also, there was a comment that git pull is much slower than cvs. While it is true that git does refresh the whole tree all the time, it is FAR more efficient at doing this than CVS, since the local and remote repositories can use a single hash to determine where each stands relative to the other, and the COW mechanism applies to directory trees so when making comparisons git does not need to traverse the full depth of the tree for every branch. A cvs update on the entire tree is basically an independent synchronization of every file in the tree. Also, by refreshing the entire tree you also catch any repoman errors that might result from commits to other packages that you didn't have visibility to when refreshing only a single package in cvs. I wonder if it would make sense to set up a practice git tree somewhere so that people can try working together on workflows/etc. We can clone a migrated tree (I have one from a few days ago on github). I'm not super-familiar with github organizations, but if it is easy to grant everybody in the gentoo organization access to a migrated tree we could do that, and host it in the organization. I don't care where we host the tree - I just don't have anything set up personally. -- Rich
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Tobias Klausmann: >>> >>> If this should really turn out to be a problem, then we could also: >>> >>> 4) Replace git's default merge driver by our own one that is better >>> suited for ebuilds. This can be done per repository via .git/config >>> and .gitattributes. >>> >> >> Certainly that would be even more helpful! > > Still, all of these scenarios cause merge commits No. 1. git pull --rebase=preserve origin master => error: could not apply ... 2. fix conflicts via 'git mergetool' (e.g. meld or vimdiff with 3 panel view... very easy to see what happened) 3. finish rebase via 'git rebase --continue' => your unpushed keyword commit has been rewritten without a merge commit 4. push That is pretty easy and takes you ~20s for a keyword merge. What's the problem?
[gentoo-dev] Unifying the PostgreSQL Ebuilds
I've been working on unifying the PostgreSQL ebuilds for a while now. Besides just being cleaner and taking a bit less time to compile, it will inherently resolve a couple issues that are difficult to workaround, such as cross compilation [1] and CFLAGS changes [2]. I'm including a list of affected packages, but I think I have everything prepared in my overlay [3] for commit to gentoo-x86. I'm aiming to do a package move instead of the virtual/postgresql mess we had last time. Before I do that, I'd like some feedback as there may be some issue I've overlooked or haven't run into. I don't really think there should be as the installation model is the same as the split ebuilds; it's still slotted, and installation paths are the same. I'm hoping to press forward with this change in the next week or so. Thank you in advance! [1] https://bugs.gentoo.org/show_bug.cgi?id=505540 [2] https://bugs.gentoo.org/show_bug.cgi?id=456876 [3] https://github.com/titanofold/titanofold-gentoo-x86 Affected Packages app-admin/collectd app-admin/rsyslog app-admin/sagan app-admin/ulogd app-backup/bacula app-backup/bareos app-crypt/onak app-editors/xemacs app-forensics/aide app-misc/sphinx app-mobilephone/gammu app-mobilephone/gnokii app-mobilephone/kannel app-office/akonadi-server app-office/calligra app-office/libreoffice app-office/openerp app-office/openerp-server dev-cpp/pficommon dev-db/barman dev-db/cppdb dev-db/libdbi-drivers dev-db/libzdb dev-db/mysql-super-smack dev-db/opendbx dev-db/pgadmin3 dev-db/pgagent dev-db/pgmemcache dev-db/pgpool2 dev-db/pgtap dev-db/pg_top dev-db/pgxnclient dev-db/postgis dev-db/psqlodbc dev-db/pygresql dev-db/slony1 dev-db/soci dev-db/textsearch_ja dev-db/tora dev-haskell/hdbc-postgresql dev-haskell/hsql-postgresql dev-java/jdbc-postgresql dev-lang/io dev-lang/php dev-libs/apr-util dev-libs/cyrus-sasl dev-libs/libhome dev-libs/libpqxx dev-libs/radlib dev-libs/redland dev-lisp/clisp dev-lua/luadbi dev-ml/postgresql-ocaml dev-perl/DBD-Pg dev-perl/pgperl dev-python/psycopg dev-python/pypgsql dev-qt/qtsql dev-ruby/pg games-server/cyphesis games-server/pvpgn games-strategy/freeciv gnome-extra/libgda gnustep-libs/sqlclient mail-filter/anubis mail-filter/dspam mail-filter/gld mail-mta/courier mail-mta/exim mail-mta/postfix media-video/motion net-analyzer/barnyard net-analyzer/barnyard2 net-analyzer/echoping net-analyzer/flow-tools net-analyzer/hydra net-analyzer/icinga2 net-analyzer/metasploit net-analyzer/munin net-analyzer/nagios-plugins net-analyzer/pmacct net-analyzer/zabbix net-dialup/accel-ppp net-dialup/freeradius net-dialup/gnuradius net-dns/bind net-dns/mydns net-dns/pdns net-firewall/nufw net-ftp/proftpd net-ftp/pure-ftpd net-im/jabberd2 net-irc/eggdrop net-irc/inspircd net-libs/courier-authlib net-libs/cvm net-libs/wt net-mail/cyrus-imapd net-mail/dovecot net-mail/ezmlm-idx net-mail/mailutils net-mail/perdition net-mail/tpop3d net-mail/vpopmail net-misc/asterisk net-misc/cfengine net-misc/mico net-misc/ser net-misc/stargazer net-print/pykota net-voip/gnugk net-voip/yate sci-biology/emboss sci-geosciences/grass sci-geosciences/mapnik sci-geosciences/osm2pgsql sci-geosciences/qgis sci-libs/gdal sci-libs/vtk sci-mathematics/pspp sci-physics/root sys-auth/libnss-pgsql sys-auth/pam-pgsql sys-cluster/gearmand sys-cluster/slurm www-apache/mod_auth_nufw www-apache/mod_auth_pgsql www-apps/liquid_feedback_core www-apps/webmcp www-servers/uwsgi -- Mr. Aaron W. Swenson Gentoo Linux Developer PostgreSQL Herd Bull Email : titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 signature.asc Description: Digital signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi! On Fri, 19 Sep 2014, Tom Wijsman wrote: > On Thu, 18 Sep 2014 19:39:08 +0200 > Tobias Klausmann wrote: > > > AIUI, we try to avoid merge conflicts, unless the merge is a > > meaningful integration of divergent processes. > > > > However, one aspect of how ebuilds are written these days will > > cause a non-trivial amount of merge commits that are not actually > > useful in that sense. > > The concept of rebasing your commits has been invented for this. In the > less common case that multiple people change the keywords, a manual > three way merge is a breeze; taking into consideration that maintainers > should be aware of KEYWORDS and other recent changes to their packages. As I pointed out, getting the right code into the tree is not the problem here. It is extra work over the current way of doing it (since I need to deal with a local commit that can't be ff'd or rebased as git is very line-oriented. On top of the extra work, there have been several mentions that only meaning ful merge-commits are wanted in the tree (or not wanted at all). AIUI, avoiding them in the keywording/stabilizing phase is currently very difficult, unless we split KEYWORDS into separate lines or find another mechanism (like having the maintainer/keyword-requestor do all the edits after the archs sign off on them). I'd be delighted to hear a simpler solution that only involves doing the semantic merge (like we do now with CVS). And at least in my case, collisions during keywording are fairly common, and will be even more so with git since fetch/pull are slower than for a CVS subdir (since git checks the whole tree for local changes, not just the current subtree, AIUI). Again, correct me if I'm wrong. I've been using git for ~4 years, but only in single-developer mode. And even there I managed to make a mess of repo histories :-/ Fortunately, nobody cares about my stuff. Regards, Tobias
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Thu, 18 Sep 2014 19:39:08 +0200 Tobias Klausmann wrote: > AIUI, we try to avoid merge conflicts, unless the merge is a > meaningful integration of divergent processes. > > However, one aspect of how ebuilds are written these days will > cause a non-trivial amount of merge commits that are not actually > useful in that sense. The concept of rebasing your commits has been invented for this. In the less common case that multiple people change the keywords, a manual three way merge is a breeze; taking into consideration that maintainers should be aware of KEYWORDS and other recent changes to their packages.
Re: [gentoo-scm] Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On 19 September 2014 06:51, Rich Freeman wrote: > > Git even allows the use of tools like meld to resolve conflicts, > besides the usual fill-the-file-with-diffs-to-cleanup approach. I'd personally discourage any kind of collision resolution in the merge itself. Mostly because I've been bitten by attempted rebases where those collision resolutions have been *lost* . Much preferable to rebase one branch or find some otherway to weed the collision out prior to merge and giving a clean track record of where the fix was applied. ( Because the fix happening in the merge is a great way to hide accidental code changes ) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
Hi! On Thu, 18 Sep 2014, Rich Freeman wrote: > On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller wrote: > >> On Thu, 18 Sep 2014, Tobias Klausmann wrote: > > > >> However, one aspect of how ebuilds are written these days will > >> cause a non-trivial amount of merge commits that are not actually > >> useful in that sense. > > > > Git can do merge conflict markers just like cvs. Also, in practice I > don't tend to run into merge conflicts with cvs - I always do a > directory update before making changes. With git I'd probably not do > a pull if I were working on an obscure pacakge, but if I were doing a > security keywording I'd certainly do a pull before touching anything > since the likelihood of a conflict is much higher. The problem isn't the conflict markers. The problem is that with git, by the time I have a conflict, I also have a local commit that I have to roll back or turn into a merge, which means extra work. > Git even allows the use of tools like meld to resolve conflicts, > besides the usual fill-the-file-with-diffs-to-cleanup approach. > > > > > If this should really turn out to be a problem, then we could also: > > > > 4) Replace git's default merge driver by our own one that is better > > suited for ebuilds. This can be done per repository via .git/config > > and .gitattributes. > > > > Certainly that would be even more helpful! Still, all of these scenarios cause merge commits, which some people seem to be rather allergic to (and I do agree that nothing of use is actually merged, since two stabilizations/keywordings are usually orthogonal). Regards, Tobias
