[gentoo-dev] Re: Last rites: eapi7-ver.eclass, eqawarn.eclass, versionator.eclass

>>>>> On Mon, 26 Aug 2024, Ulrich Mueller wrote: > Eclasses that support EAPI 6 only, which is no longer used in the > Gentoo repository. > Removal in 30 days, i.e. on 2024-09-25. Update from the local planning office (beware of the leopard!): Removal of these eclasses w

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild

> On Sat, 29 Mar 2008, Donnie Berkholz wrote: > On 19:37 Sat 29 Mar , Saleem Abdulrasool (compnerd) wrote: >> 1.1 app-editors/leafpad/leafpad-0.8.14.ebuild >> src_compile() { >> econf --enable-chooser --enable-print $(use_enable emacs) >> emake >> } > emake doe

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild

> On Sun, 30 Mar 2008, Mike Frysinger wrote: >> And IMHO the "emacs" USE flag should not be used here: >> >> $ ./configure -hs >> Configuration of Leafpad 0.8.12: >> >> Optional Features: >> [...] >> --enable-emacs implement Emacs key theme (experimental) >> >> $ equery uses =leafp

[gentoo-dev] Change "leim" USE flag from global to local

Hi, the "leim" global USE flag is only needed by a single ebuild, and isn't used in any profile. If there are no objections, I'll move it to use.local.desc. Ulrich -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Change "leim" USE flag from global to local

> the "leim" global USE flag is only needed by a single ebuild, > and isn't used in any profile. > If there are no objections, I'll move it to use.local.desc. Done. -- gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Last rites: x11-libs/motif-config

# Ulrich Mueller <[EMAIL PROTECTED]> (13 Apr 2008) # Broken as designed. Not needed by openmotif anymore; no longer # installable because of blockers against openmotif and lesstif. # Masked for removal in 30 days, bug 117057. x11-libs/motif-config -- gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] escaping variables in sed expressions

