Re: [gentoo-dev] Moving more arches to dev profiles
21.08.2013 22:28, Alexis Ballier пишет: Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc? I like this way much more. Let's clarify stabilization policy for some minor arches, e.g. policy about stabilization requests for huge packages. Cause dropping entire arch to ~arch maybe sometimes a bit overkill. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more arches to dev profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/22/2013 08:38 AM, Sergey Popov wrote: 21.08.2013 22:28, Alexis Ballier пишет: Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc? I like this way much more. Let's clarify stabilization policy for some minor arches, e.g. policy about stabilization requests for huge packages. Cause dropping entire arch to ~arch maybe sometimes a bit overkill. And hard to revert. Sparc did drop a lot of keywords lately, by removing itself from STABLEREQ w/o stabling the mentioned package. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlIVt8cACgkQknrdDGLu8JCfxgD/X6HlUv7pPFuo75aOhs1bT9Cc PqF799Z9yYsPX+042yoA/RZ2xwKaNUEIlL6XbOKpC0SivlMFIHxBxlzYeRACcPJU =yu+s -END PGP SIGNATURE-
[gentoo-dev] Header files and ABI_X86
Now that Gentoo is much better in handling multilib libraries, but Gentoo is source-based, there's the question of which header files are used between different ABI builds. As I understand it, only the headers from the default ABI are installed. That means that building for abi_x86_32 on a amd64 system will use the headers installed by the abi_x86_64 build of the used library. From a developer's point of view, does that mean that we now have to keep Gentoo in mind when writing header files, or does Gentoo apply any kind of magic here to fix differences between header files for different archs? For example, if I need to provide a PTR_SIZE macro in a header that contains the size of void pointers on this particular system, I would detect this with autoconf and then just use that, so the header file would end up simply containing: #define PTR_SIZE 8 on x86-64, and: #define PTR_SIZE 4 on x86. The x86-64 header won't work properly when building on Gentoo for abi_x86_32. As a developer, this is a no-no for me: #ifdef THIS_ARCH #define PTR_SIZE 8 #elif defined THAT_ARCH #define PTR_SIZE 4 ... because detection should be done in autoconf, not in the header file. So how does Gentoo solve that problem?
Re: [gentoo-dev] Header files and ABI_X86
Dnia 2013-08-22, o godz. 10:56:10 Nikos Chantziaras rea...@gmail.com napisał(a): Now that Gentoo is much better in handling multilib libraries, but Gentoo is source-based, there's the question of which header files are used between different ABI builds. As I understand it, only the headers from the default ABI are installed. That means that building for abi_x86_32 on a amd64 system will use the headers installed by the abi_x86_64 build of the used library. The build process installs alls headers by default and compares if they're the same. The ebuild can also specify that some headers need to be wrapped -- in that case they are installed with an ABI-detecting wrapper on top. From a developer's point of view, does that mean that we now have to keep Gentoo in mind when writing header files, or does Gentoo apply any kind of magic here to fix differences between header files for different archs? For example, if I need to provide a PTR_SIZE macro in a header that contains the size of void pointers on this particular system, I would detect this with autoconf and then just use that, so the header file would end up simply containing: #define PTR_SIZE 8 on x86-64, and: #define PTR_SIZE 4 on x86. The x86-64 header won't work properly when building on Gentoo for abi_x86_32. As a developer, this is a no-no for me: #ifdef THIS_ARCH #define PTR_SIZE 8 #elif defined THAT_ARCH #define PTR_SIZE 4 ... because detection should be done in autoconf, not in the header file. As a developer, you should learn not to put anything system- or machine- -specific in public headers. This is simply wrong, and will break more ways than you could imagine. We're hacking it over but it's far from perfect, and is not an excuse to write more screwed up software. Anything you detect about the host should be used *only* inside C files, and header files that are only used during build-time and not installed. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: Header files and ABI_X86
On 22/08/13 11:16, Michał Górny wrote: Dnia 2013-08-22, o godz. 10:56:10 Nikos Chantziaras rea...@gmail.com napisał(a): Now that Gentoo is much better in handling multilib libraries, but Gentoo is source-based, there's the question of which header files are used between different ABI builds. As I understand it, only the headers from the default ABI are installed. That means that building for abi_x86_32 on a amd64 system will use the headers installed by the abi_x86_64 build of the used library. The build process installs alls headers by default and compares if they're the same. The ebuild can also specify that some headers need to be wrapped -- in that case they are installed with an ABI-detecting wrapper on top. Perfect. That's exactly what I wanted to know :-) From a developer's point of view, does that mean that we now have to keep Gentoo in mind when writing header files, or does Gentoo apply any kind of magic here to fix differences between header files for different archs? For example, if I need to provide a PTR_SIZE macro in a header that contains the size of void pointers on this particular system, I would detect this with autoconf and then just use that, so the header file would end up simply containing: #define PTR_SIZE 8 on x86-64, and: #define PTR_SIZE 4 on x86. The x86-64 header won't work properly when building on Gentoo for abi_x86_32. As a developer, this is a no-no for me: #ifdef THIS_ARCH #define PTR_SIZE 8 #elif defined THAT_ARCH #define PTR_SIZE 4 ... because detection should be done in autoconf, not in the header file. As a developer, you should learn not to put anything system- or machine- -specific in public headers. This is simply wrong, and will break more ways than you could imagine. We're hacking it over but it's far from perfect, and is not an excuse to write more screwed up software. Anything you detect about the host should be used *only* inside C files, and header files that are only used during build-time and not installed. That's good advice in general, but sometimes this can't be done. C++ templates for example need to be in headers, and thus there's sometimes gonna be platform-specific stuff in them. Even if the headers are private, they still need to be there and will get included indirectly.
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-21, o godz. 12:33:14
Ulrich Mueller u...@gentoo.org napisał(a):
On Wed, 21 Aug 2013, Michał Górny wrote:
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
The first pair of quotes is not needed.
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
I'd test for [[ ${#DOCS[@]} -gt 0 ]] here, but presumably that's a
matter of taste.
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
This will emit an error message if HTML_DOCS is unset. So:
if [[ $(declare -p HTML_DOCS 2/dev/null) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
No test for empty array here?
I don't think it's anywhere near necessary. Since HTML_DOCS has no
default, why would people set it to empty array? Well, unless someone
plays with appending...
Then I'll better add it.
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
Make this the same as the DOCS logic, i.e.:
else
[[ ${HTML_DOCS} ]] dohtml -r ${HTML_DOCS}
fi
Maybe add a return 0 here?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-21, o godz. 14:49:45
Pacho Ramos pa...@gentoo.org napisał(a):
El mié, 21-08-2013 a las 14:35 +0200, Ulrich Mueller escribió:
On Wed, 21 Aug 2013, Pacho Ramos wrote:
Could appending to DOCS be allowed? I have seen a lot of time of me
needing to install all docs manually only to add a doc file over
default DOCS. Would be interesting to simply do: DOCS+=( otherfile )
instead of needing to specify all files handled by the install
function
We discussed this in bug 449806 already. Problems that need to be
solved:
- If we want to keep support for both array and whitespace-separated
list then we can't preset a global variable.
- How do we distinguish between DOCS being unset (i.e. install default
docs) and DOCS being empty (i.e. don't install anything)?
- We could introduce some special syntax like a __default__ marker,
but do we want such in-band signalling?
Well, the last comment by mgorny in bug report after some suggestions
rised there made me think I should wait for the einstalldocs thing :/
Yes, for something like:
src_install() {
...
einstalldocs
dodoc FOO
}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Second version:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif [[ $(declare -p DOCS) == 'declare -a'* ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS 2/dev/null) == 'declare -a'* ]] ; then
[[ ${HTML_DOCS[@]} ]] dohtml -r ${HTML_DOCS[@]}
else
[[ ${HTML_DOCS} ]] dohtml -r ${HTML_DOCS}
fi
return 0
}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Thu, 22 Aug 2013, Michał Górny wrote: Second version: Looks good to me. One minor non-technical point: Could you use double quotes instead of single quotes around declare -a, for better readability? Last time we had single quotes they ended up as backquotes in the devmanual and from there in some eclasses (see bug 444832). Ulrich
Re: [gentoo-dev] Moving more arches to dev profiles
On Thu, Aug 22, 2013 at 1:39 AM, Ben de Groot yng...@gentoo.org wrote: On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I don't see how that would work. You can't remove older versions unless a newer one is stabilized, or you'd break the tree. Sort-of. You'd break it in that users would have to accept ~arch to keep that package, or remove it. It is really no different than dropping stable keywords which forces them to do the same thing, except that you're doing it one package at a time. You could impose a time limit to respond to the STABLEREQ prior to removal (30-60 days or something). I think the result of a policy like this would be that stable keywords would get dropped on most peripheral packages, but system packages might still keep them. That might actually be the right balance - if the arch teams focus on just system or other important packages they might be able to find the time to keep up rather than trying to boil the ocean. Rich
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 11:01, Rich Freeman ri...@gentoo.org wrote: On Thu, Aug 22, 2013 at 1:39 AM, Ben de Groot yng...@gentoo.org wrote: On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I don't see how that would work. You can't remove older versions unless a newer one is stabilized, or you'd break the tree. Sort-of. You'd break it in that users would have to accept ~arch to keep that package, or remove it. It is really no different than dropping stable keywords which forces them to do the same thing, except that you're doing it one package at a time. You could impose a time limit to respond to the STABLEREQ prior to removal (30-60 days or something). I think the result of a policy like this would be that stable keywords would get dropped on most peripheral packages, but system packages might still keep them. That might actually be the right balance - if the arch teams focus on just system or other important packages they might be able to find the time to keep up rather than trying to boil the ocean. Rich What's the point of that? Most users need more than what @system provides so after they deploy the 'stable' stage3 they will start pulling ~arch packages that were never tested against the stable tree. It so much better if stage3 was also ~arch. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 18:01, Rich Freeman ri...@gentoo.org wrote: On Thu, Aug 22, 2013 at 1:39 AM, Ben de Groot yng...@gentoo.org wrote: On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I don't see how that would work. You can't remove older versions unless a newer one is stabilized, or you'd break the tree. Sort-of. You'd break it in that users would have to accept ~arch to keep that package, or remove it. It is really no different than dropping stable keywords which forces them to do the same thing, except that you're doing it one package at a time. You could impose a time limit to respond to the STABLEREQ prior to removal (30-60 days or something). The problem is with reverse dependencies. We had this a while ago with Qt libraries, and I ended up needing to mask a whole list of packages on two slacker arches. That's more trouble than it's worth for me. In my opinion we should only bother with stabilization on the most widely used arches: amd64, x86, and arm. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Moving more arches to dev profiles
On Thu, Aug 22, 2013 at 6:19 AM, Markos Chandras hwoar...@gentoo.org wrote: On 22 August 2013 11:01, Rich Freeman ri...@gentoo.org wrote: I think the result of a policy like this would be that stable keywords would get dropped on most peripheral packages, but system packages might still keep them. What's the point of that? Most users need more than what @system provides so after they deploy the 'stable' stage3 they will start pulling ~arch packages that were never tested against the stable tree. It so much better if stage3 was also ~arch. Do we actually have examples of this happening? I've never had problems with a mix of stable and ~arch keywords. Granted, I'm not running ~arch on most libs. I've seen lots of talk about stable being less reliable than ~arch, and ~arch applications on a stable core being unreliable, but I've never actually seen any real evidence that either is true. Granted, I'm not necessarily expecting a scientific study, but I haven't even heard anecdotes. I can't offer much personally - I only really use stable to any extent and I find it works just fine other than the occasional need to unmask something. Rich
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 12:24, Rich Freeman ri...@gentoo.org wrote: On Thu, Aug 22, 2013 at 6:19 AM, Markos Chandras hwoar...@gentoo.org wrote: On 22 August 2013 11:01, Rich Freeman ri...@gentoo.org wrote: I think the result of a policy like this would be that stable keywords would get dropped on most peripheral packages, but system packages might still keep them. What's the point of that? Most users need more than what @system provides so after they deploy the 'stable' stage3 they will start pulling ~arch packages that were never tested against the stable tree. It so much better if stage3 was also ~arch. Do we actually have examples of this happening? I've never had problems with a mix of stable and ~arch keywords. Granted, I'm not running ~arch on most libs. Wow! That is something we actively encourage people to avoid. Mixed systems are totally unsupported and I am sure quite a few bugs are closed as invalid when a mixed system is detected. It may work on regular basis but encouraging and supporting such configurations is definitely not desirable. It's also a bit ehm, funny, to give them a stable stage3 and then tell them that for everything else, please use ~arch. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
On 08/22/2013 01:28 PM, Markos Chandras wrote:
On 22 August 2013 12:24, Rich Freeman ri...@gentoo.org wrote:
On Thu, Aug 22, 2013 at 6:19 AM, Markos Chandras hwoar...@gentoo.org wrote:
On 22 August 2013 11:01, Rich Freeman ri...@gentoo.org wrote:
I think the result of a policy like this would be that stable keywords
would get dropped on most peripheral packages, but system packages
might still keep them.
What's the point of that? Most users need more than what @system
provides so after they deploy the 'stable' stage3 they will
start pulling ~arch packages that were never tested against the stable
tree. It so much better if stage3 was also ~arch.
Do we actually have examples of this happening? I've never had
problems with a mix of stable and ~arch keywords. Granted, I'm not
running ~arch on most libs.
Wow! That is something we actively encourage people to avoid. Mixed
systems are totally
unsupported and I am sure quite a few bugs are closed as invalid when
a mixed system is detected.
It may work on regular basis but encouraging and supporting such
configurations is definitely not desirable.
Actually this what Gentoo is all about - for me. Having the option of a
well tested stable system and just bleeding edge where wanted
(i have ~10% of my packages from arch and it works like a charm, and
like only one bug report of mine was closed due an mixed arch issue).
Having a mixed setup isn't that absurd as you want it to be.
And forcing users to not use it renders all package.{accepted_,}keywords
granularity moot.
It's like nailing them to debian stable or debian testing w/o backports
or anything.
Please stop dooming this possibility. Mixing together software versions
isn't that much of a magic as you make of it.
It's also a bit ehm, funny, to give them a stable stage3 and then tell
them that for everything else, please use ~arch.
(I'm not saying that it doesn't hurt in some places, but it's
manageable, as is living on arches with stable core and very few stable
leave packages, like I've been doing on sparc, ppc and arm.)
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 13:17, Michael Weber x...@gentoo.org wrote:
Having a mixed setup isn't that absurd as you want it to be.
And forcing users to not use it renders all package.{accepted_,}keywords
granularity moot.
It's like nailing them to debian stable or debian testing w/o backports
or anything.
Please stop dooming this possibility. Mixing together software versions
isn't that much of a magic as you make of it.
I said that it is a combination not well tested so we do not encourage
this. Users are free to do whatever they want.
When did I say the opposite? However they should not expect much
support if they use a mixed system and they run into
troubles. Someone who does that, should know what he is doing and be
prepared to run into problems.
And I will stop here because this discussion is off-topic.
It's also a bit ehm, funny, to give them a stable stage3 and then tell
them that for everything else, please use ~arch.
(I'm not saying that it doesn't hurt in some places, but it's
manageable, as is living on arches with stable core and very few stable
leave packages, like I've been doing on sparc, ppc and arm.)
This is yet to be decided.
--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
22.08.2013 16:26, Markos Chandras пишет:
On 22 August 2013 13:17, Michael Weber x...@gentoo.org wrote:
Having a mixed setup isn't that absurd as you want it to be.
And forcing users to not use it renders all package.{accepted_,}keywords
granularity moot.
It's like nailing them to debian stable or debian testing w/o backports
or anything.
Please stop dooming this possibility. Mixing together software versions
isn't that much of a magic as you make of it.
I said that it is a combination not well tested so we do not encourage
this. Users are free to do whatever they want.
When did I say the opposite? However they should not expect much
support if they use a mixed system and they run into
troubles. Someone who does that, should know what he is doing and be
prepared to run into problems.
And I will stop here because this discussion is off-topic.
It's also a bit ehm, funny, to give them a stable stage3 and then tell
them that for everything else, please use ~arch.
(I'm not saying that it doesn't hurt in some places, but it's
manageable, as is living on arches with stable core and very few stable
leave packages, like I've been doing on sparc, ppc and arm.)
This is yet to be decided.
I have mixed setup for years:
pinkbyte@oas1 ~ $ ls /etc/portage/package.accept_keywords/ -1 | wc -l
19
At home this number is above 40, iirc.
And i do not think that refusing bugreports from such systems is a
proper way.
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
22.08.2013 06:05, Albert Hopkins пишет: This sounds like cool stuff... I wonder if this could be a step towards unprivileged users being able to use portage for user-installed apps. Try Prefix[1], it works very well in some cases ;-) [1] - http://www.gentoo.org/proj/en/gentoo-alt/prefix/ -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more arches to dev profiles
On 08/22/2013 02:26 PM, Markos Chandras wrote:
On 22 August 2013 13:17, Michael Weber x...@gentoo.org wrote:
Having a mixed setup isn't that absurd as you want it to be.
And forcing users to not use it renders all package.{accepted_,}keywords
granularity moot.
It's like nailing them to debian stable or debian testing w/o backports
or anything.
Please stop dooming this possibility. Mixing together software versions
isn't that much of a magic as you make of it.
I said that it is a combination not well tested so we do not encourage
this. Users are free to do whatever they want.
Actually every other post is about keywording special versions or
running --autounmask-write. I'm saying that we do not encourage this
might not be the reality on forums/blogs/channels.
When did I say the opposite? However they should not expect much
support if they use a mixed system and they run into
troubles. Someone who does that, should know what he is doing and be
prepared to run into problems.
And I will stop here because this discussion is off-topic.
It's also a bit ehm, funny, to give them a stable stage3 and then tell
them that for everything else, please use ~arch.
(I'm not saying that it doesn't hurt in some places, but it's
manageable, as is living on arches with stable core and very few stable
leave packages, like I've been doing on sparc, ppc and arm.)
This is yet to be decided.
This is the established road that leads to user supplied KEYWORDREQ and
STABLEREQ bugs. And reality for sparc/ppc/arm, which lacks stable
keywords on lots of packages.
Imho, x86 should be added to the list too.
trollWhich environmental responsible persons runs these CPUs these
days./troll
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Moving more arches to dev profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/08/13 06:19 AM, Markos Chandras wrote: What's the point of that? Most users need more than what @system provides so after they deploy the 'stable' stage3 they will start pulling ~arch packages that were never tested against the stable tree. It so much better if stage3 was also ~arch. Actually this brings up a good point in general -- we have enough problems auto-rolling stable stage3's half the time, is it likely that we'll be able to roll ~arch stage3's for these minor arches on a regular basis if we *DO* drop all stable keywords from them?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIWDzUACgkQ2ugaI38ACPBnXgD+OYOf0ygaaR8YnCUWZmTre07p 43NJKsUpkuWJrPTxMRcBAI4tqZRYbsyLV/W9YmuqC7As3MZRLI8X58KlGLUtI5Oa =epp1 -END PGP SIGNATURE-
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
Dnia 2013-08-21, o godz. 22:05:21 Albert Hopkins mar...@letterboxes.org napisał(a): This sounds like cool stuff... I wonder if this could be a step towards unprivileged users being able to use portage for user-installed apps. I doubt it. Especially that those features actually require root privileges to be enabled :). (or CAP_SYS_ADMIN) -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Moving more arches to dev profiles
On Thu, 22 Aug 2013 14:47:18 +0200 Michael Weber x...@gentoo.org wrote: On 08/22/2013 02:26 PM, Markos Chandras wrote: I said that it is a combination not well tested so we do not encourage this. Users are free to do whatever they want. Actually every other post is about keywording special versions or running --autounmask-write. I'm saying that we do not encourage this might not be the reality on forums/blogs/channels. This might be a possible language barrier; please note that we do not encourage this can be interpreted as we encourage that you do not do this but also as we have no encouragement for this, whether it implies that we do or do not advice a choice depends on the context. Regardless, lots of people encourage others to not mix their system or use --autounmask-write in a careless way; in other words, they encourage them to only use it if they must and to be careful in how they do this. That's at least the impression that I get from our support places; in my personal opinion, I think that is the way it should be used. The goal should be for the file to be a sane solution for the user that needs it; it shouldn't become a file that is filled with all kinds of suggestions Portage can throw at you, some just aren't sane to do. Every other post shouldn't be the goal, it should be the exception... -- 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] Moving more arches to dev profiles
On Thu, Aug 22, 2013 at 7:28 AM, Markos Chandras hwoar...@gentoo.org wrote: On 22 August 2013 12:24, Rich Freeman ri...@gentoo.org wrote: Do we actually have examples of this happening? I've never had problems with a mix of stable and ~arch keywords. Granted, I'm not running ~arch on most libs. Wow! That is something we actively encourage people to avoid. Mixed systems are totally unsupported and I am sure quite a few bugs are closed as invalid when a mixed system is detected. So, this is what I was talking about - people say this but it really hasn't been borne out in reality as far as I can tell. I can certainly say that maintainers handle bugs from mixed systems all the time, if for no other reason than it is pretty hard to tell that a mixed system is in use. When bugs do crop up on mixed systems they're often the result of dependency errors - ones that are obscured by the fact that the package has only been tested on a ~arch system. The more subtle issue is if a stable package has an unstated cat/foo-ver dep and pulling in foo breaks some other stable package. Those really are still valid bugs, though it may not be so easily fixed except in the short term (unless slotted a version dep is hard to support). I've gotten caught by these on a few of my own packages, since I only testing them on ~arch very lightly (since I don't run ~arch in general) - when it happens the deps get fixed and things are just that much better off when they get to stable (and if ~arch breaks on rare occasion that is what it is for). I see the ability to run a mixed system as one of the big benefits of using Gentoo - few distros support this nearly as well. As far as it being unsupported on Gentoo goes - that all depends on your definition of support. We don't do a lot of handholding for ANY of our users. Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/gnote: gnote-3.8.1.ebuild ChangeLog
RCS file: /var/cvsroot/gentoo-x86/app-misc/gnote/ChangeLog,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- ChangeLog 22 Aug 2013 16:14:52 - 1.34 +++ ChangeLog 22 Aug 2013 16:36:24 - 1.35 @@ -1,6 +1,9 @@ # ChangeLog for app-misc/gnote # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/app-misc/gnote/ChangeLog,v 1.34 2013/08/22 16:14:52 jbartosik Exp $ +# $Header: /var/cvsroot/gentoo-x86/app-misc/gnote/ChangeLog,v 1.35 2013/08/22 16:36:24 jbartosik Exp $ + + 22 Aug 2013; jo...@gentoo.org gnote-3.8.1.ebuild: + Fix a problem pointed out by Pacho Ramos. 22 Aug 2013; jo...@gentoo.org gnote-3.8.1.ebuild: Fix too hasty commit: use proper src_install. Your ECHANGELOG_USER variable is incorrect. Your ChangeLogs have no name and the email address looks a bit weird. I presume the correct one should be jbarto...@gentoo.org Please read this http://devmanual.gentoo.org/tools-reference/echangelog/index.html -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
Am Donnerstag, 22. August 2013, 13:28:24 schrieb Markos Chandras: Do we actually have examples of this happening? I've never had problems with a mix of stable and ~arch keywords. Granted, I'm not running ~arch on most libs. Wow! That is something we actively encourage people to avoid. Mixed systems are totally unsupported and I am sure quite a few bugs are closed as invalid when a mixed system is detected. Markos, outdated information. I'd consider that standard and recommended procedure. Whoever closes bugs with combining stable and testing is unsupported needs a good kick . Cheers, A -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Moving more arches to dev profiles
On Thu, Aug 22, 2013 at 09:03:35AM +0200, Michael Weber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/22/2013 08:38 AM, Sergey Popov wrote: 21.08.2013 22:28, Alexis Ballier пишет: Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc? I like this way much more. Let's clarify stabilization policy for some minor arches, e.g. policy about stabilization requests for huge packages. Cause dropping entire arch to ~arch maybe sometimes a bit overkill. And hard to revert. Sparc did drop a lot of keywords lately, by removing itself from STABLEREQ w/o stabling the mentioned package. Give maintainers some ability to take some action as well. Say I maintain package foo, and there is an old version that is stable on a minor arch. Say a stabilization request for a newer version has been opened for a while (30-60 days is probably sufficient) and the arch team hasn't responded. I want a path that would allow me to remove the older version of foo from the tree and close out the stable request. William signature.asc Description: Digital signature
[gentoo-dev] Using use.stable.mask
Hi, It seems to be a pattern now to mask the language target USE flags for unstable versions, such as python_targets_python3_3 and php_targets_php5-5. This is very handy since e.g I do not need two revisions of dev-php/xdebug: - one that can be stabilised, supporting stable php5.3 and php5.4and one supporting - one that cannot be stabilised supporting also php5.5 However, now the time has come for php5.5 to be stabilised, and all is working great except that I cannot remove php_targets_php5-5 from use.stable.mask until all arches have stabilised php. For those arches with stable php5.5, confusion arise when they see that they cannot enable php5.5 for any ebuilds without first adding them to ~arch. This have led to bug 481532 as well as comments in stabilisation req bug 480460 A part of the problem is that x86 and amd64 is stabilised fairly quickly after filing the stabilisation bug, while for the other arches it often takes some more time. I suppose the problem could have been mitigated by each arch team stating it can be stabilised in the bug, and then do the actual keywordking at the same time. Does anyone have any idea how to handle this issue? -- Ole Markus
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/gnote: gnote-3.8.1.ebuild ChangeLog
Dnia 2013-08-22, o godz. 19:13:25 Markos Chandras hwoar...@gentoo.org napisał(a): RCS file: /var/cvsroot/gentoo-x86/app-misc/gnote/ChangeLog,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- ChangeLog 22 Aug 2013 16:14:52 - 1.34 +++ ChangeLog 22 Aug 2013 16:36:24 - 1.35 @@ -1,6 +1,9 @@ # ChangeLog for app-misc/gnote # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/app-misc/gnote/ChangeLog,v 1.34 2013/08/22 16:14:52 jbartosik Exp $ +# $Header: /var/cvsroot/gentoo-x86/app-misc/gnote/ChangeLog,v 1.35 2013/08/22 16:36:24 jbartosik Exp $ And being a little picky, those changelog messages don't look very helpful. + 22 Aug 2013; jo...@gentoo.org gnote-3.8.1.ebuild: + Fix a problem pointed out by Pacho Ramos. What problem? You should describe the changes, at least with general keyword like 'cleanup', 'missing dep', 'missing inherit' etc. Pointed out where? Is there a bug about it? If yes, you should mention it. 22 Aug 2013; jo...@gentoo.org gnote-3.8.1.ebuild: Fix too hasty commit: use proper src_install. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Using use.stable.mask
Dnia 2013-08-22, o godz. 21:08:52 Ole Markus With olemar...@gentoo.org napisał(a): However, now the time has come for php5.5 to be stabilised, and all is working great except that I cannot remove php_targets_php5-5 from use.stable.mask until all arches have stabilised php. For those arches with stable php5.5, confusion arise when they see that they cannot enable php5.5 for any ebuilds without first adding them to ~arch. [snip] Does anyone have any idea how to handle this issue? I'm not sure if I understand you correctly but wouldn't it be enough to move the stable.masks to arch profiles? Then each arch could remove it whenever ready. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Using use.stable.mask
On Thu, Aug 22, 2013 at 12:08 PM, Ole Markus With olemar...@gentoo.org wrote: However, now the time has come for php5.5 to be stabilised, and all is working great except that I cannot remove php_targets_php5-5 from use.stable.mask until all arches have stabilised php. You could have separate use.stable.mask entries in each of the arch profiles.
Re: [gentoo-dev] Using use.stable.mask
On 22/08/13 21:27, Zac Medico wrote: On Thu, Aug 22, 2013 at 12:08 PM, Ole Markus With olemar...@gentoo.org wrote: However, now the time has come for php5.5 to be stabilised, and all is working great except that I cannot remove php_targets_php5-5 from use.stable.mask until all arches have stabilised php. You could have separate use.stable.mask entries in each of the arch profiles. I was under the impression that these files should be maintained by the respective arch team. I wanted to avoid depending on them for fixing before I was able to start adding php_targets_php5-5 to ebuilds. -- Cheers, Ole Markus
Re: [gentoo-dev] Using use.stable.mask
On Thu, Aug 22, 2013 at 1:30 PM, Ole Markus With olemar...@olemarkus.org wrote: On 22/08/13 21:27, Zac Medico wrote: On Thu, Aug 22, 2013 at 12:08 PM, Ole Markus With olemar...@gentoo.org wrote: However, now the time has come for php5.5 to be stabilised, and all is working great except that I cannot remove php_targets_php5-5 from use.stable.mask until all arches have stabilised php. You could have separate use.stable.mask entries in each of the arch profiles. I was under the impression that these files should be maintained by the respective arch team. I wanted to avoid depending on them for fixing before I was able to start adding php_targets_php5-5 to ebuilds. Well, you can instruct the arch teams to make appropriate adjustments to their profiles at that same time as adding keywords. They should be able to override the existing global settings.
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 01:30:59PM +0200, Tom Wijsman wrote: On Wed, 21 Aug 2013 13:09:55 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Aug 21, 2013 at 1:04 PM, Markos Chandras hwoar...@gentoo.org wrote: I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc +many. ++many. If any of these arches considers themselves to be a major arch; they need to speak up and let us know if reasonable, but then we also need to ensure that we draw more manpower to such major arch. I think we are looking at this problem the wrong way. Why not define what is needed to be a major arch and a minor arch (~arch only). Then drop a marjor arch to a minor arch if they don't meet the requirement. For example, we could define a major as having an arch lead, 3 active devs (commited to the cvs tree in the last xyz number of days), etc I've been trying to get more involved with ia64, sparc, ppc, ppc64 so my vote is to keep those arch as a major arch. I'd be willing to help out ago mark ebuilds stable but as others have pointed out he does such a good job, its hard to compete with him ;) Cheers, -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A signature.asc Description: Digital signature
