[gentoo-dev] Packages up for grabs: x11-terms/sakura
Dear all the following packages are up for grabs after dropping desktop-misc: x11-terms/sakura https://packages.gentoo.org/packages/x11-terms/sakura -- Best, Jonas
[gentoo-dev] Packages up for grabs: sys-apps/mount-gtk
Dear all the following packages are up for grabs after dropping desktop-misc: sys-apps/mount-gtk https://packages.gentoo.org/packages/sys-apps/mount-gtk -- Best, Jonas
[gentoo-dev] Packages up for grabs: dev-util/regexxer
Dear all the following packages are up for grabs after dropping desktop-misc: dev-util/regexxer https://packages.gentoo.org/packages/dev-util/regexxer -- Best, Jonas
[gentoo-dev] Packages up for grabs: gnome-extra/synapse
Dear all the following packages are up for grabs after dropping desktop-misc: gnome-extra/synapse https://packages.gentoo.org/packages/gnome-extra/synapse -- Best, Jonas
[gentoo-dev] Last rites: net-p2p/xmr-stak
# Craig Andrews (2021-03-29) # Unmaintained upstream. # Project is also not useful due to changes in cryptocurrency mining. # Open security issue, bug #779004 # Removal on 2021-04-29, bug #779166 net-p2p/xmr-stak Thanks, ~Craig signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-editors/beaver
# Jonas Stein (2021-03-29) # Depends on gtk-2, no release since 2010. # Removal on 2021-05-01. # Bug #779148. app-editors/beaver OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] developing a separate repo spec
On 2021-03-29 Mon 00:06, Ulrich Mueller wrote: > Why not make it a chapter of PMS? A separate document would presumably > imply having a repository API (RAPI?) decoupled from EAPI? One reason is EAPI development often moves relatively slowly and many potential repo spec features are probably simple enough to discuss/implement at a quicker pace, at least initially. That being said, if EAPI 8 isn't finalized most of the repo functionality could be added to it if that approach is more agreeable. Tim
Re: [gentoo-dev] Last-rites: app-eselect/eselect-infinality, app-eselect/eselect-lcdfilter, media-fonts/infinality-ultimate-meta, media-libs/fontconfig-ultimate, media-libs/fontconfig-infinality
On 3/29/21 2:50 PM, Joonas Niilola wrote: > This has been an useful package regardless of infinality patch set. It > doesn't depend on it in any way either. > > I do have it forked already in my local overlay with few more font > packages added to the list. Would there be interest in keeping this one > alive, or replace it with some other new font-meta package? > > -- juippis > I've made fonts-meta package to replace this, please see https://github.com/gentoo/gentoo/pull/20177 for any comments. (+ more maintainers welcome!) a pkgmove + separate commit to update the ebuild with suggested changes will probably be smarter than adding a new package. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Last-rites: app-eselect/eselect-infinality, app-eselect/eselect-lcdfilter, media-fonts/infinality-ultimate-meta, media-libs/fontconfig-ultimate, media-libs/fontconfig-infinality
On 3/29/21 2:27 PM, Andreas Sturmlechner wrote: > # Removal on 2021-04-26. > > media-fonts/infinality-ultimate-meta > This has been an useful package regardless of infinality patch set. It doesn't depend on it in any way either. I do have it forked already in my local overlay with few more font packages added to the list. Would there be interest in keeping this one alive, or replace it with some other new font-meta package? -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Last-rites: app-eselect/eselect-infinality, app-eselect/eselect-lcdfilter, media-fonts/infinality-ultimate-meta, media-libs/fontconfig-ultimate, media-libs/fontconfig-infinality
# Andreas Sturmlechner (2021-03-27) # Dead upstream. Bugs #437056, #453964, #550592, #768303 # Removal on 2021-04-26. app-eselect/eselect-infinality app-eselect/eselect-lcdfilter media-fonts/infinality-ultimate-meta media-libs/fontconfig-ultimate media-libs/fontconfig-infinality signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sun, 28 Mar 2021 19:46:32 -0400 Joshua Kinard wrote: > I've kinda come to this conclusion myself. I could probably host an > extracted, micro-initramfs on my NFS server that would be loaded by the > kernel to jump to $REAL_ROOT. Not *too* much of an issue on the Octane, > because I can store the kernel command line args in a PROM variable so that > all I have to do is type "$foo" at the PROM prompt to load something. But, > SGI did their best to be inconsistent, and IP27 systems cannot permanently > save variables to NVRAM. Once you power cycle, all user-defined PROM vars > are lost. And Linux's NFS Root command args are somewhat complicated from > what I remember. Upshot is I boot the IP27 over serial console, so I can > just save bootp() args in a text file on my desktop and paste it into the > console for those instances. Have you seen CONFIG_CMDLINE? It lets you bake command line args into the kernel image itself. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpjPj3Fv0z6w.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
This is getting really long, so I'm going to remove more things I'm not answering directly. On Sun, Mar 28, 2021 at 07:31:02PM -0400, Joshua Kinard wrote: > > The problem is, there's a chicken-and-egg problem in the scenario where > > / and /usr are on separate partitions, and this is why a number of linux > > distros have moved to requiring an initramfs in this situation. > > I'm linking systemd's description here, only because it is the best > > writeup of the issue I've found [1]. > > Anything that is needed in the early boot process requires all of its > > libraries, > > dependent libraries, binaries, data files, etc to be on /, and this has > > become a moving target. > > Yeah, I've read systemd's explanation, and generally disagree with it. They > created the problem in the first place, then invented their own solution for > it, and now everyone acts like they're the wise men on the mountain for it. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Rob Landley had a lot to say about how linux should be using initramfs to handle early boot long before systemd came along, so this has been an issue a lot longer than systemd; the systemd guys just amplified it. > I still don't see the connection to the static *.a libs and whether they're > on /lib or /usr/lib, though. Unless we're implying that where the *.a's go, > so too do the *.so's go, then THAT makes sense because *.so's ARE needed at > program runtime, whereas *.a's are not. It is a linker behavior issue we discovered and worked around. In the past, Gentoo has gone an extra mile to make some things useable by people who have separate /usr without an initramfs by moving only shared libraries to /lib*. We leave everything else that would be in libdir in the default location which is /usr/lib*. This includes things like static libs, pkgconfig files etc. When we started doing this we found that the linker favors libraries in /usr/lib* over libraries in /lib*, so if you are linking to libfoo and there's a static version in /usr/lib* and a shared version in /lib* you will link to the static version. That's what bug 4411 is about. gen_usr_ldscript gets around this by creating a linker script at the original location of the shared library in /usr/lib* when it moves the shared library to /lib*. See /usr/lib64/libbz2.so for an example of the generated linker script. Getting rid of gen_usr_ldscript would move the shared libraries back to their upstream location (/usr/lib*) and remove the linker scripts. This would also allow the removal of the usr-ldscript eclass and the gen_usr_ldscript function from eutils.eclass. The up side of this is that it allows us to get rid of some of our custom code in ebuilds, and it is completely transparent to most of our user base. The down side is that if you are using separate /usr with no initramfs, libraries that you were accessing in /lib* during early boot will moved to /usr/lib* and not be available before /usr is mounted. This would cause breakage until you reconfigured your system to boot with an initramfs and mount / and /usr before jumping into the real system. > I wonder if we couldn't shovel all static libs off to a dedicated folder > somewhere, like '/usr/lib/static//*.a', similar to the way debug files > are now consolidated under '/usr/lib/debug'. Since they're only needed > during a specific kind of compilation that we don't support out-of-the-box > that happens long after the system is fully booted, stuffing them off > somewhere unimportant would make some sense. Most modern software should be > using shared libs by default, and if it ain't, that's either a bug or that > software is for a very specific function (like a bootloader). If you started creating separate static libs folders you would need one per abi, so it would end up being pretty ugly. We don't build that many static libraries right now, so I'm not sure it is worth moving them to some other folder. If we put the shared libs back in the upstream expected location (/usr/lib*) we would eliminate the linker issue. *snip* > > The way I see it, when we start to remove the gen_usr_ldscript calls, > > people using a sep-usr mount without an initramfs will run into one or > > both of these issues: > > > > - they might have to increase the size of their root partition depending > > on what gets added to /lib* > > - if one package in that list drops gen_usr_ldscript without installing > > libraries in /lib*, it will mean they need an initramfs. > > I tend to make my root partitions ~4GB, which has often been plenty of room > for well over 15 years. But again, location of the *.a static libs is > irrelevant during system boot. They are not needed nor referenced when a > program executes. A statically-compiled program has all of its dependencies > lumped inside of it, so you could put it pretty much anywhere on the > filesystem and run it (ignoring for a moment 'noexec' potentially being > set). Or even
Re: [gentoo-dev] developing a separate repo spec
> On Mon, 29 Mar 2021, Tim Harder wrote: > Is there any interest these days in developing and maintaining a > separate repo spec [1]? Among other uses, it would help in describing > standardized repo features related to metadata/layout.conf settings > allowing devs to reference a single, canonical source in order to > support repo/profiles features. > The current spec doesn't define many repo specific features leading to > people jamming all sorts of conditional features in metadata/layout.conf > via profile-formats and other entries, none of which is defined in the > current spec. > Mostly I'm asking because I'm tired of trying to support a pseudo-spec > and am quite close to dropping pkgcore's support for the few > profile-formats features it tries to enable. Why not make it a chapter of PMS? A separate document would presumably imply having a repository API (RAPI?) decoupled from EAPI? Ulrich signature.asc Description: PGP signature
