Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

2012-03-12 Thread Nathan Phillip Brink
On Mon, Mar 12, 2012 at 12:29:47PM -0500, Matthew Summers wrote:
 On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen 
  # Samuli Suominen (12 Mar 2012)
  # Severely broken wrt bugs #179178, #331181, #334835, #350059,
  # #372839, #380155, #380627, #381055, #383515, #383553, #384687,
  # and #403399. Search bugzilla with keyword lilypond. Nothing
  # left in tree that builds. Removal in 30 days.
  # Samuli Suominen (12 Mar 2012)
  # media-sound/lilypond required for this is masked in ../package.mask
  # for removal
  app-text/asciidoc test
 Just curious, but is there no one interested in this, lilypond,
 package anymore? The latest stable is 2.14.2 and the project is pretty
 active. Seems like a shame to get rid of it entirely.

I myself am quite interested in lilypond. I only use it occasionally
and am still a novice at it, but I like the typesetting it does.

Maybe next week I can find time to attack some of these bugs and
rescue it, unless if someone more qualified or with more time is


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Packages up for grabs due dragonheart retirement

2011-12-01 Thread Nathan Phillip Brink
On Wed, Jul 20, 2011 at 05:08:57PM +0200, Pacho Ramos wrote:
 Due dragonheart retirement the following packages need a new maintainer:

I've taken the remainder of the lzo family.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Linking Stage, building a ebuild

2011-12-01 Thread Nathan Phillip Brink
On Fri, Dec 02, 2011 at 12:22:30AM -0300, Willian Vale da Rocha wrote:
 I'm writing a ebuild for GNU Radio, just to learn how to write and i
 doesn't found any where(or i was looking for wrong) how to define a LDFLAGS
 for the linking stage. GNU Radio need this because they use their library.
 If i don't explain correct, i going to show the line command that i trying
 to explain
 ./configure --prefix=$HOME/image LDFLAGS=-L$HOME/image/lib64
 If i need to define prefix, how can i do it, and How can i use the LDFLAGS
 in ebuild
 Sorry about the english

Just so you know, such questions generally belong on the
gentoo-devhelp mailing list or in

In an attempt to answer your question, you should use the flag-o-matic
eclass to append directives to LDFLAGS. For example:

inherit flag-o-matic multilib

src_configure() {
append-ldflags -L${EPREFIX}/usr/$(get_libdir)/special_package \


But you appear to be trying to link to something outside of a normal
Gentoo install. If a user wanted to link a program against his own
compiled copy of the library, he would instead just invoke emerge with
the proper LDFLAGS:

# LDFLAGS=-L${HOME}/image/lib64\ -Wl,-rpath,${HOME}/images/lib64 emerge -v 

If you are writing your ebuild to compile against a package/library
which is not available in portage, your first step should be to write
an ebuild for _that_ package. I.e., write the ebuild for the library
your program needs before writing the ebuild for the program. Then the
library would be properly installed into /usr/$(get_libdir) and appear
in GCC's normal searchpaths.

If this does not help, please ask again in #gentoo-dev-help or the
gentoo-devhelp ML :-).


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Packages up for grabs

2011-11-11 Thread Nathan Phillip Brink
On Fri, Nov 11, 2011 at 09:38:24AM -0500, Ian Stakenvicius wrote:
 OK, to clarify i'm just re-listing which packages ppl have spoken up for:
 On 11/11/11 06:38 AM, Tomáš Chvátal wrote:
  dev-cpp/yaml-cpp - neurogeek
  dev-libs/softhsm - mschiff
  dev-ruby/dnsruby - mschiff
  net-dns/opendnssec - mschiff
  sys-devel/autoconf-archive - binki

I'll take autoconf-archive, unless if someone else wants it.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] [PATCH scons-utils] Support setting common SCons arguments using myesconsargs.

