Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On Mon, Mar 12, 2012 at 12:29:47PM -0500, Matthew Summers wrote: On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (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. media-sound/lilypond-2.12.4 media-sound/denemo media-sound/frescobaldi # Samuli Suominen ssuomi...@gentoo.org (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 interested... -- binki Look out for missing or extraneous apostrophes! pgpikFikeaWP7.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due dragonheart retirement
On Wed, Jul 20, 2011 at 05:08:57PM +0200, Pacho Ramos wrote: Due dragonheart retirement the following packages need a new maintainer: ... app-arch/lzop dev-libs/lzo I've taken the remainder of the lzo family. -- binki Look out for missing or extraneous apostrophes! pgpdP6uhTaIrq.pgp Description: PGP signature
Re: [gentoo-dev] Linking Stage, building a ebuild
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
pre
./configure --prefix=$HOME/image LDFLAGS=-L$HOME/image/lib64
\pre
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
irc://chat.freenode.net/gentoo-dev-help.
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 \
-Wl,-rpath,${EPREFIX}/usr/$(get_libdir)/special_package
econf
}
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
my_package
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 :-).
--
binki
Look out for missing or extraneous apostrophes!
pgp0l67yvzSAT.pgp
Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
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: app-misc/dsgui app-misc/klavaro dev-cpp/yaml-cpp - neurogeek dev-libs/softhsm - mschiff dev-ruby/dnsruby - mschiff net-dns/opendnssec - mschiff net-libs/dslib net-libs/libisds net-misc/shigofumi sys-devel/autoconf-archive - binki I'll take autoconf-archive, unless if someone else wants it. -- binki Look out for missing or extraneous apostrophes! pgpkm8X0yZYdb.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH scons-utils] Support setting common SCons arguments using myesconsargs.
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 +# @DEFAULT_UNSET +# @DESCRIPTION: +# 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? -- binki Look out for missing or extraneous apostrophes! pgpmTz74q8J6p.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
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. -- binki Look out for missing or extraneous apostrophes! pgpKZ0WR9QjLJ.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
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) and http://lists.busybox.net/pipermail/busybox/2011-September/076710.html , 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 http://lists.busybox.net/pipermail/busybox/2011-September/07.html ). 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 kern.info kernel: [10714.105621] usb 2-8: new high speed USB device using ehci_hcd and address 4 Oct 9 13:46:00 e521 kern.info kernel: [10714.241353] usb 2-8: New USB device found, idVendor=13fe, idProduct=1e00 Oct 9 13:46:00 e521 kern.info kernel: [10714.241357] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 9 13:46:00 e521 kern.info kernel: [10714.241360] usb 2-8: Product: Patriot Memory Oct 9 13:46:00 e521 kern.info kernel: [10714.241362] usb 2-8: Manufacturer: Oct 9 13:46:00 e521 kern.info kernel: [10714.241364] usb 2-8: SerialNumber: 078215A302CF Oct 9 13:46:00 e521 kern.info kernel: [10714.244241] scsi4 : usb-storage 2-8:1.0 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 kern.info 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. -- binki Look out for missing or extraneous apostrophes! pgpnJRnFjxFhx.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due tanderson retirement
On Tue, Sep 13, 2011 at 08:31:33PM +0200, Pacho Ramos wrote: Due tanderson retirement the following packages need a new maintainer: dev-libs/check dev-libs/stfl net-libs/udns Thanks for taking them I'll take dev-libs/check. -- binki Look out for missing or extraneous apostrophes! pgpORS9uj637r.pgp Description: PGP signature
Re: [gentoo-dev] multilib setup
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? pgpxMyn3sgG7J.pgp Description: PGP signature
Re: [gentoo-dev] rfc: using /libexec
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. -- binki Look out for missing or extraneous apostrophes! pgpXx3dw6xtwx.pgp Description: PGP signature
Re: [gentoo-dev] Re: Implicit system dependencies
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 gtk+? * Checking app-arch/guitar-0.1.4 for undeclared dependencies * /usr/bin/guitar links to /usr/lib64/libX11.so.6 * Missing dependency on x11-libs/libX11 * /usr/bin/guitar links to /usr/lib64/libXi.so.6 * Missing dependency on x11-libs/libXi * /usr/bin/guitar links to /usr/lib64/libXext.so.6 * Missing dependency on x11-libs/libXext * /usr/bin/guitar links to /usr/lib64/libxcb.so.1 * Missing dependency on x11-libs/libxcb * /usr/bin/guitar links to /usr/lib64/libXau.so.6 * Missing dependency on x11-libs/libXau * /usr/bin/guitar links to /usr/lib64/libXdmcp.so.6 * 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: [libgtk-1.2.so.0] 0x0001 (NEEDED) Shared library: [libgdk-1.2.so.0] 0x0001 (NEEDED) Shared library: [libglib-1.2.so.0] 0x0001 (NEEDED) Shared library: [libc.so.6] ohnopublishing mnt # See that X11 is brought in by libgtk and recursively so on and so on: ohnopublishing mnt # readelf -d /usr/lib64/libgtk-1.2.so.0 | grep -e NEEDED 0x0001 (NEEDED) Shared library: [libgdk-1.2.so.0] 0x0001 (NEEDED) Shared library: [libgmodule-1.2.so.0] 0x0001 (NEEDED) Shared library: [libglib-1.2.so.0] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libX11.so.6] 0x0001 (NEEDED) Shared library: [libc.so.6] -- binki Look out for missing or extraneous apostrophes! pgpApRTbL3K8M.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
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 PORTDIR_OVERLAY. I sorta like how overlays work currently ;-). -- binki Look out for missing or extraneous apostrophes! pgpkfdJI7hpcw.pgp Description: PGP signature
Re: [gentoo-dev] demanual update (was: Don't use / when applying sed with CFLAGS)
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
append
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:
Makefile:
CFLAGS += `pkg-config --cflags libxml-2.0`
which would work fine for:
emake
but which would override the pkg-config flags if you do:
emake CFLAGS=${CFLAGS}
--
binki
pgpwm9rxY2Hpm.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Tags (Was: RFC: split up media-sound/ category)
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 ;-). -- binki Look out for missing or extraneous apostrophes! pgppM7Fwmn7oc.pgp Description: PGP signature
Re: [gentoo-dev] Tags (Was: RFC: split up media-sound/ category)
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: cat tagmedia/tag tagvideo/tag tagkde/tag tageditors/tag /cat I'm going to just interpret this as a suggestion for a modification to metadata.xml ;-). Could this not just be: tags tagkde/tag tageditors/tag /tags Then in the category's metadata.xml, at media-video/metdata.xml, you can fill in the rest: tags tagmedia/tag tagvideo/tag /tags 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. -- binki Look out for missing or extraneous apostrophes! pgpLKnm149XfM.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
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.
--
Peter.
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 ;-).
--
binki
Look out for missing or extraneous apostrophes!
pgpFCdFauEa5F.pgp
Description: PGP signature
[gentoo-dev] Last rites: net-irc/oer, net-irc/oer-mysql
# Nathan Phillip Brink bi...@gentoo.org (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. net-irc/oer net-irc/oer-mysql -- binki Look out for missing or extraneous apostrophes! pgpjv2stg0Rei.pgp Description: PGP signature
Re: [gentoo-dev] RDEPENDing on packages from overlays?
On Sat, Apr 23, 2011 at 04:02:24AM -0700, Zac Medico wrote: On 04/22/2011 11:05 PM, Eray Aslan wrote: https://bugs.gentoo.org/show_bug.cgi?id=364445 https://bugs.gentoo.org/show_bug.cgi?id=364401 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 tree. 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 resolution. 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 ahead. 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 effort. -- binki Look out for missing or extraneous apostrophes! pgpdfNCuOGFfn.pgp Description: PGP signature
Re: [gentoo-dev] Using Jabber for developer communication
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 ;-). -- binki Look out for missing apostrophes! pgpx2AnBlmLSZ.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla 4 migration
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 awa...@chopin.edu.pl 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 tes...@gentoo.org 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 damage. 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. -- binki Look out for missing apostrophes! pgpgNGileIJ7j.pgp Description: PGP signature
Re: [gentoo-dev] Packaging LSB symlinks for ld-linux.so
On Mon, Jan 31, 2011 at 04:14:47PM +0100, Vlastimil Babka wrote: Hi, when trying to bump sci-geosciences/googleearth to a 6 beta version [1], there's a problem with missing /lib/ld-lsb.so.3 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 ld-linux.so.2. 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 ld-linux.so.2 googleearth-bin, trying LD_LIBRARY_PATH overrides, putting ld-lsb.so.3 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: http://nixos.org/patchelf.html . [1] https://bugs.gentoo.org/show_bug.cgi?id=348911 -- binki Look out for missing apostrophes! pgphi2YyIZxvt.pgp Description: PGP signature
Re: [gentoo-dev] MULTI_ABI support addition to main tree portage
On Sat, Jan 29, 2011 at 06:03:10PM +0100, Pacho Ramos wrote:
Hello
I would like to know what is blocking this from landing main tree in
the near future, as I reviewed:
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg41737.html
and looks like there wasn't major problems (at least commented in this
thread)
There are still a number of known build failures, tracked in
https://bugs.gentoo.org/alias/portage-multilib . 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
ABI=x86
ARCH=amd64
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?
--
binki
Look out for missing apostrophes!
pgpRAKQKKTE2y.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Removing .la files
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 ebuilds). 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, libltdl.la, so I had to rebuild/reinstall libtool itself without that mask. This problem is found in an autoconf macro shipped with libtool itself: http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00023.html http://lists.gnu.org/archive/html/bug-libtool/2010-02/msg00046.html Likewise, portage-multilib is configured by default to install .la files for the libtool package to work around this bug. -- binki Look out for missing apostrophes! pgp7Pd7t5EKYh.pgp Description: PGP signature
Re: [gentoo-dev] Re: [funtoo] [bugzilla-daemon-abrp7r+bbdudnm+yrof...@public.gmane.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
On Wed, Jul 07, 2010 at 06:03:49PM -0600, Ryan Hill wrote: On Thu, 8 Jul 2010 00:56:52 +0200 Enrico Weigelt weig...@metux.de 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 fork. 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. ;-) -- binki Look out for missing or extraneous apostrophes! pgpEtPmtEqhNY.pgp Description: PGP signature
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
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 (ltdl.so supposedly needs those as I was told, no idea what for). IMO, ltdl.so is probably just being silly. Perhaps these files contain information that is useful on non-Linux systems for dlopen()ing plugins. 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 some apps. libtool loader (ltdl.so) 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? shouldnotlink=yes '' If shouldnotlink=no _and_ the .la file in question is not libltdl.la 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 :-). -- ohnobinki Look out for missing apostrophes! pgp6bbcLrjBko.pgp Description: PGP signature
