[gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Fri, 05 Jul 2013 21:27:46 -0700 Brian Dolbec wrote: > On Fri, 2013-07-05 at 22:18 -0400, Rick "Zero_Chaos" Farina wrote: > > On 07/05/2013 09:41 PM, Ryan Hill wrote: > > > On Fri, 05 Jul 2013 15:47:08 -0400 > > > "Rick \"Zero_Chaos\" Farina" wrote: > > > > > >> -BEGIN PGP SIGNED MESSAGE- > > >> Hash: SHA1 > > >> > > >>> Paweł was nice enough to write a patch for us to get toolchain.eclass > > >>> up to EAPI 5. I believe it still needs some pieces like prefix support > > >>> and I haven't reviewed it in depth but it looks good so far (and much > > >>> simpler than I thought (oops)). I'm planning on moving up an EAPI at a > > >>> time, bumping it whenever we could use new features or people start > > >>> hucking fruit. > > >>> > > >>> > > >> I would be forever in your debt if toolchain were on eapi 5 and had > > >> proper subslot deps. > > > > > > What use case are you encountering? I hadn't planned on using subslots, > > > but I'm open to good reasons/bribery. > > > > > > > > > > Livecd builds work like this: > > > > stage3 tarball is unpacked, then toolchain (minimum package set) is > > built with ROOT=/tmp/stage1root and is linked to the original (seed > > stage) while being built. > > > > When we then move onto stage 2, it uses just the packages built during > > stage1 (/tmp/stage1root becomes /). This means, if seed stage has > > mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in > > stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. > > > > To combat this kind of failure we are currently running "emerge --update > > --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could > > just be "emerge --update gcc" if eapi 5 subslots were used properly. > > > > Please forgive me if any of these details aren't perfect, I'm using my > > best recollection of the most recent issue which happened when mpc was > > bumped a few months ago. > > > > I am available on irc quite a bit if you would like to discuss, however, > > if you want to keep it on the ML we really need to move this to -dev. > > > > Thanks, > > Zero > > Continuing this on -dev mail list. > > > The other thing we needed to do was completely remove the use of or > building of binpkgs during the update_seed stage. Portage has no > capability to check binpkg linking to ensure the binpkg was properly > usable. EAPI 5 subslots also put that info into the DEPENDS so portage > then considers that information. It would then reject a binpkg properly > and build from source due to the abi mismatch. I might also add that > using broken binpkgs in catalyst (like the mpc update) cause delayed > breakage, making trouble shooting the problem more difficult. > > With proper use of subslots for base system pkgs, binpkgs can be re-used > safely, saving both build and turn around time to get fully working > stages and livecd's etc. in catalyst released. The same holds true for > user systems that build and try to reuse binkgs. Thanks, these are good reasons. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Fri, 2013-07-05 at 22:18 -0400, Rick "Zero_Chaos" Farina wrote: > On 07/05/2013 09:41 PM, Ryan Hill wrote: > > On Fri, 05 Jul 2013 15:47:08 -0400 > > "Rick \"Zero_Chaos\" Farina" wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >>> Paweł was nice enough to write a patch for us to get toolchain.eclass up > >>> to > >>> EAPI 5. I believe it still needs some pieces like prefix support and I > >>> haven't reviewed it in depth but it looks good so far (and much simpler > >>> than I thought (oops)). I'm planning on moving up an EAPI at a time, > >>> bumping it whenever we could use new features or people start hucking > >>> fruit. > >>> > >>> > >> I would be forever in your debt if toolchain were on eapi 5 and had > >> proper subslot deps. > > > > What use case are you encountering? I hadn't planned on using subslots, but > > I'm open to good reasons/bribery. > > > > > > Livecd builds work like this: > > stage3 tarball is unpacked, then toolchain (minimum package set) is > built with ROOT=/tmp/stage1root and is linked to the original (seed > stage) while being built. > > When we then move onto stage 2, it uses just the packages built during > stage1 (/tmp/stage1root becomes /). This means, if seed stage has > mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in > stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. > > To combat this kind of failure we are currently running "emerge --update > --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could > just be "emerge --update gcc" if eapi 5 subslots were used properly. > > Please forgive me if any of these details aren't perfect, I'm using my > best recollection of the most recent issue which happened when mpc was > bumped a few months ago. > > I am available on irc quite a bit if you would like to discuss, however, > if you want to keep it on the ML we really need to move this to -dev. > > Thanks, > Zero Continuing this on -dev mail list. The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. EAPI 5 subslots also put that info into the DEPENDS so portage then considers that information. It would then reject a binpkg properly and build from source due to the abi mismatch. I might also add that using broken binpkgs in catalyst (like the mpc update) cause delayed breakage, making trouble shooting the problem more difficult. With proper use of subslots for base system pkgs, binpkgs can be re-used safely, saving both build and turn around time to get fully working stages and livecd's etc. in catalyst released. The same holds true for user systems that build and try to reuse binkgs.
Re: [gentoo-dev] Gentoo Hangouts
Not to mention how do you actually log a hangout for the record instead of already having logs from an irc session or mailing list. On Thu, Jul 4, 2013 at 2:10 AM, Peter Stuge wrote: > Diego Elio Pettenò wrote: > > just opening a webcam and talking is just going to give an amateurish > feeling > > ..as opposed to the very professional mailing list. > > > //Peter > >
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Fri, 5 Jul 2013 09:38:10 +0100 "Steven J. Long" wrote: > Tom Wijsman wrote: > > > > Yes, we currently have "base" and "extras" tarballs for genpatches; > > it is trivial to add a "experimental" tarball to this set, all the > > optional experimental patches will be in that tarball. This is also > > handy for maintainers of other distros whom use genpatches. > > That's cool. The bit about the user explicitly opting-in to 'fragile' > patches still is of concern, however. Why is this still of concern? (See the next response before replying) > > There shouldn't be a problem here unless the user applies a lot of > > patches that could introduce a colliding patch; in this case the > > user either has to fix the conflicting patch or exclude ours. We > > can't know for ourselves which patches will be troublesome in this > > light; but well, I feel like this only happens on a very > > exceptional basis. If an user keeps this amount of patches, ours > > are probably not needed. > > No, the problem is as mentioned, with patches for which disabling the > configure option, does not stop the patch from changing anything. Such > as aufs, as has been outlined by Greg K-H earlier in the thread. My original post mentions "3) The patch should not affect the build by default.", which I later clarified with "It's just a matter of embedding each + block in the diff with a config check and updating the counts."; in detail we QA check whether all blocks contain such a config check. It does not change anything other than insert some code which won't be parsed if you don't enable the relevant option in the menu config. > [... SNIP ...]; and can hardly be called "Proper integration", imo. Why not? > After all, these are experimental patches. If they don't play nicely, > don't let them out of the sandbox, unless the user tells us to. It's the user that can let each individual patch out of its sandbox. > Having a clear "policy" on that makes negotiating with patch authors > much simpler too, and it's far more likely they'll fall into line > where possible, just as upstreams are usually quite happy to apply > portability patches: it means they get more users and feedback. Not sure what is meant by this; but given my above clarifications, I think you were missing a detail in the approach that is taken. -- 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
[gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
Tom Wijsman wrote: > Steven J. Long wrote: > > Tom Wijsman wrote: > > > "Steven J. Long" wrote: > > > > If it does [affect the build by default] then it should never be > > > > applied, unless the user specifically asks for it, imo, and the > > > > resultant kernel is labelled -exp as you suggest. > > > > > > Yes, we are going to introduce an experimental USE flag for this. > > > > That's for the over-arching set of patches isn't it? Which takes care > > of the labelling. > > Yes, we currently have "base" and "extras" tarballs for genpatches; it > is trivial to add a "experimental" tarball to this set, all the > optional experimental patches will be in that tarball. This is also > handy for maintainers of other distros whom use genpatches. That's cool. The bit about the user explicitly opting-in to 'fragile' patches still is of concern, however. > > I think a lot of these things are checks that should happen before > > patches are included, and on every upgrade. So we need to separate > > out what the developer/ebuild-maintainer has to do to prepare files/, > > and what needs to happen in the ebuild itself. > > Please note that this discussion is regarding genpatches; so, there is > no files/ directory and the ebuild change is very minimal, changing one > or two numbers to indicate the genpatches version to use. > > Every time I add a patch to genpatches I compile a test kernel using a > test ebuild; I plan to add these checks to our genpatches scripts, then > I can call the checks script from the ebuild in a QA way. Ah OK, sorry for confusion in that case. Glad to hear you have QA covered. > > > > Unless of course the user specifically requests it. This can be a > > > > simple variable with a list of required patches, or whatever. > > > > > > With USE=-experimental (which will be the default) they are > > > excluded by default, after enabling that the user can exclude > > > patches by setting UNIPATCH_EXCLUDE through the package.env > > > mechanism. > > > > I'd feel happier if certain patches, the troublesome ones discussed, > > had to be explicity enabled, before the configuration options and the > > patch to kernel files took place. Perhaps via UNIPATCH_INCLUDE or > > USE=aufs. > > There shouldn't be a problem here unless the user applies a lot of > patches that could introduce a colliding patch; in this case the user > either has to fix the conflicting patch or exclude ours. We can't know > for ourselves which patches will be troublesome in this light; but > well, I feel like this only happens on a very exceptional basis. If an > user keeps this amount of patches, ours are probably not needed. No, the problem is as mentioned, with patches for which disabling the configure option, does not stop the patch from changing anything. Such as aufs, as has been outlined by Greg K-H earlier in the thread. This addresses the entirely reasonable concerns of users like Walter and myself, as well as the warning alarms sounded by an upstream maintainer and others. Not to address the issue risks derailing the whole effort before it has begun; and can hardly be called "Proper integration", imo. After all, these are experimental patches. If they don't play nicely, don't let them out of the sandbox, unless the user tells us to. Having a clear "policy" on that makes negotiating with patch authors much simpler too, and it's far more likely they'll fall into line where possible, just as upstreams are usually quite happy to apply portability patches: it means they get more users and feedback. Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] font.eclass add Xorg FontPath elements for non-standard paths
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/05/2013 08:37 AM, James Cloos wrote:
> While making it easier for those who want all of their fonts
> included in the x11 server-side font list is not an unreasonable
> goal, forcing them to be is unreasonable.
>
> As someone who has run X11 regularly for over 20 years now, I
> absolutely do not want any type1 or SFNT fonts in my x server font
> path. Any app I use these days with such fonts supports
> client-side fonts. For the apps which require server-side fonts,
> the bfd fonts suit best.
Ok, so optional enabled (opt-in) it will be.
> Putting all of /usr/share/fonts into the fontpath will only slow
> the X11 startup.
By which amount?
> I'd suggest either an eselect(1) driven applet to let one choose
> which directories to add to a single .d conf file, or perhaps a
> non-gentoo- specific gui app to do so. Either of those would
> provide exactly the right sort of configuation assistance for users
> who are not comfortable editing their configs in text editors.
It's not the editing of config files that concerns me, it's the need
to do so after every font installation, and keep it in sync with
installation.
What do you and Ryan think about naming the suggested file
xorg.conf.d/90-font.conf.${suffix}, add :pri=50 to every line,
so users who want it can symlink it to .conf to be loaded.
With suffix:=all or gentoo-all-fonts
User edits in .conf.in could set other priorities.
Would that be ok?
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlHWc0oACgkQknrdDGLu8JAtpQD9GUS2c01M55OvRS2gi8p2r3vs
rPs1MR9XhB8+Jgj5vl0A+gLsbDKPv/nrvS2x2z35fzwonP5DM5ESPYBdaKPaICSw
=eU0D
-END PGP SIGNATURE-