2011-10-23 Thread Nathan Phillip Brink
On Sun, Oct 23, 2011 at 08:20:37PM +0200, Micha?? G??rny wrote:
  scons-utils.eclass |   33 +
  1 files changed, 25 insertions(+), 8 deletions(-)
 +# @ECLASS-VARIABLE: myesconsargs
 +# List of package-specific options to pass to all SCons calls. Supposed to be
 +# set in src_configure().

Shouldn't this variable be named MYESCONSARGS since it is being
introduced into the global scope?


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Suggestion for getting rid of udev

2011-10-12 Thread Nathan Phillip Brink
On Wed, Oct 12, 2011 at 09:09:24AM -0400, Walter Dnes wrote:
 On Wed, Oct 12, 2011 at 05:32:05AM +, Nathan Phillip Brink wrote
  You can already try out what using mdev instead of udev is like in
  Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
  remerge busybox. You must be sure to be using busybox-1.92.2 or later
  for bug #83301.
   Did you mean busybox-1.19.2?  That's the latest ebuild in
 /usr/portage, and it's still ~amd64 (~everything for that matter).

Yes, Oops.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Suggestion for getting rid of udev

2011-10-11 Thread Nathan Phillip Brink
On Wed, Oct 12, 2011 at 12:40:23AM -0400, Walter Dnes wrote:
 Hi all
   Recently, there was a firestorm on the gentoo-user list over the idea
 that udev would eventually require /usr to be on the same physical
 parition as /, or else use initramfs, which is its own can of worms. I'm
 not a programmer, let alone a developer.  Rather than merely ranting, I
 went and searched for an alternative.
   Another option is to take the current Gentoo setup, drop udev and
 use mdev in the same manner as Alpine uses it.  In case anyone asks,
 auto mounting should still be possible.  Attached is an excerpt from
 /var/log/messages from a basic Alpine install.  The kernel messages were
 generated when I inserted a USB key into a usb jack.

Seeing from the prior conversations here (sorry for lack of citation)
, I suspect that the root problem isn't with udev itself but with the
udev rules.

The magic which makes automatic userspace configuration possible is in
the udev rules and makes udev appear to be the problem. For example,
if you switch to mdev currently, you will notice that X11's device
autodetection doesn't work so well. (At least for me, X11's
autodetection magically works for detecting input devices with udev
but not with mdev). It is concievable that you could develop a
parallel database of mdev-compatible rules and even let packages
install rules specific to themselves (with modification to mdev
). With these sorts of things, you might figure out a way to make
X11's device autoconfiguration work or perform other device
initialization tasks. But at the same time, you have a good chance of
accidentally introducing a reliance on libraries/programs installed to
/usr. This latter problem is the issue, deciding how much software
should have --prefix=/ versus the normal --prefix=/usr.

