[gentoo-dev] Gentoo/MIPS SGI LiveCD RC5 release

[Kumba]

After lots of tinkering, testing and other odd n' ends, I released on Tuesday a 
new revision of the SGI LiveCD.  Like its predecessor, RC4, this is a single CD 
that will boot and bring up several completely different SGI systems to a state 
where an install can be started.


This is one of those golden states long desired in the Linux/MIPS community, as 
previously, the only other bootable CD's capable of doing this is IRIX install 
media.  This CD is still considered RC for the time begin as several of the 
supported systems can be tricky at times to get started.  Most notably, the SGI 
Origin (IP27) series.


Perhaps the most interesting aspect of this CD is in its creation -- it was 
largely built using the upcoming 2.0 release of gentoo's release engineering 
tool, Catalyst.  Much thanks goes to Eric Edgar (rocket) and Chris Gianelloni 
(wolf31o2) of the gentoo-releng team for their assistance on the Catalyst2 side 
of things (this helped to nail several bugs in cat2 as well).


Additional thanks is extended to Stanislaw Skowronek (Skylark) for his ARCLoad 
(sys-boot/arcload) [bootloader], sgibootcd (sys-boot/sgibootcd) [CD Image 
Creator], and getdvhoff (sys-boot/getdvhoff) [utility] tools used in this CD, or 
in its creation, as well as to 'learath' of #mipslinux for SGI Origin testing 
access.


More info can be found in the README regarding questions, comments and bugs.

Initially, this can be found in my dev directory here:
http://dev.gentoo.org/~kumba/mips/releases/livecd-rc5/

But it will soon be up onto the mirrors under the experimental/mips folder.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated

[Flammie Pirinen]

2005-10-20, Petteri Räty sanoi, jotta:

> Flammie Pirinen wrote:
> > 2005-10-19, Petteri Räty sanoi, jotta:
> > 
> >>might translate the longdescriptions
> >>in metadata.xml files to Finnish.
> > 
> > 
> > Hmm, can I suggest some QA or similar stuff for these before
> > committing? I don't fully know what's the visibility of this stuff
> > though, but I'd feel much nicer if they were at least proofread or
> > peer evaluated once before providing them to public. I don't mean to
> > question your Finnish capabilities of course, I've just
> > participated in Finnish localisations of Open Source things long
> > enough to know how bad Finnish some people can produce.
> > 
> 
> I think herdstat can use this data but that's about it I think.

In that kind of case it's of course not needed. I was more thinking
along the lines that if they are commonly visible to end user via eg.
packages.gentoo.org or using some emerge or equery command, or possibly
even graphical package managers or even installer, then they will need
to be in top shape.

> Considering that every developer can add the English longdescriptions
> there without any peer review, I think it would be an overkill for
> Finnish translations. But if this is a problem I can of course run
> some diffs through you or something.

Well, any developer can add English documentation in to w.g.o webspace
as it is, and any developer can also write very visible e* output to
ebuilds etc. etc., so I suppose the quality standard has wider threshold
for English in general. Or perhaps we just trust that all gentoo
developers write perfect English already :-)


-- 
Flammie, Gentoo Linux Documentation's Finnish head translator.



pgpCZ2hHoFwq1.pgp
Description: PGP signature

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[Chris Gianelloni]

On Wed, 2005-10-19 at 21:44 +0100, John Mylchreest wrote:
> I don't particular feel comfortable doing this. the only place I can
> actually see this being of some use is with the pkg_config since an
> ebuild postinst is far too soon, and patching up Kbuild to do this is
> far too intrusive (let alone high maintenance).
> 
> A possibility (although I wouldnt like to promote it through portage)
> would be to have a wrapper/helper script which would do all of this for
> you. build-kernel or some such. But then... whats genkernel for right?

Actually, genkernel does have the --callback option, which runs an
external command before finalizing the build.  We use it for building
external modules and packages that require a configured kernel when
building the releases, but I think adding an option to genkernel
wouldn't be bad to do this for you.  We could add a command-line switch
to genkernel to automatically rebuild any external modules after it has
built the kernel.  We could use something like --autorebuild.  You could
then do something like "genkernel --autorebuild all" to build your new
kernel and automatically rebuild all of your external modules.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated

[Petteri Räty]

