[gentoo-dev] RE: [gentoo-dev-announce] New developer: Michael Hammer (mueli)
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)
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)
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
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)
* 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
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
-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
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
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
-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