[gentoo-dev] RE: [gentoo-dev-announce] New developer: Michael Hammer (mueli)

2008-05-06 Thread Duft Markus
 Joinin us from Graz, Austria is Michael mueli Hammer. He will be
 joining us to maintain kerberos related packages. Michael is
 responsible
 for the infrastructure at the Graz University of Technology and they
 run
 Gentoo of course. So no longer do you have to think about moving to
 other distros as this corner hopefully stays maintained. If he does a
 poor job on it it's time for the hammer and sickle. On his free time
 Michael restores and old Mini from 1975.

Hehe, Graz on the advance ;) Welcome.

Cheers, Markus

 
 Regards,
 Petteri



[gentoo-dev] Re: New developer: Michael Hammer (mueli)

2008-05-06 Thread Markus Ullmann

Petteri Räty schrieb:
Joinin us from Graz, Austria is Michael mueli Hammer. He will be 
joining us to maintain kerberos related packages. Michael is responsible 
for the infrastructure at the Graz University of Technology and they run 
Gentoo of course. So no longer do you have to think about moving to 
other distros as this corner hopefully stays maintained. If he does a 
poor job on it it's time for the hammer and sickle. On his free time 
Michael restores and old Mini from 1975.


So now you finally made it :)

Let's see how our new kerberos conspiracy works out... Oh wait, that 
used to be sekrit, right? ;)


Welcome !

-Jokey

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: [gentoo-dev-announce] New developer: Jeremy Olexa (darkside)

2008-05-06 Thread Fabian Groffen
On 05-05-2008 23:32:53 +0300, Petteri Räty wrote:
 Another one bites the dust. It's my usual pleasure to introduce to your 
 Jeremy darkside Olexa from Minneapolis, USA. On IRC he goes with the nick 
 name darsiide because darkside is taken. Let's see if the current owner 
 gives it up after the thousand ping marker. Jeremy will be working on 
 bringing Gentoo/Alt:Prefix to machines that many have never heard of and 
 some want to forget like ia64-hpux. His main hobbies are flying small 
 airplanes and skydiving. I guess he must have crashed his head at some 
 point.

LOL.

Welcome to the team!


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for May

2008-05-06 Thread Ciaran McCreesh
On 01 May 2008 05:30:01
Mike Frysinger [EMAIL PROTECTED] wrote:
 If you have something you'd wish for us to chat about, maybe even
 vote on, let us know !  Simply reply to this e-mail for the whole
 Gentoo dev list to see.

I'd like a decision on the eight digits thing in PMS:

 No integer part of a version specification may contain more than eight
 digits.

It's been discussed on this list previously:

http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml

and on bugzilla:

https://bugs.gentoo.org/show_bug.cgi?id=188449

and I get the impression that there aren't any particularly strong
feelings either way. So can we get a Council ruling to either kill the
limit and strongly encourage people to fix their code, or keep the
limit and start enforcing it and fixing it in the tree via repoman etc?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] New developer: Michael Hammer (mueli)

2008-05-06 Thread Michael Hammer
* Duft Markus [EMAIL PROTECTED] [080506 08:13]:
  [...] Michael is responsible
  for the infrastructure at the Graz University of Technology [...]

I've to correct this because I don't want to adorn myself with
borrowed plumes ;) I am responsible for the infrastructure of the
Insitute for Strength of Materials but not for the whole University.

  [...] and they run Gentoo of course. [...]

.. and that's really true and I am also a bit proude of it. On oure
whole Insitute we are using (except two True64 machines) Linux and
only 2 PCs are running debian - all others are running Gentoo!!

 Hehe, Graz on the advance ;) Welcome.

Thanks for the warm welcome! We'll learn windows how POSIX is written ;)

greets, mueli

-- 
--
   __
Michael Hammer/  |
GPG-Key-ID: 0x1BA5F0DE\__|
GPG-Fingerprint: ||
  8704 11D1 048A 2F24 89D0  6B9E 3EC4 6EDF 1BA5 F0DE ||
phone: +43 (0) 650 86 33 55 8||
Graz - AUSTRIA   ||
http://www.michael-hammer.at/   [EMAIL PROTECTED]~~
--

pgpHd8QVtko0S.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: qemu - add gcc-3.x dependency

2008-05-06 Thread Luca Barbato

Enrico Weigelt wrote:

Hi folks,


I'm just installing qemu, which requires gcc-3.x for building. 
The current breaks are very ugly, IMHO. 


So I'm proposing to add the old gcc-3.x as depedency to qemu,
at least as long as it doesn't build w/ newer gcc. 


What do you think about this ?



that qemu is a sore exception, you should help upstream porting to gcc-4 
if you have time, every people concerned should.


Nowadays most of the work left to be done is _pretty_ boring and 
_pretty_ simple so everybody could help patching ^^


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] preserving mtimes

