Re: [gentoo-dev] Dissolving project desktop-misc

2020-11-30 Thread Rémi Cardona

Le 29/11/2020 à 16:48, Andreas K. Hüttel a écrit :


I'm fairly certain this package cannot work with post-KMS kernel 
drivers, so anything after 2010 or so. And the laptops that sport this 
chip are probably all dead by now (mine is anyway).

I'd say, let's push this one to last-rite right away.



[gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND

2018-09-30 Thread Rémi Cardona
Le 01/10/2018 à 00:50, Mike Gilbert a écrit :
> update-desktop-database and update-mime-database are called from ROOT in
> pkg functions, so the related dependenices belong in RDEPEND.
> Signed-off-by: Mike Gilbert 

As far as the eclass goes, this is correct. But AFAIR, this was needed
because some packages look for those tools at build time. It was ages
ago so maybe it no longer applies.


Re: [gentoo-dev] Re: Reverted python3.4 defaults

2015-07-20 Thread Rémi Cardona
Le 19/07/2015 18:42, Ben de Groot a écrit :
 I would like to note that we only have around 50 packages that require
 python3, while the majority requires python2, and the remainder will
 function with either.

How far are we from building a python3-only stage3? Are there any major
blockers? Would any outside help be of use?


Re: [gentoo-dev] Re: [gentoo-dev-announce] Service relaunch:

2015-02-28 Thread Rémi Cardona
Le 26/02/2015 09:39, Markos Chandras a écrit :
 Excellent! Looks great. Thank you very much for your hard work

Seconded, this is a huge improvement over the old site.

Thanks to all involved, this is fantastic work!


Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

2015-01-19 Thread Rémi Cardona
Le 19/01/2015 23:40, Michał Górny a écrit :
 1. Compatibility. USE=ffmpeg is already used for || ( libav ffmpeg ) in
 a lot of packages. If we changed the meaning, libav users will end up
 switching '-ffmpeg libav' per-package. Ugly.
 2. Feature-oriented flags. USE=ffmpeg represents the generic feature,
 USE=libav is auxiliary implementation-switch flag. Well, maybe we could
 use, say, USE=avcodec to avoid ambiguity but that's a larger change.

I think our users are clever enough to update their USE flags as they wish.

USE=ffmpeg for FFmpeg support + USE=libav for libav support is simple
and easily understood. I'd much rather we went with that.



Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

2015-01-19 Thread Rémi Cardona
Why not :

libav? ( media-libs/libav:= )
ffmpeg? ( media-libs/ffmpeg:= )

+ REQUIRED_USE=^^ ( libav ffmpeg )

I for one would never expect USE=-libav to enable ffmpeg (nor
USE=-ffmpeg to enable libav FWIW).


Re: [gentoo-dev] Running repoman on the portage tree

2014-11-18 Thread Rémi Cardona
Le 19/11/2014 03:17, Alec Ten Harmsel a écrit :
 Hey devs,

Hi Alec,

 This is my first mail to this list. If this is out of line, let me know.

Not out of line on the topic/content, but try to avoid sending 3MB
attachments to hundreds (thousands?) of people.

 * 9233 ebuilds that use a deprecated EAPI

Unlike other distros where there's usually one version of a given
package (with the history being available in archives elsewhere), we
sometimes have dozens of available versions for a single package. When
new EAPIs come along, devs will usually improve their ebuilds when new
upstream versions are released and leave old ebuilds as-is (especially
if said ebuilds have stable keywords).

So while that number looks impressive, you need to factor in which
packages have ebuilds that use newer EAPIs. If you do come across
packages that only offer ebuilds written using deprecated EAPIs, then
I'm sure maintainers will accept contributions.



Re: [gentoo-dev] typo in scrypt USE-Flag

2014-11-02 Thread Rémi Cardona
Le 02/11/2014 17:48, Alex Xu a écrit :
 so... instead of emailing 4 people (three bug-wranglers plus one
 maintainer), you email around 300 people (assuming that subscriber count
 is around the same as #gentoo-dev users, which is probably a severe

Alex: no need for a snarky comment. A simple a bug is fine, please do
open one would have been enough.

Marco: thank you for your contribution, however small. Bugzilla is
indeed the proper place for any and all ebuild improvements.



Re: [gentoo-dev] packages masked for removal in 30 days

2014-05-23 Thread Rémi Cardona
Le vendredi 23 mai 2014 à 22:57 +0700, a écrit :
 # Google closed free usage of the translate api
 # Masked for removal in 30 days
 # openmcl has been renamed to clozurecl
 # Masked for removal in 30 days

This is worthy of gentoo-announce@g.o



Re: [gentoo-dev] Akamai secure memory allocator for OpenSSL?

2014-04-14 Thread Rémi Cardona
Le lundi 14 avril 2014 à 10:48 +0200, Tiziano Müller a écrit :
 Not really, no. I would rather wait until other people have reviewed
 and/or it has been pulled into openssl.
 To cite the Akamai dev who posted the patch [1]:
 Let me restate that: *do not just take this patch and put it into
 production without careful review.*

I, for one, am glad we didn't pull this in right away. OpenSSL is under
a lot of scrutiny now, so let's not rush any patches.



Re: [gentoo-dev] Maintainer-needed on many of my packages

2013-12-31 Thread Rémi Cardona
Le dimanche 29 décembre 2013 à 00:19 +, Robin H. Johnson a écrit :


Is this still remotely useful with KMS-enabled kernels ?



Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies

2013-11-07 Thread Rémi Cardona
Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit :
 in short: if a package requires version X then the ebuild should require
 version X; it can be forgotten but it's a bug.

That _is_ our policy. Ebuilds should - at the very least - mirror what
upstream's build script requires.

So, count my +1 there.


Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox

2013-08-24 Thread Rémi Cardona
Le mardi 20 août 2013 à 12:26 +0200, Michał Górny a écrit :
 3. FEATURES=ipc-sandbox
 Applies to: src_*
 This one separates the ebuild's *nix IPC stuff from host. This includes
 semaphores, shared memory etc. Similarly to network-sandbox, this could
 prevent ebuilds from communicating with some production servers.
 But honestly, I have no idea if anything really does it or relies on it.
 I doubt this could break something but it's worth testing.

This could impact ebuilds using the virtualx eclass, depending on how
the launched xvfb/xorg server is launched. It'd be interesting to test
the impact.

Other than that, it looks like really sweet stuff.



Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them

2013-07-27 Thread Rémi Cardona
Le vendredi 26 juillet 2013 à 21:19 -0700, Paweł Hajdan, Jr. a écrit :
  The real question is, how realistic can we make a process of testing and
  moving to stable?
 We have arch teams, we have users... when several users say it's OK I
 think it is OK. As compared to a script pushing it to the website just
 because it compiled.

How about a regular test livecds event? Kind of like a bug day. Seems
like it could also be a nice and easy way to reach potential new
contributers: just burn an ISO, reboot your computer, report back
whether network/disk access works.


Re: [gentoo-dev] Re: Packages up for grabs due lack of time

2013-02-18 Thread Rémi Cardona
Le dimanche 17 février 2013 à 22:47 -0600, Ryan Hill a écrit :
 Even after you do that it's hard to figure out what firmware files you 
 need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
 linux-firmware contains:
 Are these different versions?  Different cards?  Which do I need?

Good kernel modules *should* export needed firmwares as module
parameters. You *should* then be able to query it with modinfo:

modinfo module -F firmware

Note however that *lots* of modules (especially DVB, in my experience)
don't properly set those parameters and you're left grepping the source
code or dmesg to find which firmware you'll need...



Re: [gentoo-dev] Getting the general dev opinion (Meinungsbild) on some feature

2013-01-21 Thread Rémi Cardona
Hi Andreas,

Le dimanche 20 janvier 2013 à 16:20 +0100, Andreas K. Huettel a écrit :
 So, a thread like Should we enable useflag Z by default would then include
 Please discuss here, vote on ... with a link to the count page (updated via 
 cron every 1h). On login to ..., a message similar to the open elections 
 message could be displayed.
 Obviously the implementation does not exist, but this is conceptually simple 
 enough so it could be implemented within reasonable time. 

We (devs) participate in Gentoo in various ways and for very different
reasons. And those ways and reasons may change over time.

I, for one, no longer consider myself sufficiently informed about new
PM/EAPI features, various profile changes, etc. Though I'll gladly
update the few packages I maintain to whatever standard is expected,
I'll leave the discussion(/trolling?) to other better-informed folks as
I often have nothing of value to contribute in those areas.

In fact, I believe this to be exactly the Council's role and we already
have the necessary tools for that, including a yearly election. Council
members already represent Gentoo devs when tougher decisions need to be

So while I commend you for trying to collect everyone's opinion, I
believe it should *not* be necessary for you (or anyone else) to
organize elections or polls in order to implement new features or
changes to Gentoo.



Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

2012-11-28 Thread Rémi Cardona
Le mercredi 28 novembre 2012 à 22:49 +0100, Justin a écrit :
 Create them by hand.

The solution is to tell *upstream* how to build and ship .pc files with
their build system.

If we start shipping .pc files no one else has, projects that use such
libraries will have only 2 choices:

 - check the .pc file and use whatever fallback code they had before to
find the correct library paths and options.
 - change nothing and keep their current code

Either way, we'll be stuck maintaining .pc files no one will be using.

Please convince upstreams stuck in the middle ages that .pc files are a
Good Thing™ that make everybody's lives easier.



Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

2012-11-22 Thread Rémi Cardona
Le jeudi 22 novembre 2012 à 20:59 +0100, Michał Górny a écrit :

 You could say it's an algo like this:
 1) if you want phase functions for distutils  all other automagic,
use distutils-r1;
 2) if you don't want phase functions but want PYTHON_TARGETS and other
