Re: [gentoo-dev] Re: Glibc, non-glibc and external libs
On Thursday 16 June 2005 07:58, Duncan wrote: So... what about kicking off the virtual process now, but put it in the profile temporarily as well, avoiding having to wait for the virtual process, with a comment on the profile entry reminding you to review it with an eye for removal if the virtual process is done, say for 2006.0. Well as Gentoo/FreeBSD isn't even released I can't say what I need to do for 2006.0... always if we're going to follow Gentoo's releases instead of FreeBSD's ones, I'd actually tend for the latter because their base system releases are quite tight between them. Anyway, I prefer avoid having to mess with profiles in this way, as our profile already needs a lot more loving than the base ones as atm we don't inherit from them (profiles in overlays can't inherit profiles's in main portdir), adding more cruft over this is going to be a great problem to maintain. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgplsGW0PMISb.pgp Description: PGP signature
Re: [gentoo-dev] app-admin/mbr.. what to do...
On Thursday 16 June 2005 10:53, Patrick Lauer wrote: Maybe someone with some scripting skillz could create a list of all orphaned packages? (no metadata.xml, no active maintainer, ...) I've learned with first-person experience that no metadata doesn't means that a package is orphaned... So maybe it's better said to developers: if you maintain something *please* add a metadata, or update it, so that who looks at bugs know who to ask to. Always a drag to see packages getting dropped, but if noone maintains them there's not much that can be done. Well maybe we can have a way to define latest portage version for removed package (a tag on cvs?) so that someone can prepare a weekly tarball of removed packages waiting for new maintainers or so on. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpgAgPnuPqm5.pgp Description: PGP signature
Re: [gentoo-dev] Glibc, non-glibc and external libs
On Thursday 16 June 2005 00:02, Diego 'Flameeyes' Petten wrote: There are other solutions a part the new virtuals? Ok just to summarize. a) getopt_long isn't important right now, FreeBSD 5 already takes care of it, if in the future it will be necessary for NetBSD, OpenBSD or DragonFly, it will be another issue. b) most of the packages requiring gettext at runtime already requires it at build time atm... the simple thing to do is moving this on runtime on the packages which needs when we'll stumble across it c) main problem is libiconv, but this is required just by a few packages (gettext, glib2, bogofilter) the other uses it with gettext; as they doesn't require a specific version, we can also add dev-libs/libiconv to glibc's PROVIDE and just depend on dev-libs/libiconv. What about this? -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpylTysnfeMT.pgp Description: PGP signature
Re: [gentoo-dev] Glibc, non-glibc and external libs
On Thursday 16 June 2005 16:13, Martin Schlemmer wrote: DEPEND=!userland_GNU? ( dev-libs/libiconv ) I'd like to do that but there was disagreement about this before. For me is enough. Just keeping on heaping virtuals for everything is not the only way. Or just pull them in the profile. As I said, I'm not considering adding libiconv to profile as an option, it's not directly required. -- Diego Flameeyes Petten Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpPyV0PsVbDC.pgp Description: PGP signature
Re: [gentoo-dev] Glibc, non-glibc and external libs
On Thursday 16 June 2005 18:07, Mike Frysinger wrote: no, bsd libc doesnt directly require libiconv, but if you're using a bsd/Gentoo system and you have USE=nls, what are the chances you *dont want* libiconv ? Quite a few as 'nls' useflag is already used by freebsd's libc for other means. Maybe an iconv useflag can be acceptable, too? this probably would be better but still... when we'll have use-flags deps we should add the right deps. -- Diego Flameeyes Petten Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpYjjWem3peZ.pgp Description: PGP signature
[gentoo-dev] Glibc, non-glibc and external libs
The problem with external libraries which are needed on non-glibc systems (not sure about uclibc) to have GNU-style functions is getting bigger. Not only we need to depend on gettext and libiconv, but there's now also another library, gnugetopt which provides getopt_long function non non-glibc systems. This is going to be a problem, because waiting for new virtuals for those will take a lot of time and Gentoo/FreeBSD is slowed down by this a lot. I'm asking for a quick solution because Gentoo/FreeBSD is proceeding well but this is hurting the possibility to have all the depends cleaned out. There are other solutions a part the new virtuals? -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpPhKL2ok1ca.pgp Description: PGP signature
Re: [gentoo-dev] Glibc, non-glibc and external libs
On Thursday 16 June 2005 01:13, Olivier Crete wrote: Why dont you just add them to the profile as system packages ? I though of that but I'm not sure about it. I wish to have a systme profile as cleaner as possible and libiconv, gettext and other packages aren't needed for a lot of different packages because they doesn't use them. When I fist needed to install libiconv in the Gentoo/FreeBSD I was tinkering with, was just because I needed it ot have glib2 working for irssi.. I was already using that box as ftp and mail server. So I much prefer having them just when needed and not because it's possible that someone uses them, else it will be exactly as they were in the libc (one of the key strengths of *BSD is the fact that the libc is minimal and this makes the things simpler to maintain). -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpgTO4LCFMUG.pgp Description: PGP signature
Re: [gentoo-dev] Glibc, non-glibc and external libs
On Thursday 16 June 2005 06:22, Mike Frysinger wrote: tracking packages which need getopt is a waste of time, just force it in your profile/bsd libc/whatever it's not getopt, it's getopt_long... which is used by few packages. well actually freebsd provide it in library in latest releases, aslo if it's developed on its own... maybe I can hack a bit the build process to have this external as we need. This doesn't remove the problem on libiconv/gettext anyway. -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpZvCrqbsD1S.pgp Description: PGP signature
Re: [gentoo-dev] New Developer: Jonathan Smith (smithj)
On Tuesday 14 June 2005 02:59, Mike Doty wrote: Introducing our newest victim^H^H^H^H^H^Hdev This time at least someone who is interested in Gentoo/FreeBSD (and helped out with a couple of desktop-misc bugs about OpenPAM helping us and AMD64.. well us and us.. I feel confused...). Welcome aboard Jonathan! -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpJBVBkkskwX.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Tuesday 14 June 2005 04:43, Jason Wever wrote: One feature that would be more useful (in my honest on Tuesdays opinion) for us arch folks is the ability to mask use flags on a per-package basis. +1 for this, from the Gentoo/FreeBSD team :P We also have similar problems because sometimes there are supports which just works for some packages because the same useflag enables other things we can't support. Just for example, xorg-x11's pam flag load to compilation failures on OpenPAM systems (yeah I should work around that but I don't know the server too much, also if lately I'm having troubles..) but the rest of the pam support is usually ok. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgplnh3imzaxj.pgp Description: PGP signature
Re: [gentoo-dev] intention for kde-themes eclass
On Tuesday 14 June 2005 11:22, Michael Cummings wrote: know in 3.4.0 that you can install new wallpapers live from kde-org with an already integrated single-click The KNewStuff is great but it installs in home directory.. I think it's simple to replicate this using portage instead of using the KNewStuff, for example to spread the same setup over different machines. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgp04waMhLXE4.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Tuesday 14 June 2005 19:46, Alec Warner wrote: It seems like this is an abuse of USE flags, somewhat. I guess programs could have support for elibc_X or elibc_Y or userland_GNU or userland_DARWIN/BSD but why a USE flag for these? Because sometimes we must disable some dependency depending on the libc or the userland or the kernel used. There isn't a use flag for kernel version, there is a function for that. Why is there not a function to determine userland/arch/libc? Actually there's a variable for them but as said above, variables aren't allowed to change the deps. And there are quite a few dependencies which are needed just on some systems. Another thing is use_enable and use_with functions, takes for example kdelibs ebuild which has a $(use_enable kernel_Linux dnotify) as dnotify support is only for Linux kernels. It's true that the forced flags shouldn't show up on emerge -pv output (at least for base ones, other which can be optional on some arch and forced on others can always show up, take for example nopie/nossp which are going to be forced on Gentoo/FreeBSD (I actually was working on a similar use.force file before so I already have this done locally). -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpbo7EgKYpeY.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
On Tuesday 07 June 2005 16:04, Aron Griffis wrote: Could you explain why that policy needs to be dropped for alpha to be preferred? It's not obvious to me how that policy requires append. You can't assume that maintainer arch would be x86, and with alphabetic order, you must ask to the maintainer which is his arch (and there's no way to learn all them by heart). Maybe we can add this to metadata? -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgprAimOChZEJ.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
On Tuesday 07 June 2005 17:15, Aron Griffis wrote: That would be better for tools to help determining which are candidates for stable marking. But for humans it's not really different from looking at the ChangeLog, is it? It should be possible using ChangeLog if we are sure that ChangeLog is updated, and that the stable change is not hidden by a lot of other entries. Also some changelogs are really really long... -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpnWSdOh15ID.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Kevin Quinn (kevquinn)
On Sunday 29 May 2005 13:53, Tom Martin wrote: I just set Kevin up with CVS access. He's going to be joining the Hardened Gentoo project, in order to help (mainly) with the hardened userland. Hi Kevin! If you want to try new, exciting adventures in hardening... you can always join the bsd herd and try to add hardened support on Gentoo/FreeBSD... :) He's originally from Britain, but he now lives in Italy. Good.. now... you'll be joining english or italian takeover conspiration? Because that's going to be a critical point... Ehi! Wait! I wasn't supposed to talk about it in public... jedi trickno one ever read the above lines.../jedi trick -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpJx6nZUuY58.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Stuart Longland (Redhatter)
On Friday 27 May 2005 16:40, Tom Martin wrote: Stuart's beginnings with Linux come from his experiences with FreeBSD. Ehi that can be useful ;) Want to help with portage on FreeBSD? :P -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgp7M40tupIQ2.pgp Description: PGP signature
Re: [gentoo-dev] Pinboard of outdated ports
On Tuesday 24 May 2005 16:47, Tom Martin wrote: Maybe it would be better to tell maintainers to just subscribe to projects on freshmeat? That doesn't work too well usually. Unfortunately I have at least two packages I maintain (one directly, one as video herd) which I'm subscribed to but sends the freshmeat emails just after one or two weeks. I usually subscribe to sf.net/berlios.de notify when present, if not, their own mailing lists, rss feed and if nothing is there, I just cycle through some of them every two days. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgp1RKsN2bTqG.pgp Description: PGP signature
Re: [gentoo-dev] root:root and fbsd
On Sunday 22 May 2005 11:09, Stuart Longland wrote:
Why not just use `chmod -R 0:0 ${D}`? That should have the desired effect?
Yes that will have so that should be good for all systems. For me that is
ok... nobody disagrees?
If it's ok... Mike commit the eclass so that sys-devel/gcc will works (quite)
out of the box :)
--
Diego Flameeyes Petten
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flameeyes/
pgpp7GSeUDtU6.pgp
Description: PGP signature
Re: [gentoo-dev] Removing svga from default USE flags
On Monday 23 May 2005 00:55, Daniel Drake wrote: Any objections to dropping it from the default USE flags? Will be good to see it dropped :P -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpyjhoHIJJda.pgp Description: PGP signature
Re: [gentoo-dev] virtual/eject ?
On Monday 23 May 2005 19:16, Ciaran McCreesh wrote: How many? If it's less than a half dozen packages, you don't get a virtual. There are 8 packages directly depending on eject and one suggesting to install it (net-misc/krusader). There's also the problem that using a || () dep will break while eject-bsd is in overlay. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpEzq8TUl2PX.pgp Description: PGP signature
[gentoo-dev] root:root and fbsd
Hi,
ok another problem for Gentoo/FreeBSD project :P
Currently there are a few places where, to fix permissions of files, the
ebuilds does a chown -R root:root ${D} or something similar.
Unfortunately such a command is invalid on G/FBSD because there's no root
group, instead wheel group has GID=0.
So I was wondering for a solution for this problem: we have a $USERLAND
variable which can be used to select the way the chown must be done, if chown
root:root or chown root:wheel; I think both BSD and Darwin userland prefers
root:wheel above root:root, so maybe adding a function in eutils which fixes
the permissions based on the current $USERLAND value is enough...
Comments?
--
Diego Flameeyes Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flameeyes/
pgpfSXFApmJs4.pgp
Description: PGP signature
Re: [gentoo-dev] root:root and fbsd
On Sunday 22 May 2005 11:06, Ciaran McCreesh wrote:
get_root_group() {
That should do, so in ebuilds chown -R root;$(get_root_group) blablah.
For me is ok for G/FBSD.
Now, if someone from G/OSX or G/Darwin can tell me how they manage that, we
can be happy for all /alt archs :P
--
Diego Flameeyes Petten
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flameeyes/
pgpy1Qn3RT7G0.pgp
Description: PGP signature
Re: [gentoo-dev] death to underquoted M4 definitions
On Wednesday 18 May 2005 09:34, Aaron Walker wrote: Comments? Hmm I'm not sure about adding a band-aid function... fixing the underquoted definitions is usually trivial and requires just a little little patch. Adding a function surely will remove the need for a patch for package, and this is good, but I'm not sure about the sed expression. You tried it with bsd sed anyway? :) So the problem is: the patch will remove the need for all the patches? In this case, I think I'd love it :) -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpxSH78pFFAu.pgp Description: PGP signature
Re: [gentoo-dev] death to underquoted M4 definitions
On Wednesday 18 May 2005 17:11, Donnie Berkholz wrote: It may be easier, but upstream would appreciate us sending a patch instead of just fixing stuff locally. Not sure about this, we have also some not-so-friendly upstreams sometimes :) Well anyway I hope all those can be fixed soon, so ... -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpjgm2KXOM91.pgp Description: PGP signature
Re: [gentoo-dev] List of packages which 'inherit gcc'
On Monday 16 May 2005 00:42, Danny van Dyk wrote: media-video/cinelerra I've specifically ignored this package as it needs to go away very soon. It's p.masked, also. -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpRtjuf0IT0d.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] dev-lang/icc and dev-lang/ifc candidates for removal
On Tuesday 10 May 2005 22:11, Chris Gianelloni wrote: You are correct. However, it might be necessary to patch something that won't compile with icc, but does compile with gcc. I think this is the primary reason for the icc USE flag. Isn't tc-* functions there also for this? And anyway, there can be patches which makes something work both with icc and gcc. When I worked a bit with icc, I found out that it was just stricter than gcc, but all the changes needed to be done for icc was right also for gcc (and usually stopped gcc from throw a warning on something). Probably with gcc4 many of the errors are now shared by both compilers as it turned up even more strict than before. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpZOIrlDHiyb.pgp Description: PGP signature
Re: [gentoo-dev] Committing straight to stable
On Sunday 24 April 2005 23:35, Ciaran McCreesh wrote: They're supposed to do that for the first month or so (depending upon how long it is before it becomes obvious that you're safe). I was talking about double-checking *every* commit of every developer. That will be an overkill, imho. -- Diego Flameeyes Petten Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ pgpNkZa2mnJF3.pgp Description: PGP signature