You can already try out what using mdev instead of udev is like in
Gentoo. Just add `sys-apps/busybox mdev' to /etc/portage/package.use,
remerge busybox. You must be sure to be using busybox-1.92.2 or later
for bug #83301.

# rc-update add mdev sysinit
# rc-update del udev sysinit

But be 'ware that this isn't guaranteed to provide a successful boot

 Oct  9 13:46:00 e521 kernel: [10714.105621] usb 2-8: new high speed 
 USB device using ehci_hcd and address 4
 Oct  9 13:46:00 e521 kernel: [10714.241353] usb 2-8: New USB device 
 found, idVendor=13fe, idProduct=1e00
 Oct  9 13:46:00 e521 kernel: [10714.241357] usb 2-8: New USB device 
 strings: Mfr=1, Product=2, SerialNumber=3
 Oct  9 13:46:00 e521 kernel: [10714.241360] usb 2-8: Product: 
 Patriot Memory  
 Oct  9 13:46:00 e521 kernel: [10714.241362] usb 2-8: Manufacturer:  

 Oct  9 13:46:00 e521 kernel: [10714.241364] usb 2-8: SerialNumber: 
 Oct  9 13:46:00 e521 kernel: [10714.244241] scsi4 : usb-storage 
 Oct  9 13:46:01 e521 kern.notice kernel: [10715.279753] scsi 4:0:0:0: 
 Direct-Access  Patriot Memory   PMAP PQ: 0 ANSI: 0 CCS
 Oct  9 13:46:02 e521 kern.notice kernel: [10715.930991] sd 4:0:0:0: [sdb] 
 31326208 512-byte logical blocks: (16.0 GB/14.9 GiB)
 Oct  9 13:46:02 e521 kern.notice kernel: [10715.931980] sd 4:0:0:0: [sdb] 
 Write Protect is off
 Oct  9 13:46:02 e521 kern.debug kernel: [10715.931983] sd 4:0:0:0: [sdb] Mode 
 Sense: 23 00 00 00
 Oct  9 13:46:02 e521 kern.err kernel: [10715.931986] sd 4:0:0:0: [sdb] 
 Assuming drive cache: write through
 Oct  9 13:46:02 e521 kern.err kernel: [10715.935986] sd 4:0:0:0: [sdb] 
 Assuming drive cache: write through
 Oct  9 13:46:02 e521 kernel: [10715.981381]  sdb: sdb1
 Oct  9 13:46:02 e521 kern.err kernel: [10715.986028] sd 4:0:0:0: [sdb] 
 Assuming drive cache: write through
 Oct  9 13:46:02 e521 kern.notice kernel: [10715.986035] sd 4:0:0:0: [sdb] 
 Attached SCSI removable disk

Unless if I'm missing something, those messages _always_ show up even
if udev or mdev haven't been invoked.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Packages up for grabs due tanderson retirement

2011-09-13 Thread Nathan Phillip Brink
On Tue, Sep 13, 2011 at 08:31:33PM +0200, Pacho Ramos wrote:
 Due tanderson retirement the following packages need a new maintainer:
 Thanks for taking them

I'll take dev-libs/check.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] multilib setup

2011-09-12 Thread Nathan Phillip Brink
On Sun, Sep 11, 2011 at 03:55:49PM -0400, Mike Frysinger wrote:
 as for no-multilib systems, lib64 will be the same, and lib will be 
 symlinked to lib64.  this will be easier i think to share files between 
 multilib and non-multilib 64bit systems.

Isn't this slightly more complicated than it needs to be? Why not just
use /lib and no symlink for no-multilib 64-bit systems?

Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

2011-09-07 Thread Nathan Phillip Brink
On Wed, Sep 07, 2011 at 05:31:23PM -0400, Joshua Kinard wrote:
 Are there possibilities about breaking off just a small piece of openrc and
 putting that into /run (or /boot)?  Enough of the core scripts so that it
 can find /usr and mount it before continuing?

Isn't /run something that's supposed to be mounted with tmpfs
eventually? Currently /var/run's job is to hold volatile
data... Unless if I've missed something, I'm confused about why it
makes sense to install scripts or binaries there.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Re: Implicit system dependencies

2011-08-23 Thread Nathan Phillip Brink
On Wed, Aug 24, 2011 at 03:53:26AM +1000, Michael wrote:
 Also, on a related note, would it be appropriate to report the following 
 undeclared deps, given that the package in question already has DEPEND for 
 * Checking app-arch/guitar-0.1.4 for undeclared dependencies
  *   /usr/bin/guitar links to /usr/lib64/
  * Missing dependency on x11-libs/libX11
  *   /usr/bin/guitar links to /usr/lib64/
  * Missing dependency on x11-libs/libXi
  *   /usr/bin/guitar links to /usr/lib64/
  * Missing dependency on x11-libs/libXext
  *   /usr/bin/guitar links to /usr/lib64/
  * Missing dependency on x11-libs/libxcb
  *   /usr/bin/guitar links to /usr/lib64/
  * Missing dependency on x11-libs/libXau
  *   /usr/bin/guitar links to /usr/lib64/
  * Missing dependency on x11-libs/libXdmcp

Those look like indirect linker dependencies to me:

ohnopublishing mnt # readelf -d $(which guitar) | grep -e NEEDED
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
ohnopublishing mnt #

See that X11 is brought in by libgtk and recursively so on and so on:
ohnopublishing mnt # readelf -d /usr/lib64/ | grep -e NEEDED
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []
 0x0001 (NEEDED) Shared library: []


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package

2011-08-07 Thread Nathan Phillip Brink
On Sat, Aug 06, 2011 at 04:13:52PM +0200, Fabian Groffen wrote:
 - tree generation is dynamic
   + easy to move packages around, their category is specified by the
 tree configuration, the repository the package lives in doesn't change,
 probably overlays, betagarden, graveyard, sunset, etc. can all go
 - per package branches
   + instead of developing in overlays, simply branches could be used,
 such that a single place is sufficient to for each package

Recreating the overlay experience with many repos sounds
difficult. Many overlays include multi-component packages or changes
to interdependent packages. Using per-package branching instead of
overlays would complicate this, with a user (or layman) having to
search each package's repository for branches associated with a
particular overlay when trying to guess which overlay a package should
be pulled from.

The current behavior of PORTDIR_OVERLAY is quite well-defined and
easier to understand. It even allows overlays to gracefully fall
behind in keeping their packages up to date. For example, when a fix
in an overlay is committed to gentoo-x86 as a new ebuild revision, the
overlay maintainer can forget that he has a stale version of the
package without harming anyone because portage chooses the newest
package. It seems that the traditional overlay idea -- where overlays
overlay gentoo-x86 and eachother -- can't quite exist with per-package
branches. To recreate this idea, you'd need to have one checkout per
package per repo (including overlays) and you'd still use

I sorta like how overlays work currently ;-).


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)

2011-06-28 Thread Nathan Phillip Brink
On Tue, Jun 28, 2011 at 10:24:26PM +0400, Peter Volkov wrote:
 ?? ??, 28/06/2011 ?? 12:23 -0400, Mike Frysinger ??:
  On Tuesday, June 28, 2011 02:54:03 Micha?? G??rny wrote:
   emake CC=$(tc-getCC) CFLAGS=${CFLAGS}...
  this is easily dangerous when it comes to packages (and many do) that 
  in the Makefile.  specifying on the command line blocks those while passing 
  via env works fine.  i'm not sure it's appropriate to provide as an example.
 Hm, I'm not sure I understand what you are talking about here. Could you
 provide example?

I think he's referring to somethine like:

CFLAGS += `pkg-config --cflags libxml-2.0`

which would work fine for:

but which would override the pkg-config flags if you do:
  emake CFLAGS=${CFLAGS}


Description: PGP signature

Re: [gentoo-dev] Re: Tags (Was: RFC: split up media-sound/ category)

2011-06-24 Thread Nathan Phillip Brink
On Wed, Jun 22, 2011 at 11:20:40PM -0400, Wyatt Epp wrote:
 I bring this up because there are several packages with the same name
 and different qualification.  Obviously, they'll have different tags
 because they're not the same thing, but neither should they share the
 same directory.  So the simple solution is to just change the package
 names so we avoid collision and preserve our flat ontology (I've
 forgotten the objection to doing this; please forgive).

I believe that the objection is that it is better to follow upstreams'
package names as directly as possible. This would look better and be
less confusing than having a package named git and git-core, like I've
seen elsewhere. Having categories would also prevent changing an
ebuild's name from upstream's name only for the sake of giving it a
unique name in Gentoo.

I think that in most cases, when package name collisions happen, the
colliding packages differ enough that they'd conceivably be in
different portage categories, letting them be uniquely identified in
Gentoo. If someone is planning on writing a new program, he likely
knows about already-existing alternatives to this package. The author
of a new sound editing suite would not name his suite `sox' because
the author cannot help but to know that media-sound/sox exists. But
someone writing some new sax thing might play off of `sax' and name it
`sox', though this is hypothetical ;-).


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Tags (Was: RFC: split up media-sound/ category)