Flammie Pirinen wrote:
> 2005-10-19, Petteri Räty sanoi, jotta:
> 
> 
>>I thought that when I am bored I
> 
> 
> Join GDP Finnish translation team! We're still short one followup
> translator and pile of alt-arch stuff at least before getting official
> status and linkage. ;-)
> 

I might one day one when I have the time. At the moment I think I am a
little too busy. Because I regularly touch metadata.xml files when
working with packages I think I will stick to translating those when I
feel like it.

> 
>>might translate the longdescriptions
>>in metadata.xml files to Finnish.
> 
> 
> Hmm, can I suggest some QA or similar stuff for these before
> committing? I don't fully know what's the visibility of this stuff
> though, but I'd feel much nicer if they were at least proofread or peer
> evaluated once before providing them to public. I don't mean to
> question your Finnish capabilities of course, I've just participated in
> Finnish localisations of Open Source things long enough to know how bad
> Finnish some people can produce.
> 

I think herdstat can use this data but that's about it I think.
Considering that every developer can add the English longdescriptions
there without any peer review, I think it would be an overkill for
Finnish translations. But if this is a problem I can of course run some
diffs through you or something.

> 
> Well, I'm no expert on Portage tree stuff of course, but isn't that a
> bit too complex for the problem. I mean, if some description gets
> changed so crucially that translations need to be updated -- which as
> far as I understand shouldn't be too often -- wouldn't it be enough to
> just drop the old translations? If you really need automatic
> notification on changes in these things, cvs mailing list or CIA bot is
> easy way to see them.
> 

That would work of course, but if this data is one day going to be used
by more users then having data marked as outdated is IMHO better than
not having any data at all. With the way the Portage tree works at the
moment the removal would fast reach users too.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated

[Flammie Pirinen]

2005-10-19, Petteri Räty sanoi, jotta:

> I thought that when I am bored I

Join GDP Finnish translation team! We're still short one followup
translator and pile of alt-arch stuff at least before getting official
status and linkage. ;-)

> might translate the longdescriptions
> in metadata.xml files to Finnish.

Hmm, can I suggest some QA or similar stuff for these before
committing? I don't fully know what's the visibility of this stuff
though, but I'd feel much nicer if they were at least proofread or peer
evaluated once before providing them to public. I don't mean to
question your Finnish capabilities of course, I've just participated in
Finnish localisations of Open Source things long enough to know how bad
Finnish some people can produce.

> While thinking about it the
> following problem came to mind: When the English descriptions are
> updated there is no way currently to mark the other translations as
> outdated. I think it would be create to have a modified attribute
> [...]

Well, I'm no expert on Portage tree stuff of course, but isn't that a
bit too complex for the problem. I mean, if some description gets
changed so crucially that translations need to be updated -- which as
far as I understand shouldn't be too often -- wouldn't it be enough to
just drop the old translations? If you really need automatic
notification on changes in these things, cvs mailing list or CIA bot is
easy way to see them.

-- 
Flammie, Gentoo Linux Documentation's Finnish head translator.



pgpM5QQnJDeiF.pgp
Description: PGP signature

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[John Mylchreest]

> 2005/10/19, Herbert G. Fischer <[EMAIL PROTECTED]>:
> Perhaps the modules-update could be extended to detect new
> kernels and warn users or automatically update modules. This
> could also be documented in Gentoo docs since this is a basic
> and common problem that almost every Gentoo user may have.

module-rebuild shouldn't really have this task. it isn't the right place
to do it. It will of course quite happily do what you need it to do,
rebuild anything which installs a kernel module from portage.
> 
> 2005/10/19, John Myers <[EMAIL PROTECTED]>

> if [ -n "$(which module-rebuild 2>/dev/null)" ] ;
> then 
> if [ -n "${AUTO_MODULE_REBUILD}" ] ; then
> echo "Rebuilding external modules:"
> module-rebuild ${MODULE_REBUILD_OPTIONS}
> rebuild
> else
> echo "You might want to rebuild the following
> external modules:" 
> module-rebuild -XC list | tail -n +2
> echo
> echo "You can use module-rebuild to do that."
> echo "If you want to have your external
> modules automatically rebuilt" 
> echo "when making a kernel's modules_install
> target, set"
> echo "AUTO_MODULE_REBUILD in your environment.
> You can set"
> echo "MODULE_REBUILD_OPTIONS to options to
> pass to module-rebuild." 
> echo "(-X for example)"
> fi
> else
> echo "You might want to emerge
> sys-kernel/module-rebuild to keep track of"
> echo "kernel modules you've installed with
> emerge" 
> fi
> 
I don't particular feel comfortable doing this. the only place I can
actually see this being of some use is with the pkg_config since an
ebuild postinst is far too soon, and patching up Kbuild to do this is
far too intrusive (let alone high maintenance).