metadata stuff, use python-r1;
 3) if you don't want phase functions nor metadata, just some random
potentially useful functions, use python-utils-r1.

Please, pretty please: paste this blurb somewhere (near the top) in
*one* of the above three eclasses and modify the other 2 to point
developers to the former eclass.



Re: [gentoo-dev] The problem with new dev-python/argparse and REQUIRED_USE

2012-11-02 Thread Rémi Cardona
Le jeudi 01 novembre 2012 à 23:30 +0100, Michał Górny a écrit :
 Do you have any ideas how to solve that kind of stalemate?

How about a carefully crafted news item inviting users to enable the
latest python version and to emerge -C argparse afterwards?

We've already asked users to handle more complex upgrades themselves
using news items...



Re: [gentoo-dev] package graveyard

2011-08-17 Thread Rémi Cardona
Le 17/08/2011 21:57, Matthew Summers a écrit :
 +1 on this. It saves the ebuild for posterity AND prevents users
 hitting nasty bits. This seems to me to beg for a proper well-defined
 policy, in any case.

We already have a policy for this and it's called portage.

If a package is broken (and I mean with known ebuild issues, with known
bugs, etc), then we already have legitimate reasons to remove it.

If not, just let them be in portage.

If anything, working on tinderboxes to catch build issues early and file
bugs against packages, _that_ would help to clean up cruft from portage.


Re: [gentoo-dev] openrc-0.8.1 stable candidate

2011-04-13 Thread Rémi Cardona
Le 12/04/2011 16:56, William Hubbs a écrit :
 at long last, we have an openrc stable candidate.

Thanks to all of you who worked on this over the years, your efforts are
_really_ appreciated.

 This means we need more testers.

Openrc being so central to Gentoo, may I suggest a bigger campaign, on
planet gnome and other outlets?



Re: [gentoo-dev] FYI: USE=hal masked in base/use.mask and related

2011-03-27 Thread Rémi Cardona
Le 27/03/2011 10:36, Samuli Suominen a écrit :
 Also, both udisks and upower now have blockers for sys-apps/hal to
 prevent overlapping features.


I know you want to kill HAL with a vengeance. I don't disagree with the
ultimate goal but I think you've gone too far.

HAL and u{power,disks} are _perfectly_ parallel installable and there
are absolutely _no_ conflicts between the two.

Blockers should be used for _file_ conflicts, not for _feature_
conflicts, otherwise we'd have to mask and get rid of half (or even
more) of all the packages we provide in portage.

I urge to reconsider this blocker and mask.


Re: [gentoo-dev] rejecting unsigned commits

2011-03-24 Thread Rémi Cardona
Le 24/03/2011 22:59, Mike Frysinger a écrit :
 is there any reason we should allow people to commit unsigned
 Manifest's anymore ?  generating/posting/enabling a gpg key is
 ridiculously easy and there's really no excuse for a dev to not have
 done this already.

I, for one, have never signed my Manifests because I've always found
GnuPG to be a major PITA.

With that being said, I do understand the rationale of signing them and
I'll adapt.

However, is there a howto or something explaining how to work
_efficiently_ with GPG? How do I avoid having to type my pass-phrase for
every commit?



PS, wasn't manifest-signing supposed to become moot once we moved to git?

Re: [gentoo-dev] Re: libpng-1.5 smooth upgrade

2011-02-27 Thread Rémi Cardona
Le 26/02/2011 17:08, Enrico Weigelt a écrit :
 I could imagine a way like that:

Or we can do it like distributions always do (at least we do) :

1) find packages that don't work out of the box with libpng 1.5
2) work with upstream to fix them

Really, libpng15 is to libpng14 what gtk3 is to gtk2: a new library.
Let's treat it as such.


[gentoo-dev] Re: [gentoo-dev-announce] Stabilisation exceptions

2011-01-24 Thread Rémi Cardona
Le 24/01/2011 13:31, Christian Faulhammer a écrit :
 over the course of the years the x86 (and other architectures as well)
 has given away permissions to maintainers/teams to mark packages
 stable themselves.  As there never was a definitive list what
 exceptions exist, I compiled a list of the ones I could get from the
 top of my head in [1].  Please yell if you have those
 permissions so I can complete the list for reference purposes.

