[gentoo-dev] [warning] the bug queue has 81 bugs
Our bug queue has 81 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
Re: [gentoo-dev] Re: Referencing bug reports in git
Hi! On Tue, 11 Aug 2015, Duncan wrote: Ryan Hill posted on Mon, 10 Aug 2015 18:17:30 -0600 as excerpted: On Mon, 10 Aug 2015 12:25:58 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: What about: * bug number in summary strongly recommended Making the bug number in the summary manditory or strongly encouraged leads to wonderful commit messages like: --- cat-pkg: Fix bug #504321. Ideally, it'd be something a bit more informative (here taking Gordon's points about the previously suggested B#): cat-egory/semi-long-package-name: fix amd64-fbsd build error G-504321 I would like to see this be more common: --- cat-pkg: Make the thingy work again Gentoo-Bug: https://bugs.gentoo.org/504321 *(or 504321 Idon'tcarewhich) If we're limiting the summary to 1 line, 70-75 chars, manditory cat/package and bug number there's not a lot of room to summarize in. Note that a bug number would fit in your above summary very easily, omitting nothing, as it's only ~35/75 length. Even with my somewhat longer cat/pkg example with the longest arch- keyword I could quickly find, there's still room to indicate at minimum build vs runtime error, with the gentoo bug number reference for anyone who might find it interesting enough to look further than the one-line. People can then either select and klipper-popup (adding my usual trigger method to the others people have mentioned), or read the longer description for the full bug URL to click, if they prefer. The more we stuff into the summary line, the harder it will be to write meaningful summaries. And thus, people will write crappy ones or ignore the length limit. I recommend against any more prescription over Add the the cat/pn if meaningful, don't use more than 75 characters. The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? Regards, Tobias -- Sent from aboard the Culture ship Fine Till You Came Along
Re: [gentoo-dev] Re: useflag policies
What's not clear with 'apropriate' word in my sentence? Let me clarify - if package depend either on Qt4 or Qt5 and CAN not be built with Qt at all - force this behaviour with REQUIRED_USE. I think that it was obvious that i have meant exactly this case, cause other cases are unreasonable here. 09.08.2015 23:07, Alexandre Rostovtsev пишет: On Sun, 2015-08-09 at 22:38 +0300, Sergey Popov wrote: qa team lead hat In short - apropriate REQUIRED_USE with setting recommended USE-flag(e.g. USE=+qt4 qt5 or USE=qt4 +qt5) /qa team lead hat If a package has optional guis, why should users of the default profile get any gui enabled by default? The default profile usually means headless server. It means users who specifically don't need gtk, don't need qt4, don't need qt5, don't need X. So please don't + desktop-oriented USE flags in an ebuild's IUSE by default unless the whole ebuild is intended mainly for desktop users. Users will have default behaviour for empty make.conf. If they adjust they make.conf to globally include/exclude some Qt-related USEs - they are already moving from default and that's why - they can add apropriate options to package.use There is more than one default from which to move away. Different profiles globally enable different flags. Desktop, gnome, and kde profiles already enable qt4 globally. Plasma already enables qt4 and qt5 globally. And the desktop profile will probably end up enabling qt4 and qt5 at some point. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On 08/11/2015 10:12 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 09:56:55 Dmitry Yu Okunev dyoku...@ut.mephi.ru napisał(a): On 08/11/2015 12:06 AM, Michał Górny wrote: 3. Too many text, hard to read. Some bugs may refer to a dozen of URLs. And how is a dozen numbers better? Less text, more readable. How is: Bug: 123451, 453445, 344334, 343444 more readable than: Bug: https://bugs.gentoo.org/123451 Bug: https://bugs.gentoo.org/453445 Bug: https://bugs.gentoo.org/344334 Bug: https://bugs.gentoo.org/343444 Readability is a matter of formatting, not contents. 1. One line and 35 chars are certainly more readable than four lines and 140 chars. Character counts are completely irrelevant to readability. Visual space is. And in this case, exhibit A (also known as wall of digits) is more likely to get people confused. I think it's just individual preference. No sense to argue this. Just everybody should consider that there exists another position on this question. However I want to add an other argument: 1a. It's easier to parse the Bug: header is there only bug IDs (without URLs). What if there are different bug trackers involved? We sometimes note upstream bugs, other distro bugs, pull requests... For example Gentoo may use Gentoo-Bug:/Bug-Gentoo: as I mentioned. Debian uses Bug-Debian: for Debian ITS references and Bug: for upstream bugreport references in their patches (debian/patches/*), IIRC. And is there any guarantee that URL format won't be changed in future (that everybody won't be have to rewrite their parsers). I mean not near future, but any long future. I doubt it can change *without* changing the bug tracker software. And then, old IDs will no longer be relevant. Why? Just migrate with saved IDs. In fact, since the URLs are Bugzilla-specific it will allow us to ensure better compatibility if we start numbering bugs from 1 again. IMHO, it's a really bad idea to do not migrate previous data to the new ITS. There's URL and there's URI. Even if URL is no longer valid, it will still be a valid URI. It will still allow us to uniquely identify the bug report. Only if you will use Bugzilla or some workarounds to imitate Bugzilla. It's a lock-in. 2. Strings are read from left to right (at least in English), thus having most important information last on the line is not convenient. This is not literature. Keys usually precede values, and namespaces precede namespaced identifiers. A commit-comment is not a source code. It's an ordinary text (like literature). Literature is a long continuous text which you read left-to-right, and usually without going back. This is short text which you read randomly, possibly going back and forth, and scanning for specific details. Well, ok. But personally I have a habit to read such text left-to-right. It requires split seconds to recognize this lines similarity but it requires. Anyway as I said, I will see much more garbage while looking on the whole text if you will use URLs instead of pure IDs. As far as I'm aware, URLs are supported much more widely than Gentoo-specific bug numbers. They are uniform and unique by definition. The tools using bug numbers can be easily expanded to extract them from URLs. I don't really see forking cgit to support Gentoo bug numbers, or asking github to provide special rules for our commits. We should not adjust our ecosystem for closed and proprietary solutions like github. URLs are not github invention. Localized bug numbers are local Gentoo non-sense. So should we adjust it to ignore the rest of the world and expect everyone to create custom hackery just to be able to see a bug report? You can use header Gentoo-Bug: (instead of Bug:) and explain in documentation ways to parse that. So you're suggesting it's better to invent a custom format and tell people how to handle it, rather than use a commonly-supported format? What you mean with the custom format? I suggest to use comment as a comment, but not as a documentation about How to reach Gentoo ITS in every comment. I can agree with another argument: There should be a possibility to define an upstream bug which format in turn can be simply unified only by URLs. And it may became harder to read when neighboring headlines are formatted different ways (one header — pure IDs, another one — URLs). But _IMHO_, it doesn't outweigh disadvantages of this approach (with URLs for reference on Gentoo bug). -- Best regards, Dmitry. signature.asc Description: OpenPGP digital signature
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
On 11 August 2015 at 20:38, Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 10:29:55 Alexander Berntsen berna...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/15 22:59, Aaron W. Swenson wrote: Users can fetch/pull from Github. Users should not have to interface with or rely on proprietary software to use Gentoo. Then please provide them with true open-source infrastructure. And also remember to block all the mirrors by default. Its fine to say can in the context of They may if they want to, but they are not forced to. Having a quality infrastructure should happen in parallel to github mirrors. Uses may use the proprietary one or the opensource one. As long as nothing *demands* they use the proprietary instead of the opensource one, and there is a working path that is usable and covenient to avoid the proprietary ( which there is in this case ), then there's no real foul. The only downside is realistically, if all users cloned from gentoo infra using git, then we would drown. Ban mirrors wouldn't fix this problem, Ban github wouldn't fix this problem. So you basically *must* implement a reasonable infrastructure, and they can use github instead if it is more convenient for them. To an extent this does imply we're relying that *some* users will use github/other to decrease our server load. Meh. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/15 22:59, Aaron W. Swenson wrote: Users can fetch/pull from Github. Users should not have to interface with or rely on proprietary software to use Gentoo. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVybKCAAoJENQqWdRUGk8BIWcQANRXyH+ZRJImlbASQM1QSApS hr7Y8xFj8Wm9Ym8gTJCCxyWW8frW7yCyAJByHF6znRCjxl3qRGfKGnMd/gfYR5l8 UmRHVKaqborjzkhd6+W0EtjvxWJ6bwI2FGG4p+xCk7uVAN4V2leu2gxSeUTfWO18 DfJd92y7LM5xrzsmE5KUyB1uaHzdfxbZpR1tHix/jzK6Wpp90/lJVVL3AwnRz6Cu T9TmTXkVnWck7DIHU8OKluxgdKrEbkKRkB5wzgESAHd75T9HvECwBpFcAXkdr4X2 vnYx4+ZXvydgu8WAFimAefbpbQVaCZd8AQ9XFOIo3tiy8di5ALlSKNXG6cdVlsue GaU+qNkJavzOI+QtydJGogY7hhT3rAP1BBeeZxXdTjBO9qQUB3LCcK6IsXtbtQw/ +cbmPJPm4r1wRJD1x7NxU/1LWO3JNTcM1YxvskdKKiDYAnBadMEcjPHWt7vUA8QR GWze8YvcAr6VDjPqd366kM/fvmY4Y/2TNl3wWCB18Nagoq6dx2ba0//4pMUpfOdS /1WDMoJRQ/M4cfShgZvNnvCM7qNcJXzLc68fD1xzzvWEyhkOj/vydeztzNykLzop BUgl08J0jgokbVAwxzlnOubtK2F7vSLu6hFBliVQINoNqbPpTjxE3NIJvPfFkeUL qhbaV+CoPE7MNeH4a0lt =asRz -END PGP SIGNATURE-
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Hello. I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with my lame English here. Please tell me if it's so. On 08/11/2015 12:06 AM, Michał Górny wrote: 3. Too many text, hard to read. Some bugs may refer to a dozen of URLs. And how is a dozen numbers better? Less text, more readable. How is: Bug: 123451, 453445, 344334, 343444 more readable than: Bug: https://bugs.gentoo.org/123451 Bug: https://bugs.gentoo.org/453445 Bug: https://bugs.gentoo.org/344334 Bug: https://bugs.gentoo.org/343444 Readability is a matter of formatting, not contents. 1. One line and 35 chars are certainly more readable than four lines and 140 chars. Character counts are completely irrelevant to readability. Visual space is. And in this case, exhibit A (also known as wall of digits) is more likely to get people confused. I think it's just individual preference. No sense to argue this. Just everybody should consider that there exists another position on this question. However I want to add an other argument: 1a. It's easier to parse the Bug: header is there only bug IDs (without URLs). And is there any guarantee that URL format won't be changed in future (that everybody won't be have to rewrite their parsers). I mean not near future, but any long future. 2. Strings are read from left to right (at least in English), thus having most important information last on the line is not convenient. This is not literature. Keys usually precede values, and namespaces precede namespaced identifiers. A commit-comment is not a source code. It's an ordinary text (like literature). 3. A lot of duplicated and useless information consumes time and space, irritating people. Well, maybe I'm very special then because I can *instantly* notice that the four quoted lines are almost identical and differ only by bug numbers. Yes. But as for me this duplicated text adds a lot of garbage to the total text of a comment. It's harder to fast look over it. You were right — Visual space does matter. And Andrew said useless information — I agree. 4. Think about people using special accessibility devices like speech-to-text engine or Braille terminal. It will be pain for them to read all this notorious URLs. And we have at least one developer relying upon such devices. And that's the first valid argument. Though I would doubt that accessibility software handles random numbers better than URLs. Unless you consider retyping one of the six numbers you just heard easier than triggering some kind of URL activation feature. I remember that William Hubbs asked me to remove one very simple ASCII-arted scheme (that explains how the code works) from a patch, because it's very inconvenient to listen that stuff using speech-to-text engines. May be somebody should just ask him for his opinion on this question? I think it's more convenient to listen pure bug IDs rather than a lot of full URLs. What is a corner case? Why not defining clicking on the link in the git log as a corner case? As far as I'm aware, URLs are supported much more widely than Gentoo-specific bug numbers. They are uniform and unique by definition. The tools using bug numbers can be easily expanded to extract them from URLs. I don't really see forking cgit to support Gentoo bug numbers, or asking github to provide special rules for our commits. We should not adjust our ecosystem for closed and proprietary solutions like github. URLs are not github invention. Localized bug numbers are local Gentoo non-sense. So should we adjust it to ignore the rest of the world and expect everyone to create custom hackery just to be able to see a bug report? You can use header Gentoo-Bug: (instead of Bug:) and explain in documentation ways to parse that. -- Best regards, Dmitry. signature.asc Description: OpenPGP digital signature
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
Dnia 2015-08-11, o godz. 10:29:55 Alexander Berntsen berna...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/08/15 22:59, Aaron W. Swenson wrote: Users can fetch/pull from Github. Users should not have to interface with or rely on proprietary software to use Gentoo. Then please provide them with true open-source infrastructure. And also remember to block all the mirrors by default. -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpQRRnGxpZR1.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
Err, i have read the whole thread and still does not get a point, why i am wrong. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is required, but not both Same thing here, different REQUIRED_USE operator. But - enable one of the flags by default to ease life of users. 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Do not use REQUIRED_USE here, not needed. Now, please tell me, where am i wrong? 09.08.2015 23:08, Davide Pesavento пишет: On Sun, Aug 9, 2015 at 12:38 PM, Sergey Popov pinkb...@gentoo.org wrote: qa team lead hat In short - apropriate REQUIRED_USE with setting recommended USE-flag(e.g. USE=+qt4 qt5 or USE=qt4 +qt5) /qa team lead hat That's most painless decision for both developers and users. Developers do not need to maintain ugly dependencies like DEPEND=qt4 ? ( qt5 ( dev-qt/qtcore:5 ) !qt5 ( dev-qt/qtcore:4 ) ) ... and other mess. /qa team lead hat Users will have default behaviour for empty make.conf. If they adjust they make.conf to globally include/exclude some Qt-related USEs - they are already moving from default and that's why - they can add apropriate options to package.use Sergey, It seems you completely ignored the discussion that took place in this thread (and I also think you misunderstood the scenario judging from the example you gave). Therefore I'm sorry but I will ignore your opinion as QA team lead. Thanks, Davide -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
I think ppc64le would become popular, https://en.wikipedia.org/wiki/Ppc64. 1. enable porting x86 Linux based application with minimal effort. 2. Some PowerPC user, little endian apparently feels cheap, wrong, and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE already support little endian in powerpc. *Leno Hou* E-mail : leno...@gmail.com On Tue, Aug 11, 2015 at 5:49 PM, James Le Cuirot ch...@gentoo.org wrote: On Tue, 11 Aug 2015 17:22:21 +0800 Leno Hou leno...@gmail.com wrote: Please let me know forward/steps to port gentoo on ppc64le. I'm not on the ppc team but I do some ppc(64) testing for Java packages. Although these are relatively well-maintained keywords overall, I think the team would struggle to cope with an additional one. It's also important to note that while ppc and ppc64 can be tested on the same hardware, I think ppc64le would require different hardware? If ppc64le does become popular then I would suggest that we drop 32-bit ppc first. Others may disagree though. :) -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: Referencing bug reports in git
On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote: The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? I think you've misread The rule https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_Message_Format Emphasis added: commits that affect **primarily** a particular subsystem should prepend the following code to the first line of the commit message: **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
Dnia 2015-08-11, o godz. 09:56:55 Dmitry Yu Okunev dyoku...@ut.mephi.ru napisał(a): Hello. I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with my lame English here. Please tell me if it's so. On 08/11/2015 12:06 AM, Michał Górny wrote: 3. Too many text, hard to read. Some bugs may refer to a dozen of URLs. And how is a dozen numbers better? Less text, more readable. How is: Bug: 123451, 453445, 344334, 343444 more readable than: Bug: https://bugs.gentoo.org/123451 Bug: https://bugs.gentoo.org/453445 Bug: https://bugs.gentoo.org/344334 Bug: https://bugs.gentoo.org/343444 Readability is a matter of formatting, not contents. 1. One line and 35 chars are certainly more readable than four lines and 140 chars. Character counts are completely irrelevant to readability. Visual space is. And in this case, exhibit A (also known as wall of digits) is more likely to get people confused. I think it's just individual preference. No sense to argue this. Just everybody should consider that there exists another position on this question. However I want to add an other argument: 1a. It's easier to parse the Bug: header is there only bug IDs (without URLs). What if there are different bug trackers involved? We sometimes note upstream bugs, other distro bugs, pull requests... And is there any guarantee that URL format won't be changed in future (that everybody won't be have to rewrite their parsers). I mean not near future, but any long future. I doubt it can change *without* changing the bug tracker software. And then, old IDs will no longer be relevant. In fact, since the URLs are Bugzilla-specific it will allow us to ensure better compatibility if we start numbering bugs from 1 again. There's URL and there's URI. Even if URL is no longer valid, it will still be a valid URI. It will still allow us to uniquely identify the bug report. 2. Strings are read from left to right (at least in English), thus having most important information last on the line is not convenient. This is not literature. Keys usually precede values, and namespaces precede namespaced identifiers. A commit-comment is not a source code. It's an ordinary text (like literature). Literature is a long continuous text which you read left-to-right, and usually without going back. This is short text which you read randomly, possibly going back and forth, and scanning for specific details. As far as I'm aware, URLs are supported much more widely than Gentoo-specific bug numbers. They are uniform and unique by definition. The tools using bug numbers can be easily expanded to extract them from URLs. I don't really see forking cgit to support Gentoo bug numbers, or asking github to provide special rules for our commits. We should not adjust our ecosystem for closed and proprietary solutions like github. URLs are not github invention. Localized bug numbers are local Gentoo non-sense. So should we adjust it to ignore the rest of the world and expect everyone to create custom hackery just to be able to see a bug report? You can use header Gentoo-Bug: (instead of Bug:) and explain in documentation ways to parse that. So you're suggesting it's better to invent a custom format and tell people how to handle it, rather than use a commonly-supported format? -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpFUxUHmcnoq.pgp Description: OpenPGP digital signature
[gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
Greetings ! Any Ideas/steps of how to porting gentoo on ppc64le architecture? Is it that we should add 'ppc64le' keyword to portage ? As some of you might know, Ubuntu has been introduced in support of ppc64le. http://www.ubuntu.com/download/server/power8 ! It's just as it sounds ppc64( 64bit only ) but little endian. I've been made basic chroot environment in my Ubuntu 14.04 ppc64le manually, the packages was built and you can see here for detail: https://bpaste.net/show/e99035777057 And another way how to porting is: https://wiki.gentoo.org/wiki/Porting Please let me know forward/steps to port gentoo on ppc64le. Appreciated your thoughts, comments and efforts on it ~~~ Leno Hou E-mail: leno...@gmail.com
Re: [gentoo-dev] git commit / push signing error
Hi, On 10/08/15 21:02, Daniel Campbell (zlg) wrote: On 08/10/2015 06:15 AM, Doug Goldstein wrote: On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Doug Goldstein schrieb: gpg: cancelled by user gpg: skipped 0xA2BC03DC87ED1BD4: Operation cancelled gpg: signing failed: Operation cancelled error: gpg failed to sign the data There was an IRC discussion yesterday about this. Probably your pinentry tries to talk to a GUI and fails. Try: unset DISPLAY export GPG_TTY=$(tty) to make it fall back to curses, or use eselect pinentry to select curses as default. Interestingly, git requires GPG_TTY if eselect-pinentry is set to gtk-2 or qt4, but repoman doesn't. Best regards, Chí-Thanh Christopher Nguyễn $ eselect pinentry show Current pinentry binary implementation: pinentry-curses $ eselect pinentry list Available pinentry binary implementations: [1] pinentry-curses * Its the only version I've got on this machine. The box is headless and I ssh into and I use keychain to manage my SSH and GPG agent. What's your keychain line look like in your .bashrc/.bash_profile? Here's the relevant portion of mine. I was also having problems with it until I changed the order of the arguments: [snip] /usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY} source ~/.keychain/sporkbox-sh /dev/null source ~/.keychain/sporkbox-sh-gpg /dev/null [snip] I have it exactly like you but I can reproduce the problem as follows. - I ssh into a long running byobu session on the machine. - I have pinentry-curses eselected 1) Spawn a new shell, keychain runs, pinentry-curses asks for the passphrases that are not cached yet, and everything is fine (in all running shells!). 2) Log off and return only after the passphrase timeout of the agent 3) The problem described in this thread appears, pinentry-curses won't start, both $DISPLAY and $tty are empty. 4) To fix, I just need to run any process that is able to start pinentry-curses and type the passphrase. Keychain is one option for that. git --signed is not. The only thing that is diffent from your setup is that I use zsh. Looking at the scripts created by keychain this should be fine, though. If somebody knows how to configure pinentry curses correctly (in particular with respect to screen/multiplexing and long running sessions, that would be a great help (and wiki addition). Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
On Tue, 11 Aug 2015 17:22:21 +0800 Leno Hou leno...@gmail.com wrote: Please let me know forward/steps to port gentoo on ppc64le. I'm not on the ppc team but I do some ppc(64) testing for Java packages. Although these are relatively well-maintained keywords overall, I think the team would struggle to cope with an additional one. It's also important to note that while ppc and ppc64 can be tested on the same hardware, I think ppc64le would require different hardware? If ppc64le does become popular then I would suggest that we drop 32-bit ppc first. Others may disagree though. :) -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: rsync mirror security
On Mon, Aug 10, 2015 at 11:44 PM, Matthias Maier tam...@gentoo.org wrote: That is, I was under the impression signing a tag only signs the references themselves, and then relies on SHA1 referential integrity beyond that. No, a signed tag verifies that the whole integrirty of the entire repository, whereas a signed commit only authenticates the differences introduced by a single commit. As long as there are no conflicts, a signed commit can be rebased freely (especially also on top of malicious commits...). A signed commit and a signed tag are basically equivalent as far as authentication of the contents of the tree go. All a tag does is reference a commit by sha1, and a commit references the top level directory of the tree by sha1 in the state it was in when it was created. Sure, you can rebase a commit, but that doesn't actually change a commit. It creates one or more new commits in the place of a bunch of existing ones with new sha1s, and points the current head at the last one. If the old commits are no longer referenced by any other heads they will get garbage collected. If you point two heads at the same commit and do a rebase the history as seen by the other head won't change at all. Since a tag is just a label it is actually EASIER to tamper with than a commit. You can't change a commit without changing its hash. tags are referenced by name, not by hash, which is basically the whole point, so you CAN change the content of a tag and have it keep the same name. Of course, if you try to push/pull that new tag git is going to complain about the inconsistency, just as it does if you try to do a non-fast-forward push and so on. I don't think that having a bazillion tags or rewriting them constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). -- Rich
Re: [gentoo-dev] Re: useflag policies
11.08.2015 15:30, Michael Palimaka пишет: On 11/08/15 20:10, Sergey Popov wrote: Err, i have read the whole thread and still does not get a point, why i am wrong. You clearly have not. The reasoning behind Qt team's policy is described on the page and has been reiterated on this list. You are undermining what little confidence there is in the QA team by making decisions with no consultation about problems you do not understand. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. User choice of using USE flags is NOT a problem 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is required, but not both Same thing here, different REQUIRED_USE operator. But - enable one of the flags by default to ease life of users. Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. Same here 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Do not use REQUIRED_USE here, not needed. Now, please tell me, where am i wrong? The problem is manual intervention is required if the user has both qt4 and qt5 USE flags enabled - and this is a common configuration. It is not acceptable to make a user manually add numerous package.use entries when all they want to do is install KDE. And here I agree Qt's policy is not a perfect solution, but in the absence of some feature allowing a preference to be set when there is a conflict it's the best we've got. If you want to go this way, then please provide helper functions in eclasses to set dependencies properly for all common use cases. That will ease life both of developers and users. Leaving constructing of dependencies to developers in all cases will cause only pain in your solution. Look at the example with berkdb/gdbm, that i have posted recently. If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
11.08.2015 15:32, Michael Palimaka пишет: On 11/08/15 20:17, Sergey Popov wrote: 09.08.2015 23:28, Ulrich Mueller пишет: I disagree with this. Really, REQUIRED_USE should be used sparingly, and IMHO the above is not a legitimate usage case for it. So, you prefer to make ugly mess of deps here like i posted before or introduce some really unneded USE-flag like 'gui', 'qt', etc. to make users even more confused? Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags. And dependency string like this: !berkdb? ( !gdbm? ( sys-libs/gdbm ) ) One sentence: WHAT THE HELL? Imagine that it would be dozen of flags. Is it fun to mess with deps like this for you? Shall we ban this too? ffmpeg? ( libav? ( media-video/libav:= ) !libav? ( media-video/ffmpeg:0= ) ) No, because ffmpeg here is a feature AND name of concrete realization. Not ideal case as i would said, but it is acceptable. You want to migrate to such decision? Like: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. As i said one message earlier: Something like $(qt_use_default qtgui 5) which will generate something like this: qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) !qt5? ( !qt4? ( dev-lang/qtcore:5 ) ) would help too. If you are doing complicated things(and please, do not tell me that provided dependency string is simple and understandable by every developer in just a second without wanting to improve or simplify it) - do it through eclass. And provide nice API. Thanks for listening and sorry if i was too harsh -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
11.08.2015 13:18, Georg Rudoy пишет: You missed the fourth option: the package can not be built without Qt GUI, but it supports building with either Qt version at the same time. Not a problem. REQUIRED_USE=|| ( qt4 qt5 ) At least one of flags should be enabled, but both can be enabled too(if i understand your example correctly) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
2015-08-11 11:10 GMT+01:00 Sergey Popov pinkb...@gentoo.org: 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Take app-text/poppler as an officially supported example. Take x11-libs/qwt as an example of a library that gets a patched library name to avoid collisions (at least, last time I looked into it). I would argue this is a very desirably property for libraries in general. I even keep my own small overlay with Qt5-enabled versions of libraries like qxmpp, qtermwidget or liblastfm. Do not use REQUIRED_USE here, not needed. You missed the fourth option: the package can not be built without Qt GUI, but it supports building with either Qt version at the same time. -- Georg Rudoy
[gentoo-dev] Re: useflag policies
I'd suggest to make a QA team meeting to override this policies with more correct and rationale. Qt team members are greatly appreciated on this meeting. Even more, i think that we should not take any decision on this without at least Qt team lead(or half of Qt team devs) So, let's arrange some time and talk about this, cause it is really confusing. Qt team point is understandable, but it's still wrong. Let's make some consensus here. 02.08.2015 19:34, Ben de Groot пишет: Recently some team members of the Qt project have adopted these ebuild policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies I have an issue with the policy adopted under Requires one of two Qt versions. In my opinion, in the case where a package offers a choice between qt4 or qt5, we should express this in explicit useflags and a REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice. Other developers state that users are not interested in such implementation details, or that forced choice through REQUIRED_USE is too much of a hassle. This results in current ebuilds such as quassel to not make it clear that qt4 is an option. This goes against the principle of least surprise, as well as against QA recommendations. I would like to hear specifically from QA about how we should proceed, but comments from the wider developer community are also welcome. -- Cheers, Ben | yngwin Gentoo developer -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/microcode-ctl/
On 08/11/2015 08:34 AM, Mike Frysinger wrote: commit: 719cc5ef240b766953ddbe1e7a6593f8091eed12 Author: Mike Frysinger vapier AT gentoo DOT org AuthorDate: Tue Aug 11 06:28:16 2015 + Commit: Mike Frysinger vapier AT gentoo DOT org CommitDate: Tue Aug 11 06:34:22 2015 + URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=719cc5ef microcode-ctl: stop installing the init script Updating microcode on the fly is dangerous as it can modify the set of valid instructions. An active example of this is Intel's TSX insns -- the latest microcode push disables the insn on newer CPUs and causes SIGILL when you try to use it. But if you test for the insn before the microcode is updated, it will execute fine. For daemons that launched before the update, they'll find the flag works, and then crash later on when the insn no longer exists. Thus the only safe way to update microcode is at boot time via a builtin initramfs. Details on this operation can be found in #528712#41. I've already asked you twice on the ML why you keep ignoring the standard we set for the commit message summary and pretty much everyone is following except you. Do you ignore us on purpose?
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
On Tue, 11 Aug 2015 10:29:55 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 10/08/15 22:59, Aaron W. Swenson wrote: Users can fetch/pull from Github. Users should not have to interface with or rely on proprietary software to use Gentoo. Like the stuff running on the big expensive routers that make the internets work? Can I have my tree delivered by pigeon, since I suspect the post office runs Windows? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Referencing bug reports in git
On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote: On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote: The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group ++ Go read the proposal. This email chain simplifies it but people have already thought of most of those corner cases already. However, I do want to touch on this bit from the previous email: Or should that be split into 100 commits for easier partial rollback? Each commit should be one logical change. If you stabilize 100 separate packages in an afternoon, there should be 100 commits. If you stabilize kde-5.0 there probably should be one commit that touches 100 packages. Likewise if you rename a package and fix 100 references to it in other packages, that should probably also be a single commit (but I'd separate renaming the package from any other changes to the content of the package). That is actually one of the advantages of git. You can stabilize kde-5 and a user doing an rsync will either get kde 4.x or the full kde 5, and nothing in-between. But, one commit in the final tree should still remain one logical change. -- Rich
Re: [gentoo-dev] Re: useflag policies
11.08.2015 16:04, Sergey Popov пишет: 11.08.2015 15:32, Michael Palimaka пишет: On 11/08/15 20:17, Sergey Popov wrote: 09.08.2015 23:28, Ulrich Mueller пишет: I disagree with this. Really, REQUIRED_USE should be used sparingly, and IMHO the above is not a legitimate usage case for it. So, you prefer to make ugly mess of deps here like i posted before or introduce some really unneded USE-flag like 'gui', 'qt', etc. to make users even more confused? Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags. And dependency string like this: !berkdb? ( !gdbm? ( sys-libs/gdbm ) ) One sentence: WHAT THE HELL? Imagine that it would be dozen of flags. Is it fun to mess with deps like this for you? Shall we ban this too? ffmpeg? ( libav? ( media-video/libav:= ) !libav? ( media-video/ffmpeg:0= ) ) No, because ffmpeg here is a feature AND name of concrete realization. Not ideal case as i would said, but it is acceptable. You want to migrate to such decision? Like: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. As i said one message earlier: Something like $(qt_use_default qtgui 5) which will generate something like this: qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) !qt5? ( !qt4? ( dev-lang/qtcore:5 ) ) would help too. If you are doing complicated things(and please, do not tell me that provided dependency string is simple and understandable by every developer in just a second without wanting to improve or simplify it) - do it through eclass. And provide nice API. Thanks for listening and sorry if i was too harsh Oops, sorry dev-qt/qtgui inside the brackets, of course. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
11.08.2015 16:11, James Le Cuirot пишет: On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov pinkb...@gentoo.org wrote: If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled That sounds a little bit like what I suggested earlier. https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df But without introducing brand new useless USE flag. Which makes huge difference to me :-) -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
09.08.2015 23:28, Ulrich Mueller пишет: I disagree with this. Really, REQUIRED_USE should be used sparingly, and IMHO the above is not a legitimate usage case for it. So, you prefer to make ugly mess of deps here like i posted before or introduce some really unneded USE-flag like 'gui', 'qt', etc. to make users even more confused? Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags. And dependency string like this: !berkdb? ( !gdbm? ( sys-libs/gdbm ) ) One sentence: WHAT THE HELL? Imagine that it would be dozen of flags. Is it fun to mess with deps like this for you? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
On Tue, Aug 11, 2015 at 5:07 AM, Kent Fredric kentfred...@gmail.com wrote: Having a quality infrastructure should happen in parallel to github mirrors. Uses may use the proprietary one or the opensource one. While I generally tend to agree with you, if we're just talking about mirroring is this a real problem? Right now Gentoo has a large number of rsync/http mirrors. As far as any of us are concerned, they're just an DNS address that speaks rsync/http. None of us have any idea what OS or software they're running. If one of our mirrors is IIS running on Windows 7, that is pretty transparent to the end user. They're just mirrors. That is basically all github is in this case. A commit shows up in the gentoo infra repository, and some process somewhere pushes it to the github repository. If we were to set up an independent network of git mirrors, they'd probably work the same way. (Git should actually be pretty easy to mirror.) To an end user all they see is a DNS name that talks whatever protocol git uses. Short of an on-site inspection you'd never be able to prove that it is actually FOSS. Apologies if I sounds like an MS open standards, not open source shill - but to some extent when you're talking about networked services they work out to be the same thing. I think it is far more important to keep the infrastructure that creates the tree pure-FOSS (and documented/published so that anybody who wants to could basically roll their own Gentoo). If we use a more commercial service to just help scale it up like a CDN or something like github, that isn't really as essential to the essence of Gentoo. I do think that people who complain about depending on a github-based workflow have a legitimate concern, but that isn't what we're talking about here. In any case, nobody is getting rid of the rsync mirrors anytime soon, so we don't have to be in any rush to figure this out. Consider this thinking out loud if you will... -- Rich
Re: [gentoo-dev] Re: Referencing bug reports in git
On 08/11/2015 01:49 PM, Rich Freeman wrote: On Tue, Aug 11, 2015 at 5:12 AM, Kent Fredric kentfred...@gmail.com wrote: On 11 August 2015 at 20:57, Tobias Klausmann klaus...@gentoo.org wrote: The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? **if the change affects multiple directories**, but is mostly related to a particular subsystem, then prepend the subsystem which best reflects the intention (e.g. you add a new license, but also modify profiles/license_group ++ Go read the proposal. This email chain simplifies it but people have already thought of most of those corner cases already. However, I do want to touch on this bit from the previous email: Or should that be split into 100 commits for easier partial rollback? Each commit should be one logical change. If you stabilize 100 separate packages in an afternoon, there should be 100 commits. If you stabilize kde-5.0 there probably should be one commit that touches 100 packages. Likewise if you rename a package and fix 100 references to it in other packages, that should probably also be a single commit (but I'd separate renaming the package from any other changes to the content of the package). That is actually one of the advantages of git. You can stabilize kde-5 and a user doing an rsync will either get kde 4.x or the full kde 5, and nothing in-between. But, one commit in the final tree should still remain one logical change. Right. In addition, we just took the freedom to add the clause all commits must be repoman-valid: https://wiki.gentoo.org/index.php?title=Gentoo_git_workflowdiff=352978oldid=352858 That will be necessary too for the CI work mgorny is doing and will also make bisecting and cherry-picking easier. That is: if splitting up a commit into several makes repoman fail on some of them, it probably should be one commit instead (or you have to reconsider the order you commit stuff in... e.g. first add the license and then the package). But we are drifting OT again.
[gentoo-dev] Re: useflag policies
On 11/08/15 20:10, Sergey Popov wrote: Err, i have read the whole thread and still does not get a point, why i am wrong. You clearly have not. The reasoning behind Qt team's policy is described on the page and has been reiterated on this list. You are undermining what little confidence there is in the QA team by making decisions with no consultation about problems you do not understand. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is required, but not both Same thing here, different REQUIRED_USE operator. But - enable one of the flags by default to ease life of users. Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Do not use REQUIRED_USE here, not needed. Now, please tell me, where am i wrong? The problem is manual intervention is required if the user has both qt4 and qt5 USE flags enabled - and this is a common configuration. It is not acceptable to make a user manually add numerous package.use entries when all they want to do is install KDE. I agree Qt's policy is not a perfect solution, but in the absence of some feature allowing a preference to be set when there is a conflict it's the best we've got.
[gentoo-dev] Re: useflag policies
On 11/08/15 20:17, Sergey Popov wrote: 09.08.2015 23:28, Ulrich Mueller пишет: I disagree with this. Really, REQUIRED_USE should be used sparingly, and IMHO the above is not a legitimate usage case for it. So, you prefer to make ugly mess of deps here like i posted before or introduce some really unneded USE-flag like 'gui', 'qt', etc. to make users even more confused? Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags. And dependency string like this: !berkdb? ( !gdbm? ( sys-libs/gdbm ) ) One sentence: WHAT THE HELL? Imagine that it would be dozen of flags. Is it fun to mess with deps like this for you? Shall we ban this too? ffmpeg? ( libav? ( media-video/libav:= ) !libav? ( media-video/ffmpeg:0= ) )
Re: [gentoo-dev] Re: useflag policies
On Tue, 2015-08-11 at 16:04 +0300, Sergey Popov wrote: You want to migrate to such decision? Like: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. That flag should be called gui. Not qt. This would be the real solution to gnome team's gtk/gtk2/gtk3 flag problem and to qt team's flag problem too. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: useflag policies
On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov pinkb...@gentoo.org wrote: If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled That sounds a little bit like what I suggested earlier. https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: useflag policies
11.08.2015 16:30, Michael Palimaka пишет: Don't forget that as a project with no special authority, Qt's policy remains a suggestion for the vast majority of maintainers. If someone wishes to provide support for only one Qt version or abuse their users with REQUIRED_USE they are still free to do so. Not enforcing policies on main tree is a bad thing. If you make policy, make other maintainers follow it. I am not against consistent policy that ease life BOTH for developers and users. You think that REQUIRED_USE is abusive to users: fine. Point accepted. I think that provided DEPEND strings if they will be typed at every single qt-related ebuild that needs them are abusive to developers. So, maybe we should wrap them into eclass and stop riding our own bicycles... And then - use apropriate one-liner where it's needed, providing reasonable default and NOT confusing users with overmanaging their package.use -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
On Tue, Aug 11, 2015 at 8:26 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 11 Aug 2015 10:29:55 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 10/08/15 22:59, Aaron W. Swenson wrote: Users can fetch/pull from Github. Users should not have to interface with or rely on proprietary software to use Gentoo. Like the stuff running on the big expensive routers that make the internets work? Can I have my tree delivered by pigeon, since I suspect the post office runs Windows? Only if that pigeon has had its personal genome sequenced. BTW, did I mention that once we get all the dev gpg keys sorted out we're going to need a cheek swab from everybody? -- Rich
[gentoo-dev] Summary line (was: Re: Referencing bug reports in git)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 04:57 AM, Tobias Klausmann wrote: The more we stuff into the summary line, the harder it will be to write meaningful summaries. And thus, people will write crappy ones or ignore the length limit. I recommend against any more prescription over Add the the cat/pn if meaningful, don't use more than 75 characters. The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? Regards, Tobias The summary line limit is going to be a real issue, tbh. I think it would probably be best to adopt the convention of putting a few choice, perhaps even canned, phrases in the summary line, and ensure any and all details (effectively what the summary line used to be for when it had practically no limit) within the commit message body instead . Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. 'Fix bug' IMO in the summary doesn't work at all because, although its accurate, that bug could literally be anything at all. Multi-package commits are going to be more of an issue of course.. I did one last night, fortunately I think I can get away with using mozilla packages in place of cat/pn since it is a very specific set of packages. Perhaps for sweeping changes like that we can use the herdname or projectname or the category name (if its a particular category only)? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKBpIACgkQAJxUfCtlWe3pQgD8Ct1elGvDIObKKvskQJ1jCZIK cYvuWdMD7pobr/hH6iIA/jnYirAb9CDe4iNlVPqG2AKYbj9NJdGnpoL/TFhJtj8U =vnTb -END PGP SIGNATURE-
Re: [gentoo-dev] Summary line (was: Re: Referencing bug reports in git)
On 12 August 2015 at 02:28, Ian Stakenvicius a...@gentoo.org wrote: Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. I personally find those summaries a bit too terse. Mostly, because when I see A version is bumped I immediately expect to know which version the bump is to, but have to dig out the diff to find out. I would also prefer, where possible, to replace adjusted dependencies to be more concise, like include dev-perl/Foo in dependencies, ( though of course, apply some taste, listing more than 3 distinct new dependencies in the summary is execessive, treat them like hashtags on twitter, 1 is good, 2 is OK, 3 and you're starting to get crazy ) Multi-package commits are going to be more of an issue of course.. I did one last night, fortunately I think I can get away with using mozilla packages in place of cat/pn since it is a very specific set of packages. Perhaps for sweeping changes like that we can use the herdname or projectname or the category name (if its a particular category only)? Agreed. If you need multi-package changes and you can't think of a good category prefix to use, the commit message should visibly acknowledge that its a multi-package commit of some kind, and the *kind* of change should be very clear. Just keep in mind really the recommendations for prefix naming are descriptive, not prescriptive, and interpretation and good taste need to be applied everywhere. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Developer branches on proj/gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 10:01 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branch es etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Examples in particular I can think of for something like this being useful would be for, say, major EAPI-bump-related feature implementations (ie, EAPI5 and slot-operators/subslots), or major across-tree impementation changes like what we saw with the multilib-eclass porting. These are large projects touching most if not all ebuilds, that a great many developers would or should be involved in. Something like this could be done in a separately hosted repo instead of in the main gentoo repo, but then all developers would need to subscribe to this other repo, while having it in a branch in the main one i think would make it easier for everyone to get involved once they're ready, and would still allow the changes to stay out of the master branch until the project is ready to launch. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKEK8ACgkQAJxUfCtlWe35RwEAi2VkkJkCWXCh6tJhEKDbfmzY fP3rh20RURm84+8K2ysA/2u3dcTukXlGcLHW2xRSR/bjx5be1X+IL8A48bsqgujr =uppX -END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 10:19 AM, Rich Freeman wrote: On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:36, Rich Freeman пишет: On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:11, James Le Cuirot пишет: On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov pinkb...@gentoo.org wrote: If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled That sounds a little bit like what I suggested earlier. https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d 629b1dc9b30df But without introducing brand new useless USE flag. Which makes huge difference to me :-) If we want the typical user to not set either qt4 or qt5, are we saying that any package that could use either always enable one of them by default? Then all users get a GUI by default, and then users have to explicitly disable it? That seems to be the opposite of how we normally do things, but it does let you get away from having lots of users turning on qt. I suggested this for packages, where GUI can not be disabled AND it should be either qt4 or qt5. Then, if we do not add + to USE description, users without anything in make.conf just run the blocker What if the GUI can be disabled? Should we force users to set USE=-qt4 -qt5 to disable the GUI? Or should we force users to put one of those in their make.conf or profile to enable it (causing problems with packages that don't allow both)? I think the idea with USE=gui is that the generic profiles then no longer need any qt4/qt5/gtk3/whatever flags in them at all, and the ebuilds themselves can set a single default-enable on the particular flag that should be used by default, thus allowing REQUIRED_USE to be satisfied by default when an end-user doesn't care. However, I agree that USE=gui still has the problem where the sub-flags have active state in VDB, meaning that any change to the sub-flags will trigger rebuilds on -N even if USE=-gui. And since (if i understand this thread correctly) part of the reason for doing all of this is to ensure VDB is as accurate as possible to what the package actually uses/needs/depends on/etc, we end up not having solved anything. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKEmUACgkQAJxUfCtlWe3fowEA6Sx5CtDme6K2h5Yu0yYrfUnb 2ZunvwQFlv4QAD+fQ1wA/3aX/kfviD+FttzxHgWBH3uGg1SX8DHNCFptfv9y2lJe =6i3x -END PGP SIGNATURE-
[gentoo-dev] Developer branches on proj/gentoo
Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. proj/gentoo should be kept for serious business i.e. commits that affects the tree. On the long run, if everybody goes down that road, we will see flourish numerous branches (who said unmaintained?), all stalled at a different state of the main repo, and it will only generate a lot of noise and confusion for nothing. Further, since we've moved over to git, the main tree now gets replicated to github and we all have github accounts here, don't we? Which makes the whole forking and submitting PRs a cinch. If a developer wants to tinker with the tree, he can fork it to its github devspace, fiddle around, and later on send us a PR back with his changes to merge. Cheers, Patrice
Re: [gentoo-dev] Developer branches on proj/gentoo
Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpEZol2EBxlc.pgp Description: OpenPGP digital signature
[gentoo-dev] Re: useflag policies
On 11/08/15 23:04, Sergey Popov wrote: 11.08.2015 15:32, Michael Palimaka пишет: On 11/08/15 20:17, Sergey Popov wrote: 09.08.2015 23:28, Ulrich Mueller пишет: I disagree with this. Really, REQUIRED_USE should be used sparingly, and IMHO the above is not a legitimate usage case for it. So, you prefer to make ugly mess of deps here like i posted before or introduce some really unneded USE-flag like 'gui', 'qt', etc. to make users even more confused? Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags. And dependency string like this: !berkdb? ( !gdbm? ( sys-libs/gdbm ) ) One sentence: WHAT THE HELL? Imagine that it would be dozen of flags. Is it fun to mess with deps like this for you? Shall we ban this too? ffmpeg? ( libav? ( media-video/libav:= ) !libav? ( media-video/ffmpeg:0= ) ) No, because ffmpeg here is a feature AND name of concrete realization. Not ideal case as i would said, but it is acceptable. You want to migrate to such decision? Like: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. This looks fine to me - I have no particular solution preference. I understand there's been objection to generic GUI USE flags in the past though. As i said one message earlier: Something like $(qt_use_default qtgui 5) which will generate something like this: qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) !qt5? ( !qt4? ( dev-lang/qtcore:5 ) ) would help too. If you are doing complicated things(and please, do not tell me that provided dependency string is simple and understandable by every developer in just a second without wanting to improve or simplify I disagree but we're getting offtopic. The thread was raised regarding support of packages that at-most-one-of qt4 or qt5. Ben is of course right that for these packages, USE=qt4 qt5 automagically selecting qt5 is not the clearest result and has the potential for confusion. I feel that usability benefit of this choice outweighs the negatives. This leaves only a few options: 1. Leave the policy recommendation as-is (letting maintainers adopt or ignore it as they see fit) 2. Veto the policy recommendation and force something different (maintainers who disagree will likely either drop support for multiple qt versions or stop maintaining the package completely) 3. Create a whole new solution like USE=gui (what happens if I have multiple gui implementation USE flags set?)
[gentoo-dev] [PATCH repositories.dtd] Support multiple owner/ elements
Hello, A quick patch for review. It changes the DTD for repositories.xml to support multiple owner/ tags. We have at least one repository with more than one owner, and I don't really see creating aliases for our users just to support that. Any comments? Index: repositories.dtd === RCS file: /var/cvsroot/gentoo/xml/htdocs/dtd/repositories.dtd,v retrieving revision 1.1 diff -u -B -r1.1 repositories.dtd --- repositories.dtd12 Oct 2009 19:06:08 - 1.1 +++ repositories.dtd11 Aug 2015 14:14:28 - @@ -21,7 +21,7 @@ xmlns CDATA #FIXED '' version CDATA #FIXED '1.0' -!ELEMENT repo (name,(description)+,(longdescription)*,(homepage)?,owner,(source)+,(feed)*) +!ELEMENT repo (name,(description)+,(longdescription)*,(homepage)?,(owner)+,(source)+,(feed)*) !ATTLIST repo xmlns CDATA #FIXED '' priority CDATA #IMPLIED -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpFJdIhtwaNP.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: useflag policies
On Wed, 2015-08-12 at 00:02 +1000, Michael Palimaka wrote: 3. Create a whole new solution like USE=gui (what happens if I have multiple gui implementation USE flags set?) This is what I would suggest. It would remove 90% of the problem since most applications use only one gui toolkit. If no toolkit USE flags are set, go with the best (most stable, best supported) toolkit. If multiple flags are set - here you have a choice. The user-friendly approach is to add some logic to find the best toolkit out of the ones for which a flag is set (this gets complicated in the theoretical case of three toolkits). However, the user-friendly approach is completely unworkable when there are reverse dependencies on your package (plugins for example) that require a specific toolkit. So a better choice might be REQUIRED_USE, *but* then you must adjust package.use in all profiles to allow your package to be emerged without forcing a user to manually set/unset flags. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: useflag policies
On Tue, Aug 11, 2015 at 9:42 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:36, Rich Freeman пишет: On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:11, James Le Cuirot пишет: On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov pinkb...@gentoo.org wrote: If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled That sounds a little bit like what I suggested earlier. https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df But without introducing brand new useless USE flag. Which makes huge difference to me :-) If we want the typical user to not set either qt4 or qt5, are we saying that any package that could use either always enable one of them by default? Then all users get a GUI by default, and then users have to explicitly disable it? That seems to be the opposite of how we normally do things, but it does let you get away from having lots of users turning on qt. I suggested this for packages, where GUI can not be disabled AND it should be either qt4 or qt5. Then, if we do not add + to USE description, users without anything in make.conf just run the blocker What if the GUI can be disabled? Should we force users to set USE=-qt4 -qt5 to disable the GUI? Or should we force users to put one of those in their make.conf or profile to enable it (causing problems with packages that don't allow both)? -- Rich
Re: [gentoo-dev] Developer branches on proj/gentoo
On 8/11/15 10:19 AM, hasufell wrote: On 08/11/2015 04:10 PM, Alexis Ballier wrote: On Tue, 11 Aug 2015 16:01:05 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Then we should define 'caution' I think :) I would not say caution so much as good judgment. The first example that came to mind was working with the profiles which crosses many directories and files. In the past when I did restructuring to the hardened profiles, I tested by using a branch of the hardened-dev overlay. It was annoying and I would do a bind mount over /usr/portage/profiles and had to rebase manually. A test branch of the the main tree which could get rebased and eventually merged back would make the workflow so much better. Another example was when we revitalized the selinux policies. There were hundreds of commits to be done. A branch here that got merged back would be ideal. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Summary line
11.08.2015 17:36, hasufell пишет: On 08/11/2015 04:28 PM, Ian Stakenvicius wrote: On 11/08/15 04:57 AM, Tobias Klausmann wrote: The more we stuff into the summary line, the harder it will be to write meaningful summaries. And thus, people will write crappy ones or ignore the length limit. I recommend against any more prescription over Add the the cat/pn if meaningful, don't use more than 75 characters. The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? Regards, Tobias The summary line limit is going to be a real issue, tbh. I think it would probably be best to adopt the convention of putting a few choice, perhaps even canned, phrases in the summary line, and ensure any and all details (effectively what the summary line used to be for when it had practically no limit) within the commit message body instead . Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. 'Fix bug' IMO in the summary doesn't work at all because, although its accurate, that bug could literally be anything at all. Multi-package commits are going to be more of an issue of course.. I did one last night, fortunately I think I can get away with using mozilla packages in place of cat/pn since it is a very specific set of packages. Perhaps for sweeping changes like that we can use the herdname or projectname or the category name (if its a particular category only)? The CATEGORY: prefix is already in the wiki. Interesting idea about projectname/herdname prefix. I've already seen someone (I think ulm) prefixing with [QA]. I don't feel strong about this. IMO, if there is no useful prefix... just don't use any. The lack of prefix will make it obvious that this is a larger change. But project/herd specific prefixes could still make sense. Mgorny has commited a fix to live portage https://github.com/gentoo/portage/commit/46dafadff58da0220511f20480b73ad09f913430 I think it will be in the tree soon.
[gentoo-dev] Re: useflag policies
On 12/08/15 00:29, Rich Freeman wrote: On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:30, Michael Palimaka пишет: Don't forget that as a project with no special authority, Qt's policy remains a suggestion for the vast majority of maintainers. If someone wishes to provide support for only one Qt version or abuse their users with REQUIRED_USE they are still free to do so. Not enforcing policies on main tree is a bad thing. If you make policy, make other maintainers follow it. I am not against consistent policy that ease life BOTH for developers and users. ++ I think the qt team taking the lead on this makes sense, but this is the sort of thing that just makes sense as a treewide policy. If people don't like their suggested policy they can take it to QA/council/whatever, but it makes more sense to have projects setting standards than having everybody doing their own thing. I realize this is frustrating and contentious, but I think we're better off hashing this out, and implementing something reasonable, than having a bazillion different conventions that users have to deal with. Usually I prefer maintainer autonomy, but this is just one of those times it doesn't make sense. Isn't this moving towards a situation that we used GLEP 39 to remove?
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
On 8/11/15 10:33 AM, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 06:11 AM, Leno Hou wrote: I think ppc64le would become popular, https://en.wikipedia.org/wiki/Ppc64. 1. enable porting x86 Linux based application with minimal effort. 2. Some PowerPC user, little endian apparently feels cheap, wrong, and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE already support little endian in powerpc. In terms of the codepaths, what's different between ppc64le vs ppc64, and ppc64le vs amd64 ? Obviously kernels will differ, but in terms of C/C++/other compiled source code what needs to change? If all this needs is its own profile for a CHOST/CBUILD specification and it can leverage an existing keyword, then this should be rather simple to implement yes? We would leverage this on ppc64 keyword. It is a bit dangerous to claim that a pkg stable on ppc64 is stable on ppc64le, but we would live with that risk. Ideally you should test on both. The situation is analogous to mips where there are many different ISAs and both be and le. It is one of the reasons mips is hard to move back into stable. But having stable keywords is really nice when it comes to building and maintaining stages and keeping base pkgs versions in sync with the other arches. For this reason, I would even been in favor of restoring stable mips with the understanding that stable carries something of a risk when crossing the be/le boundry, or the mips I vs mips III, or 32 vs 64, etc. Having said that, what would break? Assembly and other code that makes assumption about byte order. There is some out there, but not much. We'll deal with it when we hit it. Any of the heavy duty stuff, like syscall interfaces or setjmp/longjmp etc, should be relegated to the libc and kernel. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKB7UACgkQAJxUfCtlWe1sbQD+KcbYpfo56GrLIVlFyw2iXbMB ZOWzuvyI8SVq/DY0SQMBAJgDIjCza8QyUgWEtq2/g5Yu+uWiCibf2ouMeNAOkQ33 =YoUg -END PGP SIGNATURE- -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: rsync mirror security
constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). It is news to me that a signature from a push is also transported to a subsequent pull request for a client, do you have some external references for this procedure? Regardless of the technical implementation, the fact still remains that with the current git repositories (gentoo and the one populated with metadata from gentoo-mirror) we might have another way of providing a signed and tamper-proof [1] ebuild tree (apart from our daily, signed snapshots). Best, Matthias [1] At least as long our git infrastructure is not compromised... signature.asc Description: PGP signature
Re: [gentoo-dev] Re: useflag policies
11.08.2015 16:36, Rich Freeman пишет: On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:11, James Le Cuirot пишет: On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov pinkb...@gentoo.org wrote: If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled That sounds a little bit like what I suggested earlier. https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df But without introducing brand new useless USE flag. Which makes huge difference to me :-) If we want the typical user to not set either qt4 or qt5, are we saying that any package that could use either always enable one of them by default? Then all users get a GUI by default, and then users have to explicitly disable it? That seems to be the opposite of how we normally do things, but it does let you get away from having lots of users turning on qt. I suggested this for packages, where GUI can not be disabled AND it should be either qt4 or qt5. Then, if we do not add + to USE description, users without anything in make.conf just run the blocker -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Quality Assurance project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Developer branches on proj/gentoo
Hi! On Tue, 11 Aug 2015, Michał Górny wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. I agree with monsierp here, person-level stuff should not be in the official repo. Also note that not in the main repo does not mean non-public. People (and projects) can always publish their version of the tree somewhere else. I personally even dislike the project branches, but those I am more willing to accept. Regards, Tobias PS: Call me a pessimist, but every time I see if it's used with caution, I think: yeah, but it won't. -- Sent from aboard the Culture ship Fine Till You Came Along
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, 11 Aug 2015 16:01:05 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Then we should define 'caution' I think :) Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Most, if not all, projects I've seen use forks for this. This doesn't prevent being public but gives a clear definition of what 'caution' is. Branches are usually reserved for releases maintainance. Alexis.
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/2015 16:32, Michał Górny wrote: Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. I like the idea, sounds very handy I have two ideas right now: 1. creating GitHub Gentoo project teams corresponding to willing Gentoo teams, 2. preparing lists of GitHub usernames on project wiki pages. Solution 1. is cleaner. In this case, we create GitHub teams under the Gentoo projects, and add appropriate Gentoo developers having GitHub accounts to the teams. Then, in PRs we can just ping the whole team like @Gentoo/Qt or like. +1 imho, clean simple, only team and ppl willing to participate can get there Solution 2. avoids adding any GitHub teams. In this case, in team wiki page we collect team member usernames like @Pesa, @kensington, ... so we could copy-paste it to pull requests. We still require extra effort when 'assigning' PRs but at least I don't have to lookup the same people over and over again. With some Wiki people help, we could even implement updating GitHub teams automatically following Wiki member changes. Your thoughts? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKCqsACgkQKiQSS7ZY+hNd9AD9FBXc16nF9sp2Xk1gBpXsduGt a2+f1tHSMN9ChSrCBM4A/Ao1nCfMNBEaI9WYBUOQ0Cti5hkjM9X66sMlnszsBahP =GS6Q -END PGP SIGNATURE-
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 08:58 AM, Sergey Popov wrote: 11.08.2015 15:30, Michael Palimaka пишет: On 11/08/15 20:10, Sergey Popov wrote: Err, i have read the whole thread and still does not get a point, why i am wrong. You clearly have not. The reasoning behind Qt team's policy is described on the page and has been reiterated on this list. You are undermining what little confidence there is in the QA team by making decisions with no consultation about problems you do not understand. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. User choice of using USE flags is NOT a problem 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is required, but not both Same thing here, different REQUIRED_USE operator. But - enable one of the flags by default to ease life of users. Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. Same here 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Do not use REQUIRED_USE here, not needed. Now, please tell me, where am i wrong? The problem is manual intervention is required if the user has both qt4 and qt5 USE flags enabled - and this is a common configuration. It is not acceptable to make a user manually add numerous package.use entries when all they want to do is install KDE. And here I agree Qt's policy is not a perfect solution, but in the absence of some feature allowing a preference to be set when there is a conflict it's the best we've got. If you want to go this way, then please provide helper functions in eclasses to set dependencies properly for all common use cases. That will ease life both of developers and users. Why do you need this? #1, if you really want RDEPEND to only include the deps the package will actually use, then you do this: old: qt5? ( list of qt5 atoms ) qt4? ( list of qt4 atoms ) ..to new: qt5? ( list of qt5 atoms ) !qt5? ( qt4? ( list of qt4 atoms ) ) BUT I would advise against this. If a user has specified both qt4 and qt5 in USE, then I see no problem with the VDB having both qt4 and qt5 atoms listed as dependencies. End-users that want a clean VDB can just make sure they only enable one flag, but end-users that don't care will have packages that just work. Leaving constructing of dependencies to developers in all cases will cause only pain in your solution. It really wont, see above. At minimum, it's barely any more work than it is with a REQUIRED_USE based solution. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKDTkACgkQAJxUfCtlWe09QAD/ST47V7i08k09c8o+dgMx8hQP cRyBiTzxHKKtQ3aqmKIBAIdjBB4rGZLLMjiu9l0KfUOkOT1J+Z8oHPWQhzDPJpqv =LCgR -END PGP SIGNATURE-
[gentoo-dev] Re: useflag policies
On 11/08/15 22:58, Sergey Popov wrote: 11.08.2015 15:30, Michael Palimaka пишет: On 11/08/15 20:10, Sergey Popov wrote: Err, i have read the whole thread and still does not get a point, why i am wrong. You clearly have not. The reasoning behind Qt team's policy is described on the page and has been reiterated on this list. You are undermining what little confidence there is in the QA team by making decisions with no consultation about problems you do not understand. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. User choice of using USE flags is NOT a problem I invite you to reproduce the problem yourself then make the judgement. Using REQUIRED_USE like this makes the affected packages unusable. 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is required, but not both Same thing here, different REQUIRED_USE operator. But - enable one of the flags by default to ease life of users. Problem: this requires manual intervention if the user has both qt4 and qt5 USE flags enabled. Same here 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Do not use REQUIRED_USE here, not needed. Now, please tell me, where am i wrong? The problem is manual intervention is required if the user has both qt4 and qt5 USE flags enabled - and this is a common configuration. It is not acceptable to make a user manually add numerous package.use entries when all they want to do is install KDE. And here I agree Qt's policy is not a perfect solution, but in the absence of some feature allowing a preference to be set when there is a conflict it's the best we've got. If you want to go this way, then please provide helper functions in eclasses to set dependencies properly for all common use cases. That will ease life both of developers and users. Leaving constructing of dependencies to developers in all cases will cause only pain in your solution. Look at the example with berkdb/gdbm, that i have posted recently. If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled How does this solve the REQUIRED_USE problem? Or is your only objection is that resulting dependency string is too hard? Don't forget that as a project with no special authority, Qt's policy remains a suggestion for the vast majority of maintainers. If someone wishes to provide support for only one Qt version or abuse their users with REQUIRED_USE they are still free to do so.
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, Aug 11, 2015 at 04:12:29PM +0200, hasufell wrote: On 08/11/2015 03:52 PM, Patrice Clement wrote: Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. proj/gentoo should be kept for serious business i.e. commits that affects the tree. On the long run, if everybody goes down that road, we will see flourish numerous branches (who said unmaintained?), all stalled at a different state of the main repo, and it will only generate a lot of noise and confusion for nothing. Further, since we've moved over to git, the main tree now gets replicated to github and we all have github accounts here, don't we? Which makes the whole forking and submitting PRs a cinch. If a developer wants to tinker with the tree, he can fork it to its github devspace, fiddle around, and later on send us a PR back with his changes to merge. Branches can still make sense, even if the model is that everyone has his own fork, see http://nvie.com/posts/a-successful-git-branching-model/ for an example. I currently don't see a reason to limit the workflow to one master branch. It doesn't necessarily generate noise or confusion and there are various ways to only fetch specific branches if you really need to do so. Git's main advantage _are_ branches and it has sufficient methods to deal with a lot of them. If they cause trouble, we can still prune them and enforce stricter rules, but since we don't even know how they will be used, this point is moot yet. I'm with mgorny and hasufell on this; I'm not worried about regulating branches that much. Also, since we have our own tree on g.g.o, the tree on github is a mirror, so we should treat it as such, e.g. it could go down at any point, and if it does, we can keep working based on our official tree. There's even a way in git itself to do something like a github pull request (see the git request-pull command), so we don't need to rely on github for that. William signature.asc Description: Digital signature
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
On Tue, 11 Aug 2015 10:33:26 -0400 Ian Stakenvicius a...@gentoo.org wrote: On 11/08/15 06:11 AM, Leno Hou wrote: I think ppc64le would become popular, https://en.wikipedia.org/wiki/Ppc64. 1. enable porting x86 Linux based application with minimal effort. 2. Some PowerPC user, little endian apparently feels cheap, wrong, and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE already support little endian in powerpc. In terms of the codepaths, what's different between ppc64le vs ppc64, and ppc64le vs amd64 ? Obviously kernels will differ, but in terms of C/C++/other compiled source code what needs to change? If all this needs is its own profile for a CHOST/CBUILD specification and it can leverage an existing keyword, then this should be rather simple to implement yes? I spoke to blueness in #gentoo-powerpc and he basically said the same thing, that the existing ppc64 keyword should suffice. He noted that we do not have different keywords for every mips variant because that would be a lot of keywords! Stage 3 tarballs (possibly cross-compiled) could be provided and some initial work could be done to ensure they actually function but beyond that, endian issues would simply be dealt with as they are reported. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 09:04 AM, Sergey Popov wrote: 11.08.2015 15:32, Michael Palimaka пишет: On 11/08/15 20:17, Sergey Popov wrote: 09.08.2015 23:28, Ulrich Mueller пишет: I disagree with this. Really, REQUIRED_USE should be used sparingly, and IMHO the above is not a legitimate usage case for it. So, you prefer to make ugly mess of deps here like i posted before or introduce some really unneded USE-flag like 'gui', 'qt', etc. to make users even more confused? Really, look at man-db ebuild. Especially on berkdb and gdbm USE flags. And dependency string like this: !berkdb? ( !gdbm? ( sys-libs/gdbm ) ) One sentence: WHAT THE HELL? Imagine that it would be dozen of flags. Is it fun to mess with deps like this for you? Shall we ban this too? ffmpeg? ( libav? ( media-video/libav:= ) !libav? ( media-video/ffmpeg:0= ) ) No, because ffmpeg here is a feature AND name of concrete realization. Not ideal case as i would said, but it is acceptable. You want to migrate to such decision? Like: qt? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) Fine by me, if you would ask. As i said one message earlier: Something like $(qt_use_default qtgui 5) which will generate something like this: qt4? ( qt5? ( dev-lang/qtcore:5 ) !qt5? ( dev-lang/qtcore:4 ) ) !qt5? ( !qt4? ( dev-lang/qtcore:5 ) ) would help too. Woah -- why would qt5 be a dep when both flags are off? If you have a package that -needs- one version enabled, then in that case I do fully support REQUIRED_USE=|| ( qt4 qt5 ). '||' being the one-or-more-of operator. The other alternative here would be that there is no qt5 flag, just a qt4 one, and the qt4 one toggles qt5 off and qt4 on. And that just isn't pretty, so let's not do that. And using this form of REQUIRED_USE I believe (if I understand what QA's and QT's stances are on this) is not in conflict with either group, right? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKDosACgkQAJxUfCtlWe2Z8QD/Z+NvyJ0VXoIQH/KRPy8Asete iXZTpA1QgLDh4xYJE9YBAOTV61mJP472jBu/kEmJOK9cZPFW9PfJ15I0IvoBWdNF =1oaz -END PGP SIGNATURE-
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, 11 Aug 2015 16:19:12 +0200 hasufell hasuf...@gentoo.org wrote: On 08/11/2015 04:10 PM, Alexis Ballier wrote: On Tue, 11 Aug 2015 16:01:05 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Then we should define 'caution' I think :) Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Most, if not all, projects I've seen use forks for this. Blender does not, afaik. And I've seen a lot of projects doing that. The difference between e.g. myremote/featurebranch and upstream/featurebranch is just that someone has looked over upstream/featurebranch and that it requires pull requests to get stuff in (so the developer work happens in their developer forks, but the results still get into the same upstream branch). You can merge remote tracking branches just the same you merge 'upstream' branches. You can even rebase them which tends to give a better history but is harder if you forbid non fast-forward pushes to gentoo.git. Pull requests are only useful for pre-commit reviews. That would, for example, make sense for libressl. Since we basically just overwrite a lot of ebuilds to be able to test them with libressl patches. That is currently done with an overlay which always opens up the problem that we lack behind the tree and undesired openssl ebuilds leak in for the user, because of tree-overlay desync. Branch or remote, this doesn't change anything since no commit to master will automagically update your branch. The only thing you're achieving is a fixed gentoo-x86 tree snapshot + an overlay in the same repo, which you could already do anyway.
Re: [gentoo-dev] Re: useflag policies
On Tue, Aug 11, 2015 at 9:19 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:11, James Le Cuirot пишет: On Tue, 11 Aug 2015 15:58:49 +0300 Sergey Popov pinkb...@gentoo.org wrote: If both of flags are not set - we stick to default. Should this be set in EVERY ebuild explicitly? Maybe provide some sugar like $(qt_use_default qtgui 5), where qt_use_default is the name of function, qtgui is the package and 5 is the slot for default choice, where either BOTH of flags(qt4, qt5) are enabled or disabled That sounds a little bit like what I suggested earlier. https://archives.gentoo.org/gentoo-dev/message/884257a2d924a51851d629b1dc9b30df But without introducing brand new useless USE flag. Which makes huge difference to me :-) If we want the typical user to not set either qt4 or qt5, are we saying that any package that could use either always enable one of them by default? Then all users get a GUI by default, and then users have to explicitly disable it? That seems to be the opposite of how we normally do things, but it does let you get away from having lots of users turning on qt. Normally we'd just turn them on in a profile, but you can't do this if some packages need qt4, some need qt5, and some fail if both are enabled. -- Rich
Re: [gentoo-dev] Developer branches on proj/gentoo
On 08/11/2015 03:52 PM, Patrice Clement wrote: Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. proj/gentoo should be kept for serious business i.e. commits that affects the tree. On the long run, if everybody goes down that road, we will see flourish numerous branches (who said unmaintained?), all stalled at a different state of the main repo, and it will only generate a lot of noise and confusion for nothing. Further, since we've moved over to git, the main tree now gets replicated to github and we all have github accounts here, don't we? Which makes the whole forking and submitting PRs a cinch. If a developer wants to tinker with the tree, he can fork it to its github devspace, fiddle around, and later on send us a PR back with his changes to merge. Branches can still make sense, even if the model is that everyone has his own fork, see http://nvie.com/posts/a-successful-git-branching-model/ for an example. I currently don't see a reason to limit the workflow to one master branch. It doesn't necessarily generate noise or confusion and there are various ways to only fetch specific branches if you really need to do so. Git's main advantage _are_ branches and it has sufficient methods to deal with a lot of them. If they cause trouble, we can still prune them and enforce stricter rules, but since we don't even know how they will be used, this point is moot yet.
Re: [gentoo-dev] Re: useflag policies
On Tue, Aug 11, 2015 at 9:39 AM, Sergey Popov pinkb...@gentoo.org wrote: 11.08.2015 16:30, Michael Palimaka пишет: Don't forget that as a project with no special authority, Qt's policy remains a suggestion for the vast majority of maintainers. If someone wishes to provide support for only one Qt version or abuse their users with REQUIRED_USE they are still free to do so. Not enforcing policies on main tree is a bad thing. If you make policy, make other maintainers follow it. I am not against consistent policy that ease life BOTH for developers and users. ++ I think the qt team taking the lead on this makes sense, but this is the sort of thing that just makes sense as a treewide policy. If people don't like their suggested policy they can take it to QA/council/whatever, but it makes more sense to have projects setting standards than having everybody doing their own thing. I realize this is frustrating and contentious, but I think we're better off hashing this out, and implementing something reasonable, than having a bazillion different conventions that users have to deal with. Usually I prefer maintainer autonomy, but this is just one of those times it doesn't make sense. -- Rich
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, 11 Aug 2015 10:26:46 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 8/11/15 10:19 AM, hasufell wrote: On 08/11/2015 04:10 PM, Alexis Ballier wrote: On Tue, 11 Aug 2015 16:01:05 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Then we should define 'caution' I think :) I would not say caution so much as good judgment. The first example that came to mind was working with the profiles which crosses many directories and files. In the past when I did restructuring to the hardened profiles, I tested by using a branch of the hardened-dev overlay. It was annoying and I would do a bind mount over /usr/portage/profiles and had to rebase manually. A test branch of the the main tree which could get rebased and eventually merged back would make the workflow so much better. Another example was when we revitalized the selinux policies. There were hundreds of commits to be done. A branch here that got merged back would be ideal. you probably did this before it happened, but a solution in the last months could have been to fork gentoo-portage-rsync-mirror, merge it back (or better: rebase onto it) from time to time, and do a squashed PR that you can merge with mgorny's scripts.
Re: [gentoo-dev] Developer branches on proj/gentoo
On 08/11/2015 04:10 PM, Alexis Ballier wrote: On Tue, 11 Aug 2015 16:01:05 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branches etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Then we should define 'caution' I think :) Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Most, if not all, projects I've seen use forks for this. Blender does not, afaik. And I've seen a lot of projects doing that. The difference between e.g. myremote/featurebranch and upstream/featurebranch is just that someone has looked over upstream/featurebranch and that it requires pull requests to get stuff in (so the developer work happens in their developer forks, but the results still get into the same upstream branch). That would, for example, make sense for libressl. Since we basically just overwrite a lot of ebuilds to be able to test them with libressl patches. That is currently done with an overlay which always opens up the problem that we lack behind the tree and undesired openssl ebuilds leak in for the user, because of tree-overlay desync.
[gentoo-dev] Re: useflag policies
On 11/08/15 23:39, Sergey Popov wrote: 11.08.2015 16:30, Michael Palimaka пишет: Don't forget that as a project with no special authority, Qt's policy remains a suggestion for the vast majority of maintainers. If someone wishes to provide support for only one Qt version or abuse their users with REQUIRED_USE they are still free to do so. Not enforcing policies on main tree is a bad thing. If you make policy, make other maintainers follow it. I am not against consistent policy that ease life BOTH for developers and users. With what authority? Whether we like it or not, no project has any formal authority to tell others how to handle their part of Gentoo. You think that REQUIRED_USE is abusive to users: fine. Point accepted. I think that provided DEPEND strings if they will be typed at every single qt-related ebuild that needs them are abusive to developers. So, maybe we should wrap them into eclass and stop riding our own bicycles... And then - use apropriate one-liner where it's needed, providing reasonable default and NOT confusing users with overmanaging their package.use Please read Ben's original post again. Dependency strings are not the topic.
[gentoo-dev] Mirroring Gentoo project/team members on GitHub
Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. I have two ideas right now: 1. creating GitHub Gentoo project teams corresponding to willing Gentoo teams, 2. preparing lists of GitHub usernames on project wiki pages. Solution 1. is cleaner. In this case, we create GitHub teams under the Gentoo projects, and add appropriate Gentoo developers having GitHub accounts to the teams. Then, in PRs we can just ping the whole team like @Gentoo/Qt or like. Solution 2. avoids adding any GitHub teams. In this case, in team wiki page we collect team member usernames like @Pesa, @kensington, ... so we could copy-paste it to pull requests. We still require extra effort when 'assigning' PRs but at least I don't have to lookup the same people over and over again. With some Wiki people help, we could even implement updating GitHub teams automatically following Wiki member changes. Your thoughts? -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpcKS2VQk_90.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 06:11 AM, Leno Hou wrote: I think ppc64le would become popular, https://en.wikipedia.org/wiki/Ppc64. 1. enable porting x86 Linux based application with minimal effort. 2. Some PowerPC user, little endian apparently feels cheap, wrong, and PCish. 3. Other distrbutions like Ubuntu, Redhat and SUSE already support little endian in powerpc. In terms of the codepaths, what's different between ppc64le vs ppc64, and ppc64le vs amd64 ? Obviously kernels will differ, but in terms of C/C++/other compiled source code what needs to change? If all this needs is its own profile for a CHOST/CBUILD specification and it can leverage an existing keyword, then this should be rather simple to implement yes? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKB7UACgkQAJxUfCtlWe1sbQD+KcbYpfo56GrLIVlFyw2iXbMB ZOWzuvyI8SVq/DY0SQMBAJgDIjCza8QyUgWEtq2/g5Yu+uWiCibf2ouMeNAOkQ33 =YoUg -END PGP SIGNATURE-
Re: [gentoo-dev] Summary line
On 08/11/2015 04:28 PM, Ian Stakenvicius wrote: On 11/08/15 04:57 AM, Tobias Klausmann wrote: The more we stuff into the summary line, the harder it will be to write meaningful summaries. And thus, people will write crappy ones or ignore the length limit. I recommend against any more prescription over Add the the cat/pn if meaningful, don't use more than 75 characters. The cat/pn rule is tricky anyway: what if one commit touches 100 packages? Or should that be split into 100 commits for easier partial rollback? Regards, Tobias The summary line limit is going to be a real issue, tbh. I think it would probably be best to adopt the convention of putting a few choice, perhaps even canned, phrases in the summary line, and ensure any and all details (effectively what the summary line used to be for when it had practically no limit) within the commit message body instead . Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. 'Fix bug' IMO in the summary doesn't work at all because, although its accurate, that bug could literally be anything at all. Multi-package commits are going to be more of an issue of course.. I did one last night, fortunately I think I can get away with using mozilla packages in place of cat/pn since it is a very specific set of packages. Perhaps for sweeping changes like that we can use the herdname or projectname or the category name (if its a particular category only)? The CATEGORY: prefix is already in the wiki. Interesting idea about projectname/herdname prefix. I've already seen someone (I think ulm) prefixing with [QA]. I don't feel strong about this. IMO, if there is no useful prefix... just don't use any. The lack of prefix will make it obvious that this is a larger change. But project/herd specific prefixes could still make sense.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 06:10 AM, Sergey Popov wrote: Err, i have read the whole thread and still does not get a point, why i am wrong. It's old battle like we have beforce with gtk meaning any versions of GTK flag. This behaviour should be killed with fire. Let's me reiterate some of the cases: 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can be chosen, but not both. Fix this with REQUIRED_USE, do not enable any of Qt flags by default Why does this need REQUIRED_USE at all? neither flag is necessary, and just because the package only uses one flag at a time doesn't mean we should require users that have both flags set in profiles to -have to- package.use one of them off. 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is required, but not both Same thing here, different REQUIRED_USE operator. But - enable one of the flags by default to ease life of users. IUSE=qt4 +qt5 and USE=qt4 -qt5 globally (ie from profiles) is going to make a REQUIRED_USE force an exception in package.use as well. Again, annoying to end-users for no overly good reason and see #1 . 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such package even exists?) Do not use REQUIRED_USE here, not needed. Now, please tell me, where am i wrong? IMO it's wrong because REQUIRED_USE is a BFH for what really ends up as an extra, dangling enabled use flag. Unless there's a case (and i truely doubt there is) that there's a package with IUSE=qt4 that depends on ANOTHER package with IUSE=qt4 qt5, and that other package only builds against one implementation, AND the dep on the first package doesn't include any use deps, I still see no actual -need- for REQUIRED_USE. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKCZwACgkQAJxUfCtlWe3GqwEA2UCV9E+h+Djy7+KiwqODkEjv MiToijoa6ncX3xicD4cA/3PIQcv3ObG+obxECkB1gzyYclQrVGCaHT79DAkVE3oK =2iat -END PGP SIGNATURE-
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
11.08.2015 17:32, Michał Górny пишет: Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. I have two ideas right now: 1. creating GitHub Gentoo project teams corresponding to willing Gentoo teams, 2. preparing lists of GitHub usernames on project wiki pages. Solution 1. is cleaner. In this case, we create GitHub teams under the Gentoo projects, and add appropriate Gentoo developers having GitHub accounts to the teams. Then, in PRs we can just ping the whole team like @Gentoo/Qt or like. Solution 2. avoids adding any GitHub teams. In this case, in team wiki page we collect team member usernames like @Pesa, @kensington, ... so we could copy-paste it to pull requests. We still require extra effort when 'assigning' PRs but at least I don't have to lookup the same people over and over again. With some Wiki people help, we could even implement updating GitHub teams automatically following Wiki member changes. Your thoughts? First one more clear. Jut don't forget update it, when someone new join the team, as usual.
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, Aug 11, 2015 at 10:26 AM, Anthony G. Basile bluen...@gentoo.org wrote: I would not say caution so much as good judgment. The first example that came to mind was working with the profiles which crosses many directories and files. In the past when I did restructuring to the hardened profiles, I tested by using a branch of the hardened-dev overlay. It was annoying and I would do a bind mount over /usr/portage/profiles and had to rebase manually. A test branch of the the main tree which could get rebased and eventually merged back would make the workflow so much better. Another example was when we revitalized the selinux policies. There were hundreds of commits to be done. A branch here that got merged back would be ideal. Agree. You could still do this with an outside repository that everybody adds a remote to (a git repository can have many remotes). You can merge/rebase from a branch outside of gentoo to one inside of gentoo. I think the preference should be that users doing their own work should try to keep the interim stuff out of the main gentoo repository. On the other hand, when collaborating teams should be welcome to use the gentoo repository or their own overlay as makes sense, with the preference moving more to gentoo as the number of impacted devs/testers/etc gets bigger. It will always be a judgment call. In the end there isn't that big a difference in git between git checkout origin/proj/kde5 and git checkout kde5overlay/master. That is the beauty of git. -- Rich
Re: [gentoo-dev] Developer branches on proj/gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 12:03 PM, hasufell wrote: On 08/11/2015 05:21 PM, Alexis Ballier wrote: Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit? You will run repoman (and probably other pkgcore based checks) before you push that merge. That is for sure. The only problem that can arise there is that we don't roll our versions via branches, but via filenames. That means you may merge correctly, but in master there was already a newer version of app-misc/foo which now lacks the multilib migration (which isn't a tree breaker, since stuff still repomanchecks). We could probably come up with some magic git/bash lines that help with that. As in: not just detect merge-conflicts, but also soft conflicts in the sense that someone else touched the same ebuild-directory as you in between. NixOS for example has (probably not only for that reason) not any version based filenames, but they roll release-channels via branches. That sort of relates to the idea that was brought up last year, if portage could be made to detect and do VDB-only merges and would re-emerge ebuilds based on the fact that they were modified rather than their ${PVR} being incremented, then we could get rid of revision#'s entirely. Not a true version removal but it would reduce the number of distinct files we would be working with in cases like the above. But this isn't the place to discuss that tangent I don't think; that needs a whole new thread and a whole lot of portage development and possibly a PMS change? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKHf0ACgkQAJxUfCtlWe23RQEAuuHF7S5bKHl8ayGYgitGZFuh ETcKKDxaKw76i2pVDwkA/RLwUKUpbZpId7mvl3j9c4obO9ZAxCaxW25UikU1ZtsV =YBDy -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rsync mirror security
On Tue, Aug 11, 2015 at 10:53 AM, Matthias Maier tam...@gentoo.org wrote: constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). It is news to me that a signature from a push is also transported to a subsequent pull request for a client, do you have some external references for this procedure? They're stored in the tree under the ref refs/push-certs. I have no idea how to go about verifying them - they're pretty new so there aren't a lot of docs. I had no idea they were even there until Robin answered a similar question I asked him. git ls-remote for those curious about what other refs are lying around. -- Rich
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
Dnia 2015-08-11, o godz. 18:45:40 hasufell hasuf...@gentoo.org napisał(a): On 08/11/2015 06:42 PM, Michał Górny wrote: Dnia 2015-08-10, o godz. 22:51:59 hasufell hasuf...@gentoo.org napisał(a): I was wondering if that could be automated in a separate branch (only needs to update in 24h intervals). Please don't cruft the repo with huge metadata. And I have metadata-applied mirrors for all repositories at [1]. [1]:https://github.com/gentoo-mirror/ The problem with those mirrors is... the history is gone and the signatures as well. So people would have to clone the metadata-cache from that mirror, put it into the real mirror clone and then probably still update it via egencache, because they are not perfectly in sync. I know. I'm planning to improve it when I have some time. So far this was easier because not all repos are git, and I'm not really into trying hard to convert other VCS-es. -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpchQVprgyFI.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 10:01 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branch es etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Examples in particular I can think of for something like this being useful would be for, say, major EAPI-bump-related feature implementations (ie, EAPI5 and slot-operators/subslots), or major across-tree impementation changes like what we saw with the multilib-eclass porting. These are large projects touching most if not all ebuilds, that a great many developers would or should be involved in. Something like this could be done in a separately hosted repo instead of in the main gentoo repo, but then all developers would need to subscribe to this other repo, while having it in a branch in the main one i think would make it easier for everyone to get involved once they're ready, and would still allow the changes to stay out of the master branch until the project is ready to launch. For me, this is actually a reason to prohibit it :) EAPI bumps should be done package by package, not at a major scale: otherwise, let's just scrap EAPI entirely and update the API as we see fit with p.masked package managers :) multilib eclasses conversions should also be done one by one to be done properly (otherwise using multilib-portage is probably a better idea) and each conversion touches one package (two if you count emul-*). Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit?
Re: [gentoo-dev] Developer branches on proj/gentoo
On 08/11/2015 05:21 PM, Alexis Ballier wrote: Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit? You will run repoman (and probably other pkgcore based checks) before you push that merge. That is for sure. The only problem that can arise there is that we don't roll our versions via branches, but via filenames. That means you may merge correctly, but in master there was already a newer version of app-misc/foo which now lacks the multilib migration (which isn't a tree breaker, since stuff still repomanchecks). We could probably come up with some magic git/bash lines that help with that. As in: not just detect merge-conflicts, but also soft conflicts in the sense that someone else touched the same ebuild-directory as you in between. NixOS for example has (probably not only for that reason) not any version based filenames, but they roll release-channels via branches.
Re: [gentoo-dev] Re: useflag policies
On Tue, Aug 11, 2015 at 10:42 AM, Michael Palimaka kensing...@gentoo.org wrote: On 12/08/15 00:29, Rich Freeman wrote: I realize this is frustrating and contentious, but I think we're better off hashing this out, and implementing something reasonable, than having a bazillion different conventions that users have to deal with. Usually I prefer maintainer autonomy, but this is just one of those times it doesn't make sense. Isn't this moving towards a situation that we used GLEP 39 to remove? Fair enough. I don't really have a problem with the qt team proposing a policy and having QA or the Council bless it. Or having a more general policy and the QA policy is just an instance of it. -- Rich
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
Dnia 2015-08-10, o godz. 22:51:59 hasufell hasuf...@gentoo.org napisał(a): On 08/10/2015 10:47 PM, Andrew Savchenko wrote: On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote: On 08/10/2015 05:09 PM, Rich Freeman wrote: On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert flop...@gentoo.org wrote: Expanding on this: the rsync master creates the following files/directories under metatdata. On my own system, I like to symlink them to locations outside my repo so that related portage features continue to work. I would like to have these added in .gitignore. metadata/dtd/ # used by something? metadata/glsa/ # used by the GLSA utilities? matadata/herds.xml # used by equery from gentoolkit metadata/news/ # used by eselect news As a side note, it probably wouldn't hurt to set up a guide for running git on /usr/portage, including setting up these symlinks, running egencache after emerge --sync, etc. I imagine that this is a configuration that many developers will tend to use, and with the advent of git we may see more users who tend to contribute doing the same. In fact, this should be the recommended way of running gentoo for everyone. Our rsync methods are still inherently insecure (unless I missed something), because: 1. machine key 2. profiles, eclasses and so on are not covered with a signature/Manifest anyway Not unless metadata cache will be synced too from a trusted source. It takes too much time to generate, especially on non-brand-new hardware. I was wondering if that could be automated in a separate branch (only needs to update in 24h intervals). Please don't cruft the repo with huge metadata. And I have metadata-applied mirrors for all repositories at [1]. [1]:https://github.com/gentoo-mirror/ -- Best regards, Michał Górny http://dev.gentoo.org/~mgorny/ pgpAowOCShyhg.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Summary line
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 10:35 AM, Kent Fredric wrote: On 12 August 2015 at 02:28, Ian Stakenvicius a...@gentoo.org wrote: Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: adjusted dependencies' are generic (and short) enough yet descriptive enough to see what went on while scanning the log. I personally find those summaries a bit too terse. Mostly, because when I see A version is bumped I immediately expect to know which version the bump is to, but have to dig out the diff to find out. I would also prefer, where possible, to replace adjusted dependencies to be more concise, like include dev-perl/Foo in dependencies, ( though of course, apply some taste, listing more than 3 distinct new dependencies in the summary is execessive, treat them like hashtags on twitter, 1 is good, 2 is OK, 3 and you're starting to get crazy ) I agree, these are short and don't have nearly as much meaning as they should -- if there's space, absolutely we should add more meaning. I think my point still stands though that the short description should be more like these messages rather than fix bug#someting when there's absolutely no indication of what the bug is actually about. So long as all of the details are in the main commit message body, of course... -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKFFcACgkQAJxUfCtlWe0FRAEAgrL/FYmdYlA10JQyjkhrWPW6 Md6CjK5CCWQh35sz5U8A/Agp6d8HHSu69ZinmhE1VCw9D8TjJ3r5WtQYEo0X8Vhj =WHfg -END PGP SIGNATURE-
Re: [gentoo-dev] Developer branches on proj/gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 11:21 AM, Alexis Ballier wrote: On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 10:01 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branch es etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Examples in particular I can think of for something like this being useful would be for, say, major EAPI-bump-related feature implementations (ie, EAPI5 and slot-operators/subslots), or major across-tree impementation changes like what we saw with the multilib-eclass porting. These are large projects touching most if not all ebuilds, that a great many developers would or should be involved in. Something like this could be done in a separately hosted repo instead of in the main gentoo repo, but then all developers would need to subscribe to this other repo, while having it in a branch in the main one i think would make it easier for everyone to get involved once they're ready, and would still allow the changes to stay out of the master branch until the project is ready to launch. For me, this is actually a reason to prohibit it :) EAPI bumps should be done package by package, not at a major scale: otherwise, let's just scrap EAPI entirely and update the API as we see fit with p.masked package managers :) Not EAPI bumps, but implementation of major new features as a result of the new EAPI. Most EAPI changes generally are beneficial to particular ebuilds, but some (such as slot-operators and subslots) really needed to be implemented across a great many packages (and eclasses too at times). We did it with overlays and patches via b.g.o and slowly things migrated, but I think it would have gone a lot faster if all developers had quick and easy access to a branch. multilib eclasses conversions should also be done one by one to be done properly (otherwise using multilib-portage is probably a better idea) and each conversion touches one package (two if you count emul-*). But they don't just touch one package -- you pretty much needed to do a full deptree at a time. We worked around it with a rather messy 'delete all files in emul-* that collide with the multilib-built packages currently available' plus a convoluted set of ||() deps wrapping each emul and the individual alternative atoms. And even then it was still a mess to try and actually use it on end-user systems due to various conflicts. Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit? This makes sense, yes; the merge back to the main tree could very well be more difficult than it's worth, however if the branch is available to all, then the migration into the main tree could be done piecemeal in batches too rather than in one huge swash. The point is, I think it'd be easier and faster to implement these major treewide projects (and easier to verify too) if the work could be done in a branch available to all, rather than in what would effectively be an overlay someplace external.How we manage it effectively, I can't say one way or the other but likely this is something that we will need to learn from experience as much as decree policy for. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXKGfIACgkQAJxUfCtlWe11XgD/SvvIb9pcZ/k2WRH5OsrKG2G4 0uYC0godRRVytY7s78MA/0dMKUqAlVmqF/HntzPJYoLAqQxGCsrNassDB1iLBV6p =/msL -END PGP SIGNATURE-
Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)
On 08/11/2015 06:42 PM, Michał Górny wrote: Dnia 2015-08-10, o godz. 22:51:59 hasufell hasuf...@gentoo.org napisał(a): I was wondering if that could be automated in a separate branch (only needs to update in 24h intervals). Please don't cruft the repo with huge metadata. And I have metadata-applied mirrors for all repositories at [1]. [1]:https://github.com/gentoo-mirror/ The problem with those mirrors is... the history is gone and the signatures as well. So people would have to clone the metadata-cache from that mirror, put it into the real mirror clone and then probably still update it via egencache, because they are not perfectly in sync.
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
On Tue, Aug 11, 2015 at 04:32:40PM +0200, Michał Górny wrote: Hello, everyone. Now that we're officially on git and can officially use pull requests to provide rapid community interaction, it'd be convenient to have a little better framework for pinging package maintainers. With the unofficial mirror/pull request project, I was either looking for project member GitHub accounts and pinging found project members by name, or talking to them directly on IRC. However, with the growth in number of pull requests this will become more and more inconvenient. Therefore, I think it's time to be able to mirror teams willing to work with GitHub community there for easier 'pings'. People can also use the git request-pull command to tell maintainers where to pull from, so I'm not sure that mirroring every team/member on github is necessary. William signature.asc Description: Digital signature
Re: [gentoo-dev] Managing etc/* in an embbeded system
On 08/11/2015 10:48 AM, Joakim Tjernlund wrote: On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: Sent from an iPhone, sorry for the HTML... On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: There can not be any manual merges after an SW update here. I started to look at INSTALL_MASK, what if I set INSTALL_MASK to point to all conf files I want to manage myself. Then /etc/inittab etc. will not be touched when updating init This sounds like overkill. If you've already installed a custom /etc/inittab, then when you emerge init, it won't overwrite your inittab even if you don't change anything in your portage config. emerge won't touch any files in /etc unless they don't already exist. ..AND have been modified. IIRC if the hash of the config files match what they were when the package was previously emerged, then the files are updated aren't they? I expect that this is fine in the situation described, but it's worth knowing that a config file left unmodified may be replaced with a different vanilla config file later on. Sure, but what if I need to change a conf file in an installed system? Or rebuild a a system from scratch? The user only runs a one SW update command to update an installed system in the field and cannot edit a bunch of files too. Especially when there are hundreds of systems sitting in remote locations. If you use the profile-bashrcs profile-formats setting [1], then your profiles can use package.bashrc to define post_src_install and/or INSTALL_MASK to remove unwanted config files from upstream packages. Then you can easily replace the upstream config files with config files installed by your own configurations installed by your own ebuilds. Finally getting back to this after lots of distractions. I cannot get profile-formats = profile-bashrcs to work. I have in metadata/layout.conf: masters = gentoo profile-formats = portage-2 profile-bashrcs then in profiles/tmv3-target-overlay/profile.bashrc: INSTALL_MASK= Doing portageq envvar INSTALL_MASK just yields an empty line I guess I am missing something here? See the man portage for profile-bashrcs details. It uses package.bashrc rather than profile.bashrc, so that explains why it's not working for you. -- Thanks, Zac
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote: On 08/11/2015 10:48 AM, Joakim Tjernlund wrote: On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: Sent from an iPhone, sorry for the HTML... On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: There can not be any manual merges after an SW update here. I started to look at INSTALL_MASK, what if I set INSTALL_MASK to point to all conf files I want to manage myself. Then /etc/inittab etc. will not be touched when updating init This sounds like overkill. If you've already installed a custom /etc/inittab, then when you emerge init, it won't overwrite your inittab even if you don't change anything in your portage config. emerge won't touch any files in /etc unless they don't already exist. ..AND have been modified. IIRC if the hash of the config files match what they were when the package was previously emerged, then the files are updated aren't they? I expect that this is fine in the situation described, but it's worth knowing that a config file left unmodified may be replaced with a different vanilla config file later on. Sure, but what if I need to change a conf file in an installed system? Or rebuild a a system from scratch? The user only runs a one SW update command to update an installed system in the field and cannot edit a bunch of files too. Especially when there are hundreds of systems sitting in remote locations. If you use the profile-bashrcs profile-formats setting [1], then your profiles can use package.bashrc to define post_src_install and/or INSTALL_MASK to remove unwanted config files from upstream packages. Then you can easily replace the upstream config files with config files installed by your own configurations installed by your own ebuilds. Finally getting back to this after lots of distractions. I cannot get profile-formats = profile-bashrcs to work. I have in metadata/layout.conf: masters = gentoo profile-formats = portage-2 profile-bashrcs then in profiles/tmv3-target-overlay/profile.bashrc: INSTALL_MASK= Doing portageq envvar INSTALL_MASK just yields an empty line I guess I am missing something here? See the man portage for profile-bashrcs details. It uses package.bashrc rather than profile.bashrc, so that explains why it's not working for you. hmm, I figured I could use profile.bashrc to set stuff for all pkgs? In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not print anything either. It occurred to me that portageq envvar is not the right tool see variable defined in bash scripts? Is there some other tools I can use? Jocke
[gentoo-portage-dev] [PATCH] egencache: Always output EAPI=0 in cache entries
Remove the code skipping EAPI=0 output in cache entries. There is really no reason to treat EAPI=0 specially here, and this makes the output more consistent. --- bin/egencache | 2 -- 1 file changed, 2 deletions(-) diff --git a/bin/egencache b/bin/egencache index 6075ccf..5c00248 100755 --- a/bin/egencache +++ b/bin/egencache @@ -297,8 +297,6 @@ class GenCache(object): # EAPI from _parse_eapi_ebuild_head, we don't write cache # entries for unsupported EAPIs. if metadata is not None and eapi_supported: - if metadata.get('EAPI') == '0': - del metadata['EAPI'] for trg_cache in self._trg_caches: self._write_cache(trg_cache, cpv, repo_path, metadata, ebuild_hash) -- 2.5.0
Re: [gentoo-dev] Managing etc/* in an embbeded system
On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: Sent from an iPhone, sorry for the HTML... On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: There can not be any manual merges after an SW update here. I started to look at INSTALL_MASK, what if I set INSTALL_MASK to point to all conf files I want to manage myself. Then /etc/inittab etc. will not be touched when updating init This sounds like overkill. If you've already installed a custom /etc/inittab, then when you emerge init, it won't overwrite your inittab even if you don't change anything in your portage config. emerge won't touch any files in /etc unless they don't already exist. ..AND have been modified. IIRC if the hash of the config files match what they were when the package was previously emerged, then the files are updated aren't they? I expect that this is fine in the situation described, but it's worth knowing that a config file left unmodified may be replaced with a different vanilla config file later on. Sure, but what if I need to change a conf file in an installed system? Or rebuild a a system from scratch? The user only runs a one SW update command to update an installed system in the field and cannot edit a bunch of files too. Especially when there are hundreds of systems sitting in remote locations. If you use the profile-bashrcs profile-formats setting [1], then your profiles can use package.bashrc to define post_src_install and/or INSTALL_MASK to remove unwanted config files from upstream packages. Then you can easily replace the upstream config files with config files installed by your own configurations installed by your own ebuilds. Finally getting back to this after lots of distractions. I cannot get profile-formats = profile-bashrcs to work. I have in metadata/layout.conf: masters = gentoo profile-formats = portage-2 profile-bashrcs then in profiles/tmv3-target-overlay/profile.bashrc: INSTALL_MASK= Doing portageq envvar INSTALL_MASK just yields an empty line I guess I am missing something here?
Re: [gentoo-dev] RFC: News item about Nepomuk removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, given non-negative replies this is published now. Greeting. Am 08.08.2015 um 13:28 schrieb Johannes Huber: Hello Gentoos, please read and comment on the attached news item for the upcoming Nepomuk removal. Greetings, - -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID FDF4F788 -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVyjmnXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vPt8QAJAz9KMS2/WZQ10ss2I5qqYI 3VM91lt2GQ0FBypu5sAiTFftqXOYdB7prY1iW4QmBWvFpR7Ul9qfeZED1dTHkS4F yAZ4BfseaO2pVcQaQ/biKDxKOKBU7j/FJ94fSpLOuLju52Ed2+RJ3eKD6w9LBNjr THVWiv6kQehMu4hk16EY5nRyAM8pRuU+iaZ2P5xthqhMnIieXhbxS77T9W6DHWnM 3U11y5lukcFBKWPoBVcfKWuQHaaobwW8QpAz0gOmb7kI4jm2Q5L2Y2oW3gfWR9pM V2PmRZ7XwQ/SRYgTBRlL3vpkQQ7uq9VUcp2C0XfNbXDYRzh3af+0uvAiG6h8GilK SeTbrcmEmE7DQVedbSNw78SX/GnU/Ql8KanNM01qc3oJfWfsxsFruezfDklNmQ83 ma+cSk3PR1ZOe6BmUKX9Wl+Jy/jS0eASxjHPd946W8KcOZNwzRhZxMJV5lOP09Xn /cIJalaI3ZbAwtc1FldUDLbMwzQUXH8HsqkRHM5vdfXRcIflMA1ryKMGQbXgCWrQ vSG999wCPtAG3skaqok8ZCaGr5qgqOkIGvv3I7wKY71OKCNe2wHuM5GmPW9uqtVI RnchiDFxGnS5NiIehjo/AWal/fDT6V3C9JizlLYQ5wiEL+zIoWRtt+SzohXUcIHe LR1TqelJ56TZ/p4ou8Lj =EnjI -END PGP SIGNATURE- Title: Nepomuk removal Author: Johannes Huber j...@gentoo.org Content-Type: text/plain Posted: 2015-08-11 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-db/virtuoso-server With KDE SC 4.13.0 release the default semantic desktop search engine switched from Nepomuk to Baloo.[1] This change was honoured in Gentoo by changing the semantic-desktop use flag to cover the new engine and moving the old to nepomuk use flag. The underlaying storage backend for Nepomuk aka Virtuoso DB has a lot of unsolved upstream issues[2], therefore we will remove it. This means packages with build options on the old stack will drop them. Other packages which hard requiring it will be removed. If you are still using Nepomuk you can switch to Baloo by globally enable semantic-desktop and disabling nepomuk use flag in /etc/portage/make.conf or using one of the kde desktop profiles. [1] https://www.kde.org/announcements/4.13/ [2] https://bugs.gentoo.org/buglist.cgi?quicksearch=virtuoso -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAABCgBmBQJVyjeuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vv+AQAMkio+WhdU+gE3rDNdKuRts4 aXafLqE8pIi+kcURGmsuWquc9hv90qcRgYdN7O12jIRHA9YLhsJCa8tbvDw9cP3r 17qG1FBwAE1qDDhWOAeMN+LovL5qnRnZNN52LSSbpFbCp7gzSwSGp+gRsNg3VYVW LtwwYUm22DafFIfWAgk0ie/2H3JdTaJv/Ob++ZE6aQjlnLplQe9n0fGYmrp3EV8Y gumVD3tH7327Ic2vexxvy/sWcPgbY4UeNXQKxlYkIpwcFzm/bjofqFHrq1xH5Dm5 arxMb56M98U5oVtrWve1+7TVDbWsOfOEjaEliAuel7QjS6aAMlQHoWhpn1maFCZX vpTVW6JS0o+GbTg39+oGxQ/x6WCuNUW/kf3Y4SWxYygL61nrf/lK7EyBKefF0IZd G+HDFXkMff2WXE/bp8GZRoGz5UCpWaEqx7blhNNQRTI8AXFQpMPdLJGpkIiepRIl 1FRCNeZ5GMlXjszsTxyU6YomYHqK+nalV2olcb1mu8u8DuEMdFWfY9ckQtMYQJ1i 9bxAGtZuQMiEGBp0PJ4JxBgpnRYhsQyry6MCCdBN7vEeb0Gwd/i3baG2xb8FNIEw TRHYpD1NlaPoF8L7x2qn9eNbJSgM0d/y5y0ZVWnUes/yczBZEEHUfL/S8o5cX3bb 1PVTIWOsEtz0mzFI5Mfy =6hti -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: News item about Nepomuk removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 09.08.2015 um 05:01 schrieb Duncan: Johannes Huber posted on Sat, 08 Aug 2015 13:28:08 +0200 as excerpted: Title: Nepomuk removal Looks good here, and the title's nice and short too. =:^) Thanks for positive feedback. Greetings - -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID FDF4F788 -BEGIN PGP SIGNATURE- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJVyjnsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0N0Y0MTczMjZGRTRGODM5M0MzOTU4RDAy OTU0NDVDRUY5MDcyRDJGAAoJEClURc75By0vJ6MQAK7lt/OdbDzTZLmyPdbQ376K 8QcvNF2dUtJa/nSHzlKxk1D+AEI9PfP6VQE2tkrk5uIEtr+KVfP91ZO8QCUeXUZT wapWr4AldPaSxK6cwzW9/oHm0Ux4MU4VQKk4bgjR6ImjxDhYwJxc8OHosPzbviY1 /ABJbLIfj3Hp1XY1leSoY20rEBYmy1yRCkMPjVz7pCGEH1697sQIkmv5xBCaI4SA Hb0AwpuQXzYyW4DIevZZH2PMyMj9WBVmjcg7VdQexf6JOySljit3Ws2tdLdHaUHu Kz4Bm98h1KX3XnqUwnWIVhuAzvUR06C7e6Cm4M92PRX1Oyp5+W2HscAPGHLZEHCs S7Y33ZSHwOU5EqysFm43fplLZxSfGy9+wysHBztjueb0qAjNYBlidFdMhv3ab0PB JwPYzR5IdTuMk032RZKxjksS8yJlJazgL9SmfxVucK9/o9S46g5y86JgG9Ll+tln sDXETQot5wPhN+wxniNTBSzR89paQARtFbEufrn53ITu2hwL3Log0iU1Poie0zZX EADTyuXC6sLhrDwGZQZOH+OApL1LH6QM53chrpUCfpBuh08qgINo498wdB90/cdG ctLUyofX71H+7rNxi5qt7kiFyjkF5aI2/gAktlVQJpFEfxnCZWHJLEIFLTYvSnnv wOTt0X7ct7h4Mer8eOpU =HwoP -END PGP SIGNATURE-
Re: [gentoo-dev] golang-vcs.eclass: remove the EGO_SRC variable
All, I found something in this patch which I have fixed locally. It is just a replace on a couple of lines, so I'll explain what it is here rather than reposting the patch. Every occurance of '%/*' in the patch should be '%/...' instead. William signature.asc Description: Digital signature
Re: [gentoo-portage-dev] [PATCH] egencache: Always output EAPI=0 in cache entries
On 08/11/2015 10:38 AM, Michał Górny wrote: Remove the code skipping EAPI=0 output in cache entries. There is really no reason to treat EAPI=0 specially here, and this makes the output more consistent. --- bin/egencache | 2 -- 1 file changed, 2 deletions(-) diff --git a/bin/egencache b/bin/egencache index 6075ccf..5c00248 100755 --- a/bin/egencache +++ b/bin/egencache @@ -297,8 +297,6 @@ class GenCache(object): # EAPI from _parse_eapi_ebuild_head, we don't write cache # entries for unsupported EAPIs. if metadata is not None and eapi_supported: - if metadata.get('EAPI') == '0': - del metadata['EAPI'] for trg_cache in self._trg_caches: self._write_cache(trg_cache, cpv, repo_path, metadata, ebuild_hash) LTGM. -- Thanks, Zac
Re: [gentoo-dev] [PATCH repositories.dtd] Support multiple owner/ elements
On Tue, Aug 11, 2015 at 10:16 AM, Michał Górny mgo...@gentoo.org wrote: Hello, A quick patch for review. It changes the DTD for repositories.xml to support multiple owner/ tags. We have at least one repository with more than one owner, and I don't really see creating aliases for our users just to support that. Any comments? Sounds reasonable, but please make sure the tools (layman) can handle it properly.
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, 11 Aug 2015 18:03:54 +0200 hasufell hasuf...@gentoo.org wrote: On 08/11/2015 05:21 PM, Alexis Ballier wrote: Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit? You will run repoman (and probably other pkgcore based checks) before you push that merge. That is for sure. passing repoman, or any static checker, is definitely a very small subset of what is needed to be good for gentoo-x86 The only problem that can arise there is that we don't roll our versions via branches, but via filenames. That means you may merge correctly, but in master there was already a newer version of app-misc/foo which now lacks the multilib migration (which isn't a tree breaker, since stuff still repomanchecks). We could probably come up with some magic git/bash lines that help with that. As in: not just detect merge-conflicts, but also soft conflicts in the sense that someone else touched the same ebuild-directory as you in between. NixOS for example has (probably not only for that reason) not any version based filenames, but they roll release-channels via branches. After fixing all these sorts of conflicts, I hope you test things thouroughly, again, after the merge. In the end, it's shorter and simpler to stop and think at the beginning on how to split your work in small commits without branching.
Re: [gentoo-dev] Re: useflag policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/11/2015 03:41 AM, Sergey Popov wrote: I'd suggest to make a QA team meeting to override this policies with more correct and rationale. Qt team members are greatly appreciated on this meeting. Even more, i think that we should not take any decision on this without at least Qt team lead(or half of Qt team devs) So, let's arrange some time and talk about this, cause it is really confusing. Qt team point is understandable, but it's still wrong. Let's make some consensus here. 02.08.2015 19:34, Ben de Groot пишет: Recently some team members of the Qt project have adopted these ebuild policies: https://wiki.gentoo.org/wiki/Project:Qt/Policies I have an issue with the policy adopted under Requires one of two Qt versions. In my opinion, in the case where a package offers a choice between qt4 or qt5, we should express this in explicit useflags and a REQUIRED_USE=^^ ( qt4 qt5 ). This offers the user the clearest choice. Other developers state that users are not interested in such implementation details, or that forced choice through REQUIRED_USE is too much of a hassle. This results in current ebuilds such as quassel to not make it clear that qt4 is an option. This goes against the principle of least surprise, as well as against QA recommendations. I would like to hear specifically from QA about how we should proceed, but comments from the wider developer community are also welcome. -- Cheers, Ben | yngwin Gentoo developer I'm interested in this meeting as well, as maintainer of a package that can be built with one of two toolkit versions. At the moment, I'm using REQUIRED_USE with a preference preset for users that don't care, but it does cause a problem when both flags are set (so it's something I'd like to fix). I'd like to be part of the conversation if you don't mind. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVykQPAAoJEAEkDpRQOeFwVAgP+wYqVva9YHWmUOwC2dyrUFhx EjnPHBRaAsd6vOdoKKoFbO2c4wMhcoXb2C9pgLDw4O+eB2Q7JE3iMiiG/vAwGGtN 10meoAjvFV+DxpB7EYiHNj8NtlKq8PAncHusu6H/eP7YwdS37ruO4E89nBbXzxjU JQru2bxL6Jf7m/LuI5lihdU6fwe1GrsDz0fCaeZ/49zBE8EPY1PjDbV8G8vHq/S6 UAgGXmFbzN8lPXfgBgnaD4O6So+WrhILUeTy4CVUQu0599W4UFmLqOmupeRHD0SM wHjtJ/0gW+Wfb7VbuQsfrmNYuu0Fh/Wx15qs62/8YcgIOxb5YI31cefPa7e3HZbm RQ52JC16Pl7VxPEsf5jhcQ6+QCpdOi/jH7B72JQiSgmtLF9N6j4kcr8XGtJB/HLy PlJES1865ugS8LWpMiJCCwGyO8o/lOi4scbumw+XxjWj43Z93d66wGK84Yf2goAL VBVA0JjzrJ46EIrBbqOPECMZZvJjeq4t28V3DHAdLPZmxhvLQjIjEqb8wywR5USa NJ4kDgP5H85udznBk7JWapFu+ipphFm8uzKt6nqCeAfVc/y3n4rLZ9aUDCBVKodv lzr652TmUw2sBvmhM6oRqsGZuMg6t0peBOOTFjTMJl+WYG+eUybvsWk9RQ9HQpuW aqpPa6GiLL9Gbx8JTX8F =JOKI -END PGP SIGNATURE-
Re: [gentoo-dev] Developer branches on proj/gentoo
On Tue, 11 Aug 2015 11:51:14 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 11:21 AM, Alexis Ballier wrote: On Tue, 11 Aug 2015 11:11:43 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/08/15 10:01 AM, Michał Górny wrote: Dnia 2015-08-11, o godz. 15:52:16 Patrice Clement monsie...@gentoo.org napisał(a): Hi there According to https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, there may be developer-specific, task-specific, project-specific branch es etc. As far as I understand, it means I can go and create my own branch on the main repository and push it and it gets spread all over the place. Is that correct? Could someone explain to me the rationale behind this decision? Truth to be told, I kinda dislike the fact any developer can do this. As long as it's used with caution, I don't see a problem. Of course it would be bad if everyone pushed branches for any minor change. However, if there is a long-term work going on a branch, I don't see a problem with keeping it public. Examples in particular I can think of for something like this being useful would be for, say, major EAPI-bump-related feature implementations (ie, EAPI5 and slot-operators/subslots), or major across-tree impementation changes like what we saw with the multilib-eclass porting. These are large projects touching most if not all ebuilds, that a great many developers would or should be involved in. Something like this could be done in a separately hosted repo instead of in the main gentoo repo, but then all developers would need to subscribe to this other repo, while having it in a branch in the main one i think would make it easier for everyone to get involved once they're ready, and would still allow the changes to stay out of the master branch until the project is ready to launch. For me, this is actually a reason to prohibit it :) EAPI bumps should be done package by package, not at a major scale: otherwise, let's just scrap EAPI entirely and update the API as we see fit with p.masked package managers :) Not EAPI bumps, but implementation of major new features as a result of the new EAPI. Most EAPI changes generally are beneficial to particular ebuilds, but some (such as slot-operators and subslots) really needed to be implemented across a great many packages (and eclasses too at times). We did it with overlays and patches via b.g.o and slowly things migrated, but I think it would have gone a lot faster if all developers had quick and easy access to a branch. I'm glad this wasn't done that way actually. When subslots appeared, there was a serious tendency to use them in a fashion that caused useless rebuilds most of the time. With time, and discussions on some specific cases, saner practices were adopted. multilib eclasses conversions should also be done one by one to be done properly (otherwise using multilib-portage is probably a better idea) and each conversion touches one package (two if you count emul-*). But they don't just touch one package -- you pretty much needed to do a full deptree at a time. Sorry, but no. There was an order in which you could do it, but that's all. We worked around it with a rather messy 'delete all files in emul-* that collide with the multilib-built packages currently available' plus a convoluted set of ||() deps wrapping each emul and the individual alternative atoms. And even then it was still a mess to try and actually use it on end-user systems due to various conflicts. We split up the huge task into small and manageable ones, yes. I see it as a clear benefit and I'd even say this is one of the major reasons multilib-portage didn't make it. This also allowed to iteratively improve the multilib approach with the experience gained from converting small parts while getting feedback from those interested. I don't know what conflicts you're talking about, but I haven't seen any that was not due to a poor conversion. Big changes that that go in feature branches and are merged in one pass are, from my experience, way too much prone to errors. Did anyone ever try to review a merge commit? This makes sense, yes; the merge back to the main tree could very well be more difficult than it's worth, however if the branch is available to all, then the migration into the main tree could be done piecemeal in batches too rather than in one huge swash. The point is, I think it'd be easier and faster to implement these major treewide projects (and easier to verify too) if the work could be done in a branch available to all, rather than in what would effectively be an overlay someplace external. You seem to like pull requests and pre-commit reviews :) I believe it is optimistic to say that because there is a
Re: [gentoo-dev] Managing etc/* in an embbeded system
On 08/11/2015 11:11 AM, Joakim Tjernlund wrote: On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote: On 08/11/2015 10:48 AM, Joakim Tjernlund wrote: On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: On 07/23/2015 12:46 AM, Joakim Tjernlund wrote: On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote: Sent from an iPhone, sorry for the HTML... On Jul 22, 2015, at 5:38 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: There can not be any manual merges after an SW update here. I started to look at INSTALL_MASK, what if I set INSTALL_MASK to point to all conf files I want to manage myself. Then /etc/inittab etc. will not be touched when updating init This sounds like overkill. If you've already installed a custom /etc/inittab, then when you emerge init, it won't overwrite your inittab even if you don't change anything in your portage config. emerge won't touch any files in /etc unless they don't already exist. ..AND have been modified. IIRC if the hash of the config files match what they were when the package was previously emerged, then the files are updated aren't they? I expect that this is fine in the situation described, but it's worth knowing that a config file left unmodified may be replaced with a different vanilla config file later on. Sure, but what if I need to change a conf file in an installed system? Or rebuild a a system from scratch? The user only runs a one SW update command to update an installed system in the field and cannot edit a bunch of files too. Especially when there are hundreds of systems sitting in remote locations. If you use the profile-bashrcs profile-formats setting [1], then your profiles can use package.bashrc to define post_src_install and/or INSTALL_MASK to remove unwanted config files from upstream packages. Then you can easily replace the upstream config files with config files installed by your own configurations installed by your own ebuilds. Finally getting back to this after lots of distractions. I cannot get profile-formats = profile-bashrcs to work. I have in metadata/layout.conf: masters = gentoo profile-formats = portage-2 profile-bashrcs then in profiles/tmv3-target-overlay/profile.bashrc: INSTALL_MASK= Doing portageq envvar INSTALL_MASK just yields an empty line I guess I am missing something here? See the man portage for profile-bashrcs details. It uses package.bashrc rather than profile.bashrc, so that explains why it's not working for you. hmm, I figured I could use profile.bashrc to set stuff for all pkgs? You can, but package.bashrc might lead to better organization, since it allows you to use package atoms to specify which bashrc file(s) will be sourced by a particular ebuild. In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not print anything either. It occurred to me that portageq envvar is not the right tool see variable defined in bash scripts? Is there some other tools I can use? There's no tool for this, but you can put an elog message in the bashrc to provide an indication that it's working as expected. -- Thanks, Zac
Re: [gentoo-dev] Re: useflag policies
Is a possible solution something like an eselect module to indicate the preferred interface kit? It could default to any package that is available with a sequential set of preferred order. Then ebuild would consult the eselect module, and users who care can select the kit they want, and users who don't care/know get the default. Just a nickel's worth opinion. Due to inflation it isn't 2 cents any more. -- G.Wolfe Woodbury redwo...@gmail.com
Re: [gentoo-dev] Re: useflag policies
On Tue, Aug 11, 2015 at 3:13 PM, Gregory Woodbury redwo...@gmail.com wrote: Is a possible solution something like an eselect module to indicate the preferred interface kit? It could default to any package that is available with a sequential set of preferred order. Then ebuild would consult the eselect module, and users who care can select the kit they want, and users who don't care/know get the default. That still neglects the case where a user just wanted to say use the best version of qt for any particular package, which I'd argue is probably the most common use case. It may not make sense to have one global preference system-wide, and managing it per-package is painful. It really does make sense to leave it up to the maintainer, while still letting people either turn off qt entirely if they'd prefer to do so, or override the default implementation when they really want to. There is always requiring any package that supports qt to enable either qt4 or qt5 by default, so the typical user who wants qt does nothing, the typical user who doesn't want qt sets USE=-qt4 -qt5, and then anybody who wants to override things per-package can do so. That is simple to define in ebuilds, and you can set REQUIRED_USE to prevent them both from being set. It just means having qt support by default all over the tree and forcing people who don't want it to explicitly turn it off. That is simple to do at least, but not really in keeping with the general spirit of the base profile being a minimal one. And it would still be difficult to do anything at the profile level if it were appropriate to do so. -- Rich
Re: [gentoo-portage-dev] [PATCH] egencache: Always output EAPI=0 in cache entries
On Tue, 11 Aug 2015 10:54:10 -0700 Zac Medico zmed...@gentoo.org wrote: On 08/11/2015 10:38 AM, Michał Górny wrote: Remove the code skipping EAPI=0 output in cache entries. There is really no reason to treat EAPI=0 specially here, and this makes the output more consistent. --- bin/egencache | 2 -- 1 file changed, 2 deletions(-) diff --git a/bin/egencache b/bin/egencache index 6075ccf..5c00248 100755 --- a/bin/egencache +++ b/bin/egencache @@ -297,8 +297,6 @@ class GenCache(object): # EAPI from _parse_eapi_ebuild_head, we don't write cache # entries for unsupported EAPIs. if metadata is not None and eapi_supported: - if metadata.get('EAPI') == '0': - del metadata['EAPI'] for trg_cache in self._trg_caches: self._write_cache(trg_cache, cpv, repo_path, metadata, ebuild_hash) LTGM. yeah, merge please -- Brian Dolbec dolsen
Re: [gentoo-dev] golang-vcs.eclass: remove the EGO_SRC variable
On Tue, Aug 11, 2015 at 01:22:40PM -0500, William Hubbs wrote: All, I found something in this patch which I have fixed locally. It is just a replace on a couple of lines, so I'll explain what it is here rather than reposting the patch. Every occurance of '%/*' in the patch should be '%/...' instead. William All, this has been committed along with an identical fix to golang-vcs-snapshot.eclass. These were pretty high priority, so I hope it is ok that they were committed about twenty-four hours after the post here. William signature.asc Description: Digital signature