Re: [gentoo-dev] ebuild copyright assignment
On 18/02/15 09:12, Jeroen Roovers wrote: On Wed, 18 Feb 2015 08:48:19 +0100 Justin (jlec) j...@gentoo.org wrote: On 18/02/15 08:40, Jeroen Roovers wrote: I seem to recall the developer quizzes may have had (or indeed requested) some more information on this matter. The test ebuild focuses on this topic. What is that? jer At the end of the review session we ask the recruits to fix an ebuild which has numerous technical and, as mentioned, legal aspects to take care of. Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild copyright assignment
On Wed, 18 Feb 2015 08:48:19 +0100 Justin (jlec) j...@gentoo.org wrote: On 18/02/15 08:40, Jeroen Roovers wrote: I seem to recall the developer quizzes may have had (or indeed requested) some more information on this matter. The test ebuild focuses on this topic. What is that? jer
Re: [gentoo-dev] ebuild copyright assignment
On Wed, 18 Feb 2015 09:34:21 +0100 Justin (jlec) j...@gentoo.org wrote: At the end of the review session we ask the recruits to fix an ebuild which has numerous technical and, as mentioned, legal aspects to take care of. That's a novelty I wasn't aware of, then. The technical practicalities of copyright assignment have a legal basis which I assume the test ebuild question(s) doesn't quiz recruits on. jer
Re: [gentoo-dev] ebuild copyright assignment
On 18/02/15 09:48, Jeroen Roovers wrote: On Wed, 18 Feb 2015 09:34:21 +0100 Justin (jlec) j...@gentoo.org wrote: At the end of the review session we ask the recruits to fix an ebuild which has numerous technical and, as mentioned, legal aspects to take care of. That's a novelty I wasn't aware of, then. The technical practicalities of copyright assignment have a legal basis which I assume the test ebuild question(s) doesn't quiz recruits on. jer No, explicit question about that. This is part of the set of topics which we cover outside the scope of the quizzes. Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: About reducing or even removing stable tree for some arches
El mié, 18-02-2015 a las 03:11 +, Duncan escribió: Pacho Ramos posted on Mon, 16 Feb 2015 14:34:50 +0100 as excerpted: The current policy of maintainers dropping keywords after 90 days is simply not applied because it leads up to that maintainer needing to kill himself that keyword and ALL the reverse deps keywords and, then, all that effort should probably be replaced by making the opposite, I mean, reducing the stable tree of that arches to a minimum and moving all the other packages to testing. The main advantage of this is that it needs maybe more effort in one round but it solves the problem for the future. On the other hand trying to kill keywords of a package *and all its reverse deps* requires a lot of work every time the problem appears. Perhaps my non-dev status prevents me from understanding the difficulty here, but... I really don't see the problem. Maybe that explains it, I have personally suffered it when we needed to dekeyword most gnome stuff on all arches but amd64/x86 and even months later we were still needing to remember to either keep moving to testing other packages or finally postponing the move to testing for some and try to stabilize some again (as the chain of reverse dep kept growing forever). I don't want to have to repeat that for every package that is not attended in 90 days, and seeing that the arch teams that are unable to stabilize/keyword things are, consequently, also unable to make this huge work, the 90 days policy isn't going to start working any time soon (it has never worked indeed as nobody wants to do the manual job of checking all the reverse deps, move that deps to testing, recheck for the reverse deps of those, and repeat and repeat).
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
Is there a communication problem? I don't remember getting either: * a bug report * a ping * a review request Did I miss something? Justin Lecher (jlec): jlec15/02/17 13:39:15 Modified: ChangeLog Added:watchdog-0.8.3.ebuild Log: Version Bump (Portage version: 2.2.17/cvs/Linux x86_64, signed Manifest commit with key B9D4F231BD1558AB!)
Re: [gentoo-dev] Making more repoman checks fatal
Patrick Lauer: ebuild.badheader, That would break repoman for the majority of overlays. You don't really expect overlay maintainers to follow gentoo copyright, do you? Really... before repoman is fixed, none of this will happen (or people will just run a hacked repoman version).
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
Dnia 2015-02-18, o godz. 16:11:53 Mike Frysinger (vapier) vap...@gentoo.org napisał(a): vapier 15/02/18 16:11:53 Modified: fcaps.eclass Log: clarify USE=filecaps intention #540430 Revision ChangesPath 1.11 eclass/fcaps.eclass Please commit the missing ChangeLog update and remember to update the ChangeLog after changing any eclass in any way. This is an official policy for any commits to the Gentoo repository [1] and a lack of consistency in entries to the ChangeLog is confusing to our developers and users. [1]:http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html -- Best regards, Michał Górny pgpc87RHdV11E.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] arm64 update
On Thu, Feb 19, 2015 at 3:27 AM, Tom Gall tg...@gentoo.org wrote: So first, for those interested in cheap arm64 hardware, the first 96 board is going to start shipping in March for ~$129. The HiKey board is an 8 way 64 bit ARM board with 8 A53 cores. (No A57s bummer!) Only had a gig of memory on the board but it’s not a bad device. I’ve had one for about 2-3 weeks now. I’m basically running off a USB hard disk for the moment and thankfully the kernel continues to improve. The one downside is you really really need a 1.8v USB - UART cable. You can get them from digikey and connect it on the board. If working with raw cables makes you squeamish take a breath, you’ll be fine. Info and links at: https://www.96boards.org Ok so hardware aside here’s the arm64 gentoo plan. 1) new stage3 put together and get that onto the mirrors for consumption. 2) Get the handbook extended to include arm64 3) continued package stabilization If devs don't mind working out of a chroot - I can potentially get access to some hardware or possibly help test after things are a bit more stable. If possible I do really recommend getting something with an A57 core (vs a53) - there is quite a bit of difference from the compiler side of how they compare. How much are the APM xgene1 systems selling for? Has anyone tried to request hw from: APM, ARM, Cavium or AMD?
[gentoo-dev] Mailing list for ebuild review
The topic of a review workflow comes up frequently, but Gitlab, Gerrit, etc. are blocked on a host of other problems that may never be resolved. It would still be nice to be able to request reviews somewhere, and for ebuilds, a mailing list combined with a threaded MUA works fine. Would anyone else find gentoo-review@lists.g.o useful? I think a lot of simple problems could be quickly caught with a second set of eyeballs. There is already gentoo-dev-help@, but it's /very/ quiet. If we could all agree to subscribe and do reviews there, that would work as well.
[gentoo-dev] arm64 update
So first, for those interested in cheap arm64 hardware, the first 96 board is going to start shipping in March for ~$129. The HiKey board is an 8 way 64 bit ARM board with 8 A53 cores. (No A57s bummer!) Only had a gig of memory on the board but it’s not a bad device. I’ve had one for about 2-3 weeks now. I’m basically running off a USB hard disk for the moment and thankfully the kernel continues to improve. The one downside is you really really need a 1.8v USB - UART cable. You can get them from digikey and connect it on the board. If working with raw cables makes you squeamish take a breath, you’ll be fine. Info and links at: https://www.96boards.org Ok so hardware aside here’s the arm64 gentoo plan. 1) new stage3 put together and get that onto the mirrors for consumption. 2) Get the handbook extended to include arm64 3) continued package stabilization Volunteers most welcome. Regards, Tom (tgall_foo, Dr_Who)
[gentoo-dev] Last rites: games-board/kaya
# Michael Palimaka kensing...@gentoo.org (19 Feb 2015) # Doesn't work with current version of ruby. Dead upstream. # Masked for removal in 30 days. games-board/kaya
Re: [gentoo-dev] Making more repoman checks fatal
On 16 Feb 2015 11:45, Rafael Goncalves Martins wrote: On Mon, Feb 16, 2015 at 11:19 AM, Mike Frysinger wrote: On 16 Feb 2015 21:00, Patrick Lauer wrote: Thus I suggest making the following warnings proper errors: some of these are because they produce false positives. at least these bugs probably need to be fixed first: https://bugs.gentoo.org/405017 https://bugs.gentoo.org/488836 https://bugs.gentoo.org/533460 I think that just the last bug is still valid. the first is still broken: $ cd dev-python/boto/ $ cvs up $ repoman full RepoMan scours the neighborhood... Note: use --include-dev (-d) to check dependencies for 'dev' profiles RepoMan sez: If everyone were like you, I'd be out of business! $ rm *.ebuild $ cvs up /dev/null $ repoman full RepoMan scours the neighborhood... ebuild.badheader 17 dev-python/boto/boto-2.11.0.ebuild: Invalid Gentoo Copyright on line: 1 dev-python/boto/boto-2.19.0.ebuild: Invalid Gentoo Copyright on line: 1 ... -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
On 18 Feb 2015 23:10, Mike Gilbert wrote: On Wed, Feb 18, 2015 at 7:08 PM, Patrick Lauer patr...@gentoo.org wrote: On Wednesday 18 February 2015 18:43:59 hasufell wrote: Is there a communication problem? I don't remember getting either: * a bug report * a ping * a review request Did I miss something? Yes. Why is this package metadata missing the python herd for no reason? Speaking as the current python lead, we don't claim ownership of everything in dev-python. As a Gentoo developer, I find it silly to raise a stink on a mailing list over what appears to be a very simple version bump of a very simple ebuild. This is not going to convince anyone that a peer review workflow is a desirable thing; I don't want to have someone rubber stamp every trivial version bump. +1 -mike signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
On Wed, Feb 18, 2015 at 7:08 PM, Patrick Lauer patr...@gentoo.org wrote: On Wednesday 18 February 2015 18:43:59 hasufell wrote: Is there a communication problem? I don't remember getting either: * a bug report * a ping * a review request Did I miss something? Yes. Why is this package metadata missing the python herd for no reason? Speaking as the current python lead, we don't claim ownership of everything in dev-python. As a Gentoo developer, I find it silly to raise a stink on a mailing list over what appears to be a very simple version bump of a very simple ebuild. This is not going to convince anyone that a peer review workflow is a desirable thing; I don't want to have someone rubber stamp every trivial version bump.
[gentoo-dev] [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions
The attached patch proposes two helper functions to be added to
qmake-utils.eclass. These functions echo the correct directory where
qt binaries such as moc and lrelease are located. They can be used in
ebuilds when such binaries need to be called directly. (Ebuilds should
not rely on qtchooser for this.)
Please review before I commit.
--
Cheers,
Ben | yngwin
Gentoo developer
--- gentoo-x86/eclass/qmake-utils.eclass 2014-11-22 11:04:23.765870730 +0800
+++ overlay/qt/eclass/qmake-utils.eclass 2015-02-11 23:10:51.067484243 +0800
@@ -51,6 +51,25 @@
esac
}
+# @FUNCTION qt4_get_bindir
+# @DESCRIPTION:
+# Get the correct location of Qt4's installed binaries.
+qt4_get_bindir() {
+ local qtbindir=${EPREFIX}/usr/$(get_libdir)/qt4/bin
+ if [[ -x ${qtbindir} ]]; then
+ echo ${qtbindir}
+ else
+ echo ${EPREFIX}/usr/bin
+ fi
+}
+
+# @FUNCTION qt5_get_bindir
+# @DESCRIPTION:
+# Get the correct location of Qt5's installed binaries.
+qt5_get_bindir() {
+ echo ${EPREFIX}/usr/$(get_libdir)/qt5/bin
+}
+
# @VARIABLE: EQMAKE4_EXCLUDE
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -158,11 +177,7 @@
[[ -n ${EQMAKE4_EXCLUDE} ]] eshopts_pop
- # determine qmake binary location
- local qmake_path=${EPREFIX}/usr/$(get_libdir)/qt4/bin/qmake
- [[ ! -x ${qmake_path} ]] qmake_path=${EPREFIX}/usr/bin/qmake
-
- ${qmake_path} \
+ $(qt4_get_bindir)/qmake \
-makefile \
QMAKE_AR=$(tc-getAR) cqs \
QMAKE_CC=$(tc-getCC) \
@@ -213,7 +228,7 @@
ebegin Running qmake
- ${EPREFIX}/usr/$(get_libdir)/qt5/bin/qmake \
+ $(qt5_get_bindir)/qmake \
-makefile \
QMAKE_AR=$(tc-getAR) cqs \
QMAKE_CC=$(tc-getCC) \
Re: [gentoo-dev] ebuild copyright assignment
On Wed, Feb 18, 2015 at 7:28 AM, Peter Stuge pe...@stuge.se wrote: Justin (jlec) wrote: This is part of the set of topics which we cover outside the scope of the quizzes. A brief comment from reality is that this legal problem is quit likely a significant hurdle for many potential developers - as for me. If you want contributing to be easy, overhead like this can't exist. It isn't clear to me what the overhead is here. The only things devs need to do with respect to copyright is follow the law and ensure that ebuilds have the correct copyright notice. Following the law doesn't always make things easier, but that isn't something we really have any choice in. Putting the correct copyright notice at the top of your ebuilds isn't that difficult - it is already in the ebuild template and any other ebuild in the tree you might copy from. There are concerns that the current policy isn't ideal legally and that it restricts our options for accepting outside code. Those are legitimate concerns, but any change isn't likely to make things any easier on contributors. In fact, many of the potential improvements are likely to make things harder, which is a big reason why there hasn't been a huge rush to change things. It would be nice if we could just tell our developer candidates that they don't have to be concerned with copyright at all, but that would not be very good for any of us. Our mirror sponsors would drop us like hot potatoes, anybody using us for professional work would be concerned about needing to double-check everything we do so that they don't get in trouble, and sooner or later we could end up getting sued by somebody or at least subject to DMCA takedowns. Gentoo is very careful to comply with copyright law, and when we do struggle with issues they tend to be in very gray areas (which we usually end up mirror restricting anyway to keep our mirror sponsors out of any risk). While the trustees and members of the licensing team tend to get into discussions around legal details (often tapping into outside resources when doing so), the average developer really just needs to make sure that they commit their own work into the tree itself, have permission for Gentoo to use the work of others, that they stick the standard copyright notice in their ebuilds, and that anything in a SRC_URI is under a redistributable license or set RESTRICT=mirror. Obviously this is a quick summary and not a substitute for the devmanual - I'm sure there are one-off situations that come up that I'm not thinking of. -- Rich
[gentoo-dev] Re: [PATCH] qmake-utils.eclass: add qt{4,5}_get_bindir helper functions
On Wed, Feb 18, 2015 at 12:58 PM, Ben de Groot yng...@gentoo.org wrote:
The attached patch proposes two helper functions to be added to
qmake-utils.eclass. These functions echo the correct directory where
qt binaries such as moc and lrelease are located. They can be used in
ebuilds when such binaries need to be called directly. (Ebuilds should
not rely on qtchooser for this.)
Please review before I commit.
Thanks Ben.
The -x test on line 59 should be a -d.
Also, I'd rephrase the description as follows:
Echoes the directory where Qt{4,5} binaries are installed.
And you're missing a colon after @FUNCTION.
Thanks,
Davide
Re: [gentoo-dev] ebuild copyright assignment
Rich Freeman wrote: This is part of the set of topics which we cover outside the scope of the quizzes. A brief comment from reality is that this legal problem is quit likely a significant hurdle for many potential developers - as for me. If you want contributing to be easy, overhead like this can't exist. It isn't clear to me what the overhead is here. The only things devs need to do with respect to copyright is follow the law Ah, but which law? I understand that law in e.g. Germany does not permit non-natural persons to own copyright. The public domain concept is also not recognized world-wide. So a German citizen who wants to contribute an ebuild now has a significant legal questionmark on their hands, when actually they just want to publish an ebuild. and ensure that ebuilds have the correct copyright notice. Define correct... ;) It would be nice if we could just tell our developer candidates that they don't have to be concerned with copyright at all, but that would not be very good for any of us. Every author of every work is automatically concerned with copyright. I think Gentoo's policy of requiring copyright assignment would be better replaced with a policy of requiring a (ideally specific) very permissive license, something like MIT or BSD-2. Gentoo is very careful to comply with copyright law Sure. Being governed by US law is a whole different topic. //Peter
Re: [gentoo-dev] ebuild copyright assignment
Justin (jlec) wrote: This is part of the set of topics which we cover outside the scope of the quizzes. A brief comment from reality is that this legal problem is quit likely a significant hurdle for many potential developers - as for me. If you want contributing to be easy, overhead like this can't exist. Think Shanzhai, not DMCA. //Peter
Re: [gentoo-dev] ebuild copyright assignment
On Wed, Feb 18, 2015 at 9:07 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: The only things devs need to do with respect to copyright is follow the law Ah, but which law? I understand that law in e.g. Germany does not permit non-natural persons to own copyright. The public domain concept is also not recognized world-wide. So a German citizen who wants to contribute an ebuild now has a significant legal questionmark on their hands, when actually they just want to publish an ebuild. We don't ask every Gentoo developer to independently formulate a copyright policy. They just have to follow the policy. Gentoo developers do not need to worry about whether copyright assignment exists in Germany. They just have to stick Copyright Gentoo Foundation at the top of their ebuilds. Whether that policy makes sense is a different matter, which is why there is a desire to improve the policy. Gentoo devs are not required to participate in these discussions, but they will be required to follow a new policy if it is enacted. and ensure that ebuilds have the correct copyright notice. Define correct... ;) # Copyright - Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 That is the current policy, and is correct by definition. Of course, we want to improve on this. However, all a dev needs to know today is to do it this way. I think Gentoo's policy of requiring copyright assignment would be better replaced with a policy of requiring a (ideally specific) very permissive license, something like MIT or BSD-2. That is part of my draft proposal, though it doesn't specify which license we'd use. Gentoo is very careful to comply with copyright law Sure. Being governed by US law is a whole different topic. We endeavor to follow the law everywhere. Whether the current policy does so is a different topic indeed. :) I'm not saying that things are perfect. I'm just saying that Gentoo devs don't have to understand copyright law everywhere on the planet to comply. Our current policies are fairly simple. They might or might not be too simple, but the concern I was replying to was just the concern that understanding copyright policy is a burden on new developers. The current policy is very simple and shouldn't really be a burden to understand. -- Rich
Re: [gentoo-dev] arm64 update
On Feb 18, 2015, at 2:32 PM, C Bergström cbergst...@pathscale.com wrote: On Thu, Feb 19, 2015 at 3:27 AM, Tom Gall tg...@gentoo.org mailto:tg...@gentoo.org wrote: So first, for those interested in cheap arm64 hardware, the first 96 board is going to start shipping in March for ~$129. The HiKey board is an 8 way 64 bit ARM board with 8 A53 cores. (No A57s bummer!) Only had a gig of memory on the board but it’s not a bad device. I’ve had one for about 2-3 weeks now. I’m basically running off a USB hard disk for the moment and thankfully the kernel continues to improve. The one downside is you really really need a 1.8v USB - UART cable. You can get them from digikey and connect it on the board. If working with raw cables makes you squeamish take a breath, you’ll be fine. Info and links at: https://www.96boards.org https://www.96boards.org/ Ok so hardware aside here’s the arm64 gentoo plan. 1) new stage3 put together and get that onto the mirrors for consumption. 2) Get the handbook extended to include arm64 3) continued package stabilization If devs don't mind working out of a chroot - I can potentially get access to some hardware or possibly help test after things are a bit more stable. Always good to hear. If possible I do really recommend getting something with an A57 core (vs a53) - there is quite a bit of difference from the compiler side of how they compare. Yeah there’s certainly more performance with A57 cores. OTOH, the best dev board is the one you have in your hand. How much are the APM xgene1 systems selling for? Has anyone tried to request hw from: APM, ARM, Cavium or AMD? It’s a good question. I’ve been personally wondering about the AMD Seattle boards. I do have a request in for one. ARM Juno I have access to remotely which isn’t the best situation for putting together install instructions and testing :-/ Best, Tom
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
Patrick Lauer: Why is this package metadata missing the python herd for no reason? Because the python herd doesn't currently maintain the package, nor did they ask me to be co-maintainers. Also Why are you pretending to own packages when we're supposed to be working together as a community / team / ... ?! Working as a community involves a review workflow, whether you like that or not. Similarly, ignoring each other is not working together. Everything else is just random stuff happening to a repository.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
On Wednesday 18 February 2015 18:43:59 hasufell wrote: Is there a communication problem? I don't remember getting either: * a bug report * a ping * a review request Did I miss something? Yes. Why is this package metadata missing the python herd for no reason? Also Why are you pretending to own packages when we're supposed to be working together as a community / team / ... ?! Justin Lecher (jlec): jlec15/02/17 13:39:15 Modified: ChangeLog Added:watchdog-0.8.3.ebuild Log: Version Bump (Portage version: 2.2.17/cvs/Linux x86_64, signed Manifest commit with key B9D4F231BD1558AB!)
Re: [gentoo-dev] arm64 update
On 02/18/15 15:32, C Bergström wrote: On Thu, Feb 19, 2015 at 3:27 AM, Tom Gall tg...@gentoo.org wrote: So first, for those interested in cheap arm64 hardware, the first 96 board is going to start shipping in March for ~$129. The HiKey board is an 8 way 64 bit ARM board with 8 A53 cores. (No A57s bummer!) Only had a gig of memory on the board but it’s not a bad device. I’ve had one for about 2-3 weeks now. I’m basically running off a USB hard disk for the moment and thankfully the kernel continues to improve. The one downside is you really really need a 1.8v USB - UART cable. You can get them from digikey and connect it on the board. If working with raw cables makes you squeamish take a breath, you’ll be fine. Info and links at: https://www.96boards.org Ok so hardware aside here’s the arm64 gentoo plan. 1) new stage3 put together and get that onto the mirrors for consumption. 2) Get the handbook extended to include arm64 3) continued package stabilization If devs don't mind working out of a chroot - I can potentially get access to some hardware or possibly help test after things are a bit more stable. I don't mind chroots. I want to build stage3 and do stabilizations. If possible I do really recommend getting something with an A57 core (vs a53) - there is quite a bit of difference from the compiler side of how they compare. How much are the APM xgene1 systems selling for? Has anyone tried to request hw from: APM, ARM, Cavium or AMD? I have about $1000 in grant money. Want to recommend some equipment? -- 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: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
On Thursday 19 February 2015 00:48:18 hasufell wrote: Patrick Lauer: Why is this package metadata missing the python herd for no reason? Because the python herd doesn't currently maintain the package, nor did they ask me to be co-maintainers. So you put a python package in the dev-python category (which is almost completely managed by the python herd). Then you don't ask the python herd if they want to co-maintain it ... I'm not quite sure how your reality works, but it seems to not share much with mine. But at least you found something new to be offended about and life doesn't get too boring ...
