Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] grimoire general problem.

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: Benoit PAPILLAULT <benoit.papillault AT sourcemage.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] grimoire general problem.
  • Date: Wed, 16 Feb 2005 08:52:13 -0800

On Wed, Feb 16, 2005 at 09:52:04AM +0100, Benoit PAPILLAULT wrote:
> Seth Alan Woolley a écrit :
> >When an official ISO comes out, gcc-3.4.x and a more recent glibc
> >snapshot should be in place in the stable grimoire.
>
> gcc-3.4 will be in stable soon??? Is it something new or did i missed
> something in the past mails?

There's a bug for it, and most of the problems with gcc-3.4 are
resolved. It's my anticipation reading the bug that it will be in test
soon, and in stable after that in time for an official ISO release.

>
> >A clear solution is to have benoit install a custom grimoire with all
> >his fixes onto the test iso. They don't get trammeled on update, and,
> >if he commits them to perforce, we can see exactly what he's having
> >issues with so we can pull the fixes into test and then to stable.
>
> Correct. That would be a solution I've been thinking of. But since it
> has been decided up to now that stable should be used, I will not
> consider it agreed on and won't implement it.

Wait, there's a difference between what you do in test isos and what you
do in stable isos. For a stable iso, there shouldn't be a custom
grimoire at all. For a test iso, it should use stable griomire with a
fixes overlay. When all the fixes are in stable, you drop the overlay
grimoire, freeze the stable grimoire except for ISO-critical bugfixes,
and then release.

>
> >Or he can commit to devel and ask for quick testing before we do an
> >early pull to stable. In any case, if it hit perforce where other
> >developers can see active, immediate feedback, we'd actually know about
> >the problems before they become a problem. The feedback cycle works
> >both ways.
>
> I'm going to ask that for glibc. I'm pretty surprised that apparently
> nobody will take care of the bugs I reported on glibc devel version
> since they don't seem mandatory to solve the initial issue (installed
> system not able to rebuild).

If they are mandatory, can you explain why they are mandatory rather
than declaring that they (your specific fixes rather than proposed
alternatives) are mandatory?

>
> I'm pretty worried about this point because, as part of my ISO job, we
> have discussed about using INSTALL_ROOT feature to solve some problem of
> the current ISO generation script and i'm currently investigating it.
> So, if the glibc spell in devel do not implement this feature, either I
> need to have my own grimoire (with the possibility of re-creating the
> initial problem), either I leave.

There are two bugs about this:

http://bugs.sourcemage.org/show_bug.cgi?id=7209
http://bugs.sourcemage.org/show_bug.cgi?id=8242

Do you have a patch that fixes the 8242 issue?

Are you using INSTALL_ROOT right now? Is this holding back your push to
a release?

>
> Furthermore, I reported as much bugs as possible because I tested devel
> glibc as much as I can and I think it would be good to have a rock solid
> glibc, especially since it's going to be in stable pretty soon. It's up
> to grimoire's people to let us know if they are going to fix them or not.
>
> Since some of the fix to those bugs have been posted in bug #7560, they
> can just be integrated in devel glibc. Can I take care of that last
> point if nobody is already doing it? (This last question is directed to
> our grimoire lead or to the people currently working in devel glibc). I
> have asked now :-)

Reading that bug indicates that you proposed fixes and the sorcery and
grimoire team leaders worked on an alternative method that appears to
have worked. If there's some reason that's not the case, can you note
it in the bug? The last three comments are from people other than you,
so it seems there is some feedback happening.

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8 3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgpf2CBbABtaF.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page