A possibility (although I wouldnt like to promote it through portage)
would be to have a wrapper/helper script which would do all of this for
you. build-kernel or some such. But then... whats genkernel for right?

- John


-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated

[Eric Brown]

I think someone in the documentation herd (Xavier Neys?) has a system for this 
in place for regular documents, but it's probably not used for metadata files 
yet.

-Original Message-
From: Petteri Räty [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 19, 2005 3:59 PM
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Adding support to metadata.xml to mark longdescriptions 
as outdated

I thought that when I am bored I might translate the longdescriptions in
metadata.xml files to Finnish. While thinking about it the following
problem came to mind: When the English descriptions are updated there is
no way currently to mark the other translations as outdated. I think it
would be create to have a modified attribute or make an other solution
that would make it easy to find outdated descriptions in the tree. The
modification of the date could easily be integrated to for example repoman.

Regards,
Petteri Räty (Betelgeuse)


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Adding support to metadata.xml to mark longdescriptions as outdated

[Petteri Räty]

I thought that when I am bored I might translate the longdescriptions in
metadata.xml files to Finnish. While thinking about it the following
problem came to mind: When the English descriptions are updated there is
no way currently to mark the other translations as outdated. I think it
would be create to have a modified attribute or make an other solution
that would make it easy to find outdated descriptions in the tree. The
modification of the date could easily be integrated to for example repoman.

Regards,
Petteri Räty (Betelgeuse)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[Herbert G. Fischer]

Oops... sorry for the last e-mail. I confess that I did not read your
code-piece before answering. It's exactly what I had in mind (as you
saw).2005/10/19, Herbert G. Fischer <[EMAIL PROTECTED]>:
Perhaps the modules-update could be extended to detect new kernels and
warn users or automatically update modules. This could also be
documented in Gentoo docs since this is a basic and common problem that
almost every Gentoo user may have.

Thanks for the patch!2005/10/19, John Myers <[EMAIL PROTECTED]
>:
On Wednesday 19 October 2005 06:36, Henrik Brix Andersen wrote:> On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:[snip]> > - Patch kernel's "make" to warn at the end of "make modules_install"
[snip]> I think you should check out sys-kernel/module-rebuildActually, a combination of these might not be a bad idea.Something like this (not tested):if [ -n "$(which module-rebuild 2>/dev/null)" ] ; then
if [ -n "${AUTO_MODULE_REBUILD}" ] ; thenecho "Rebuilding external modules:"module-rebuild ${MODULE_REBUILD_OPTIONS} rebuildelseecho "You might want to rebuild the following external modules:"
module-rebuild -XC list | tail -n +2echoecho "You can use module-rebuild to do that."echo "If you want to have your external modules automatically rebuilt"
echo "when making a kernel's modules_install target, set"echo "AUTO_MODULE_REBUILD in your environment. You can set"echo "MODULE_REBUILD_OPTIONS to options to pass to module-rebuild."
echo "(-X for example)"fielseecho "You might want to emerge sys-kernel/module-rebuild to keep track of"echo "kernel modules you've installed with emerge"
fi

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[Herbert G. Fischer]

Perhaps the modules-update could be extended to detect new kernels and
warn users or automatically update modules. This could also be
documented in Gentoo docs since this is a basic and common problem that
almost every Gentoo user may have.

