[gentoo-dev] about modifying an ebuild in local overlay and $FILESDIR

2017-04-26 Thread Christian Bricart
Hi all,

from time to time, I need to make (and maintain) modifications to an
ebuild from the main tree in my local overlay.
So basically, I create the directory structure from
/usr/portage/// under
/usr/local/portage///, copy over the ebuild and do my
modifications in the ebuild.
So far how an overlay works ;-)

But if there are references to patches, init-scripts, conf-files, etc
from $FILESDIR w/i the original ebuild, one also needs to copy those
into /usr/local/portage/../../files/ ..

Is it possible to "overlay" such files used in epatch(), newins(),
newconfd(), newinitd(), etc too..?

so i.e:
FILESDIR = "${repository_location}/${CATEGORY}/${PN}/files"
should support a fallback to:
FILESDIR = "${PORTDIR}/${CATEGORY}/${PN}/files"
if not found...
(or actually to the defined $master from the repo used)

Christian



Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM

2015-06-03 Thread Christian Bricart
Am 03.06.2015 um 22:32 schrieb Ciaran McCreesh:
 On Wed, 03 Jun 2015 22:22:39 +0200
 i've just hit the constraint CHECKREQS_MEMORY=3G in
 =www-client/chromium-44.* on a 2 GiB RAM machine.. (having
 additionally
 5G Swap on SSD..)

 I personally doubt that check-reqs_memory() in the eclass should only
 check for *physical* rather than *virtual* RAM to fulfill this
 constraint and fail if unsatisfied.
 
 Swap is horrifically slow. It's better to fail than to use swap for
 stuff...
 
(basically) agreed - but in distcc/icecream/whatever builds, linking
*may* also be done on remote machines, which *may* fulfill the memory
constraint..
we're talking about *build* constraints rather than *run* constraints,
right..?

Christian




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM

2015-06-03 Thread Christian Bricart
Dear devs,

i've just hit the constraint CHECKREQS_MEMORY=3G in
=www-client/chromium-44.* on a 2 GiB RAM machine.. (having additionally
5G Swap on SSD..)

I personally doubt that check-reqs_memory() in the eclass should only
check for *physical* rather than *virtual* RAM to fulfill this
constraint and fail if unsatisfied.

So my proposal would rather be:

* $CHECKREQS_MEMORY=pysical RAM - ok
* $CHECKREQS_MEMORYpysical RAM  = virtual RAM - ewarn
* $CHECKREQS_MEMORYvirtual RAM - eerror (may still be overridden by
${I_KNOW_WHAT_I_AM_DOING} in check-reqs_output() )

what do you think?

cheers
  Christian



Re: [gentoo-dev] openrc stabilization todo

2009-12-03 Thread Christian Bricart
Joshua Saddler schrieb:
 On Thu, 3 Dec 2009 02:44:47 +
 Sylvain Alain d2_rac...@hotmail.com wrote:
 Hi everyone,  I think that the best should be to release a migration guide
 just before the official release and also a news on the first page of
 Gentoo.org
 
 You really should have checked our doc repo before sending your mail:
 
 http://www.gentoo.org/doc/en/openrc-migration.xml
 
 I, Cardoe, and Uberlord wrote it back in April 2008[1].
 
 [1] 
 http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/openrc-migration.xml

mentioning possible migration issues and pointing at the docs above:

(AFAIK the only) documentation handling networking migration states:

+--
| ...
| Also, /etc/conf.d/net no longer uses bash-style arrays for
| configuration.
| Please review /usr/share/doc/openrc-version/net.example
| for configuration instructions. Conversion should be relatively
| straight-forward, for example a static IP assignment would change
| as follows:
| ...
+--
(and no - more complex examples are *not* described
 in /u/s/d/o/net.example as stated..)

Apart from that, the newnet file will be /etc/conf.d/network ..

Regarding USE=-oldnet migrations, that are actually *using* oldnet Bash
arrays within /etc/conf.d/net (like me) are left alone and not even
Funtoo has a porting guide..

my $0.02
  Christian





Re: [gentoo-dev] Last rites for net-misc/asterisk-chan_bluetooth

2009-07-30 Thread Christian Bricart
Mounir Lamouri schrieb:
 # Mounir Lamouri volk...@gentoo.org (30 Jul 2009)
 # Masked for removal in 60 days.
 # Upstream's unactive since 2005. Do not support asterisk versions in tree.
 # bug 279383
 net-misc/asterisk-chan_bluetooth
 
 

may be replaced by (unpackaged) chan_mobile?

-- http://www.chan-mobile.org/

Christian




OT: IRIX media (was: Re: [gentoo-dev] Available hardware)

2008-01-16 Thread Christian Bricart
Jeremy Huddleston wrote:
 Hey Dan,
 
 You don't happen to have IRIX discs for the Octane2 do you?  I have an
 O2, and I wanted to install IRIX on it to test some stuff out, but I
 lost the disks and SGI wants $450 to send me new ones (yikes!).

That's odd.. I asked SGI about two years ago about IRIX media for an
Indy.. they replied that's no problem to ship the OS install CDs for
IRIX, as if you own an SGI hardware you also own the initial OS for it -
so I got the original IRIX 6.something installation CDs for free -
directly from SGI...

Christian
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Removing of package games-rpg/planeshift

2007-03-14 Thread Christian Bricart
Tupone Alfredo schrieb:
 games-rpg has been masked on 18 jul 2006 and there is a pending bug
 #167547 Broken dependancies in games-rpg/planeshift-0.3.011
 Removing is planned for this end of week: 17 Mar 2007.
 
