Re: [gentoo-dev] [RFC PATCH v2 04/20] www-servers/nginx: add nginx.tmpfiles for managing /var/tmp/nginx
just my 2¢ here and sorry if I might have overlookt a rationale earlier why moving nginx's temp dir to "generic purpose" /var/tmp/… and not keeping it at /var/lib/nginx/tmp/* ? Especially, when there even is/would be a tmpfiles entry taking care of it's existence and ownership. Christian Am 29.07.24 um 23:52 schrieb Zurab Kvachadze: This places the burden on creating and cleaning /var/tmp/nginx in world-writable /var/tmp on systemd-tmpfiles(8). Signed-off-by: Zurab Kvachadze --- www-servers/nginx/files/nginx.tmpfiles | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 www-servers/nginx/files/nginx.tmpfiles diff --git a/www-servers/nginx/files/nginx.tmpfiles b/www-servers/nginx/files/nginx.tmpfiles new file mode 100644 index ..af9cdd26973f --- /dev/null +++ b/www-servers/nginx/files/nginx.tmpfiles @@ -0,0 +1,2 @@ +D /var/tmp/nginx 0755 root root +x /var/tmp/nginx
[gentoo-dev] Re: Arch Status and Future Plans
Am 26.06.24 um 09:38 schrieb Florian Schmaus: Hi Arthur, thanks for taking the time to write this mail. On 25/06/2024 19.33, Arthur Zamarin wrote: x86 Stable 32-bit arch. I'll be honest, I don't believe at all this should be stable arch anymore. I have the impression as well. The time to drop stable keywords for x86 probably has come. But I always wonder if there is a x86 use-case we are not aware of. Therefore, if there is a group of x86 Gentoo users out there, then they should speak now and ideally elaborate a bit on their use case. well - at least *I* am running x86 on a bunch of Intel Atom boards (-march=bonnell, "Diamondville") which are mostly purposed as routers, but also keeping some of those early "Netbooks" based on that processor alive. All equipped with (the platform's max of) 2 Gi RAM, they still suit their purpose well… Cheers Christian
Re: [gentoo-dev] [PATCH] 2024-02-01-grub-upgrades: add news item
Am 28.01.24 um 17:25 schrieb Mike Gilbert: […] +On upgrades, it is common for users to mismatch the grub-install options +they used for the current and previous versions of grub. This will cause +a stale core image to exist. For example: + +/boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image) +/boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image) +/boot/grub/x86_64-pc/*.mod (grub 2.12 modules) despite x64, the path is always /boot/grub/i386-pc/*.mod for GRUB_PLATFORMS=pc Christian
Re: [gentoo-dev] Help wanted with net-misc/frr maintenance
Am 13.07.23 um 09:10 schrieb Jaco Kroon: Hi Alarig, On 2023/07/12 15:18, Alarig Le Lay wrote: Hello Jakov, On Wed 12 Jul 2023 10:54:47 GMT, Jakov Smolić wrote: Hi all, I was recently left as the sole maintainer of net-misc/frr and given I'm not actively using the package anymore it would be good if someone who is an active user could take over. There are several open bugs and a new upstream release. I can stay as a secondary maintainer and help out (non-Gentoo developers are also welcome, I can proxy for you), otherwise if no one is interested I'll drop the package to maintainer-needed soon. Regards, I’m already maintaining bird, so I could happily step in for frr as well! Happy to assist where I can. For the most part frr "just works" for us though. Also not something we like to upgrade on a frequent basis unless there is a specific reason to. Kind Regards, Jaco FYI: upstream also has a (neglected?) overlay on their site: https://github.com/FRRouting/gentoo-overlay Christian
[gentoo-dev] about modifying an ebuild in local overlay and $FILESDIR
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
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
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_MEMORY>pysical RAM && <= virtual RAM -> ewarn
* $CHECKREQS_MEMORY>virtual 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
Joshua Saddler schrieb: > On Thu, 3 Dec 2009 02:44:47 + > Sylvain Alain 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-/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
Mounir Lamouri schrieb: > # Mounir Lamouri (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)
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
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?
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
Re: [gentoo-dev] missing ide discs mapping is udev's fault?
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. 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
[gentoo-dev] missing ide discs mapping is udev's fault?
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