Thanks for the patch!2005/10/19, John Myers <[EMAIL PROTECTED]>:
On Wednesday 19 October 2005 06:36, Henrik Brix Andersen wrote:> On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:[snip]> > - Patch kernel's "make" to warn at the end of "make modules_install"
[snip]> I think you should check out sys-kernel/module-rebuildActually, a combination of these might not be a bad idea.Something like this (not tested):if [ -n "$(which module-rebuild 2>/dev/null)" ] ; then
if [ -n "${AUTO_MODULE_REBUILD}" ] ; thenecho "Rebuilding external modules:"module-rebuild ${MODULE_REBUILD_OPTIONS} rebuildelseecho "You might want to rebuild the following external modules:"
module-rebuild -XC list | tail -n +2echoecho "You can use module-rebuild to do that."echo "If you want to have your external modules automatically rebuilt"
echo "when making a kernel's modules_install target, set"echo "AUTO_MODULE_REBUILD in your environment. You can set"echo "MODULE_REBUILD_OPTIONS to options to pass to module-rebuild."
echo "(-X for example)"fielseecho "You might want to emerge sys-kernel/module-rebuild to keep track of"echo "kernel modules you've installed with emerge"
fi

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[John Myers]

On Wednesday 19 October 2005 06:36, Henrik Brix Andersen wrote:
> On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:
[snip]
> > - Patch kernel's "make" to warn at the end of "make modules_install"
[snip]
> I think you should check out sys-kernel/module-rebuild
Actually, a combination of these might not be a bad idea.

Something like this (not tested):

if [ -n "$(which module-rebuild 2>/dev/null)" ] ; then
if [ -n "${AUTO_MODULE_REBUILD}" ] ; then
echo "Rebuilding external modules:"
module-rebuild ${MODULE_REBUILD_OPTIONS} rebuild
else
echo "You might want to rebuild the following external modules:"
module-rebuild -XC list | tail -n +2
echo
echo "You can use module-rebuild to do that."
echo "If you want to have your external modules automatically rebuilt"
echo "when making a kernel's modules_install target, set"
echo "AUTO_MODULE_REBUILD in your environment. You can set"
echo "MODULE_REBUILD_OPTIONS to options to pass to module-rebuild."
echo "(-X for example)"
fi
else
echo "You might want to emerge sys-kernel/module-rebuild to keep track of"
echo "kernel modules you've installed with emerge"
fi


pgph1baGir1Oz.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.

[Jeff Smelser]

On Wednesday 19 October 2005 07:46 am, Petre Rodan wrote:
> is that
> grant all privileges on 'DB'.* to 'user'@'localhost' identified by
> 'password'; deprecated in 4.1?
> because it inserts the line in mysql.users, but authentication is
> impossible :/

Do it here all the time..

> I had to use this syntax to get things going:
>
> GRANT USAGE ON *.* TO 'user'@'localhost' IDENTIFIED BY 'password' WITH
> MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
>
> GRANT ALL PRIVILEGES ON `DB`.* TO 'user'@'localhost';
>
> maybe it would be a Good Thing(TM) to add this to the upgrade document?

I have seen this when the mysql tables are out of scope with mysqld. Restart 
is usually the only thing that fixes this.. 

Unless you have MAX_CONNECTIONS_PER_HOUR defined to low somewhere.. show 
global viariables like 'MAX_CONNECTIONS_PER_HOUR' will show that.. (something 
to the affect)

And you do NOT need the flush priv command after grant statements, only when 
you go after the priv tables directly.

Jeff


pgppwawZJUKE5.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.

[John Myers]

On Wednesday 19 October 2005 07:18, Petre Rodan wrote:
> can anyone please check out if you can create a new user with the
> 'deprecated' version and that you can actually use it in mysql-4.1.14? I
> invariably got 'bad password for user ...'.
What client version are you using? This sounds like it could be related to the 
new password crypto change, IIRC.


pgphXBLzCctwG.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.

[Petre Rodan]

Hi,

On Wed, Oct 19, 2005 at 09:30:19AM -0400, Jeffrey Forman wrote:
> Petre Rodan wrote:
> > is that
> > grant all privileges on 'DB'.* to 'user'@'localhost' identified by 
> > 'password';
> > deprecated in 4.1?
> > because it inserts the line in mysql.users, but authentication is 
> > impossible :/
> > 
> > I had to use this syntax to get things going:
> > 
> > GRANT USAGE ON *.* TO 'user'@'localhost' IDENTIFIED BY 'password' WITH 
> > MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
> > 
> > GRANT ALL PRIVILEGES ON `DB`.* TO 'user'@'localhost';
> > 
> > maybe it would be a Good Thing(TM) to add this to the upgrade document?
> > 
> 
> Peter,
> 
> After adding a person with the grant option, one must usually 'flush
> privileges' to update all the tables and allow the person access.