0.3.011 is wy t old and not compatible with current server versions.

BUT see:
http://bugs.gentoo.org/show_bug.cgi?id=155790#c7

maybe it only needs some love after all...

Christian
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] missing ide discs mapping is udev's fault?

2006-02-21 Thread Christian Bricart

Richard Fish wrote:

On 2/21/06, Christian Bricart [EMAIL PROTECTED] wrote:


Hi,
So I have /dev/hda through /dev/hdl which are ok. But the mappings to
/dev/discs/discX with X  7 are missing.



snip


I wanted to file a bug report, but I'm not certain if it's actually
udev's fault.



Yes, it is udev's fault, but it is not a bug.  The /dev/discs nodes
were a convention of devfs, and _never_ standard.


Re-checked.. /dev/discs seems to be based on /dev/ide/-mapping and yet 
they are not complete:


magrathea ~ # find /dev/ide -name disc -o -name cd
/dev/ide/host0/bus0/target0/lun0/disc
/dev/ide/host0/bus0/target1/lun0/disc
/dev/ide/host0/bus1/target0/lun0/cd
/dev/ide/host0/bus1/target1/lun0/disc
/dev/ide/host2/bus0/target0/lun0/disc
/dev/ide/host2/bus0/target1/lun0/disc
/dev/ide/host4/bus0/target0/lun0/disc
/dev/ide/host4/bus1/target0/lun0/disc
/dev/ide/host4/bus1/target1/lun0/disc

so /dev/ide/host/bus0/target1/lun0/disc (which ought to be /dev/hdj) is 
missing there.

But see the listing in sysfs:

magrathea ~ # find /sys/bus/ide/drivers/ide* -type l | sort -k 7 -t /
/sys/bus/ide/drivers/ide-disk/0.0
/sys/bus/ide/drivers/ide-disk/0.1
/sys/bus/ide/drivers/ide-cdrom/1.0
/sys/bus/ide/drivers/ide-disk/1.1
/sys/bus/ide/drivers/ide-disk/2.0
/sys/bus/ide/drivers/ide-disk/2.1
/sys/bus/ide/drivers/ide-disk/4.0
/sys/bus/ide/drivers/ide-disk/4.1
/sys/bus/ide/drivers/ide-disk/5.0
/sys/bus/ide/drivers/ide-disk/5.1

and the listing from dmesg:

magrathea ~# dmesg | grep ^hd | grep drive
hda: Maxtor 4D040H2, ATA DISK drive
hdb: SAMSUNG SP1614N, ATA DISK drive
hdc: IDE-CD R/RW 16x10A, ATAPI CD/DVD-ROM drive
hdd: Maxtor 92041U4, ATA DISK drive
hde: Maxtor 4G120J6, ATA DISK drive
hdf: Maxtor 96147H6, ATA DISK drive
hdi: SAMSUNG SP1614N, ATA DISK drive
hdj: IC35L040AVER07-0, ATA DISK drive
hdk: SAMSUNG SP1614N, ATA DISK drive
hdl: SAMSUNG SP1614N, ATA DISK drive

And hdparm iterates through /dev/ide/* if found...
Is /dev/ide according to LSB? Or is this also supposed to vanish? ;-)
Then I'll have to file a bug for hdparm instead :)

Christian



From the ChangeLog (there are many other entries BTW):

*udev-064-r1 (31 Jul 2005)

  31 Jul 2005; Greg Kroah-Hartman [EMAIL PROTECTED]
  +files/udev.rules-064-r1, +udev-064-r1.ebuild:
  Start moving to a sane /dev naming scheme.
  This release removes the devfs names for the tty and consolde devices, and the
  symlinks that were implementing the LSB standard names.  We only implement the
  LSB names now, which saves over 3Mb of RAM on /dev.

-Richard



--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] missing ide discs mapping is udev's fault?

2006-02-21 Thread Christian Bricart
Mike Frysinger schrieb:
 On Tuesday 21 February 2006 17:56, Richard Fish wrote:
 On 2/21/06, Christian Bricart [EMAIL PROTECTED] wrote:
 And hdparm iterates through /dev/ide/* if found...
 I assume you are talking about the init script?  Because my hdparm
 binary requires one to specify a device node, there is no iteration...

 If so, AFAIK that exists only for those still running devfs.  If
 /dev/ide does not exist, it iterates over all devices found by
 dev/hd?.
 
 correct ... hdparm init script assumes if you have the /dev/ide compatible 
 stuff, you're using devfs-style names, otherwise it'll use normal /dev/hd? 
 parsing

yep, see: http://bugs.gentoo.org/show_bug.cgi?id=123647
(which has status FIXED right now ;) )

Christian

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] missing ide discs mapping is udev's fault?

2006-02-20 Thread Christian Bricart
Hi,

yesterday I've noticed, that some mappings in /dev/discs are missing on
my machine.
Actually I have an additional ATA controller with some discs attached.
So I have /dev/hda through /dev/hdl which are ok. But the mappings to
/dev/discs/discX with X  7 are missing.

Whose fault would that be in the first case? hot- or coldplug? udev?
I've looked through /etc/udev/scripts/ide-devfs.sh but could not find
anything wrong there so far.

I've noticed he missing mappings as e.g. /etc/init.d/hdparm loops
through /dev/discs/discX to set params for all discs attached and thus
misses the last two.

I wanted to file a bug report, but I'm not certain if it's actually
udev's fault.

Christian

-- 
gentoo-dev@gentoo.org mailing list