> On Tue, 15 Apr 2008, Marijn Schouten (hkBst) wrote: > There are several option to handle this. I could use a less common > delimiter or I could escape it: ${D//_/\_} instead of ${D}. I could > use a sed expression that doesn't suffer from this problem (thanks > to dleverton): > sed -ne '\_^

Re: [gentoo-dev] What are blocks used for?

> On Wed, 16 Apr 2008, Ciaran McCreesh wrote: > Blocks do not work: > * It's often not obvious what the user's supposed to do to resolve a > block. > * Once the user has worked out how to resolve the block correctly, > it's often hard to do so since resolving some blocks is best done by > fo

Re: [gentoo-dev] Prioritising contact information in metadata.xml

> On Thu, 24 Apr 2008, Luis Francisco Araujo wrote: > | One other thing is that it is sometimes difficult to figure out to > | whom a bug should be assigned, because metadata.xml for many packages > | simply isn't clear. If you list a few developers as well as a herd, > | does that mean you wa

[gentoo-dev] Move app-admin/{skey,otpcalc} to sys-auth category

If no objections are raised, I am going to move the packages mentioned in the subject from app-admin to sys-auth in about one week from now. Packages depending on skey: app-admin/sudo:skey net-misc/openssh:skey net-nds/tac_plus:skey sys-apps/shadow:skey sys-auth/pam_skey-1.1.5 Pack

Re: [gentoo-dev] RFC: lzma tarball usage

> On Wed, 07 May 2008, Natanael Copa wrote: > busybox has unlzma and seems to be a part of "system". > Should also be easy to create a really tiny unlzma from the busybox > source and ship with portage, or create a patch for tar or something. The decoder of lzma-utils is also written in C on

Re: [gentoo-dev] RFC: lzma tarball usage

> On Wed, 7 May 2008, Benedikt Morbach wrote: > tar-1.20 has lzma support, so maybe it could handle this too, once it > goes into stable This doesn't help, since it needs the lzma binary as a filter. Ulrich -- gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: RFC: lzma tarball usage

> On Thu, 08 May 2008, Diego 'Flameeyes' Pettenò wrote: >>> So it would also be possible to compile "lzmadec" without any need >>> for C++. Just call "make" in subdirs liblzmadec and lzmadec. >> >> What about USE=decode-only or something similar for lzma-utils, >> then? If desired, it could e

[gentoo-dev] Lenght of version components [was: Council meeting summary for 8 May 2008]

> On Thu, 8 May 2008, Donnie Berkholz wrote: > PMS: Are versions allowed to have more than 8 digits? > - > specifically to ask the package maintainers with extremely > long PVs whether they were needed and to test the

Re: [gentoo-dev] LaTeX documentation

> On Mon, 12 May 2008, Andrey Grozin wrote: > There are two methods commonly used to fight against this situation > in ebuilds: using addwrite or setting VARTEXFONTS="${T}/fonts". The > second method is, probably, better. Why? This would mean that all fonts must be regenerated each time the p

Re: [gentoo-dev] Re: Moving some packages around

> On Mon, 12 May 2008, Ryan Hill wrote: > [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: >> - bison and flex should get out of the system package set, what >> clearer than moving them out of sys-*? They are not so commonly >> used so there should no compelling reason to have them instal

[gentoo-dev] Re: Moving some packages around

> On Sun, 18 May 2008, Diego 'Flameeyes' Pettenò wrote: >> A Lexical Analyser and a Parser Generator are also required by >> IEEE Std 1003.1 (aka POSIX) as part of the C-Language Development >> Utilities. > IIRC POSIX mandates vi too, and we don't have that in system. No, it's optional ("Use

[gentoo-dev] Re: About herds and their non-existant use

> On Sat, 24 May 2008, Tiziano Müller wrote: > Changing your name because of technical difficulties? This is really > not the way to go. Systems have to be adjusted to meet our needs, > not the other way round (in case it is possible of course). +1 > But nevertheless, it would be nice to hav

[gentoo-dev] Re: RFC: --as-needed to default LDFLAGS

[Answering to some random message in this long thread.] > On Sat, 31 May 2008, Brian Harring wrote: > So... folks have pointed out a benefit to using --as-needed. > The benefit itself doesn't seem particularly in dispute, analyze > the fallout from it- if the best that is offered is "the spec

Re: [gentoo-dev] Nominations for council

> On Tue, 03 Jun 2008, George Prowse wrote: >> Someone can clarify but don't you need to be a Foundation member to >> nominate or support nominations? >> >> [...] > Anyone can nominate but only members get a vote. GLEP 39 says something else: | * Council members will be chosen by a general

Re: [gentoo-dev] merging two packages - upgrade path?

> On Thu, 5 Jun 2008, Matthias Schwarzott wrote: > This post is about how to create a nice upgrade path when merging two > packages. > The packages I care about are media-plugins/vdr-streamdev-{client,server}, > that we wanted to merge into one media-plugins/vdr-streamdev package. > So the

Re: [gentoo-dev] merging two packages - upgrade path?

> On Thu, 5 Jun 2008, Matthias Schwarzott wrote: >> With #1 the user will get a message about the blockers immediately. >> With #2 his emerge (maybe of many packages) will needlessly die >> when it reaches your package. > With #1 user will get no message, as neither the user nor the > package

Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009

> On Wed, 18 Jun 2008, Panagiotis Christopoulos wrote: > I want to nominate: > 1. Marijn Schouten (hkBst) > 2. Ulrich Müller (ulm) I accept. Ulrich pgp4Cl437iZ97.pgp Description: PGP signature

[gentoo-dev] new virtual/texi2dvi

Hi, sys-apps/texinfo installs scripts texi2dvi, texi2pdf etc. which are not functional because the necessary dependencies on TeX are missing. Therefore aballier and myself propose to introduce a new-style virtual which will pull in the necessary dependencies: - texi2dvi script -> sys-apps/texi

Re: [gentoo-dev] metadata.xml USE flag descriptions

> On Mon, 28 Jul 2008, Doug Goldstein wrote: > If people wish to take specific categories, please let this thread know. > Ford_Prefect is taking gnome-base I can take app-emacs and (the rest of) app-editors. Ulrich

[gentoo-dev] Re: [gentoo-dev-announce] metadata.xml USE flag descriptions

> On Mon, 28 Jul 2008, Doug Goldstein wrote: > After a category is converted, it will be auto-generated EXCLUSIVELY > from metadata.xml. A minor issue: use.local.desc is not sorted properly anymore. It should be sorted by category/package first, then by the USE flag. For example (they are al

Re: [gentoo-dev] LICENSE and revbumps

> Should LICENSE changes require a revision bump? No, since it would be a waste of users' resources. For example, if a dev has missed a change from GPL-2 to GPL-3 (which I guess is a common case), would you really have users reinstall the package in this case? What would be the benefit? Ulrich

Re: [gentoo-dev] Remove global USE flag tetex

> On Wed, 3 Sep 2008, Christian Faulhammer wrote: > there should be no more packages in the tree that have USE=tetex, so > this global USE flag can be removed. Any opinions? Go for it! Ulrich

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog use.desc

> opfer 08/09/03 07:24:18 > Modified: ChangeLog use.desc > Log: > remove tetex USE flag Looks like you've forgotten to remove it from use.defaults and from use.mask in profiles. Ulrich

[gentoo-dev] Re: Phase order changes (was: One-Day Gentoo Council Reminder for September)

> On Thu, 11 Sep 2008, Zac Medico wrote: > I think it's worthwhile to have consistent phase ordering across all > EAPIs. Consider an upgrade from EAPI 0 to EAPI 2. If the phase order > is consistent across all EAPIs, as implemented in > >=sys-apps/portage-2.1.5, then the order of phase executi

Re: [gentoo-dev] Re: Request for feedback on GNU Patch change

> On Wed, 17 Sep 2008, C. Bergström wrote: > Here's another idea and I don't know why I didn't think of it > sooner.. Instead of any system change to the patch ebuild.. Inside > the eutils.eclass do a quick check for gpatch and if it exists use > that vs patch. Why not simply alias patch=gpat

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

> On Sun, 21 Sep 2008, Steve Long wrote: > Vaeth wrote: >> let me remark that the more clever way to this is >> [ -n "${DOCS}" ] && eval "dodoc ${DOCS}" > [...] > BASH arrays will cope with *any* character apart from NUL, which > isn't allowed in filenames. Can you _guarantee_ the same? It s

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

> On Mon, 22 Sep 2008, Kent Fredric wrote: > find /usr/share/doc/ -wholename "* *" > /usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2 Yes, and if you look into src_install of the ebuild, it does: dodoc doc/*.txt So a simple "dodoc ${DOCS}" with DOCS="... doc/*.txt ..." would work eve

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

> On Sun, 21 Sep 2008, Steve Long wrote: > That works for that specific case, yes, but it's still not a general > solution, which is what BASH arrays were invented for. For instance, > an ebuild author cannot specifically include a file with spaces, and > ignore all the other files in the same

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

> On Wed, 24 Sep 2008, Steve Long wrote: > As I said; generality in lib functions seems like a useful thing. Other ebuild variables are space separated lists, so why should DOCS be an exception? So far nobody has shown a real-life example of an existing ebuild that could profit from the arra

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

> On Tue, 30 Sep 2008, Petteri Räty wrote: >>> dodoc ${DOCS} || die "dodoc failed" >> This seems alright fine to me > It's not. If you want to have default DOCS then you should loop > through the items and check with [[ -e ]] before trying to install > them. I'm not convinced that this is a

[gentoo-dev] EAPI-2 and src_configure in eclasses

How should exporting of src_configure in eclasses be handled? Should it be conditional, depending on the EAPI? Or is it O.K. to export src_configure unconditionally, since it doesn't harm for EAPI<2? A concrete example is elisp.eclass which should export an empty elisp_src_configure function for E

Re: [gentoo-dev] EAPI-2 and src_configure in eclasses

> On Sun, 5 Oct 2008, Alexis Ballier wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: >> Export it if and only if EAPI is 2. > By the way, do we really want to special case eapi-2 in every eclass ? > That's lot of code duplication and will get even worse when we'll reach > eapi-42. That wo

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

> On Sun, 5 Oct 2008, Robert Buchholz wrote: >> > It's not. If you want to have default DOCS then you should loop >> > through the items and check with [[ -e ]] before trying to >> > install them. >> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't >> fail but the warning

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

> On Sun, 5 Oct 2008, Robert Buchholz wrote: >> So if the ebuild includes non-existing files in DOCS, then why would >> you want to suppress the warnings? > I don't. My point was that the default action on an empty DOCS > variable is to "dodoc AUTHORS ChangeLog NEWS README", and this > should

[gentoo-dev] Re: bzr.eclass into Portage

> On Fri, 21 Mar 2008, Christian Faulhammer wrote: > "Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]>: >> With the help of Ingmar we did some cleanup and added support for >> eclass-manpages at >> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob_plain;f=eclass/bzr.ecl

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

> On Sun, 05 Oct 2008, Thomas Sachau wrote: >> econf \ >> [...] >> ${myconf} || die > "|| die" could be dropped All our documentation (devmanual, ebuild howto, skel.ebuild, pms) recommends "econf || die". So maybe you should first make an effort to have it changed there? I wouldn't consider

[gentoo-dev] Re: bzr.eclass into Portage

> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote: > No objections here, just a question. Do you know if the issue with the > lp:// sources has been fixed in bzr? Looks like this is working fine with bzr-1.5, so I'll change the dependency. Ulrich

Re: [gentoo-dev] Projects without a homepage, and valid contents of HOMEPAGE (per bug 239268)

> On Sun, 5 Oct 2008, Robin H Johnson wrote: >> > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/"; >> That would impose needless lookups on subdomains of gentoo.org for >> clients trying to load the homepage. > http://gentoo.org/package-has-no-homepage/ then. Couldn't a page be cre

[gentoo-dev] Re: bzr.eclass into Portage

> On Mon, 13 Oct 2008, Steve Long wrote: > No objections, a minor point wrt bash: > EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants) > doesn't do anything (beyond waste lex and yacc time.) It does something, namely assigns an empty string if the variable was undefined before. ;-) git.

Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs

> On Sat, 18 Oct 2008, Robin H Johnson wrote: > 3. If you want the default assignment to go to a maintainer, and NOT >the herd, move the element further down in the metadata.xml! I disagree about this point. IMHO the procedure described in

Re: [gentoo-dev] Re: bzr.eclass into Portage

>>>>> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote: > Ulrich Mueller wrote: >> As I just learned there are (at least) three overlays using >> bzr.eclass, namely desktop-effects, emacs, and ltsp. >> >> So I think it is justified to move bzr.ecla

[gentoo-dev] virtual/tetex removed

As announced beginning of September, the tetex virtual was finally removed. See bug 222501 for details. Ulrich

Re: [gentoo-dev] /usr/share/texmf-site

> On Fri, 28 Nov 2008, Andrey Grozin wrote: > Some time ago, some Gentoo TeX guru (don't remember who) advised to > include the following code to the sci-mathematics/maxima ebuild: > [...code...] This code calls "kpsewhich" which means that the location of files installed by the ebuild will

Re: [gentoo-dev] Gentoo Council nominations are now closed

> On Sat, 29 Nov 2008, Mauricio Lima Pilla wrote: > What are the nominees intending to do if they are elected? I miss > the manifests. I think that you will be able to judge for yourself, without an election campaign from my side. Quality and quantity of my contributions might be a criterion.

Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

> On Sun, 30 Nov 2008, James Cloos wrote: > If it does move to metadata, it will need to be copied into /var/db > on install. It is important information which should not be lost if > the package is ever removed from portage. Also, a scan shows that there are about 400 ebuilds in the tree th

Re: [gentoo-dev] [RFC] global useflags

> On Sat, 3 Jan 2009, Markus Meier wrote: > my proposals: > xft: Build with support for XFT font renderer (x11-libs/libXft) +1 BTW, why do we have a virtual/xft? Is this a leftover from the times of monolithic X? > And the special case, which probably needs some discussion is the > gsm fla

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January

> On Wed, 7 Jan 2009, Donnie Berkholz wrote: > Does anyone have additional topics for the Jan 22 meeting? Could you cover the PMS/documentation issue of bug 250077? Or, if you prefer to generalise, set up a procedure to resolve such conflicts? Ulrich

Re: [gentoo-dev] One-Day Gentoo Council Reminder for January 22

> On Thu, 22 Jan 2009, Tobias Scherbaum wrote: >> - PMS, bug #250077: Do we need to get involved in this? (-dev) > We haven't been asked to get involved, therefore we don't need to.

[gentoo-dev] Last rites: x11-misc/hotkeys

# Ulrich Mueller (25 Jan 2009) # Masked for removal in 60 days. Produces segfaults and doesn't work # with recent X server due to API changes. Upstream dead. Bug 242462. x11-misc/hotkeys

Re: [gentoo-dev] bzr.eclass

> On Sat, 14 Feb 2009, Christian Faulhammer wrote: > Please review the attached patch. + local repo_type=3D$(bzr info "${EBZR_BRANCH_DIR}" | head -n 1 | cut -d '= (' -f 1) + if [[ "${repo_type}" !=3D "Lightweight checkout " ]]; then This test looks very fragile t

[gentoo-dev] wikipedia-mode und outline-magic

Hallo, ich hatte mit meiner letzten Änderung in wikipedia-mode ein "(require 'outline-magic)" aufgenommen. Bei nochmaligem Nachdenken bin ich mir nicht mehr sicher, ob das richtig war. - wikipedia-mode kann ohne outline-magic übersetzt und benutzt werden. - outline-magic definiert outline-promote

Re: [gentoo-dev] wikipedia-mode und outline-magic

>>>>> On Mon, 16 Feb 2009, Ulrich Mueller wrote: [something in German] Please ignore this message. I inserted the wrong "To:" address. Sorry, Ulrich

Re: [gentoo-dev] prepalldocs is now banned

> On Wed, 18 Feb 2009, Alexis Ballier wrote: > Then, for the nth time, what would be the good solution? How would > one convert prepalldocs usage to something allowed? I've failed to > find anything about it in the relevant bug and the only answer I've > seen is "remove it". You can count on m

Re: [gentoo-dev] prepalldocs is now banned

> On Wed, 18 Feb 2009, Ciaran McCreesh wrote: > If you don't explicitly need compression, don't do anything. You mean if the user has requested compression with PORTAGE_COMPRESS, ignore it? What about FEATURES="nodoc", ignore it too? > And if you're trying to make a space-critical distributi

Re: [gentoo-dev] prepalldocs is now banned

> On Wed, 18 Feb 2009, Ciaran McCreesh wrote: >> You mean if the user has requested compression with >> PORTAGE_COMPRESS, ignore it? > Yup. It's a misfeature. You can see this by considering the > proportion of ebuilds that honour it... All ebuilds that install things with "dodoc" at least.

Re: [gentoo-dev] prepalldocs is now banned

> On Wed, 18 Feb 2009, Ciaran McCreesh wrote: > Because if you look at the statistics, it's pretty obvious that it's > a stupid idea. If you've got USE=doc, somewhere around 4% of managed > files are in /usr/share/doc, and once you take inode sizes into > account, you can knock that down to ab

[gentoo-dev] Re: bzr.eclass

> On Thu, 19 Feb 2009, Christian Faulhammer wrote: >> > +# The bzr command to get the diff output. >> > +EBZR_DIFF_CMD="bzr diff" >> >> > + ${EBZR_DIFF_CMD} | diffstat >> >> Why does this need to happen? Please add a comment. > It produces Git-like output about how much has change

Re: [gentoo-dev] prepalldocs implementation in eutils.eclass (was: prepalldocs is now banned)

> On Thu, 19 Feb 2009, Tiziano Müller wrote: > Instead of breaking things you could have tried to come up with a > real solution. This could be said about the council's decision as well. > [1] > src_install() { > emake DESTDIR="${D}" docdir="/usr/share/doc/${PF}" > prepalldocs > } > (or

Re: [gentoo-dev] prepalldocs implementation in eutils.eclass (was: prepalldocs is now banned)

> On Thu, 19 Feb 2009, Nirbheek Chauhan wrote: >> This will not work. dodoc operates only on files, not on directories. > Tiziano mentioned that later in the email. Perhaps you missed it? I didn't miss it. Read his message again: >>> The only problem I see here is that either or >>> ${T}/d

[gentoo-dev] Proposal for compression handling (was: Re: prepalldocs is now banned)

> On Wed, 18 Feb 2009, Alexis Ballier wrote: >> If you really, genuinely think you have a case for compression of >> docs, backed up with statistics showing that it's a relevant >> change, then you should write a proposal for future EAPIs for >> handling it, > I don't understand why something

Re: [gentoo-dev] prepalldocs implementation in eutils.eclass (was: prepalldocs is now banned)

> On Thu, 19 Feb 2009, Tiziano Müller wrote: >> emake DESTDIR="${D}" docdir="${T}/doc" >> dodoc "${T}/doc" > should be dodoc "${T}/doc/*" O.K., that looks better. However, you still copy files around, for the sole purpose to enable dodoc's "magic" side effect (which also is not mentioned in

Re: [gentoo-dev] Proposal for compression handling

> On Thu, 19 Feb 2009, Ciaran McCreesh wrote: > If there's an inclusion list and an exclusion list, there's only a > need to delete things from the exclusion list if the exclusion list > has bad initial values, and never any need to delete things from the > inclusion list. And since reliably r

[gentoo-dev] Re: bzr.eclass

> On Fri, 20 Feb 2009, Christian Faulhammer wrote: > $ time (bzr diff --old lp:bzr-gentoo-overlay \ > --new /media/disk/bzr-overlay/|diffstat) > real0m50.088s This is prohibitive. Drop it completely, or enable it only if some environment variable is set. Ulrich

Re: [gentoo-dev] Proposal for compression handling

> On Thu, 19 Feb 2009, Brian Harring wrote: >> - "docompress" (without option or with option "-a"): add paths >> (directories or files) to the inclusion list >> - "docompress -x": add paths to the exclusion list > Globbing support? No, I would say. The other do* commands don't have it, and "

Re: [gentoo-dev] Proposal for compression handling

> On Sat, 21 Feb 2009, Zac Medico wrote: > Keep in mind that using a glob that way is going to mean that > docompress has to join each path with the current directory and > then strip $D from the left side. Doing it that way complicates the > implementation details a bit, and it's not quite as

Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

> On Wed, 25 Feb 2009, Petteri Räty wrote: > Let's try something new. I would like to get opinions from as many > people as possible about GLEP 55 and alternatives listed here in order > to get some idea what the general developer pool thinks. I've already commented on this in December 2007 [

[gentoo-dev] package.use in profiles and IUSE defaults

Is it safe to remove an entry from package.use (in profiles) if the package has an IUSE default for the respective flag? To be more concrete, Emacs ebuilds have IUSE="+xpm" now, but we still have an entry "app-editors/emacs xpm" in profiles/base/package.use which I would like to remove. As I under

Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support

> On Fri, 06 Mar 2009, Donnie Berkholz wrote: > Any thoughts? > + *) > + die "Unknown EAPI ${EAPI}" > + ;; Is is safe to assume that an unknown EAPI will provide a "die" function? Ulrich

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

> On Sun, 8 Mar 2009, Ciaran McCreesh wrote: > Last time I checked, every single use of foo? as a direct child of || > in the tree was wrong, as were the Portage docs. Let's say you have the > following: > DEPEND="|| ( > foo? ( cat/foo ) > bar? ( cat/bar ) > cat/ba

Re: [gentoo-dev] Ideas for a (fast) EAPI=3

> On Sun, 08 Mar 2009, Tiziano Müller wrote: >> > http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ I get "Not Found - Error 404" for this URL. Ulrich

Re: [gentoo-dev] EAPI 3 PMS Draft

> On Tue, 17 Mar 2009, Tiziano Müller wrote: > You forgot to mentioned that we probably also want that > default_src_configure/src_compile die when they try to `cd` to an > invalid ${S}. Sorry, seems that I've missed the discussion on this one. There is no 'cd "${S}"' command in the default

Re: [gentoo-dev] EAPI 3 PMS Draft

> On Tue, 17 Mar 2009, Peter Volkov wrote: > Probably this is not best implementation, but it describes idea > well. If failures are non fatal I don't object to having src_test > enabled by default and I'll all for this even. [Replying to a random message in this thread.] Has anyone already

Re: [gentoo-dev] EAPI 3 PMS Draft

> On Tue, 17 Mar 2009, Tiziano Müller wrote: >> I hope you don't propose to remove this useful fallback behaviour >> in general? > Yes I do since I don't see anything useful in it. But I'm ready to > be taught otherwise. There are dozens of packages in app-emacs making use of this feature (m

Re: [gentoo-dev] EAPI 3 PMS Draft

> On Tue, 17 Mar 2009, Ciaran McCreesh wrote: >> There are dozens of packages in app-emacs making use of this >> feature (most of them from before my time, so don't blame me ;-) ). >> Typically their source is a single compressed lisp file and >> everything takes place in WORKDIR. S is not nee

[gentoo-dev] Last rites: app-text/xetex, dev-tex/xkeyval, dev-tex/breqn

# Ulrich Mueller (18 Mar 2009) # Depends on teTeX. Fails to build. # Newer version is included in app-text/texlive-core. # Masked for removal in 60 days, bug 227593. app-text/xetex # Ulrich Mueller (18 Mar 2009) # Depends on teTeX. Newer version is included # in dev-texlive/texlive

Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}

> On Sun, 22 Mar 2009, mrness wrote: > Please do not apply patches that have ${P} prefix in other ebuild > versions than ${PV}. > Is that hard to create a new patch with a proper name? And multiply number and total size of files in ${FILESDIR}? Ulrich

[gentoo-dev] newins "-" for standard input?

Now that "dosed" is going to be banned, what would people think of "newins" (and the other "new*" commands) accepting "-" as the first argument? I don't know how many usage cases there are, but the following are obvious: sed 's/quux/quuux/' foo | newins - foo It would allow for here documents:

Re: [gentoo-dev] newins "-" for standard input?

> On Mon, 23 Mar 2009, Ciaran McCreesh wrote: >> Now that "dosed" is going to be banned, what would people think of >> "newins" (and the other "new*" commands) accepting "-" as the first >> argument? > There's a slightly different variation in exheres-0: as well as do* > and new*, there's als

Re: [gentoo-dev] newins "-" for standard input?

> On Mon, 23 Mar 2009, Tiziano Müller wrote: >> what would people think of "newins" (and the other "new*" commands) >> accepting "-" as the first argument? > I like it :-) Bug 263565 now. Ulrich

Re: [gentoo-dev] Gentoo Council Reminder for March 26

> On Thu, 26 Mar 2009, Tiziano Müller wrote: > Am Mittwoch, den 25.03.2009, 23:23 + schrieb Ciaran McCreesh: >> > > 9) EAPI 3 bans || ( use? ( ... ) ) >> > >> > What is the suggested replacement? If there's a decent one, sure. >> >> The replacement is to write the deps out correctly. Ever

Re: [gentoo-dev] Please review: prefix.eclass

> On Fri, 27 Mar 2009, Fabian Groffen wrote: > Please review. >r=$? >eend ${r} >[[ ${r} != 0 ]] && die "failed to eprefixify ${x}" Here you could save a variable, since eend returns the status: eend $? || die "failed to eprefixify ${x}" Ulrich

Re: [gentoo-dev] Preserving mtimes for EAPI3

> On Mon, 30 Mar 2009, Peter Alfredsen wrote: >> No, an EAPI bump is necessary. Older (post-EAPI) Portage versions >> do something different, so any ebuild relying upon particular >> behaviour is already broken. > For an example of this, see http://bugs.gentoo.org/264308 I would say that is

Re: [gentoo-dev] Preserving mtimes for EAPI3

> On Mon, 30 Mar 2009, Marijn Schouten (hkBst) wrote: > On behalf of the Lisp project (which includes the Emacs subproject) > I'd like to propose that preservation of mtimes be included as a > requirement of EAPI3. > [...] > Background: Dynamic languages such as Common Lisp and Elisp, but >

Re: [gentoo-dev] Preserving mtimes for EAPI3

> On Mon, 30 Mar 2009, Petteri Räty wrote: > For most features the block is the need for Portage to implement the > feature. If I read the thread correctly, Portage already implements > what is wanted here so it's just a matter of agreeing on the > specification. Not completely. Portage prese

[gentoo-dev] Re: Preserving mtimes for EAPI3

> On Mon, 30 Mar 2009, ABCD wrote: > Personally, I would use > find "${D}" -type f \! -newermt "@${stamp1}" -exec \ > touch -c -d "@${stamp1}" {} + > and > find "${D}" -type f -newermt "@${stamp2}" -exec \ > touch -c -d "@${stamp2}" {} + > to avoid an unneeded call

[gentoo-dev] Re: Preserving mtimes for EAPI3

> On Tue, 31 Mar 2009, ABCD wrote: > Here is a solution that should work with find(1p) and touch(1p): > Immediately preceding pkg_setup, > `touch "${PORTAGE_BUILDDIR}/.pre_pkg_setup`; > immediately following src_install, > `touch "${PORTAGE_BUILDDIR}"/.post_src_install`. > Then, the followin

Re: [gentoo-dev] Preserving mtimes for EAPI3

>>>>> On Tue, 31 Mar 2009, Michael Haubenwallner wrote: > On Mon, 2009-03-30 at 19:14 +0200, Ulrich Mueller wrote: >> 1. Record two timestamps: >> before calling pkg_setup, timestamp1; >> after src_install has completed, timestamp2. >> >> 2. Afte

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

> On , 01 Apr 2009, Mike Frysinger 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. Since EAPI 3 is on the agenda already, I would ask the council to consider inclusion of "

Re: [gentoo-dev] RFC: EAPI cheat sheet for your desktop

> On Tue, 31 Mar 2009, Christian Faulhammer wrote: > Have a look at http://v-li.de/temp/eapi_cheatsheet.pdf>, > print it, fold it and tell me if you like or not (and especially > what exactly). The Gentoo store should have a coffee mug with this. ;-) Ulrich

[gentoo-dev] Last rites: app-text/tetex

# Ulrich Mueller (2 Apr 2009) # De-supported by upstream since three years, see http://tug.org/teTeX/ # Please use app-text/texlive as a replacement. A migration guide is at # http://www.gentoo.org/proj/en/tex/texlive-migration-guide.xml # Package has open security issues in bug 264598. # Masked

[gentoo-dev] net-www category

Long time ago [1] it was decided that category net-www should be retired, since the www-* categories exist for these packages. However, if I look at the category, then most packages in it were created in 2006 or later. In my understanding, at least no new packages should be created in net-www. An

Re: [gentoo-dev] net-www category

> On Fri, 3 Apr 2009, Jim Ramsay wrote: >> Another question is if the existing ones should still be moved to >> some www-* category? > Should? I have no idea. Where exactly would we move these packages? > The quasi-more-usefully-named www-misc? Yes, if none of the other www-* categories fi

Re: [gentoo-dev] News item for review: teTeX deprecation

> On Fri, 3 Apr 2009, Heath N Caldwell wrote: > On 2009-04-04 00:57, Christian Faulhammer wrote: >> please review attached news item. Well, I'd thought that last rites plus the message in package.mask were enough (it also mentions the URL of the migration guide). But of course it cannot harm

Re: [gentoo-dev] net-www category

> On Fri, 3 Apr 2009, I wrote: > Since most of the stuff in net-www seems to be browser plugins, > we could create www-plugins. Is the following a reasonable scheme? net-www/adobesvg -> www-plugins/adobesvg net-www/awstats -> www-misc/awstats net-www/di

  1   2   3   4   5   6   7   8   9   10   >