2011-06-24 Thread Nathan Phillip Brink
On Wed, Jun 22, 2011 at 08:57:47PM -0400, Wyatt Epp wrote:
 Tags are basically keywords you can use to describe packages, allowing
 you to easily search and explore your options based on what the
 packages actually does (if we want to get technical, anything that
 identifies a package is a sort of tag: name, version, license, set,
 checksum, etc.). ??It's just a vocabulary that eases the burden of
 human lookup. ??The categories we have now are essentially (pairs of)
 tags tied to a treelike structure in an actual filesystem, and I'd
 wager that's a decent place to start, too-- probably the most
 prominent problem I can see with the current method comes from these
 edge cases where one category is obviously not enough. ??The obvious
 solution is probably to just stick our semantic metadata into the
 metadata.xml. ??So for...say, media-video/kdenlive,
 catmedia-video/cat[1] becomes more like this:

I'm going to just interpret this as a suggestion for a modification to
metadata.xml ;-). Could this not just be:


Then in the category's metadata.xml, at media-video/metdata.xml, you
can fill in the rest:


It would be nice to take advantage of the existing categories in
Gentoo instead of having to duplicate all of this information over and
over -- if this is to be done with metadata.xml.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

2011-06-01 Thread Nathan Phillip Brink
On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote:
 On 01/06/2011 04:08 , Peter Volkov wrote:
  ?? ??, 30/05/2011 ?? 14:55 -0700, Brian Harring ??:
  The problem is, that's a *fuzzy* definition. 
  Ok, let's start with something and then we'll add more items if
  required. Currently I'd like to propose following text:
  The ChangeLog must be updated with each commit. The only possible
  relaxations for this rule are:
  1. Nonfunctional whitespace changes
  2. Changes in comments (lines starting with # in ebuild, or leading text
  in patches)
  3. Manifest updates
  4. Changes in ChageLog itself ;)
  Something unclear? Anything else?