2008-05-06 Thread Marijn Schouten (hkBst)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi list,

files installed by portage to ${ROOT} do not have the same time stamps as the 
same files
in ${D}. This creates problems for Common Lisp implementations and one Scheme
implementation in our overlay, explained in [1]. Current work-around is tarring 
up and
untarring to preserve mtimes. Fixes mentioned in [2] could reduce that hack to 
a touch of
some generated files to make them older than their sources, at least in our 
case.

Unfortunately not all package managers implement the same behaviour and I don't 
think PMS
says anything about it.

With reference counting implemented there doesn't seem to be any reason not to 
preserve
mtimes by default anymore and I think that would be the correct thing to do, 
but either
way I'd like PMS to specify what should happen wrt to mtimes, so that I can 
rely on that.

Marijn

[1]:http://bugs.gentoo.org/show_bug.cgi?id=16162#c32
[2]:http://bugs.gentoo.org/show_bug.cgi?id=16162#c52

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgg30wACgkQp/VmCx0OL2xnQwCfayTo5PATYpCPRgcROP+9p0ES
jroAn3H2XJ103UC3V7XglDGSWZLHPDRH
=4pVG
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] preserving mtimes

2008-05-06 Thread Ciaran McCreesh
On Wed, 07 May 2008 00:44:28 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
 and I think that would be the correct thing to do, but either way I'd
 like PMS to specify what should happen wrt to mtimes, so that I can
 rely on that.

PMS makes no guarantee as to what happens with mtimes, which means you
can't rely upon things happening one way or the other. This is
deliberate -- preserving mtimes leads to all kinds of weirdness on
packages that are generated from a raw tar file rather than from a
build system.

 Current work-around is tarring up and untarring to preserve mtimes.

That's not really any good either. The proper solution would be to fix
whatever it is that's mtime-sensitive.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] preserving mtimes

2008-05-06 Thread Brian Harring
On Wed, May 07, 2008 at 01:52:19AM +0100, Ciaran McCreesh wrote:
 On Wed, 07 May 2008 00:44:28 +0200
 Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
  and I think that would be the correct thing to do, but either way I'd
  like PMS to specify what should happen wrt to mtimes, so that I can
  rely on that.
 
 PMS makes no guarantee as to what happens with mtimes, which means you
 can't rely upon things happening one way or the other. This is
 deliberate -- preserving mtimes leads to all kinds of weirdness on
 packages that are generated from a raw tar file rather than from a
 build system.

I'd be curious what weirdness you're referring to, since pkgcore has 
preserved mtime from the get go.

Yet to see a single issue from it, although *I* could think of a few 
instances where it would be problematic- that said, those pkgs already 
do postinst resetting of mtime to work around portage/paludis 
resetting mtime, so those issues doesn't appear.


  Current work-around is tarring up and untarring to preserve mtimes.
 
 That's not really any good either. The proper solution would be to fix
 whatever it is that's mtime-sensitive.

That's not exactly much of a solution; simplest example, that results 
in python.eclass:python_mod_compile, invoked during postinst to reset 
the cached bytecode mtimes (essentially).  Aside from this being 
uncontrolled/untracked access to the live fs, this slows down merges 
due to redundant work.

Finally, it also trashes the chksums that the manager records upon 
merging to the fs- so an mtime/chksum based unmerger can/will orphan 
those files.

Frankly, the mtime issue keeps rearing its head and needs killing- 
it's been an issue for near 4 years even, back in the OSX days we had 
to rewrite .a TOC's since the linker was mtime aware.

See no reason to preserve this misfeature.  Can't comment on paludis, 
but it shouldn't be an issue for portage to make the leap from what 
I've seen source wise.

~harring


pgpmpRrDwQqsf.pgp
Description: PGP signature


Re: [gentoo-dev] preserving mtimes

2008-05-06 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marijn Schouten (hkBst) wrote:
 Hi list,
 
 files installed by portage to ${ROOT} do not have the same time stamps
 as the same files
 in ${D}.

Any timestamp difference here is not due to portage itself (since
portage-2.1.3). The timestamp change is usually due to the default
values of these variables which are defined in ebuild.sh:

export INSOPTIONS=-m0644
export EXEOPTIONS=-m0755
export LIBOPTIONS=-m0644
export DIROPTIONS=-m0755

It's currently possible for ebuilds to call the insopts, diropts,
exeopts, and libopts functions to modify these variables. If they
add the -p option, then timestamps will be preserved. I suppose we
can add -p to the default options if that's what everybody wants.

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkghFakACgkQ/ejvha5XGaOLSQCeNOXhp5BY7pIeB/dfQ0lQGkEM
7doAoL9y/VH24DAQ9xDnmV4BlwB2Q5rt
=fW6M
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list