Re: [gentoo-dev] Projects and subproject status
On 11-01-2008 21:52:08 -0500, Mike Frysinger wrote: On Tuesday 08 January 2008, Fabian Groffen wrote: - sort out the 64-bits targets with their multilib-hell forced upon us dont know exactly what you're referring to, but multilib is completely optional. http://article.gmane.org/gmane.linux.gentoo.alt/3329 In short: gcc inserts 64-bits library paths which causes the linker first to look inside the host dirs, then in my prefix lib dirs, which creates interesting problems, since the runtime linker gets our runpath directions to look in the prefix lib dirs first. Anyway, it makes linking/runtime fail in cases where the host provided libs are incompatible with the prefix provided ones. Added to that that when I implemented the ldwrapper on amd64 (fedora) linux I didn't fully understand the full multilib picture, some decisions I made there now just feel plain wrong, especially given that each distro seems to implement the multilib thing different (Gentoo: /lib = native bits size, Fedora: /lib = 32-bits, Debian ...). I didn't get it fully right in my post above though, because every distro/os has a kernel configured in such a way that for a 64-bits object, the search path points to the 64-bits host-specific lib paths. So it seems that only binutils doesn't want to know about 64-bits host-specific lib paths, and gcc takes actions to compensate that. Thanks. -- Fabian Groffen Gentoo on a different level -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Projects and subproject status
On Saturday 12 January 2008, Fabian Groffen wrote: On 11-01-2008 21:52:08 -0500, Mike Frysinger wrote: On Tuesday 08 January 2008, Fabian Groffen wrote: - sort out the 64-bits targets with their multilib-hell forced upon us dont know exactly what you're referring to, but multilib is completely optional. http://article.gmane.org/gmane.linux.gentoo.alt/3329 sorry, when i first read the multilib-hell, i assumed you meant the Gentoo pieces rather than the binutils/gcc pieces. i could post some corrections to the piece there, but in the end, they wouldnt get you to a final working solution. Added to that that when I implemented the ldwrapper on amd64 (fedora) linux I didn't fully understand the full multilib picture, some decisions I made there now just feel plain wrong, especially given that each distro seems to implement the multilib thing different (Gentoo: /lib = native bits size, Fedora: /lib = 32-bits, Debian ...). I didn't get it fully right in my post above though, because every distro/os has a kernel configured in such a way that for a 64-bits object, the search path points to the 64-bits host-specific lib paths. So it seems that only binutils doesn't want to know about 64-bits host-specific lib paths, and gcc takes actions to compensate that. i dont know why you keep saying kernel over and over when the kernel plays no role here whatsoever. if you want to keep things sane, i would say just follow the tool convention and any/all distro conventions be damned. longer term, i'm really not familiar with how the prefix stuff is architected, so i cant give much guidance unless i sat down and learned it. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: scm eclasses/ebuilds and revision logging
Bernd Steinhauser wrote:
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
Hope someone comes up with some good ideas. ;)
Would something like this work for you?
pkg_preinst() {
local pkgdate=$(date +%Y%m%d %H:%M:%S)
subversion_wc_info
if [[ -n ${PORT_SCMDIR} ]]; then
[[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
cp ${ROOT}/${PORT_SCMDIR}/${PN}.revision ${T}
echo ${pkgdate} - ${P} was merged at revision ${ESVN_WC_REVISION} \
${T}/${PN}.revision
insinto ${PORT_SCMDIR}
doins ${T}/${PN}.revision
fi
}
that's for subversion of course. set PORT_SCMDIR in make.conf.
--
fonts,by design, by neglect
gcc-porting, for a fact or just for effect
wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RE: Re: Item for 10 Jan 2008 Council meeting
(Didn't really have anything specific to reply to, so just picking this) On Sat, 2008-01-12 at 05:39 +, Steve Long wrote: Mr McCormick Ehh, Ferris and I resolved our issues after a couple emails and just a little time to chill out. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages looking for new maintainer
Hi, As I need to reduce my workload some packages are looking for new maintainer: * app-editors/scite - only one bug #203489 - GTK+ fr_FR.UTF-8 locale issue * media-video/griffith - easy to maintain, has only one bug but it looks like upstream thing (bug #202484), media-video: * net-im/jabberd and net-im/jabberd2 - after much work it's in good shape, there's only one bug: version bump for net-im/jabberd, Marko helps a lot with jabberd2 * www-apache/mod_cband - also easy to maintain griffith could be taken by video herd, mod_cband by apache herd, but scite and jabberd need maintainers. -- Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51 desktop-misc, java, apache, ppc, vim, kernel... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] extend profiles.desc to include experimental profiles
On Sat, 2008-01-12 at 00:40 -0500, Mike Frysinger wrote: On Friday 11 January 2008, Chris Gianelloni wrote: For one, a way to mark a profile as deprecated in profiles.desc so repoman doesn't scan it (currently, we remove tend to remove them from the list). is this really needed ? i'm trying to see why this would be useful, and not coming up with much ... profiles.desc exists for two reasons: - for qa tools to scan - so people have a list of valid profiles if a profile is deprecated and on the way out, neither of these two things apply to it, so what's the use of having it listed ? we can already mark profiles deprecated for users who already have it selected ... I guess I was thinking more for the package manager. As I said, I would love for it to enforce a valid profile as defined in profiles.desc, even if it is a deprecated one, until the user switches. This means the deprecated profile needs to be listed in profiles.desc, but we don't want to run QA on it, as you said. The second would be a change to repoman that's more invasive in that it changes current behavior a good bit, but having repoman only scan stable profiles, by default, with options to scan the other types. i think by moving our most annoying profiles out of the dev to the exp state would mean that any warnings left while in the dev state are something we want to be seeing and addressing. the problem right now is that we have two types of profiles listed in dev: ones that people should care about and shouldnt be breaking and ones that people shouldnt care about and are free to break. package maintainers obviously dont (and shouldnt) know which are which. Indeed. I can see that with the profiles reassigned there's no need for this. I've always wanted to have *every* valid profile listed in profiles.desc so we can do things like have portage not allow someone to use a profile that isn't listed in profiles.desc (of course, overlay users crazy enough could do their own profiles.desc and it would be stacked with the in-tree one). The main problem with doing this has been the effect on repoman, since it scans every listed profile every time. I know that most of the profile selection tools out there already only show profiles that are listed in profiles.desc, so it wouldn't really be a change for them, but I think it would be useful elsewhere, too. All in all, having profiles.desc actually showing the status of all of the profiles would be great. i could see it tied to FEATURES=strict. if you have this enabled, then you're only allowed to use declared profiles (which means if you use a non-standard one, you'd need to declare it). Sure. I see no reason to not allow someone to turn it off. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: www-servers/apache-2.0 friends
+# Benedikt Böhm [EMAIL PROTECTED] (12 Jan 2008) +# Masked for apache-2.0 removal, bug #203578 +dev-cpp/cppserv +=dev-libs/apr-0* +=dev-libs/apr-util-0* +=dev-util/subversion-1.3* +=www-servers/apache-2.0* signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: www-servers/apache-2.0 friends
2008-01-12 19:56:19 Benedikt Böhm napisał(a): +# Benedikt Böhm [EMAIL PROTECTED] (12 Jan 2008) +# Masked for apache-2.0 removal, bug #203578 +dev-cpp/cppserv +=dev-libs/apr-0* +=dev-libs/apr-util-0* +=dev-util/subversion-1.3* +=www-servers/apache-2.0* Also mask www-apache/mod_auth_external. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
Perhaps I'm just so much used to seeing automatic signatures separated by -- \r\n and consider non-separated text as typed by the author. (And yes, Chris, I need beer from pubs :) ) Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] scm eclasses/ebuilds and revision logging
Avuton Olrich schrieb:
On 1/11/08, Bernd Steinhauser [EMAIL PROTECTED] wrote:
Hi,
this is sth. that has been brought up in the KDE4 forums thread and on
irc. The thing is, that if you're using a live ebuild you might very
likely run into bugs, that have been introduced in a newer revision.
Now when you get in touch with upstream about that bug it might be very
useful if you can tell them, that you know, that a specific version in
the past worked. The idea was now to add the ability to the scm eclasses
to do this automatically.
So after installation then sth. like this
${CAT}/${P} merged at revision (or commit) ${REVISION}
to a file like /var/log/portage/scm.log.
Now I'm sure there are a few dirty ways to achieve this, but I wonder if
there is an easy and clean way to do this?
The problem is (I think so), that you can't just write sth. to / because
of the sandbox, so there needs to be a way to get around that, and it
should also happen after installation (post_inst).
Now if anyone wonders if this might even be useful for the distributed
scm's, I do think so. Because of course if you merge sth. from another
tree, or your ebuild repo_uri fetches from a local dir, then you might
have _other_ commit hashes than upstream, but at least you can then look
into your own repo and tell them, when that was and what happened since
then.
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
update-live-ebuilds[1] already stores scm x's 'cookie' (hash,
revision, whatever). CVS and TLA are the only two which don't have a
specific cookie that changes in the local directory, so sha1sum is
used on a file that is known to change with repository changes, thus
they are not a good target for this.
Cookie values and the emerging epoch are stored in a uniform manner,
in /var/db/ule/*, and since ULE is bash even a caveman could add
logging stuff to it cleanly.
I would suspect anyone who uses live ebuilds on a routine basis should
already know about ULE and be using it. Please excuse me if this
method considered 'dirty', or offtopic, it was not meant to be.
Patches and criticism welcome.
[1]http://forums.gentoo.org/viewtopic-t-518701.html
http://repo.or.cz/w/ule.git
Well, of course that would be possible, but I thought about making this
part of the ebuilds, because normally you need that kind of information
when you previously didn't think about it and imho it should be part of
the stand procedure for live ebuilds.
Bernd
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: scm eclasses/ebuilds and revision logging
Ryan Hill schrieb:
Bernd Steinhauser wrote:
I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)
Hope someone comes up with some good ideas. ;)
Would something like this work for you?
pkg_preinst() {
local pkgdate=$(date +%Y%m%d %H:%M:%S)
subversion_wc_info
if [[ -n ${PORT_SCMDIR} ]]; then
[[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
cp ${ROOT}/${PORT_SCMDIR}/${PN}.revision ${T}
echo ${pkgdate} - ${P} was merged at revision
${ESVN_WC_REVISION} \
${T}/${PN}.revision
insinto ${PORT_SCMDIR}
doins ${T}/${PN}.revision
fi
}
that's for subversion of course. set PORT_SCMDIR in make.conf.
This is sort of what I thought of (of course you brought it into
detail), but I didn't know if there is maybe a better way, or if there
is actually a way to do this after the installation and not in preinst.
But I guess if nobody comes up with something better this is the way to
do it.
Maybe sth. like elog, just you don't log a message to summary.log, but
you log the revision of the package.
(Meaning, that you can use elog in every phase of an ebuild.)
Bernd
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] scm eclasses/ebuilds and revision logging
On Friday 11 January 2008, Bernd Steinhauser wrote:
this is sth.
reading your e-mail drove me nuts as i cant figure out what sth means.
google says Sonic The Hedgehog. not sure how this applies to Gentoo (he's
really fast?).
that has been brought up in the KDE4 forums thread and on
irc. The thing is, that if you're using a live ebuild you might very
likely run into bugs, that have been introduced in a newer revision.
Now when you get in touch with upstream about that bug it might be very
useful if you can tell them, that you know, that a specific version in
the past worked. The idea was now to add the ability to the scm eclasses
to do this automatically.
when i'm upstream, i leverage `svn info` and such so that the active rev makes
it into the version information. but this would of course require changes to
upstream stuff.
So after installation then sth. like this
${CAT}/${P} merged at revision (or commit) ${REVISION}
to a file like /var/log/portage/scm.log.
Now I'm sure there are a few dirty ways to achieve this, but I wonder if
there is an easy and clean way to do this?
The problem is (I think so), that you can't just write sth. to / because
of the sandbox, so there needs to be a way to get around that, and it
should also happen after installation (post_inst).
considering you care about the *src* and not *pkg*, you'd probably want to
have it done in src_install. if you exported a variable, it'd be retrievable
later in the vdb, but that isnt easy for users.
installing into a common accepted directory (like /usr/share/scm/$P) is one
possibility, but that too kind of sucks. but it would be trivial for users
to glean ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] sth (Was: scm eclasses/ebuilds and revision logging)
On Sat, 12 Jan 2008 19:11:06 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: reading your e-mail drove me nuts as i cant figure out what sth means. google says Sonic The Hedgehog. not sure how this applies to Gentoo (he's really fast?). It's an abbreviation for Similar To Harring. You'll also see fex, which is Finds English eXtraneous. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New eclasses for KDE 4
On 00:22 Sat 12 Jan , Wulf C. Krueger wrote: Hello, fellow Gentoo devs! Attached you'll find the new eclasses for KDE 4. We'd like to commit them on Sunday, 14th, to be able to get KDE 4.0.0 into the official tree (package.masked, though). We would welcome any comments, especially if accompanied by patches ;) and, of course, your kind approval to commit it. :-) Could you use has() instead of hasq() ? Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] scm eclasses/ebuilds and revision logging
Mike Frysinger schrieb: On Friday 11 January 2008, Bernd Steinhauser wrote: this is sth. reading your e-mail drove me nuts as i cant figure out what sth means. google says Sonic The Hedgehog. not sure how this applies to Gentoo (he's really fast?). http://en.wiktionary.org/wiki/something Sorry, thought that was common. ;) Bernd -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: scm eclasses/ebuilds and revision logging
Bernd Steinhauser schrieb: http://en.wiktionary.org/wiki/something Sorry, thought that was common. ;) It seems so from german-schools' english teaching books. ;) Greetz -Jokey signature.asc Description: OpenPGP digital signature