I think these are reasonable.

 Maybe typos in e{log,warn,info} messages and/or typos in general (
 variables, functions etc )

But typos in variables and functions (which in most cases _imply_
functional changes) are generally bugs which should be mentioned in
the ChangeLog. Typos in informational messages (e{log,warn,info})
might also affect the user and thus be `functional' indirectly. I
think that the 4-item list is complete enough ;-).


Look out for missing or extraneous apostrophes!

Description: PGP signature

[gentoo-dev] Last rites: net-irc/oer, net-irc/oer-mysql

2011-05-13 Thread Nathan Phillip Brink
# Nathan Phillip Brink (13 May 2011)
# Abandoned by upstream. QA issues, such as failing _FORTIFY_SOURCE
# checks. Bugs 240918, 252000, 332111, 339545, 354493.
# Removal on 2011-07-12.


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] RDEPENDing on packages from overlays?

2011-04-23 Thread Nathan Phillip Brink
On Sat, Apr 23, 2011 at 04:02:24AM -0700, Zac Medico wrote:
 On 04/22/2011 11:05 PM, Eray Aslan wrote:
  Basically, there are requests to add packages to RDEPEND in virtual/mda
  and virtual/mta that are not in the official tree but in sunrise.
  On one side, *DEPENDing on a package outside the tree doesn't seem
  right.  Additionally, keeping track of all the overlays and their
  package versions, USE flags and flag changes are potentially too much to
  track.  We will be making changes to a virtual package without testing
  whether it works.
 I would assume that it's the overlay maintainers' responsibility to test
 and report any problems. Any such problems would should affect the
 overlay users, so it shouldn't cause any regression for users who don't
 choose to use the overlay.
  On the other hand, we are making life (unneccesarily?) difficult for
  overlay users by not incorporating the requested changes to the official
 I don't imagine it's that much work to maintain a fork of the virtual.
 It's just an inconvenience for users since the version from the overlay
 might become temporarily outdated and cause problems with dependency

I would prefer that the virtual maintenance still happen in the main
tree whenever possible. In this case, the virtual's maintainer seems
willing to add the package atoms to the virtual -- the only concern
was whether or not it was allowed to *DEPEND on atoms known not to be
in gentoo-x86. So the answers I've read all add up to a yes, go

Encouraging overlays to maintain their own virtual replacements would
be encouraging more people who are not familiar with a particular
virtual to mess with it in their own repositories. Also, if multiple
overlays each need to add a single but different DEPEND to a
particular virtual, the user will end up with only one of these
virtual overrides. Someone who overrides a virtual in an overlay would
thus be expected to take into account other overlays which provide
candidates for that virtual. Having overlay maintainers do this would
be much more of a mess than letting one person manage the gentoo-x86
virtual and get everything done right once and without duplication of


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Using Jabber for developer communication

2011-04-10 Thread Nathan Phillip Brink
On Sun, Apr 10, 2011 at 10:29:56PM -0300, Zhu Sha Zang wrote:
 Em 10-04-2011 08:54, George Prowse escreveu:
  Currently, research has told us that that the best format for
  communication is MSN
 It is a joke too, right?

This idea of MSN is very much a joke. Noone would possibly support
using it ;-).


Look out for missing apostrophes!

Description: PGP signature

Re: [gentoo-dev] Bugzilla 4 migration

2011-03-08 Thread Nathan Phillip Brink
On Tue, Mar 08, 2011 at 03:53:01PM +0100, Micha?? G??rny wrote:
 On Tue, 08 Mar 2011 16:41:08 +0200
 Antoni Grzyma??a wrote:
   On Tue, 8 Mar 2011 15:26:34 +0100, Micha? Grny wrote:
   On Mon, 07 Mar 2011 15:06:25 -0500
   Olivier Cr??te wrote:
   On Mon, 2011-03-07 at 20:47 +0100, Micha?? G??rny wrote:
Why does everyone assume it needs to be enforced? If user is
interested in protecting his/her data, he/she can simply use
https://. If he/she is not, there is no real reason to enforce
slower (and not always supported) SSL.
   Maybe it's not to protect the user, but to protect the Gentoo
   infrastructure.. And really, SSL has been supported by every
   browser for the last 15 years. And it is not in any way slow or
   slower than non-SSL.
   If you really think you need to force all users to use SSL, thus
   assuming they're unable to make their own decisions, why don't you
   restrict bugzie access completely?
   You don't seem to (or pretend not to) understand that using SSL 
   protects not *the user* (in which case, yes, a user is free to leave
  the door to *his own* house wide open), but the Gentoo infrastructure
  that is far from his own and that all of us are using.
 Please explain to me how not using SSL for a particular bugzie user is
 going to hurt Gentoo infra. Even if we're talking about a dev,
 and we're really assuming a dev is completely unaware of security
 issues he/she's dealing with, I'd say power outage could cause more

If you access a bug which a user marked private/for devs only, or some
security bug, then the process of you viewing this information without
SSL would disclose this information to anyone listening on your
network. And disclosing your session cookie would allow anyone to find
any such private data they _want_ to find rather than just the content
you're viewing. Thus, by encrypting everything you are protecting
Gentoo users' data which is posted as private on bugzilla because they
trust that ``private'' actually means private.

  Besides, complaining about SSL being slow is absurd considering how
  mildly interactive and how low-traffic a typical bugzilla session is.
  You could do just fine over a 9600 bps modem.
 It is more absurd to waste 5 minutes trying to establish login session
 due to packet loss.

And if you have such a bad internet connection as you claim to have,
then perhaps there's a higher chance of people trolling your packets
anyways :-p.


Look out for missing apostrophes!

Description: PGP signature

Re: [gentoo-dev] Packaging LSB symlinks for

2011-01-31 Thread Nathan Phillip Brink
On Mon, Jan 31, 2011 at 04:14:47PM +0100, Vlastimil Babka wrote:
 when trying to bump sci-geosciences/googleearth to a 6 beta version [1], 
 there's a problem with missing /lib/ file, which the binary 
 somehow requires, and otherwise fails with a rather cryptic error 
 message (saying that the binary itself is missing).
 Apparently this is mandated by LSB and some distros provide it in 
 packages such as lsb-core (debian/ubuntu), redhat-lsb (fedora) or 
 glibc-lsb (mandriva), possibly along with other files. It's always a 
 symlink to
 Gentoo only seems to have one lsb-related package (sys-apps/lsb-release) 
 which is just some query script.
 So, I think the options are:
 1) adding the symlink to the googleearth itself
 2) adding an extra package for the symlinks
 3) adding the symlink to glibc itself
 4) working around it somehow
 I've tried 4) with no luck (executing googleearth-bin, 
 trying LD_LIBRARY_PATH overrides, putting symlink in the 
 same directory as the binary), nothing worked except creating the 
 symlink under /lib. If there was a way, it would be easiest for me.
 Doing 1) would be easy but rather incorrect and possibly result in 
 collisions in the future.
 Doing 3) would be a question for glibc maintainers (didn't try yet), but 
 I guess they won't like it.
 Doing 2) is a question of what package to put it in and what else to put 
 there. Frankly, I don't want to study all of LSB to see what's the 
 lsb-core/redhat-lsb packages about, just to get googleearth working, if 
 there's no general interest in LSB compliance. The mandriva approach 
 seems easiest for my needs (it's just the ld symlinks and nothing more). 
 But I understand that I shouldn't make such decision myself, so I ask 
 here. Thoughs?

Have you checked if patchelf can fix the googleearth binary? I think
that it is intended for this sort of problem: .



Look out for missing apostrophes!

Description: PGP signature

Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

2011-01-29 Thread Nathan Phillip Brink
On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
 I would like to know what is blocking this from landing main tree in
 the near future, as I reviewed:
 and looks like there wasn't major problems (at least commented in this

There are still a number of known build failures, tracked in . There are probably
many more portage-multilib-related build failures which haven't been
encountered yet nor reported. Also, even these reported bugs are not
necessarily fixed first because they only affect us the minority ;-).

Most everything is easy to debug and as simple as replacing calls to
$(LD) in poorly-written Makefileswith with calls to $(CC), fixing
packages which ignore CFLAGS (where we store our -m32) or LDFLAGS
(where we now also store -m32 since one's not allowed to require
buildsystems to call $(CC) with $(CFLAGS) when objects are being
linked into an executable or library).

However, packages which use qmake or cmake macros installed by KDE are
more difficult to debug and there are other funny issues such as
CFLAGS being stored by a library's buildsystem and stored into
/usr/share instead of an ABI-dependent directory, breaking packages
which use that library... ;-)

Also, there are still some decisions/changes to portage-multilib which
might be made The most recent idea discussed was: should ${ARCH}
useflags (like SRC_URI=x86? ( http://host/my-binari-x86.tar.bz2 ))
be replaced with ${ABI} useflags or should we rewrite a bunch of
ebuilds in the tree to be multilib-aware? For example:

Say we have

Does ``use x86'' return true or do we need to use ``use multilib_abi_x86''?
Do detect the true arch, do we need ``use arch_amd64'' or does ``use amd64'' 
still return true?


Look out for missing apostrophes!

Description: PGP signature

Re: [gentoo-dev] Re: Removing .la files

2010-10-24 Thread Nathan Phillip Brink
On Sun, Oct 24, 2010 at 09:57:33PM +, Duncan wrote:
 Enrico Weigelt posted on Sun, 24 Oct 2010 22:09:30 +0200 as excerpted:
  I'm doing some investigation on which .la files are still needed and
  which are not. In general, .la files only are in use by very few
  packages which use them to load plugins (I've seen no package which
  actually requires them for compile-time importing in production).
 FWIW, flameeyes has done quite a bit of work on this, but I'm not sure 
 it's published anywhere.
 FWIW2, I recently took the big jump myself, PKG_INSTALL_MASKing *.la files 
 (I run FEATURES=buildpkg so that's effectively install-masking them too, 
 but they don't get in the binpkgs at all that way), then rebuilding my 
 entire system, and while it's /possible/ certain plugins don't work, I've 
 not noticed it.

I use tommy's portage-multilib which doesn't install any .la files
unless if ``shouldnotlink=true'' is found in the .la file. I think
that the only sorts of problems we've encountered are similar to bug
300256 (caused by Gentoo splitting up a package into multiple

 I needed only one exception, sys-devel/libtool itself.  At least one 
 package (IIRC imagemagick but I could be recalling incorrectly) tests for 
 a properly configured libtool in the configure script by testing for 
 libtool's single *.la file,, so I had to rebuild/reinstall 
 libtool itself without that mask.

This problem is found in an autoconf macro shipped with libtool itself:

Likewise, portage-multilib is configured by default to install .la
files for the libtool package to work around this bug.


Look out for missing apostrophes!

Description: PGP signature

Re: [gentoo-dev] Re: [funtoo] [ [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

2010-07-11 Thread Nathan Phillip Brink
On Wed, Jul 07, 2010 at 06:03:49PM -0600, Ryan Hill wrote:
 On Thu, 8 Jul 2010 00:56:52 +0200
 Enrico Weigelt wrote:
  Hi folks,
  YFYI: yet another of my ebuilds kicked-down.
  It's an improved version of procmail, which automatically creates
  missing maildir directories.
 Upstream first (TM).

I'm pretty sure that the main problem with procmail is that its upstream is 
quite dead. The proper solution might be simply a fork of procmail by someone 
who is willing to accept and apply distros' patches. This would be completely 
independent of distributions... or could be similar to Fedora (or a Fedora 
maintainer) starting up tigervnc. The problem with this approach would be 
getting enough momentum behind it and having distributions recognize such a 

I was myself interested in pushing a patch (unfortunately it's still unfinished 
:-/) to procmail's upstream, but had trouble finding the upstream. If anyone 
has had better luck or knows of a fork like I describe above, I'd be 
interested. Of course, knowing that there is an upstream to submit such a patch 
to would be a great encouragement for me to finish writing it. ;-)


Look out for missing or extraneous apostrophes!

Description: PGP signature

Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass

2010-06-02 Thread Nathan Phillip Brink
On Mon, May 31, 2010 at 03:29:01PM +0200, Maciej Mrozowski wrote:
 On Wednesday 26 of May 2010 19:27:43 Mike Frysinger wrote:
  On Wednesday 26 May 2010 05:38:00 Maciej Mrozowski wrote:
   I've updated documentation, added example usage and option to keep
   libtool files ( supposedly needs those as I was told, no idea
   what for).

IMO, is probably just being silly. Perhaps these files contain
information that is useful on non-Linux systems for dlopen()ing

  more applicable to us w/Linux is that static linking with libtool needs
  them. the AUTOTOOLS_KEEP_LA_FILES seems kind of spurious considering
  current tree behavior and assumption of gnu-capable linking systems.
 It is spurious when we forget about run-time dynamic linking (plugins) in 
 libtool loader ( needs .la files unfortunately. One example - 
 imagemagick - removing .la files for coders makes 'convert' unable to locate 
 them (silly, but hey...).

This case can be caught by checking if the .la file has the following in it:
# Should we warn about portability when linking against -modules?

If shouldnotlink=no _and_ the .la file in question is not
itself, it is generally safe to remove. This is the current policy of
the portage-multilib branch of the multilib overlay. libtool archive
files which are safe to remove are removed by portage-multilib after
the install phase. It seems to work well enough.

Removing .la files which are useless on a given system would be very
nice. It would be even more useful if unused .a files could be swept
away at the same time :-).


Look out for missing apostrophes!

Description: PGP signature