X11 has requested and was granted permission from all arch teams to
stabilize x11-misc/util-macros and all media-fonts/* (those that we are
responsible for anyhow).

There might be another 2 or 3 packages that I've forgotten but we rarely
modify them anyway...



Re: [gentoo-dev] Deprecate EAPIs 0 and 1?

2011-01-02 Thread Rémi Cardona
Le 31/12/2010 17:04, Brian Harring a écrit :
 Quick scan of the tree via `pinspect eapi_usage`, the percentile is
   eapi: '0' 13934 pkgs found, 50.43% of the repository
   eapi: '2' 8679 pkgs found, 31.41% of the repository
   eapi: '3' 4432 pkgs found, 16.04% of the repository
   eapi: '1' 583 pkgs found, 2.11% of the repository

Based on those stats, I would definitely deprecated EAPI 1 since it's
almost unused, and EAPI 2 since its behavior is really close to EAPI 3.

As others have mentioned, only for _new_ ebuilds.

My 2¢,


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-12-05 23h59 UTC

2010-12-05 Thread Rémi Cardona
Le 06/12/2010 01:25, Robin H. Johnson a écrit :
 media-libs/libresample2010-12-01 19:06:41 chainsaw
 media-libs/libresample2010-12-01 16:59:41 chainsaw

A glitch in the matrix?


Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-04 Thread Rémi Cardona
Le 04/10/2010 08:35, Michał Górny a écrit :
 On Mon, 04 Oct 2010 00:00:22 +0200
 Rémi Cardona wrote:
 #2a) pkg-config is one solution (what upstream Xorg says: if you
 want a static libX11, use pkg-config --static), other teams/herds
 could fix their packages' .pc files to correctly list all required
 packages for proper static linking. It's not rocket science.
 AFAIK more .pc files rather need fixing to list only direct
 dependencies when '--static' is not used. pkg-config itself takes care
 of the dependencies pretty well.

Right, either way, .pc files usually need a little tweaking as devs
rarely touch them unless something is really broken. Patching (in
accordance with upstream of course) may be required.

But it's definitely my preferred solution (and a cross-platform one at



Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-03 Thread Rémi Cardona
Le 03/10/2010 16:29, Luca Barbato a écrit :
 I think the simpler solution is that if it needs .la, before reaching
 the tree it has to be fixed...

Using libltdl (libtool's dlopen wrapper) is a *legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.

The discussion here is about random apps and libs, that install .la
files for no other reason that they were *built* using libtool.

Such programs will work just fine without .la files. The only risk is
breaking :

 1) building other packages (see the dbus bug)
 2) building *static* programs/libs

#1 can be fixed using lafilefixer which sanitizes .la files so that
they stop referencing other .la files.

#2 is harder :

#2a) pkg-config is one solution (what upstream Xorg says: if you want a
static libX11, use pkg-config --static), other teams/herds could fix
their packages' .pc files to correctly list all required packages for
proper static linking. It's not rocket science.

#2b) drop support for static linking altogether. It can make sense for
some packages, but definitely isn't suitable for the entire portage tree.

So again, these are the only 2 issues we should be addressing.



Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-02 Thread Rémi Cardona
Le 02/10/2010 21:54, Jorge Manuel B. S. Vicetto a écrit :
 With that goal in mind, I'd like to ask anyone with arguments about this
 issue to present them as a reply to this thread.

[putting on my X11 cap]

As far as X11 packages are concerned (libX11, libXext, cairo, etc), we
can remove .la files now since upstream only supports linking through
pkg-config (static linking included).

So X11 can remove them any time, I was just waiting for a flag-day to do it.



Re: [gentoo-dev] FYI: Rules for distro-friendly packages

2010-06-27 Thread Rémi Cardona
Le 26/06/2010 21:39, Enrico Weigelt a écrit :
 #2 One point i don't agree is the dont add -Werror rule. actually,
 i'm thinking of making -Wall and -Werror mandatory. if some
 package doenst build fine, it's simply broken. period.

You're obviously new here...

Just take a stroll through bugzilla to see how much we _fight_ against
-Werror. Let's see why you obviously have not thought through this
completely before writing this :

We currently offer 11 different slots of GCC, 3 of gcc-apple, each with
multiple versions, 3 versions of llvm-gcc, 2 versions of clang, 7
versions of icc, so in all 26 *major* versions. You do well know that
each compiler prints out different warnings for the *same* code...

We also offer 10 versions of glibc, 8 versions of uclibc, and 7 versions
of klibc. Each version may have header bugs, so may trigger warnings for
perfectly good code.

And finally we offer 5 unmasked versions of binutils (newer ones even
have a brand new linker - gold) and 5 versions of binutils-apple. Again,
different tools, different warnings...

If you want to make -Werror mandatory, you *MUST* test all combinations

Otherwise, packages will break for no good reason and users will hate us.

-Werror is a perfectly fine *developer* feature. For example, Gnome
autoconf macros enable it for development snapshots, but never ever
enable it for stable releases.

So please, if you want to write nonsense, don't write it in the name of


PS, Diego (flameeyes) is already having enough issues with his tinderbox
running *ONE* compiler/linker/libc combination...

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/traits: traits-3.4.0.ebuild

2010-06-10 Thread Rémi Cardona
Le 10/06/2010 22:45, Arfrever Frehtes Taifersar Arahesis a écrit :
 2010-06-10 22:20:44 Nirbheek Chauhan napisał(a):
 On Fri, Jun 11, 2010 at 1:30 AM, Arfrever Frehtes Taifersar Arahesis wrote:
 2010-06-10 21:27:40 Jeremy Olexa napisał(a):
 I see no reason to *not* add a ChangeLog entry here.

 ChangeLog entries are not required for trivial changes.

 A trivial change is fixing a typo, or a manifest problem, a missing
 quotation mark, etc. Anything else is not trivial.

 Anything that changes how an ebuild functions, what it does, or the
 installed files (and/or their contents) is NOT a trivial change.
 This commit only removed some compiler warnings.

Why argue about this? Just always add a ChangeLog entry, like everyone
else. This is in everyone's interest, including yours.



Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*

2010-06-06 Thread Rémi Cardona
Le 06/06/2010 02:08, Sebastian Pipping a écrit :
 can you explain how that happens?

Standard dependency resolution for packages with slots, there's nothing
specific about python.



Re: [gentoo-dev] autotools.eclass eautomake update

2010-05-25 Thread Rémi Cardona
Le 25/05/2010 00:17, Mike Frysinger a écrit :
 so prove me wrong and post some useful feedback on the change.  i'm
 simply being realistic.

Even if you think no one will ever comment on your patches, I've seen
enough projects where posting patches and doing reviews generated
interest and got people to contribute.

Unless you want to keep this eclass to yourself, posting patches is a
Good Thing (tm).

Maybe you should grep for AC_INIT_AUTOMAKE too, as that's what lots of
folks used a while ago.



Re: [gentoo-dev] autotools.eclass eautomake update

2010-05-25 Thread Rémi Cardona
Le 25/05/2010 09:23, Mike Frysinger a écrit :
 Even if you think no one will ever comment on your patches, I've seen
 enough projects where posting patches and doing reviews generated
 interest and got people to contribute.
 i'm just asking for proof that it's useful here

And I'm asking you to try it regardless of proof. Consider this a social

 no, because that isnt how autoreconf works today.  current behavior mimics 
 current autotools.

Makes sense, thanks for the explanation.



Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?

2010-05-15 Thread Rémi Cardona
Le 14/05/2010 14:45, Jorge Manuel B. S. Vicetto a écrit :
 Please share your thoughts on this so we can decide how to act on this case.

X11 team doesn't use it. While some of our users do come back and close
bugs as VERIFIED every now and then, it just doesn't mean anything in
the team's workflow.

As far as we're concerned, we could just prune it.



Re: [gentoo-dev] ccache causing problems

2010-04-29 Thread Rémi Cardona
Le 29/04/2010 09:06, Paweł Hajdan, Jr. a écrit :
 What actions would you suggest?

Don't use ccache. We (speaking as a former gnome herd member) have had
countless unexplained bugs due to ccache.

Now, the gnome procedure for build failures is to ask users to first
disable distcc and ccache before trying to reproduce the bug, and that
solves nearly all the weird issues that no-one else can reproduce.

Bottom line, unless you're building the same code over and over again,
don't use ccache. And even if you are, don't use it, its cache is just
too easily broken.



Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits

2010-04-27 Thread Rémi Cardona
Le 24/04/2010 19:40, Petteri Räty a écrit :
 What do you think about not allowing commits to eclasses without
 mentioning an another developer who has reviewed and approved the diff
 in the commit message? There's enough people on gentoo-dev for urgent
 stuff too.

More bureaucracy and policies when we arguably have enough (or even too
much...?) My vote is a clear and resounding *no*.

If someone f*cks up, revert the commit if the issue isn't fixed quickly.

If that someone f*cks up again, call devrel on his ass.

If anything, we should be working on versionned eclasses rather than VCS

My 2 euro cents.



Re: [gentoo-dev] Policy regarding the inactive members

2010-04-11 Thread Rémi Cardona
Le 11/04/2010 15:16, Markos Chandras a écrit :
 How about the participation to the discussions which took place every
 day on our mailing lists or in IRC?

I, for one, am actually glad that the council (as such) isn't involved
in every troll fest we have on -dev, and I hope we keep it that way.

 I guess not since we need to
 explicitly bring each issue to the meeting so council can talk about it.

That's the whole point of the council (as I understand it): they only
come in when there are issues that we (non-council devs) can't solve on
our own.

Why bother them with stuff that doesn't really concern them?



Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?

2010-04-05 Thread Rémi Cardona
Le 03/04/2010 11:50, Petteri Räty a écrit :
 I don't think later is valid resolution. If there's a valid bug it just
 means it's never looked at again. If the bug is not valid then a
 different resolution should be used. So what do you think about
 disabling later? I would like to avoid things like this:
 Not applicable to the bug above but in general our social contract says:
 We will not hide problems

You're basically blaming LATER and other resolutions for users failing
to *search* correctly.

How about changing how users search instead?

Let's make the small search box search for ALL bugs instead of just
opened ones. *That* should help tremendously.

That, and what Mart suggested. That's a good idea too.



Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-03-07 Thread Rémi Cardona
Le 01/03/2010 11:38, Samuli Suominen a écrit :
 I'd prefer EAUTORECONF (as it's already used in xfconf.eclass for the
 same purpose, and has no reason to differ) or even SNAPSHOT, but XORG_
 prefix seems redudant

We decided to put the prefix to make things clearer for ebuild writers
and to make the eclass variables consistent. The 5 extra chars are worth it.

Besides, this option isn't used a lot, so it won't clutter up portage
too much ;)



Re: [gentoo-dev] Calling unknown commands in an ebuild

2010-02-07 Thread Rémi Cardona
Le 08/02/2010 03:24, Mike Frysinger a écrit :
 if we wanted to specifically target semi-common errors (and i think 'epatch' 
 w/out eutils.eclass falls into this category), then a repoman check would be 
 it might also be useful to add a default epatch() to the initial env that 
 would be clobbered when the inherit occurred.
   epatch() { die you need to inherit eutils.eclass to use epatch ; }

+1, that's a very good idea! I've stopped counting how many times that's
happened to me.

I'm sure there are other common mistakes we all do, but this particular
one is a low-hanging fruit.



[gentoo-dev] Re: removal news item for =eselect-opengl-1.1.1-r2 going stable

2010-01-18 Thread Rémi Cardona
Le 17/01/2010 12:26, Tomáš Chvátal a écrit :
 Howdy guys,
 please review the attached file and suggest updates to in.
 I was asked for this thing going stable due to its being dependency of
 new nvidia-drivers.
 Also this thing is probably blocker for the bug on eselect-opengl i just

I'm not a big fan of the wording but it's something we refine, the
general idea is fine though.

I'll try to come up with something soon. If not, it can still be posted
as-is, it gets the point across.



Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-29 Thread Rémi Cardona
Le 29/12/2009 14:43, Henry Gebhardt a écrit :
 4) add a USE-flag, say devel, that, when enabled, allows
 compiling programs against the package. x11-libs/libXtst would
 have an RDEPEND like this:
 RDEPEND=devel? x11-libs/inputproto

This doesn't solve anything. It will just annoy users as they will have
to enable USE=devel.

So it's like the current situation, only way more annoying...


Re: [gentoo-dev] Non-free software in Gentoo

2009-12-28 Thread Rémi Cardona
Le 28/12/2009 06:36, Vincent Launchbury a écrit :
 I recently emailed the Gentoo PR team, voicing my concerns about the
 amount of non-free software within Gentoo. I got an interesting response
 from Sebastian Pipping, who said that while Gentoo is all about choice,
 including the choice to install non-free software, the project is
 interested in making it easy for people to run a 100% free system,
 should they choose that path.

Gentoo - like the rest of Free and Open Source Software - isn't about
choice, it's about empowering users.

Gentoo gives you tools and documentation to do whatever you wish. It
doesn't mean that we (Gentoo) _have_ to support it.

With that out of the way, moving on to the rest of the mail.

 1) Not all of the licenses are completely accurate. For example, the
 Linux kernels are listed as soley GPL-2, yet they contain blobs of
 non-free firmware.

Indeed, that's a very good point. And that's precisely why I was against
ACCEPT_LICENSE to begin with.

It's a good idea on paper, but it's just not feasible at a large scale
(like portage) without a proper _team_ of devoted people sifting through
code and license blobs to make it useful. I'm also pretty sure a couple
lawyers would be needed as well.

Unless people dedicate time and effort, ACCEPT_LICENSE is useless.


The rest of your points are indeed all valid as well.

I can only encourage you to either work with individual developers to
get ebuilds fixed (USE=bindist or whatever) or join our ranks to fix
this yourself if you really want a pure Free Gentoo.

 This is my first post here, so I apologize if it's misdirected. I'm not
 sure if I'd really be able to help much on the technical side, but if
 this garners any cooperation, I'll gladly help out with anything I can.
 If someone could point me in the right direction, I'd be very grateful.

I'd say this is probably better suited for gentoo-project, but it's
probably ok to start here, to gauge interest :)

Best of luck


Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread Rémi Cardona
Le 28/12/2009 10:10, a écrit :
 List of Gentoo bugs:


Others and myself have spent considerable time making those deps the way
they are because :

1) upstream packaging is a bit uncommon
2) ebuild deps don't fit with upstream deps
3) a few embedded devs told me they wiped /usr/include when making images

So if you want to fix this properly, a new DEP variable needs to be
cooked up : add the following deps to ebuilds' DEPEND when those ebuids
DEPEND on this ebuild.

Until such a variable exist, having the protos in both DEPEND and
RDEPEND is the only _valid_ solution.



Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread Rémi Cardona
Le 28/12/2009 22:04, Fabio Erculiani a écrit :
 On Mon, Dec 28, 2009 at 9:51 PM, David Leverton wrote:
 On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote:
 What all this has to do with the fact that they are just build
 dependencies? Just wondering.

 They're not just build dependencies.  They're required to use the library in 
 certain way, namely to compile other programs against it.  As long as we
 don't have compile-against dependencies, the only correct way to express that
 is RDEPEND (and also DEPEND because they're /also/ needed to build the
 library itself).
 To me you are saying that DEPEND would work just fine. No?

No, but I understand why you're insisting. It took us a few weeks to
wrap our heads around this to understand it.

Let's take an example (bug #228211 but there are dozens more).

In this example, libfakekey does : #include XTest.h

and its checks for xtst.pc. Both files are provided by
x11-libs/libXtst so this dep is added to DEPEND and RDEPEND.

The problem comes from libXtst's XTest.h which #includes XInput.h
which was provided by x11-proto/inputproto [1].

inputproto is/was a build-time dep of libXtst.
 - libXtst _directly_ requires inputproto at build-time only
 - libXtst _directly_ requires libXi at build-time and run-time

However :
 - requiring libXtst at build-time _also_ requires inputproto.

For most users out there, this would never be a problem since most
Gentoo users always keep build-time deps on their systems.

The problem arises for people who only keep run-time deps, usually for
binary packages. inputproto being a DEPEND-only dep of libXtst, binary
users will never get inputproto when they build libfakekey.

So there were 3 solutions :

1) add explicit deps in _all_ packages that DEPEND on libXtst to _also_
depend on inputproto even if they don't use it at all (most don't, they
just use XTest functions).

2) add inputproto to libXtst's DEPEND and RDEPEND

3) modify EAPI to add a new *DEPEND variable to cater X's very special

Solution #1 is error prone. If we fix ebuilds now, new ebuilds might
pop up later with broken dependencies. No go.

Solution #3 really isn't for me. I tried getting near PMS and I got bit.
If anyone wants to do this, I'll help, but I won't do this on my own.

So we went with solution #2. Yes, it does add nasty little headers on a
binary distribution, but that was a far better compromise than any of
the other 2 solutions.

Really, the correct solution (please _listen_ and _trust_ me on this) is
to add a new dependency variable to EAPI to correctly describe how X
headers and libs really work. That's solution #3. I agree with you,
pulling protos in both DEPEND and RDEPEND is a hack, but it's *much*
better than the other alternatives.


[1] This file is now part of libXi, but the problem has now shifted to
XI.h, so it's still going to be the exact same problem today, but for
the sake of simplicity, I'll keep it short.

Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread Rémi Cardona
Le 28/12/2009 23:53, Fabio Erculiani a écrit :
 Interesting, eventually somebody gave me a detailed and technical
 explanation without [bla bla snip]. Thanks Rémi.
 Yes, I agree with you that the best (and the one I would go for, too)
 solution is adding support to a new *DEPEND, perhaps one that could
 host build-deps only. It looks weird that other PMs out there do
 that since 1994 (replace 1994 with older value).
 Perhaps adding a big fat # XXX somewhere in ebuilds would have helped
 us all in saving some time today.

We could indeed, but back then we had something like 20~30 dupes so it
felt like an obvious fix. I'll start adding comments in the overlay to
clear it up.

 So, at least for now, I suspect I have to give up and close my shiny
 27 bugs. Right?

I'm afraid so, yes :)

But if you do want to tackle the EAPI/PMS issue, feel free to reuse the
tracker for that. I'll gladly tune in for that discussion.



Re: [gentoo-dev] metdata.dtd should require herd/

2009-12-16 Thread Rémi Cardona

Le 15/12/2009 16:19, Peter Volkov a écrit :

we will force all metadata.xml files have strict order of tags: first
herd/  then other tags. Currently there are about 200 ebuilds with
different order .

Others and I actually make use of the order in metadata.xml. The first 
entry is the one that will get bugs assignment in bugzilla, and the 
others will get CCed.

So if we're really going with herds first in metadata.xml, could we have 
an optional attribute - or whatever else you see fit - to convey that 
_this_ herd/maintainer is the main herd/maintainer?



Re: [gentoo-dev] Re: QA last rites for x11-wm/ion

2009-12-15 Thread Rémi Cardona

Le 15/12/2009 08:09, Ulrich Mueller a écrit :

On Tue, 15 Dec 2009, Peter Hjalmarsson wrote:

On the other hand this may be something for treecleaners? A package
that has not been bumped for 7 years? With at least three releases
since, and a bumprequest open for at least one year? A link to a
webside that does not exist?

And both its sucessors x11-wm/ion2 and x11-wm/ion3 already punted two
years ago.

Wasn't there some licence issue with this package, too?

That was with ion3 IIRC. Something about the author changing the license 
from GPL to don't patch ion3 ever without telling me about it and 
showing me your patches so I can approve them.

Or something similar, wikipedia/google might know more than me.

As far as the original ion is concerned, the masking seems perfectly in 
order. If someone wants it, that person can step up and do the work 
(directly or via proxy).



[gentoo-dev] X license cleaning spree

2009-12-15 Thread Rémi Cardona

Dear all,

I've started working on one of my to-do items that is usually very 
low-priority : cleaning up X-related licenses in portage.

This is one of the last remains of the Xorg split from a few years ago. 
X being a big hairy mess, those who managed the transition a few years 
ago decided that each X package would have its own license file. Not 
being a lawyer myself, I very much understand why they made that choice.

Now that the very few legal issues surrounding Xorg have been ironed 
out, we can safely clean up all those license files into one : MIT.

So here's the list of license that I'm planning on killing because they 
are - word for word - identical to MIT :


And here's a list of packages that use one or more of these licenses. 
Please let me know if/when you've fixed them. I'll open bugs next week 
for the remaining packages, and I'll just fix the rest myself within a 


Help will be most appreciated :)



Re: [gentoo-dev] X license cleaning spree

2009-12-15 Thread Rémi Cardona

Le 15/12/2009 10:35, Ulrich Mueller a écrit :

On Tue, 15 Dec 2009, Rémi Cardona wrote:

And here's a list of packages that use one or more of these licenses.
Please let me know if/when you've fixed them.



Thanks :)

[gentoo-dev] Last rites: x11-apps/{ttmkfdir,xfs,xfsinfo}

2009-12-14 Thread Rémi Cardona

# Rémi Cardona (13 Dec 2009)
# ttmkfdir had multiple QA issues and bugs (bugs #209616, #235354 and 

# xfs is completely useless, even on thin clients
# and xfsinfo is useless if xfs goes



Re: [gentoo-dev] ACCEPT_KEYWORDS=~amd64 emerge -avDNut world

2009-12-10 Thread Rémi Cardona

Le 10/12/2009 17:22, Samuli Suominen a écrit :

In perfect world ~amd64 shouldn't be much different from amd64, so
here's a list generated from up-to-date system (stable chroot) from today.

If you maintain some of these packages, and it could go stable, please
open a stablereq for it. :-)

If you don't find this information useful, just move on... no need to
reply. Thanks! ;-)

The X packages will be handled, as always, with a proper stabilization 

Cheers :)


Re: [gentoo-dev] openrc stabilization todo

2009-12-04 Thread Rémi Cardona

Le 04/12/2009 11:41, Mike Frysinger a écrit :

On Wednesday 02 December 2009 20:22:07 Jeremy Olexa wrote:

Can parallel init script startup be made the default yet? I've been
running with it for months and never noticed a problem..

not for stable.  no point in proactively shooting our conservative users in
the face.  let's shoot the unstable ricers first.

Sounds like a good first step. +1 from me.


Re: [gentoo-dev] openrc stabilization todo

2009-12-03 Thread Rémi Cardona

Le 03/12/2009 02:22, Jeremy Olexa a écrit :

Can parallel init script startup be made the default yet? I've been
running with it for months and never noticed a problem..

I've been running it for more than a year on half a dozen boxes, without 
any issues as well.

+1 for making it the default.


Re: [gentoo-dev] Deprecated eclasses

2009-11-30 Thread Rémi Cardona

Le 30/11/2009 05:26, Jonathan Callen a écrit :


ACK on this one, Gilles and I have been meaning to remove it a long time 

Thanks for cleaning it all up :)


Re: [gentoo-dev] global USE flag description change: css

2009-11-15 Thread Rémi Cardona

Le 15/11/2009 00:16, Doug Goldstein a écrit :

The css USE flag currently says:

Enables ripping of encrypted DVDs

But that really doesn't describe the usage correctly. It enables the
ability to READ encrypted DVDs. I'm going to make the change if no one

+1, makes perfect sense.


[gentoo-dev] Last rites: xf86-video-imstt and xf86-video-vermilion

2009-11-15 Thread Rémi Cardona

# Rémi Cardona (15 Nov 2009)
# Broken since xorg-server 1.5 stabilization
# see bugs #248529 and #248531
# Masked for removal in 7 days

'nuff said :)


Re: [gentoo-dev] QA is unimportant?

2009-11-10 Thread Rémi Cardona

Le 09/11/2009 17:30, Patrick Lauer a écrit :

Ok, here's the real problem;

Unmaintained stuff is unmaintained


Just piping in to say that dropping a package from portage isn't the end 
of the world, we have a very good process for it and it has proven to be 
very effective.

Dead packages should be masked :

1) it tells users that no-one among us devs really care about the 
package. And it's good because we're not lying or pretending to care. I 
think it's honest of us to admit that some packages are abandoned. Users 
deserve to know.

2) it sends a crystal-clear message that this package is up for grabs, 
either by another dev or by a user with a proxy-maintainer. This is yet 
another good thing because it might encourage users to join our ranks.

3) it allows to effectively clear out cruft, and $deity knows portage is 
full of it. Faster sync times, fewer security risks, etc.

So while of course we're not going to p.mask perl because its sole 
maintainer has decided to stop working on it, but for _less_ _important_ 
packages, masking and treecleaning is a *good* thing.

And besides, the beauty of CVS is that deleted files are never really 
gone, so a deleted package can be brought back from the dead in a few 

So really, don't feel obliged to touch/bump/fix all unmaintained 
packages, fix those that you use and treeclean the rest. It'll be for 
the best.



Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME

2009-10-26 Thread Rémi Cardona

Le 24/10/2009 15:42, Maciej Mrozowski a écrit :

If you have any comments, suggestions, important notices regarding this
change, please keep discussion in gentoo-desktop mailing list.

IMHO, we shouldn't even have desktop/server subprofiles to begin with.

I've always considered Gentoo to be an opt-in distro where after a 
successful install, you end up with a bash prompt and a _means_ of 
installing new packages.

Finding out what USE flags mean and do is part of the Gentoo experience. 
If we were doing spin-off distros like Ubuntu and Fedora do, then 
subprofiles would be fine, but we're not.

So with my X hat on, I won't be adding any X subprofile.

And with my (former?) Gnome hat on, I vote against any gnome subprofile.



Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME

2009-10-26 Thread Rémi Cardona

Le 26/10/2009 22:58, Richard Freeman a écrit :

Gentoo is about choice.

No it isn't. Gentoo is about empowering users, giving them the ability 
and tools to _change_ the distro to _their_ needs.

Gentoo does _not_ cater to all the possible needs.

This is somewhat off-topic, but it irks me every time I see/hear it, so 



Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

2009-10-16 Thread Rémi Cardona

Hi Daniel,

Le 17/10/2009 01:29, Daniel Bradshaw a écrit :

So as I say, it occurs to me that most people probably follow some
variation of this selective upgrade method.
It might be handy to have some kind of metadata in the ebuilds that can be
used to indicate a package that is demanding.
Then that flag could be used to highlight the package on a dep tree, or
optionally to block the emerge unless the package is specified explicitly.

IMHO, we already have the infrastructure for such info. We have elog and 
news items.

Now we (gentoo devs) are finally starting to add news items for bigger 
updates (gnome, X, java, etc) and that's a good thing. But we definitely 
cannot and should not use news items for minor upgrades.

elog is much better suited for such upgrade notices.

However, since elog was put in portage, ebuilds have been using 
elog/ewarn/einfo _way_ too much. We're now at a point where the elog 
output at the end of an emerge phase is just _useless_ because of all 
the noise.

And with your metadata proposal, I'm worried the same thing will happen. 
Devs will enable the troublesome flag for a release, forget to remove 
it for the next bump and a few months later, half the packages in 
portage are labeled as such.

I really don't want to sound like I want to kill your idea but I'm 
somewhat doubtful it'll really work given our track record with other 
such infrastructure.

Cheers :)


Re: [gentoo-dev] News Item: GNOME 2.26 upgrade

2009-10-06 Thread Rémi Cardona

Le 06/10/2009 13:02, Mart Raudsepp a écrit :

On T, 2009-10-06 at 02:11 +0300, Mart Raudsepp wrote:


See attached news item for consideration.
Suggestions on how to improve it, including the text section, very

Attached is a tweaked version with wording fixes from dabbott and author
as me instead of team, as I understood to be more appropriate.

I will probably wait for further reviews for a couple hours and then
commit this and proceed with CCing arch teams for the stabilization

not handle the desktop. = not handle the desktop's background image

But even without this change

Reviewed-by: Rémi Cardona


Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-02 Thread Rémi Cardona

Thanks for the wording, I've somewhat made it a bit stronger.

@Dev, please ACK or NAK or whatever.


Title: Migration to Server 1.6 and libxcb 1.4
Author: Remi Cardona
Content-Type: text/plain
Posted: 2009-10-02
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: x11-base/xorg-server-1.6
Display-If-Installed: x11-libs/libxcb-1.4

We're pleased to announce the stabilization of xorg-server-1.6. Users 
are strongly encouraged to read the following two guides before upgrading:

Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-02 Thread Rémi Cardona

Le 02/10/2009 09:43, Ulrich Mueller a écrit :

On Fri, 02 Oct 2009, Rémi Cardona wrote:

We're pleased to announce the stabilization of xorg-server-1.6. Users
are strongly encouraged to read the following two guides before upgrading:

GLEP 42 says that you should wrap lines at 72 columns, where possible.

And apart from the wrapping?

Nothing else to add?



Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-02 Thread Rémi Cardona

Le 02/10/2009 10:22, Petteri Räty a écrit :

Thus, at least 72 hours before a proposed news item is committed, it
must be posted to the gentoo-dev mailing list and Cc:ed to
(exceptions may be made in exceptional circumstances). Any complaints —
for example regarding wording, clarity or accuracy — must be addressed
before the news item goes live. hasn't been CC:ed as far as I see.

Josh now has commented on it.

May I request a faster commit time since I didn't expect Samuli to 
stabilize everything so quickly?


[gentoo-dev] Xorg 1.6/libxcb 1.4 stabilization news item

2009-10-01 Thread Rémi Cardona

Hi guys,

Could anyone write up a one-liner news item for the xorg-server 1.6 
stabilization with there 2 upgrade guides :

I tried figuring out how to write one myself, but failed miserably 
because of the entirely non-intuitive GLEP.

Basically, all stable users should see that news item.

Thanks in advance to the benevolent soul who will write it and commit it :)


[gentoo-dev] Last rites: dev-python/pyxf86config and dev-python/rhpxl

2009-09-24 Thread Rémi Cardona
# Rémi Cardona (24 Sep 2009)
# Both require xorg-server's libxf86config library which is busted
# and they both have no maintainer. See bug #222683
# Masked for removal in 30 days



[gentoo-dev] Last rites: opengl-manpages, xorg-docs, xorg-sgml-doctools

2009-09-22 Thread Rémi Cardona

# Rémi Cardona (19 Sep 2009)
# Outdated and useless X doc packages
# Masked for removal in 30 days

Before anyone asks, opengl-manpages is a snapshot for Dec '00. The 
online documentation at is much much more up-to-date.



Re: [gentoo-dev] EAPI and system packages

2009-09-20 Thread Rémi Cardona

Le 20/09/2009 02:31, Ryan Hill a écrit :

If not, when can
we drop support for old EAPIs?  Your opinions please.

Let's drop it now. We've waited long enough. Portage with EAPI=2 has 
been stable for more than a year.


Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)

2009-09-06 Thread Rémi Cardona

Le 06/09/2009 02:34, Thomas Anderson a écrit :

Ciaran's really not making homework up for gentoo. Why, remi stated himself that
we have homework to do(and we sometimes don't do that homework)

I did, but I also stated upstream might have some homework to do 
themselves. Here's a list of things that  :

 - COPYING automagically copied by automake (that would make the file 
be GPL-2+ or GPL-3+)

 - code stolen from other projects under a non-compatible/viral license
 - bundled libraries
 - code that's so old, no-one really knows what the original license 
(XFree86/Xorg) is or who the copyright holders are (Mozilla)

And I haven't even had my morning coffee yet.

Even if _we_ do our homework, all those reasons above might mislead us 
into thinking a package has license ABC, while in fact it's under 
license ABC+ and XYZ.

I don't see how a new EAPI will help us with all the aforementioned 
issues. And for the proposed LICENSE sets to work correctly, the whole 
tree needs to be audited, and each new _version_ of each package needs 
to be rigorously checked if we want to provide something users can _trust_.



Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash

2009-09-05 Thread Rémi Cardona

Le 05/09/2009 11:25, Duncan a écrit :

This is off-topic for gentoo-dev. Please continue this discussion in 



Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)

2009-09-04 Thread Rémi Cardona

Le 03/09/2009 23:27, Mounir Lamouri a écrit :

But the content of the license is the same. That only means you can use
a newer one.
I mean we do not need a new license file for that. It's up to upstream
to write somewhere if it's GPL-2 or GPL-2+, am I right ?

Yes, that's for upstream to figure out. For instance, the kernel is 
GPL-2 only while some other pacakges are 2+.

I don't want to sound like an ass, but that's why I think we shouldn't 
bother too much with LICENSE and all that stuff.

We're not _lawyers_. None of us can guarantee that :
1) the LICENSE field in our ebuilds are correctly set according to what 
upstream says.
2) that the actual code of the package is indeed under that license and 
not tainted by some other code.

For instance, I'm still working on migrating all the X11 packages to the 
MIT license (mainly for cleaning purposes), but in fact, each and 
every package should have its own license file (like today) because the 
MIT license requires that we acknowledge all major contributions to the 
code. Therefore, using a template like ${PORTAGE}/licences/MIT does is 
probably not a good idea from a legal point of view.

And the X code being over 15 years old, only God knows who we should be 
thanking for this million lines of code.

While you're idea is very nice on paper, actually doing it requires much 
_much_ more work than just adding operators and sets to portage.


Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)

2009-09-04 Thread Rémi Cardona

Le 04/09/2009 20:52, David Leverton a écrit :

Is that really a problem?

To me, it's not. :)

 I admit to not being around for the original design
decisions, but I would assume that the purpose of having LICENSE in ebuilds
is to tell users what licence the package is under (whether or not it's
accurate is a different matter), and the purpose of having the licences
themselves in the tree is so that it's easy for users to look them up and
decide whether they want to accept the conditions or not.  For that purpose,
the exact list of credits is irrelevant.

That was just an example to show that unless we go through a precise and 
thorough audit of all the packages we offer, the LICENSE variable is 
_informational_ at best.

Having tools to manipulate those variables is very misleading since 
users will (rightfully) assume that we've done our homework and that 
upstream did too.

I don't intend to stop anyone from creating new tools, but I just want 
us all to realize the limits of what is being done here.



[gentoo-dev] Last rites: www-plugins/gnash

2009-09-04 Thread Rémi Cardona

# Rémi Cardona (04 Sep 2009)
# Masked for removal in 60 days, old and unmaintained in Gentoo
# Uses removed VIDEO_CARDS flag (see bug #282981)



[gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash

2009-09-04 Thread Rémi Cardona

Le 04/09/2009 22:41, Andrew John Hughes a écrit :

So there'll be no Free Flash support in Gentoo any more?
I hope someone will pick this up, this is a high priority FSF project after all.

There's media-libs/swfdec that's still offically maintained by the Gnome 

As far as gnash is concerned, it can still be saved by a willing 
maintainer. Nothing more, nothing less.



Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)

2009-09-03 Thread Rémi Cardona

Le 03/09/2009 23:10, Mounir Lamouri a écrit :

Duncan wrote:

Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted:

However I do notice that GPL-2+ could make things easier. Why not
introduce a license group for it like @GPL-2+ or so, instead? That would
be transparent and use existing means.

I've always thought Gentoo needed plus versions of the versioned
licenses, anyway.  GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be
different licenses, because really, they are.

AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about that ?

GPL-2+ means GPL-2 GPL-3 GPL-4 ...

Not quite the same thing as just GPL-2


Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)

2009-08-31 Thread Rémi Cardona

Le 01/09/2009 00:12, Mounir Lamouri a écrit :


As you should know, GLEP 23 [1] introduced USE flags conditions in
LICENSE variable and || operator in addition of licenses groups and


/me still thinks LICENSE should be informational _at_best_. Users who 
rely on LICENSE to build an FSF-approved system will simply be mislead.

If we want to support this sort of things properly, we should have a 
treewide license audit. Anything short of that will just be a disservice 
to our users.



Re: [gentoo-dev] New 10.0 LiveDVD release enhancements

2009-08-23 Thread Rémi Cardona

Le 23/08/2009 11:02, Chip Parker a écrit :

On Sun, Aug 23, 2009 at 12:07 AM, Alexey  wrote:

Hi all!

Also i think it wil be good idea to include parted into liveDVD since
its only tool that support gpt partition tables =)

+1 On this one. Since parted comes with partprobe, which is really
nice when you want to change the partition tables on a live box.

Will one of you file a bug assigned to the relevant team? (probably releng).

Feature requests are handled through bugzilla. -dev is most just a black 
hole for this sort of things.


Re: [gentoo-dev] New global USE flag mp4

2009-08-21 Thread Rémi Cardona

Samuli Suominen a écrit :

description: Support for MP4 container format

[+ C  ] mp4 (media-sound/amarok):
Build the TagLib plugin for writing tags in Mp4 container files (m4a).
Please note that by enabling this USE flag, the resulting package will
not be redistributable, as it links to media-libs/libmp4v2, distributed
under a GPL-incompatible license.

amarok could have USE=bindist too, couldn't it?


Re: [gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles

2009-08-19 Thread Rémi Cardona

Paul de Vrieze a écrit :

As a service to users, you might want to create an empty library:

touch foo.c
gcc -shared foo.c -o

That's all

Like Samuli said, it's a hack and doing that would be wrong. I will not 
trade short-term peace of mind for a long term hell for whoever will be 
maintaining X after me.

Just like the expat soname change, we have to remove the band-aids at 
some point, even if it hurts.


Re: [gentoo-dev] Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

2009-08-18 Thread Rémi Cardona

Le 18/08/2009 03:30, Steven J Long a écrit :


This thread was dead for more than 4 days. Yet you pick it up and you 
try to pick a fight with Ciaran.

I for one am tired of your behavior on this list and I will not hesitate 
to contact UserRel to get you out of this list if you don't settle down 
and start acting like an adult.

Now step away from this thread.



[gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles

2009-08-18 Thread Rémi Cardona

Hi all,

Just a quick heads up that I have just unmasked x11-libs/libxcb-1.4 and 
its companion libraries in all profiles _except_ 2008.0.

As some of you have already found out, since 1.2, libxcb stopped 
shipping a very specific library: This library was only 
ever meant to be used internally by libX11, but due to libtool's 
infamous .la files, the removal of this library may cause some headaches 
during the upgrade.

Here are a few steps to fix the breakage :

1) make sure that /usr/lib/libxcb-xlib.* are gone. Portage 2.2_rc* users 
_should_ remove it as well.

2) run /usr/portage/x11-libs/libxcb/files/ to fix .la 
files. If the tool reports broken packages, please read on. If not, 
lucky you, your system is ready to go :)

3) run the following one liner to rebuild a simple, yet effective, 
subset of potentially broken packages. Do not worry, packages you don't 
have installed will not be installed.

emerge --oneshot --nodeps \
$(for i in x11-proto/ x11-libs/libxcb x11-libs/libX11 x11-libs/libXext \
   x11-libs/libX x11-libs/xcb-util x11-libs/cairo \
   x11-libs/pango x11-libs/gtk+ gnome-base/libgnomeui \
   x11-libs/qt-gui; do \
qlist -IC $i; \
done) -pv

4) use revdep-rebuild (from app-portage/gentoolkit) to finish fixing the 
rest of your system.

I hope those instructions are clear enough. If not, please don't 
hesitate to let me know.

Oh and if someone with sufficient guidexml skills could xmlify these 
instructions, I would be very thankful :)

Thanks for reading this.


Re: [gentoo-dev] Last rites: 14 X input drivers

2009-07-14 Thread Rémi Cardona

Le 13/07/2009 19:22, Robert Buchholz a écrit :

We're using the x11-drivers/xf86-input-microtouch for a cash register.
It works fine, but I think the machine is still on Xorg Server 1.3.

I don't have the capacity to maintain this driver myself, but it seems
bug #276615 has a patch, so I wonder why it needs to be abandoned. Whom
exactly shall I contact upstream about the deprecation?

Well, to start off, you might want to check if your hardware is now 
supported directly by the kernel. If that's the case, then you can use 
xf86-input-evdev which will make your life much easier.

But TBH, I really don't know much about writing X drivers. All I can 
offer is to commit patches upstream and maybe make tarballs.

My suggestion for now is to create a - ebuild of the microtouch 
driver inside the x11 overlay and make it point to the latest commit 
that has a chance of working: before the one that adds the AC_MSG().

If that doesn't work, you might want to get in touch with upstream X 
people via the xorg or xorg-devel mailing lists (resp. at and

Hope that helps


[gentoo-dev] Last rites: 14 X input drivers

2009-07-13 Thread Rémi Cardona

# Rémi Cardona (13 Jul 2009)
# broken and unmaintained by upstream, masked for removal in 30 days
# see bug #277521 for more info

All of those are marked as unsupported by upstream and their git code no 
longer builds (./configure was made to abort on purpose).

More will probably come later, but this is the first round of 
low-hanging fruits.



Re: [gentoo-dev] Last rites: 14 X input drivers

2009-07-13 Thread Rémi Cardona

Le 13/07/2009 16:56, Marijn Schouten (hkBst) a écrit :

Why were they marked unsupported by upstream? Is there a replacement, are they
no longer needed, some other reason?

Some are now supported by the kernel. For the rest, nobody owns the 
hardware anymore. (ur98 is for a head-tracker... does anyone own that?)

All have in common that they've been broken (in portage) for many months 
and no-one noticed until Sabayon folks started doing tinderbox builds :)

If someone is sincerely impacted by this, please get in touch with 
upstream (CC me) because most of those drivers could come back to life 
with very little work. They mostly need someone testing them.

But as they stand now, I'm getting rid of them.



Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?

2009-07-07 Thread Rémi Cardona

Le 07/07/2009 18:20, Ciaran McCreesh a écrit :

I would be entirely happy if you could get the people whose stated aim
is to disrupt PMS and / or third party package managers to stop
poisoning the atmosphere.

Then _please_ for the love of God just _ignore_ him.

Thank you

Re: [gentoo-dev] About time to unify cdda and cdaudio USE flags and make the remaining one global?

2009-07-05 Thread Rémi Cardona

Le 05/07/2009 03:12, Sebastian Pipping a écrit :

Lars Wendler wrote:

So what do you think? Should we convert the bug into a tracker and open bugs
for any package using the USE-flag that should be converted into the other

+1 from me, sounds reasonable.

Ditto, sounds good.

And now for some bikeshedding fun, which flag are we going to keep? ;)



Re: [gentoo-dev] A Little Council Reform Anyone?

2009-07-02 Thread Rémi Cardona

Ned Ludd a écrit :
[snip, lots of insightful stuff I either agree with or don't really 

So lets have some damn fun again !...@#$ 

_That_ I whole heartedly agree with. Please, all of you in the new 
council, try to keep this in mind :)



[gentoo-dev] Enough about GLEP5{4,5}

2009-06-07 Thread Rémi Cardona

Seriously, let's stop.

This endless debate has gone on for waaay too long and it is just plain 
spam now.

I'm just too tired of reading those endless discussions that are going 

Let's just all agree we've failed to reach a consensus and let's spend 
time on something else.

Surely I must not be the only one who's completely bothered by those 
debilitating threads?



Re: [gentoo-dev] New app-eselect category?

2009-05-26 Thread Rémi Cardona

Le 26/05/2009 22:43, Sérgio Almeida a écrit :


There isn't yet. The code is still pretty ugly and I'm still refactoring
to the new architecture before I can make it public (or even officially
git it). I will post it on this mailing list as soon as experimentations
are possible.

Please do try to make it available somewhere (even if only with a dumb 
live - git ebuild) so that we can actually try it out.

I can't remember when was the last Gentoo GSoC project that we were 
actually able to use/see/build...

Good luck for your Summer of Code :)


Re: [gentoo-dev] about gold bugs

2009-05-15 Thread Rémi Cardona

Le 15/05/2009 23:20, Ryan Hill a écrit :

Could I ask that people stop closing bugs against the gold linker with
such classy witticisms as patches welcome.

Honestly, a little heads up before gold hit portage would have been nice 

I already had 2 bugs with gold-related issues even before I had realized 
that binutils had gained a new USE flag... I honestly thought people 
were testing gold from an overlay or self-made ebuilds.

But point taken, gold bugs are toolchain bug :)

Best of luck with gold, I'm eager to try it out!



Re: [gentoo-dev] Last rites: a bunch of X stuff no one should be using since 1994

2009-05-10 Thread Rémi Cardona

Le 09/05/2009 13:05, Marijn Schouten (hkBst) a écrit :

Hash: SHA1

� wrote:

# R�mi  (09 May 2009)
# XPrint is dead, long live XPrint

For kings I understand this comment, but can you explain how it applies to 

The replacement for XPrint would be cairo which has PostScript and PDF 
output backends.

FTR, the actual XPrint server has been removed from the main Xorg 
repository. It's still available in its own repo (a fork of the main 
repo just before the removal), but it's actively *un*maintained.

Cheers :)


Re: [gentoo-dev] Project summaries

2009-05-10 Thread Rémi Cardona

Le 06/05/2009 08:49, Christian Faulhammer a écrit :


any project lead/member can post an answer to this mail for a status

X11 Herd Status Update

Short term or recently done :
 - 1.5.3-r5 went stable (I'm sure y'all noticed)
 - there will be another 1.5 stable server within a few weeks
 - 1.6.x will go into ~arch pretty soon
 - alpha is pretty much the only arch that doesn't have 1.5 keyword but 
thanks to frequent poking, things should change pretty soon

 - 1.3 and 1.4 will get p.masked as soon as alpha and arm stabilize 1.5.3,
 - 1.3 will get treecleaned during the summer, 1.4 maybe a bit later...
 - the X11 overlay now has support for the nouveau driver and Gallium 
(thanks to a few external but essential contributors)

Medium term :
 - libxcb 1.2 will be moved to portage once we figure out a sane way to 
handle the disappearance of For those who haven't heard 
or seen what happens during the upgrade, let's just say that the upgrade 
from expat 1.95 to 2.0 was a walk in the park compared to this.

 - continue cleaning up useless libs and protos

Longer term :
 - major Docs overhaul, what we have now is a complete mess. Any help 
with this is greatly appreciated. See [1] for a short todo list.
 - try to keep up with upstream X, even if it means upsetting some 
users. Actually forcing folks to upgrade to 1.5 has been very 
beneficial, a lot of bugs were uncovered and reported upstream.

Intel Driver Status Update

 - 2.6.3 is the current stable
 - 2.7.0 is still p.masked, 2.7.1 will likely go in ~arch when it's out
 - The next stable driver will probably be 2.8 once xorg-server 1.6 is 
in portage and deemed stable enough.
 - The upcoming 2.8 branch will have a lot less code and options (no 
more DRI1, XAA, EXA, ...), making it easier to maintain and to use.



Re: [gentoo-dev] Project summaries

2009-05-10 Thread Rémi Cardona

Le 10/05/2009 23:43, Gokdeniz Karadag a écrit :

It seems like you have forgotten the link.



[gentoo-dev] Last rites: a bunch of X stuff no one should be using since 1994

2009-05-08 Thread Rémi Cardona

# Rémi Cardona (09 May 2009)
# Low-Bandwidth X and the X Proxy Management stuff has been declared
# dead since last century. All of those will be gone in 30 days

# Rémi Cardona (09 May 2009)
# XPrint is dead, long live XPrint
# nothing in portage uses those apps and libs anymore
# will be removed in 30 days (see bug #264982 for rationale)

If anyone cares, yell now. Otherwise, they will be gone from portage in 
30 days.

To those who believe XPrint and Low-Bandwidth X are still useful: get 
yourself a clue :)



Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development

2009-05-06 Thread Rémi Cardona

Petteri Räty a écrit :

Currently we really don't need to fail that many
people as those who end up at that point in the process almost always
have good enough skills as they have contributed via overlays for quite
a while.

Ditto on that. Most recruits I've been actively watching these past few 
months (Ford_prefect, nirbheek and now mrpouet) have all been trained 
that way :

 - they send us patches for ebuilds
 - we tell them how they are wrong and they fix 'em
 - after a while, they get access to the overlay
 - we still whack them with the cluebat when they break stuff

But the whole overlay process is very positive because it's hands-on 

The ebuild quiz is usually a very good time for them to reflect on all 
the work they did and they understand more why we had to whack them a 
few times. Things make much more sense for them.

All in all, I would say overlays + the ebuild quiz make for very good 
recruits. I have yet to be disappointed by this recruitment process.



Re: [gentoo-dev] On git and pushing official gentoo branches

2009-04-26 Thread Rémi Cardona

Le 26/04/2009 23:55, Gilles Dartiguelongue a écrit :

Hello list,

As many of you might already know, gnome switched to git about 2 weeks
ago so I'd like to take a pick at what people do concerning upstream
using git. How do you present patches you maintain for gentoo to
upstream ? Own maintained git server, gentoo hosted git, others ?

I've been thinking about something similar for most of X and 
FreeDesktop's packages which are pretty much all hosted using git as well.

Ideally, something like Ubuntu's Launchpad's DVCS capabilities would 
help. But that's probably wishful thinking on my part.



Re: [gentoo-dev] EAPI-3 draft: slot operator support

2009-04-09 Thread Rémi Cardona

Mart Raudsepp a écrit :


This thread is for any discussion about the slot operator support item
in EAPI-3 draft.

Could anyone actually give a good reason for slot operators? What 
packages would have a _clear_ benefit from using them? I'm asking for an 
actual list of packages, not just some package that may exist in a 
parallel universe.

To me it just looks like it's overly complicated and it makes my eyes bleed.


  1   2   3   >