Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox: ChangeLog rox-2.7-r2.ebuild
On Thursday 20 December 2007, Donnie Berkholz wrote: > On 15:05 Mon 17 Dec , Jim Ramsay (lack) wrote: > > Added:rox-2.7-r2.ebuild > > > > IUSE="+svg +video" > > svg already defaults on for all the desktop profiles, so I'm not really > sure what that's gaining you. today for a subset of profiles. tomorrow ? other profiles ? i dont think duplication here is a big deal and the point of IUSE defaults is so these defaults can be in the package and not worry about the profile -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Running a script to remove useless deps like virtual/libc from ebuilds
I have a script coming up that can remove virtual/libc dependencies from
ebuilds automatically but can this be done safely for all ebuilds are
are there ebuilds in system that really need this dep for stage building
etc? Are there other deps to like this that could be removed? At least
sys-libs/zlib could be one. Attached is a version that prints a unified
diff for the changes my script would make.
Regards,
Petteri
#!/usr/bin/python
from __future__ import with_statement
import portage
from fnmatch import filter
import os
import re
import sys
from contextlib import nested
from difflib import unified_diff
dep_start = re.compile('^R?DEPEND.*')
ws_re = re.compile('^\s*$')
dep_end = re.compile('.*"$')
for root, dirs, files in os.walk(portage.settings['PORTDIR']):
for ebuild in filter(files, '*.ebuild'):
path = os.path.join(root, ebuild)
print path
with nested(open(path), os.tmpfile()) as (f,tmp):
in_dep = False
lines = f.readlines()
new = []
for line in lines:
if dep_start.match(line):
in_dep = True
if in_dep:
if dep_end.match(line):
in_dep = False
if line.find('virtual/libc') is not -1:
line =
line.replace('virtual/libc','')
if not ws_re.match(line):
tmp.write(line)
new.append(line)
else:
tmp.write(line)
new.append(line)
else:
tmp.write(line)
new.append(line)
sys.stdout.writelines(unified_diff(lines, new))
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Random items I'd like to discuss
On Sun, 30 Dec 2007 08:38:10 +0100 Luca Barbato <[EMAIL PROTECTED]> wrote: > > Multiply number of dep types (build, run, install, compile against, > > post, probably more) by number of requirement levels (required, > > suggested, recommended) by number of ABI combinations by number of > > system combinations by whatever else ends up being useful. > > I'm against suggested and recommended. I don't like it in debian and I > won't like it in gentoo. the rest shouldn't interest an ebuild by > itself but should be handled by the package manager. The package manager can't. It needs to be told -- there's no way to guess up front (or, indeed, after the fact) what dependencies really are. > bad users of tools are always present, by itself autotools gives > support and usually works out of box. No, autotools doesn't give support. It doesn't, for example, have any way of generating source files using a program that's part of the package that requires a library that's part of the package. The sad fact is, no matter how you use autotools in non-trivial cases you'll end up breaking *something*, and cross compiling is the least visible thing to break. > > Tree branching will very quickly become unmanageable. Users will be > > forced to choose a branch, but useful features will be spread across > > different branches. > > Only if you don't manage it correctly. > > I know what I'm doing on linux and it is _quite_ branched. That's because things get merged in quickly... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] media-libs/svgalib maintainers wanted
Hi, Are there any developers who use svgalib and would be interested in helping out maintenance-wise? It's currently maintained by Mike (spanky) but he doesn't use it or have any interest in it - he just looks after it because nobody else does. I believe he's about to commit the fix for the current critical open bug (#195632) but if anyone else is interested in helping out it would probably help response-time in the future (it does have some real users who have been bitten by this bug for a number of weeks). It's not a fun package to maintain - not very useful IMO, it's a kernel module that lives outside the kernel so it will regularly break overnight, upstream are rather dead, etc, but if someone wouldn't mind putting some time towards it now and then, some of our users would appreciate it :) Thanks, Daniel -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Maintainer needed for motif related ebuilds
There are currently a few issues open with the motif related ebuilds that need resolving. https://bugs.gentoo.org/buglist.cgi?quicksearch=motif The ones I see as big issues right now (since they are in QA's bug list): https://bugs.gentoo.org/show_bug.cgi?id=147067 https://bugs.gentoo.org/show_bug.cgi?id=117057 If you are an interested developer, please start looking at these bugs and figuring out how to best resolve these issues. If you are an interested user and want to help out, please contact me off list and you can help me start fixing these issues. Thanks, -- Mark Loeser email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpQfau3WEVPW.pgp Description: PGP signature
[gentoo-dev] has_version etc parallelisability
Is it legal for ebuilds to call has_version and friends in parallel? Is it legal for ebuilds to call has_version and friends after the ebuild process has terminated? Discuss. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-12-30 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-12-30 23h59 UTC. Removals: dev-libs/libcpml2007-12-27 11:56:48 armin76 dev-libs/libcxml2007-12-27 11:56:50 armin76 dev-lang/ccc2007-12-27 11:57:36 armin76 dev-lang/cfal 2007-12-27 11:57:38 armin76 dev-lang/cxx2007-12-27 11:57:39 armin76 Additions: dev-php/PEAR-HTTP_Session2 2007-12-24 12:41:42 armin76 dev-php/PEAR-Text_Highlighter 2007-12-24 14:44:13 armin76 x11-libs/qt-assistant 2007-12-24 14:52:28 caleb dev-embedded/u-boot-tools 2007-12-24 21:17:06 vapier dev-util/gitosis2007-12-25 10:50:21 robbat2 media-video/captury 2007-12-25 18:14:36 trapni virtual/ada 2007-12-26 22:07:35 george dev-ruby/ruby-dict 2007-12-27 13:38:02 flameeyes app-shells/bashdb 2007-12-27 20:00:37 vapier games-mud/wxmud 2007-12-28 02:32:00 leio sci-libs/ipp2007-12-28 11:24:56 bicatali net-libs/libtirpc 2007-12-29 08:58:18 vapier net-nds/rpcbind 2007-12-29 09:13:54 vapier net-libs/libasyncns 2007-12-29 17:37:35 flameeyes sci-biology/finchtv 2007-12-30 00:47:40 je_fro sci-chemistry/massxpert 2007-12-30 00:53:45 je_fro sys-auth/nsvs 2007-12-30 02:51:09 chtekk dev-dotnet/dbus-sharp 2007-12-30 03:14:17 compnerd dev-dotnet/dbus-glib-sharp 2007-12-30 03:18:27 compnerd dev-python/sqlitecachec 2007-12-30 10:01:07 vapier www-apache/mod_auth_imap2 2007-12-30 17:13:58 hollow www-apache/mod_auth_tkt 2007-12-30 17:28:16 hollow x11-themes/nuvox2007-12-30 23:15:28 flameeyes -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-libs/libcpml,removed,armin76,2007-12-27 11:56:48 dev-libs/libcxml,removed,armin76,2007-12-27 11:56:50 dev-lang/ccc,removed,armin76,2007-12-27 11:57:36 dev-lang/cfal,removed,armin76,2007-12-27 11:57:38 dev-lang/cxx,removed,armin76,2007-12-27 11:57:39 Added Packages: dev-php/PEAR-HTTP_Session2,added,armin76,2007-12-24 12:41:42 dev-php/PEAR-Text_Highlighter,added,armin76,2007-12-24 14:44:13 x11-libs/qt-assistant,added,caleb,2007-12-24 14:52:28 dev-embedded/u-boot-tools,added,vapier,2007-12-24 21:17:06 dev-util/gitosis,added,robbat2,2007-12-25 10:50:21 media-video/captury,added,trapni,2007-12-25 18:14:36 virtual/ada,added,george,2007-12-26 22:07:35 dev-ruby/ruby-dict,added,flameeyes,2007-12-27 13:38:02 app-shells/bashdb,added,vapier,2007-12-27 20:00:37 games-mud/wxmud,added,leio,2007-12-28 02:32:00 sci-libs/ipp,added,bicatali,2007-12-28 11:24:56 net-libs/libtirpc,added,vapier,2007-12-29 08:58:18 net-nds/rpcbind,added,vapier,2007-12-29 09:13:54 net-libs/libasyncns,added,flameeyes,2007-12-29 17:37:35 sci-biology/finchtv,added,je_fro,2007-12-30 00:47:40 sci-chemistry/massxpert,added,je_fro,2007-12-30 00:53:45 sys-auth/nsvs,added,chtekk,2007-12-30 02:51:09 dev-dotnet/dbus-sharp,added,compnerd,2007-12-30 03:14:17 dev-dotnet/dbus-glib-sharp,added,compnerd,2007-12-30 03:18:27 dev-python/sqlitecachec,added,vapier,2007-12-30 10:01:07 www-apache/mod_auth_imap2,added,hollow,2007-12-30 17:13:58 www-apache/mod_auth_tkt,added,hollow,2007-12-30 17:28:16 x11-themes/nuvox,added,flameeyes,2007-12-30 23:15:28 Done.
[gentoo-dev] USE flag documentation
This is a very very rough draft/question about how we should move forward with USE flag documentation and specification. The entire idea of a single USE flag having different meanings will need to be revisted later. I just want to get an idea of how we can document these different meanings. Please read my ideas here: http://dev.gentoo.org/~halcy0n/gleps/glep-0054.html Let me know if you like any of those ideas, or if they all suck (and if they do, you better tell me why). I'm not sure which is the best way forward, which is why I want everyone to contribute towards the best solution moving forward. I really don't want to be stuck with something that is going to end up being a pain a year down the road. Thanks, -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgp5KMFB9dR0l.pgp Description: PGP signature
Re: [gentoo-dev] USE flag documentation
On 12/30/07, Mark Loeser <[EMAIL PROTECTED]> wrote: > This is a very very rough draft/question about how we should move > forward with USE flag documentation and specification. The entire idea > of a single USE flag having different meanings will need to be revisted > later. I just want to get an idea of how we can document these > different meanings. Please read my ideas here: > > http://dev.gentoo.org/~halcy0n/gleps/glep-0054.html > > Let me know if you like any of those ideas, or if they all suck (and if > they do, you better tell me why). I'm not sure which is the best way > forward, which is why I want everyone to contribute towards the best > solution moving forward. I really don't want to be stuck with something > that is going to end up being a pain a year down the road. > > Thanks, > One of the GLEP's primary goals is to provide a global use flag definition and over-ride it with a local definition. How does putting all flags in use.desc and over-riding local flags in use.local.desc not accomplish this? How does the glep intend to handle USE_EXPAND? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] has_version etc parallelisability
Ciaran McCreesh kirjoitti: > Is it legal for ebuilds to call has_version and friends in parallel? Is > it legal for ebuilds to call has_version and friends after the ebuild > process has terminated? Discuss. > Do you/anybody know if they are used in parallel in the tree at the moment? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] has_version etc parallelisability
On 12/30/07, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Is it legal for ebuilds to call has_version and friends in parallel? Is > it legal for ebuilds to call has_version and friends after the ebuild > process has terminated? Discuss. If the pm implements read/write locking on the underlying datastore (which it should probably have regardless of this request) then I don't see a problem in parallel has_version calls. I don't get your second example..do you mean the ebuild is running has_version in the background and then terminating? > > -- > Ciaran McCreesh > > -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Random items I'd like to discuss
Luca Barbato wrote: > Some items I have in wishlist > > - LRDEPEND link runtime dep (I need to link against that in order to run) I heartily concur with a link dependency, since it's such a fundamental relationship between packages: if A links to B we need to recompile A when the ABI for B changes. How useful is the distinction between runtime vs buildtime in that respect? (I can't see the point of linking to something if it's never used at runtime.) > - BDEPEND build dep (I need those tools in order to build) > Agreed. I'd hope LDEPEND and BDEPEND could cover all current DEPEND uses. Either you depend on something to be installed as you link to its headers and use it at runtime, or you need the tool to build, eg make. (RDEPENDs with no linkage, and hence no requirement to be installed at build-time, and PDEPENDs to break circular chains are the ones I know about.) But I don't know how that interacts with || DEPENDs. wrt SUGGEST et al, I don't see why those can't be kept separately in metadata.xml, if labelling isn't implemented, since they're only of use for package selection, not depgraph resolution (as I understand it). > - arch/ctarget support in deps (same way you have use deps) > Interesting idea. > - explicit ctarget support in the package manager emerge --cross=target > something. > Definitely, at least as much as we can do with the standard variables and GNU make. So not everything will cross-compile, that's to be expected. It would be cool to tie that into the tinderbox stuff that solar and bonsaikitten have done, so that testing could be automated. > - tools to explicitly manipulate sets > I must be missing something with these: they just seem like lists of packages (which you might want updated together, or compiled with the same set of flags etc.) That kind of stuff is more to do with scripting afaict, than the core package manager. (eg using predefined files for any and all configuration before compiling, and then resetting once the set is built. Recovery issues aren't so bad if the user knows the machine has crashed and runs the program to reset stuff before anything else is emerged.) > long time ideas: > > - support cross, multiarch, multilib in a saner and seamless way > Yeah, even if it means building everything in a chroot, for development libs at least. http://tldp.org/HOWTO/Multi-Distro-Dev/use.html (old) reminds me of this; I found it the other day and it looked a lot like stuff we do in Gentoo chroots. -- [EMAIL PROTECTED] mailing list