I did flush a million times. I lost almost 4 hours with this mysql upgrade due 
to authentication problems.
It worked only when I used the second syntax.

can anyone please check out if you can create a new user with the 'deprecated' 
version and that you can actually use it in mysql-4.1.14? I invariably got 'bad 
password for user ...'.

a bug report will follow tomorrow.

thx,
peter

-- 
petre rodan
<[EMAIL PROTECTED]>
Developer,
Hardened Gentoo Linux 


pgpNaVwuQMEkW.pgp
Description: PGP signature

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[Herbert G. Fischer]

That's cool.2005/10/19, Henrik Brix Andersen <[EMAIL PROTECTED]>:
On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:> There could be some way to remember users what installed packages need to be> reemerged after a new kernel is installed.>> I thought in this ideas:
>> - Patch kernel's "make" to warn at the end of "make modules_install"> - Warn user after any boot (during init.d stage). This script should detect> the new kernel and warn users if some of the installed ebuilds need to be
> reemerged.>> What do you think?I think you should check out sys-kernel/module-rebuildRegards,Brix--Henrik Brix Andersen <[EMAIL PROTECTED]
>Gentoo Metadistribution | Mobile computing herd

Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[Henrik Brix Andersen]

On Wed, Oct 19, 2005 at 11:32:19AM -0200, Herbert G. Fischer wrote:
> There could be some way to remember users what installed packages need to be
> reemerged after a new kernel is installed.
> 
> I thought in this ideas:
> 
> - Patch kernel's "make" to warn at the end of "make modules_install"
> - Warn user after any boot (during init.d stage). This script should detect
> the new kernel and warn users if some of the installed ebuilds need to be
> reemerged.
> 
> What do you think?

I think you should check out sys-kernel/module-rebuild

Regards,
Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgpagRUAPS8kW.pgp
Description: PGP signature

[gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

[Herbert G. Fischer]

There could be some way to remember users what installed packages need to be reemerged after a new kernel is installed.

I thought in this ideas:

- Patch kernel's "make" to warn at the end of "make modules_install"
- Warn user after any boot (during init.d stage). This script should
detect the new kernel and warn users if some of the installed ebuilds
need to be reemerged.

What do you think?

Herbert

Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.

[Jeffrey Forman]

Petre Rodan wrote:
> is that
> grant all privileges on 'DB'.* to 'user'@'localhost' identified by 'password';
> deprecated in 4.1?
> because it inserts the line in mysql.users, but authentication is impossible 
> :/
> 
> I had to use this syntax to get things going:
> 
> GRANT USAGE ON *.* TO 'user'@'localhost' IDENTIFIED BY 'password' WITH 
> MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
> 
> GRANT ALL PRIVILEGES ON `DB`.* TO 'user'@'localhost';
> 
> maybe it would be a Good Thing(TM) to add this to the upgrade document?
> 

Peter,

After adding a person with the grant option, one must usually 'flush
privileges' to update all the tables and allow the person access.


-Jeffrey

-- 

---
Jeffrey Forman
Gentoo Infrastructure
Gentoo Release Engineering
bugs.gentoo.org Administrator
[EMAIL PROTECTED]
---
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bugzilla Bug #109301 dev-db/mysql-4.1.14 stable request.

[Petre Rodan]

Hi,

On Mon, Oct 17, 2005 at 04:06:29PM +0200, Francesco R. wrote:
> mysql-4.1.14 has been added to the tree on 29 Aug 2005, should be time 
> to stabilize the 4.1 branch of mysql.

quick question regarding this new version.

is that
grant all privileges on 'DB'.* to 'user'@'localhost' identified by 'password';
deprecated in 4.1?
because it inserts the line in mysql.users, but authentication is impossible :/

I had to use this syntax to get things going:

GRANT USAGE ON *.* TO 'user'@'localhost' IDENTIFIED BY 'password' WITH 
MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;

GRANT ALL PRIVILEGES ON `DB`.* TO 'user'@'localhost';

maybe it would be a Good Thing(TM) to add this to the upgrade document?


bye,
peter

-- 
petre rodan
<[EMAIL PROTECTED]>
Developer,
Hardened Gentoo Linux 


pgpd8cfoCMICg.pgp
Description: PGP signature