Re: [gentoo-dev] What to do with people who use internal eclass functions?
On Mon, 26 Aug 2013 09:38:04 +0200 Michał Górny wrote: > I've noticed that some people are using internal eclass functions > in their ebuilds. [...] What should I do to them? File a bug report. Don't do anything "to" anyone. jer
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
On Mon, Aug 26, 2013 at 07:04:44PM +0200, Tom Wijsman wrote: > > [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1 > No idea, I'm fairly new and learned this as part of the quiz. > > [1], 3.h. Mailing lists, second paragraph; I quote for you: > > If you send a message to dev-announce, you should manually cross-post > > to an on topic mailing list and set reply-to there. Specifically I meant that the mails will be dropped if there is no reply-to. That's a change from historical. > But your mails are fine, because they do have Reply-To; so, there is > something else going wrong that made it no longer get to g-d-a@l.g.o. They didn't actually. The gentoo-dev lists adds Reply-To, but gentoo-dev-announce does NOT. That's why I fixed my script now. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
On Mon, 26 Aug 2013 16:06:40 + "Robin H. Johnson" wrote: > On Mon, Aug 26, 2013 at 11:56:51AM +0200, Tom Wijsman wrote: > > Seems like a bug with g-d-a because the mail header has not changed. > > The mail itself is proper, nothing wrong with it; the Reply-To > > header should not matter with regards to delivery. We might even > > risk not receiving them if we send them to g-d-a only if there is a > > bug present. > I have fixed the script to add Reply-To. > > However, where was this change announced to devs? I also can't find > any documentation of it. Please update the Developer Handbook [1], > quizzes, and possibly also the mailing list page. > > [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1 No idea, I'm fairly new and learned this as part of the quiz. [1], 3.h. Mailing lists, second paragraph; I quote for you: > If you send a message to dev-announce, you should manually cross-post > to an on topic mailing list and set reply-to there. But your mails are fine, because they do have Reply-To; so, there is something else going wrong that made it no longer get to g-d-a@l.g.o. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
just to be clear: I prefer the 1st patch but I would give the variable (COMPLETE_MULTILIB) a more private name and document this is only for multilib-portage and it will not work with regular portage.
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
On Mon, Aug 26, 2013 at 11:56:51AM +0200, Tom Wijsman wrote: > Seems like a bug with g-d-a because the mail header has not changed. > The mail itself is proper, nothing wrong with it; the Reply-To header > should not matter with regards to delivery. We might even risk not > receiving them if we send them to g-d-a only if there is a bug present. I have fixed the script to add Reply-To. However, where was this change announced to devs? I also can't find any documentation of it. Please update the Developer Handbook [1], quizzes, and possibly also the mailing list page. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1 -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
On Sun, 25 Aug 2013 16:15:31 +0200 Ulrich Mueller wrote: > > first version (multilib1.patch) directly changes the output of the > > currently used multilib_is_native_abi() function: > > I think this would be very misleading. If a function is called > multilib_is_native_abi then it should test for exactly that, not for > something else. Native abi only really makes sense as 'the abi you want the binaries for'; maybe it is misleading, but i don't think it's worth changing the name. However, these patches do not make sense as the only thing they do is allowing building binaries twice so that the 'native abi' ones override the previously built binaries. The justification for this is an invalid, utterly broken, hypothetical case where people install packages with invalid settings (disabling default/native abi). Even if we want to support this approach, this will not work that easily: Some packages install both binaries and libraries; usually the binaries have more deps than the libraries, hence the correct dep string for this packages is [MULTILIB_USEDEP] on the deps of the libraries and a plain dep (assuming native abi) for the rest. Look at e.g. jack-audio-connection-kit or lame. Anything else is bloated. If we want to allow multibin, or rather a mixed system where some bins have ABI A and some others have ABI B, this will require a more thorough solution than these quick hacks: With one of these patches, if you ask for building all the binaries and disable your native abi, you get a binary with a non native ABI but also get broken deps in your packages since they do not RDEPEND on the correct ABI of its deps. Alexis.
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/08/13 10:30 AM, Michał Górny wrote: > Dnia 2013-08-25, o godz. 16:15:31 Ulrich Mueller > napisał(a): > >>> On Sun, 25 Aug 2013, Thomas Sachau wrote: >> >>> first version (multilib1.patch) directly changes the output of >>> the currently used multilib_is_native_abi() function: >> >> I think this would be very misleading. If a function is called >> multilib_is_native_abi then it should test for exactly that, not >> for something else. > > It's for multilib-portage. It hacks over everything in the > environment. None of multilib variables are really meaningful in > this context, so I don't have a problem with hacking that > behavior. > Multilib-portage could just override the definition of multilib_is_native_abi so that it's always true -- this change isn't necessary for that particular use case. It *is* necessary to support end-users that want to do what multilib-portage offers but just with regular portage. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIbYWkACgkQ2ugaI38ACPDjKwEAq5Ocxg4NItUkZ+qS+4Hj2iag zVqJpa0E2oDDAyXpK5IBAIR7S0NOfHuN3hd/5fVNKebxdlwUo4yPee8rWFHv8Q48 =dqDh -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25/08/13 10:15 AM, Ulrich Mueller wrote:
>> On Sun, 25 Aug 2013, Thomas Sachau wrote:
>
>> workaround: add a variable, which changes the return of the
>> function checking for the current ABI (always true with variable,
>> without only true, when $ABI == $DEFAULT_ABI)
>
> Would this variable be set by the user, in profiles, or in
> ebuilds?
>
>> first version (multilib1.patch) directly changes the output of
>> the currently used multilib_is_native_abi() function:
>
> I think this would be very misleading. If a function is called
> multilib_is_native_abi then it should test for exactly that, not
> for something else.
>
- From the discussion on this that we had ~2 weeks ago, it seems that
'multilib_is_native_abi' is only used in the wild now (and only meant
to be used) to handle the cases where we want to say, build everything
for default_abi and only build certain bits for the others.
If there was a common usage that is important for the actual native
abi (for instance, some sort of check enabling alternate code in a
build system for a specific CHOST or whatnot), then keeping
multilib_is_native_abi as it is would make a lot of sense, but since
there isn't any cases of this I'm not sure it matters -- changing it's
functionality to essentially become multilib_is_default_abi() (whether
we rename it or not) seems to make the most sense to me.
>> second version (multilib2.patch) creates a new function, which
>> should then be used by ebuild authors to check, if they should
>> build ABI-specific content or not (using build_binaries()
>> function instead of multilib_is_native_abi() function)
>
> +build_binaries() {
>
> Name space pollution? Prefix with "multilib" please.
>
> + if [[ ${COMPLETE_MULTILIB} == yes ]] ; then + return 0 +
> else +
> multilib_is_native_abi + fi
>
> This can be expressed much shorter (and clearer):
>
> [[ ${COMPLETE_MULTILIB} == yes ]] || multilib_is_native_abi
>
> But allow me a stupid question, why do you want to build binaries
> for other ABIs anyway? It's called multilib, not multibin.
>
> Ulrich
>
Some users want to have a toolchain that is 64bit and the rest of the
userspace that is 32bit. Or, they want to just have certain packages
installed 32bits, to support specific use-cases. Essentially, the
want to have multi-abi instead of multi-lib, and so they want the
current multi-lib to be expanded to allow them to do it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
iF4EAREIAAYFAlIbYR8ACgkQ2ugaI38ACPBG8AEAgcED8DZxyN0c98nMKvkCwNRG
zO6AcwF83oBL0PzOErsA/0gPMFZsX0+sKOXHo557L9X0Ha3S+9V8ZQVDWBVVL0Xk
=pvlE
-END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-emulation/dolphin: dolphin-9999.ebuild dolphin-3.5.ebuild ChangeLog
On 08/26/2013 09:19 AM, Devan Franchini (twitch153) wrote:
>
> -src_prepare() {
> +pkg_pretend() {
> +
> + local ver=4.6.0
> + local msg="${PN} needs at least GCC ${ver} set to compile."
> +
> + if ! version_is_at_least ${ver} $(gcc-fullversion); then
> + eerror ${msg}
> + die ${msg}
> + fi
> +}
>
> - version_is_at_least 4.6.0 $(gcc-fullversion) || die "${PN} needs
> >=gcc-4.6.0 set to compile."
> +src_prepare() {
>
This can break binpkgs, use
[[ ${MERGE_TYPE} != binary ]]
Re: [gentoo-dev] What to do with people who use internal eclass functions?
On Mon, Aug 26, 2013 at 3:38 AM, Michał Górny wrote: > I've noticed that some people are using internal eclass functions > in their ebuilds. I mean, functions that are explicitly marked > @INTERNAL and that start with an underscore. What should I do to them? Seems crazy to need a written policy to not do something so dumb... > What should I do now? Mask the ebuild? Proceed with changing > the function and break it? Seems like masking and changing is the most appropriate course of action. By all means log a bug and give the maintainer a week or whatever. The only exception I'd make would be for important packages. I wouldn't make it because their maintainers are important, but because we care about our users. Obviously we can't go masking bash or whatever. However, we should in general consider the use of internal functions a QA issue, and follow-up with the devs doing so. Maybe burning at the stake is a bit harsh since the issue hasn't come up before, but there is no excuse for this. > > Or maybe do we need to have GPG signature verification of bash > tracebacks in every internal function to prevent developers from using > those? This is not a technical problem, it is a people problem. If any internal functions lack underscores or are referenced in the devmanual/etc those should be fixed, and /maybe/ a repoman warning would be helpful (really? a developer might not realize they've used an undocumented internal function?). Sure, maybe some of those internal functions are useful and should turn into published APIs. Devs are welcome to step up and do just that if it makes sense (and following the normal eclass process). However, devs are not welcome to just use internal APIs and then make users deal with the aftermath when ebuilds break. Using internal APIs is bad practice - if anybody doesn't already understand why they're probably on the wrong list. Rich
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
On Mon, 26 Aug 2013 11:22:35 +0200 Theo Chatzimichos wrote: > On Monday, August 26, 2013 00:25:01 Robin H. Johnson wrote: > > The attached list notes all of the packages that were added or > > removed from the tree, for the week ending 2013-08-25 23h59 UTC. > > These mails are not going through gentoo-dev-announce any more, I > suppose because they don't have proper Reply-To set. Could you please > send them only to gentoo-dev-announce? > > Theo Seems like a bug with g-d-a because the mail header has not changed. The mail itself is proper, nothing wrong with it; the Reply-To header should not matter with regards to delivery. We might even risk not receiving them if we send them to g-d-a only if there is a bug present. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
On Monday, August 26, 2013 00:25:01 Robin H. Johnson wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2013-08-25 23h59 UTC. These mails are not going through gentoo-dev-announce any more, I suppose because they don't have proper Reply-To set. Could you please send them only to gentoo-dev-announce? Theo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What to do with people who use internal eclass functions?
On Mon, 26 Aug 2013 09:38:04 +0200 Michał Górny wrote: > I've noticed that some people are using internal eclass functions > in their ebuilds. I mean, functions that are explicitly marked > @INTERNAL and that start with an underscore. What should I do to them? First, figure out why they use the internal eclass function: - Does the ebuild really need what the internal function does at all? - Is there a non-internal eclass function they can use instead? - Does the eclass not fit the use case of the package? Depending on these questions, you'll either need to file a bug for the developer to fix it _or_ need to make adjustments to the eclass. > I would expect that Gentoo developers are professionals. Or at least > semi-reasonable people. Yet it seems that I was mistaken. Yet, they hack a workaround once in a hundred (semi) or thousand (pro). > We were never pinged about the internal function use. Nobody bothered > to ask us why the function is internal and what they should they use > instead. I guess it was the usual 'it works, i don't care' case. Agreed, it should have been communicated to you; while you could theoretically read through all the ebuilds, the most reasonable thing you can only do is properly document the eclass and its proper uses. If they use internal functions without letting you know, not your fault... > What should I do now? Mask the ebuild? Proceed with changing > the function and break it? Evaluate the use case and file a bug or make eclass adjustments. The ebuild isn't broken so it might not need a mask; you might be able to consider this a QA violation, if so, skip the bug and fix it yourself. > Or maybe do we need to have GPG signature verification of bash > tracebacks in every internal function to prevent developers from > using those? Things like that seem overly complicated for what you want to do; it isn't so much that it is a bad thing to implement, but it is rather that the more complicated you make it the harder it gets to implement. The idea of adding QA checks to repoman sounds sane; it could probably easily build a whitelist of internal eclass functions (it already does for other things), after that it just has to match them in the ebuild. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] What to do with people who use internal eclass functions?
On 26 August 2013 19:55, Pacho Ramos wrote: > El lun, 26-08-2013 a las 09:38 +0200, Michał Górny escribió: > > > I would open a bug and try to contact the developer. Not sure if > internal functions could be named in a "standard" way allowing repoman > to die on its usage by ebuilds :/ > > This really resonates my continued desire to be able to add QA checks to repoman without needing to modify the repoman code. I know Repoman already has a whole lot of eclass-based checks, but they appear to be hardcoded in the checks themselves ( repoman/checks.py ), which means to simply enforce some degree of sane usage of an eclass, one has to modify portage itself to add the checks.. -- Kent
Re: [gentoo-dev] What to do with people who use internal eclass functions?
On 26 August 2013 19:38, Michał Górny wrote: > Hello, all. > > I've noticed that some people are using internal eclass functions > in their ebuilds. I mean, functions that are explicitly marked > @INTERNAL and that start with an underscore. What should I do to them? > > Not sure if this is a warnings/error category yet, but imo, repoman should at least warn about this if at all possible. > I would expect that Gentoo developers are professionals. Or at least > semi-reasonable people. Yet it seems that I was mistaken. > Sometimes in the case of "I accept my code will be broken in the future", then its somewhat acceptable by proxy to use internal functions. Though granted, if this is in an ebuild, then that ebuild should not be stabilized imo. > We were never pinged about the internal function use. Nobody bothered > to ask us why the function is internal and what they should they use > instead. I guess it was the usual 'it works, i don't care' case. > > What should I do now? Mask the ebuild? Proceed with changing > the function and break it? > I would consider that acceptable, because an ebuild that uses an internal function, is something I would consider "already broken", as using an internal function is acknowledging an inevitable breakage will occur. > Or maybe do we need to have GPG signature verification of bash > tracebacks in every internal function to prevent developers from using > those? > > -- > Best regards, > Michał Górny > -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] What to do with people who use internal eclass functions?
El lun, 26-08-2013 a las 09:38 +0200, Michał Górny escribió: > Hello, all. > > I've noticed that some people are using internal eclass functions > in their ebuilds. I mean, functions that are explicitly marked > @INTERNAL and that start with an underscore. What should I do to them? > > I would expect that Gentoo developers are professionals. Or at least > semi-reasonable people. Yet it seems that I was mistaken. > > We were never pinged about the internal function use. Nobody bothered > to ask us why the function is internal and what they should they use > instead. I guess it was the usual 'it works, i don't care' case. > > What should I do now? Mask the ebuild? Proceed with changing > the function and break it? > > Or maybe do we need to have GPG signature verification of bash > tracebacks in every internal function to prevent developers from using > those? > I would open a bug and try to contact the developer. Not sure if internal functions could be named in a "standard" way allowing repoman to die on its usage by ebuilds :/
[gentoo-dev] What to do with people who use internal eclass functions?
Hello, all. I've noticed that some people are using internal eclass functions in their ebuilds. I mean, functions that are explicitly marked @INTERNAL and that start with an underscore. What should I do to them? I would expect that Gentoo developers are professionals. Or at least semi-reasonable people. Yet it seems that I was mistaken. We were never pinged about the internal function use. Nobody bothered to ask us why the function is internal and what they should they use instead. I guess it was the usual 'it works, i don't care' case. What should I do now? Mask the ebuild? Proceed with changing the function and break it? Or maybe do we need to have GPG signature verification of bash tracebacks in every internal function to prevent developers from using those? -- Best regards, Michał Górny signature.asc Description: PGP signature
