Bouncing messages from gentoo-dev@lists.gentoo.org
Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: - 89057
Re: [gentoo-dev] desktop profile: Switch make.defaults to +elogind, drop consolekit
On Montag, 1. April 2019 01:23:17 CET Andreas Sturmlechner wrote: > We've had sys-auth/elogind available in Gentoo repo for quite a while now, > and it seems to work fine for many people, as Plasma, Cinnamon, and the > recently added Gnome support have shown. ... > Also, with that change we can really start to think about xorg-server[-suid] > default (again). > > Here's the original elogind integration tracker: > https://bugs.gentoo.org/show_bug.cgi?id=elogind-support > > A new tracker has been set up for +elogind revdep stabilisation: > https://bugs.gentoo.org/show_bug.cgi?id=elogind-default I think it is time to finally move on with this. I'm going to write up a news item, do the usual review, then publish at the same time as switching the desktop profile make.defaults. Does that sound about right? > So now is the time for maintainers of packages depending on sys-auth/ > consolekit to check for any work to do, and test migration. Assuming everyone have made their packages ready? Regards, Andreas signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2019-10-27 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2019-10-27 23:59 UTC. Removals: app-office/geierlein 20191024-06:39 hannod5dda180e8f games-fps/ut2004-action20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-airbuccaneers 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-cor 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-crossfire 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-deathball 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-fragops 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-hamsterbash 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-muralis 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-strikeforce 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-troopers 20191027-22:49 chewi9ef701d8e96 games-fps/ut2004-unwheel 20191027-22:49 chewi9ef701d8e96 virtual/python-pmw 20191027-11:53 mgorny 9eaf42363de x11-misc/enlightenment-extra 20191026-09:53 juippis ce9d33c11ba Additions: acct-group/dnsmasq_exporter20191023-16:46 williamh 4e4d24a09fc acct-user/dnsmasq_exporter 20191023-16:55 williamh f2a163d97fc app-metrics/dnsmasq_exporter 20191023-17:33 williamh 9e80ba44814 app-misc/qcma 20191025-17:45 mva 76a7dc6dc5e dev-go/golicense 20191021-18:24 williamh be190d6f7f5 dev-libs/stp 20190104-03:56 juippis 4146e80b7fd dev-ruby/whole_history_rating 20191025-09:43 mgorny 2fe535dde66 dev-util/kubebuilder 20191019-12:11 mrueg3edfd542777 media-libs/vitamtp 20191025-17:39 mva fd73ce01ec0 x11-themes/papirus-icon-theme 20191027-18:36 zlogene 8c5326eff11 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: games-fps/ut2004-action,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-airbuccaneers,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-cor,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-crossfire,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-deathball,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-fragops,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-hamsterbash,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-muralis,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-strikeforce,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-troopers,removed,chewi,20191027-22:49,9ef701d8e96 games-fps/ut2004-unwheel,removed,chewi,20191027-22:49,9ef701d8e96 virtual/python-pmw,removed,mgorny,20191027-11:53,9eaf42363de x11-misc/enlightenment-extra,removed,juippis,20191026-09:53,ce9d33c11ba app-office/geierlein,removed,hanno,20191024-06:39,d5dda180e8f Added Packages: x11-themes/papirus-icon-theme,added,zlogene,20191027-18:36,8c5326eff11 app-misc/qcma,added,mva,20191025-17:45,76a7dc6dc5e media-libs/vitamtp,added,mva,20191025-17:39,fd73ce01ec0 dev-ruby/whole_history_rating,added,mgorny,20191025-09:43,2fe535dde66 dev-util/kubebuilder,added,mrueg,20191019-12:11,3edfd542777 app-metrics/dnsmasq_exporter,added,williamh,20191023-17:33,9e80ba44814 acct-user/dnsmasq_exporter,added,williamh,20191023-16:55,f2a163d97fc acct-group/dnsmasq_exporter,added,williamh,20191023-16:46,4e4d24a09fc dev-go/golicense,added,williamh,20191021-18:24,be190d6f7f5 dev-libs/stp,added,juippis,20190104-03:56,4146e80b7fd Done.
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, 27 Oct 2019 12:05:02 -0500 William Hubbs wrote: > If a build dep of something changes, the correct response with > --with-bdeps=y is to rebuild everything that depends on the changed dep. Unfortunately, my learned experience of portage is the "correct response" is not something portage wants to do on its own without hand holding. /me has *only* had to write tools to get around this problem pgpLsAGDSXUkK.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] separate /usr without initramfs
On 10/27/2019 12:12, Matt Turner wrote: > On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot wrote: >> >> On Sun, 27 Oct 2019 05:38:48 -0400 >> Joshua Kinard wrote: >> >>> Why do I not like an initramfs, though? Well, for one, it complicates the >>> kernel compiles (and it makes them bigger, something which is an issue on >>> the old SGI systems at times). Two, it's another layer that I have to >>> maintain. Three, it violates, in my mind, the simplicity of keeping the >>> kernel and userland separated (e.g., kernel does kernel-y things, userland >>> does userland-y things). >> >> You make it sound like the initramfs has to be built into the kernel >> image. It can be but it usually isn't. I suspect you know that though? >> Admittedly that does depend on support from your bootloader. While GRUB >> and U-Boot have supported this for years, I forget what oddball >> bootloaders your hardware may be using. > > Though he's likely not using it, GRUB2 supports all the platforms he > mentioned (x86, amd64, sparc64, [sgi] mips). Nope, never took to GRUB. Never bought into the selling point of "you don't have to edit a config file for every kernel update". Also don't have a working sparc64 box anymore, as the Blade 100 died quite a long time ago. I still have a SunFire v240, but it's got a PROM release that can't netboot, and the updated version that can was released 3 days after Oracle bought Sun and locked SunSolve up (thanks, Oracle). Plus the thing is as loud as a jet engine. As far as GRUB working on SGI systems, that's news to me. ARCS is pretty unique on each SGI system, so it's not like one can write a tiny bit of code to cover them all. I'll have to investigate GRUB's documentation to see if can deal w/ machines running ARCS, and whether it can handle IP27, IP30, and even IP35. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] separate /usr without initramfs
On 10/27/2019 06:06, James Le Cuirot wrote: > On Sun, 27 Oct 2019 05:38:48 -0400 > Joshua Kinard wrote: > >> Why do I not like an initramfs, though? Well, for one, it complicates the >> kernel compiles (and it makes them bigger, something which is an issue on >> the old SGI systems at times). Two, it's another layer that I have to >> maintain. Three, it violates, in my mind, the simplicity of keeping the >> kernel and userland separated (e.g., kernel does kernel-y things, userland >> does userland-y things). > > You make it sound like the initramfs has to be built into the kernel > image. It can be but it usually isn't. I suspect you know that though? > Admittedly that does depend on support from your bootloader. While GRUB > and U-Boot have supported this for years, I forget what oddball > bootloaders your hardware may be using. As mentioned (and later pointed out in the thread), I use LILO. Considering upstream is dead now, how much longer that will persist is an open question. I am a creature very wedded to habit, and LILO, for whatever its ills and warts are, has always just worked for me, so I have stuck with it. Having to edit a config file before each kernel update is the trivialest of tasks, especially since I tend to only update the kernel once every few months. The SGI systems all boot using netboot because I compile their kernels on my dev box and then host them over TFTP. It's just a lot easier that way, especially since ARCS (the SGI version of a BIOS) has had network booting built in since pretty much 1990 (and earlier, I think). It's really the SGI Indy (IP22) that refuses to netboot if the kernel's size is >11MB. All of those kernels are monolithic, since the hardware in such systems is pretty much fixed for all time. Granted, my Indy gave up the ghost some time ago (probably the infamous RTC battery issue), so I am really just left with an O2 (which refuses to netboot anything >41MB), Octane, and two IP27-class systems, which don't have size limits (that I've found yet) for what they'll boot. For actual disk booting on those systems, well, there's really just the super-old ArcLoad project. Written by the mastermind behind Octane's Linux port, he aimed to make it very GRUB-like, so it has some of GRUB's filesystem code in it for direct booting, or it can boot kernels stored in a special area of the disk called the volume header (on disks w/ SGI's partition layout). Except that imported GRUB code is beyond ancient (11+ years old?), so it probably won't load a kernel off of ext4 or even XFSv5 partitions now. Thus you really just have the volume header approach, and that has its own limits. That all said, it doesn't really matter if the initramfs is built into the kernel or loaded somewhere into memory by the bootloader. It's still a wholly-separate userland layer that needs its own libc and whatever small amount of tools to help mount required partitions and/or flash CPU microcode before the kernel tries invoking /sbin/init. That's just a terrible design. I mean, you can put lipstick on a pig, but it's still a bloody pig. >> Maybe I'm just a old codger who refuses to accept change. I'm fine with >> that description. I like things to remain somewhat simple, and my view of >> Linux, both kernel and userland, over the last few years is one of growing >> dismay due to the constant introduction of subsystem layer atop subsystem >> layer for very little gain. How much longer until we need a kernel to boot >> the kernel to mount the userland that mounts the userland (yo dawg)? > > Isn't that what the BIOS and bootloader do? On the plus side, you can > now boot straight from UEFI to kernel without a bootloader but on the > other hand, UEFI is horrifically over-complex. Yeah, UEFI is one of those Eldritch horrors spoken of in the Necronomicon. It's really just there so gamerz bois can have their uber-fancy gaming system fully specced out. Ironically, SGI's ARCS was capable of doing most of what UEFI does 20 years ago, including pretty GFX and even playing music when the system boots up (e.g., Indy's infamous "ass trumpet"). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
On Sun, 2019-10-27 at 13:49 -0500, William Hubbs wrote: > On Sun, Oct 27, 2019 at 06:58:00PM +0100, Michał Górny wrote: > > On Sun, 2019-10-27 at 12:40 -0500, William Hubbs wrote: > > > Most upstreams and build systems do not make this distinction, so this > > > causes unnecessary hacks in ebuilds. > > > > > > > The hacks aren't 'unnecessary'. There is a very good reason that files > > that are used *purely at build time* don't land in /. That reason is > > disk space. Even if people nowadays are forced to use initramfs with > > separate /usr, it doesn't mean you should just let their rootfs fill up > > with useless files. > > The useless files argument really holds no water with me. We install > many files on / that are useless in one situation or another. > Some examples are logrotate files when logrotate isn't installed, Do we really install logrotate files to /? > systemd units for openrc systems and openrc init scripts for systemd > systems. Those files are at least needed in some scenarios. You're talking about files that are never used without /usr mounted. And that can't be used because they depend on headers in /usr/include. > > Talk to me about useless files on / after we put all of these, and > possibly others I can't think of, behind use flags. > > > Do you have any *real* argument? Because 'unnecessary hack' is > > basically your feeling of ebuild aesthetics. My aesthetics is more > > worried about useless clutter in /lib*. FHS agrees with me, as you > > yourself admitted yesterday. > > Any downstream hack means that we are being lazy and not reporting the > bug upstream and asking them to fix it. > > This particular issue is not a big deal to any other distro and has > never been. Shouldn't we try to get upstreams to do this if it is so > important? > Because 'any other distro' usually means a binary distro that moves files around after installing. And splits static libraries into separate packages. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] qmail.eclass: hide qmail-pop3 behind a use flag
Other solutions offer much more features and better security, so do not install this by default. Keep it for the moment for those who explicitely want it. diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass index b6ef483aa82..5a30461704e 100644 --- a/eclass/qmail.eclass +++ b/eclass/qmail.eclass @@ -169,11 +169,13 @@ qmail_full_install() { einfo "Installing all qmail software" insopts -o root -g qmail -m 755 doins bouncesaying condredirect config-fast except preline qbiff \ - qmail-{pop3d,qmqpd,qmtpd,qread,qstat,smtpd,tcpok,tcpto} \ + qmail-{qmqpd,qmtpd,qread,qstat,smtpd,tcpok,tcpto} \ qreceipt qsmhook tcp-env + use pop3 && doins qmail-pop3d insopts -o root -g qmail -m 711 - doins qmail-{clean,getpw,local,popup,pw2u,remote,rspawn,send} splogger + doins qmail-{clean,getpw,local,pw2u,remote,rspawn,send} splogger + use pop3 && doins qmail-popup insopts -o root -g qmail -m 700 doins qmail-{lspawn,newmrh,newu,start} @@ -261,7 +263,13 @@ qmail_tcprules_install() { insopts -o root -g "$GROUP_ROOT" -m 0644 doins "${GENQMAIL_S}"/tcprules/Makefile.qmail doins "${GENQMAIL_S}"/tcprules/tcp.qmail-* - use ssl || rm -f "${D}${TCPRULES_DIR}"/tcp.qmail-pop3sd + use ssl && use pop3 || rm -f "${D}${TCPRULES_DIR}"/tcp.qmail-pop3sd +} + +qmail_supervise_install_one() { + dosupervise ${i} + diropts -o qmaill -g "$GROUP_ROOT" -m 755 + keepdir /var/log/qmail/${i} } qmail_supervise_install() { @@ -269,16 +277,13 @@ qmail_supervise_install() { cd "${GENQMAIL_S}"/supervise - for i in qmail-{send,smtpd,qmtpd,qmqpd,pop3d}; do - dosupervise ${i} - diropts -o qmaill -g "$GROUP_ROOT" -m 755 - keepdir /var/log/qmail/${i} + for i in qmail-{send,smtpd,qmtpd,qmqpd}; do + qmail_supervise_install_one ${i} done - if use ssl; then - dosupervise qmail-pop3sd - diropts -o qmaill -g "$GROUP_ROOT" -m 755 - keepdir /var/log/qmail/qmail-pop3sd + if use pop3; then + qmail_supervise_install_one qmail-pop3d + use ssl && qmail_supervise_install_one qmail-pop3sd fi declare -F qmail_supervise_install_hook >/dev/null && \ @@ -375,7 +380,9 @@ qmail_rootmail_fixup() { qmail_tcprules_fixup() { mkdir -p "${TCPRULES_DIR}" - for f in {smtp,qmtp,qmqp,pop3}{,.cdb}; do + local POP_FILES= + use pop3 && POP_FILES="pop3 pop3.cdb" + for f in {smtp,qmtp,qmqp}{,.cdb} ${POP_FILES}; do old="/etc/tcp.${f}" new="${TCPRULES_DIR}/tcp.qmail-${f}" fail=0 @@ -417,13 +424,15 @@ qmail_supervise_config_notice() { elog "ln -s ${SUPERVISE_DIR}/qmail-send /service/qmail-send" elog "ln -s ${SUPERVISE_DIR}/qmail-smtpd /service/qmail-smtpd" elog - elog "To start the pop3 server as well, create the following link:" - elog "ln -s ${SUPERVISE_DIR}/qmail-pop3d /service/qmail-pop3d" - elog - if use ssl; then - elog "To start the pop3s server as well, create the following link:" - elog "ln -s ${SUPERVISE_DIR}/qmail-pop3sd /service/qmail-pop3sd" + if use pop3; then + elog "To start the pop3 server as well, create the following link:" + elog "ln -s ${SUPERVISE_DIR}/qmail-pop3d /service/qmail-pop3d" elog + if use ssl; then + elog "To start the pop3s server as well, create the following link:" + elog "ln -s ${SUPERVISE_DIR}/qmail-pop3sd /service/qmail-pop3sd" + elog + fi fi elog "Additionally, the QMTP and QMQP protocols are supported, " elog "and can be started as:" signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] [PATCH] emerge: fix error message for unknown options (bug 673400)
Do not use parse_known_args to parse positional arguments, since that causes unknown options to be handled like unknown positional arguments. Bug: https://bugs.gentoo.org/673400 Signed-off-by: Zac Medico --- lib/_emerge/main.py | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/lib/_emerge/main.py b/lib/_emerge/main.py index 486664c84..0d2c45a4f 100644 --- a/lib/_emerge/main.py +++ b/lib/_emerge/main.py @@ -299,7 +299,6 @@ def _find_bad_atoms(atoms, less_strict=False): def parse_opts(tmpcmdline, silent=False): myaction=None myopts = {} - myfiles=[] actions = frozenset([ "clean", "check-news", "config", "depclean", "help", @@ -810,9 +809,11 @@ def parse_opts(tmpcmdline, silent=False): parser.add_argument(dest=myopt.lstrip("--").replace("-", "_"), *args, **kwargs) + parser.add_argument('positional_args', nargs='*') + tmpcmdline = insert_optional_args(tmpcmdline) - myoptions, myargs = parser.parse_known_args(args=tmpcmdline) + myoptions = parser.parse_args(args=tmpcmdline) if myoptions.alert in true_y: myoptions.alert = True @@ -1165,9 +1166,7 @@ def parse_opts(tmpcmdline, silent=False): if myaction is None and myoptions.deselect is True: myaction = 'deselect' - myfiles += myargs - - return myaction, myopts, myfiles + return myaction, myopts, myoptions.positional_args def profile_check(trees, myaction): if myaction in ("help", "info", "search", "sync", "version"): -- 2.21.0
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
On Sun, Oct 27, 2019 at 06:58:00PM +0100, Michał Górny wrote: > On Sun, 2019-10-27 at 12:40 -0500, William Hubbs wrote: > > Most upstreams and build systems do not make this distinction, so this > > causes unnecessary hacks in ebuilds. > > > > The hacks aren't 'unnecessary'. There is a very good reason that files > that are used *purely at build time* don't land in /. That reason is > disk space. Even if people nowadays are forced to use initramfs with > separate /usr, it doesn't mean you should just let their rootfs fill up > with useless files. The useless files argument really holds no water with me. We install many files on / that are useless in one situation or another. Some examples are logrotate files when logrotate isn't installed, systemd units for openrc systems and openrc init scripts for systemd systems. Talk to me about useless files on / after we put all of these, and possibly others I can't think of, behind use flags. > Do you have any *real* argument? Because 'unnecessary hack' is > basically your feeling of ebuild aesthetics. My aesthetics is more > worried about useless clutter in /lib*. FHS agrees with me, as you > yourself admitted yesterday. Any downstream hack means that we are being lazy and not reporting the bug upstream and asking them to fix it. This particular issue is not a big deal to any other distro and has never been. Shouldn't we try to get upstreams to do this if it is so important? > So why do you believe we should introduce this regression? And why are > you trying to sneak it past most of the developers via gentoo-portage- > dev instead of gentoo-dev? This attack is un called for. This list is as open as any other, and there is no need for you to make this out to be some kind of conspiracy theory to "sneak" something past the developers. William signature.asc Description: Digital signature
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
On Sun, 2019-10-27 at 12:40 -0500, William Hubbs wrote: > Most upstreams and build systems do not make this distinction, so this > causes unnecessary hacks in ebuilds. > The hacks aren't 'unnecessary'. There is a very good reason that files that are used *purely at build time* don't land in /. That reason is disk space. Even if people nowadays are forced to use initramfs with separate /usr, it doesn't mean you should just let their rootfs fill up with useless files. Do you have any *real* argument? Because 'unnecessary hack' is basically your feeling of ebuild aesthetics. My aesthetics is more worried about useless clutter in /lib*. FHS agrees with me, as you yourself admitted yesterday. So why do you believe we should introduce this regression? And why are you trying to sneak it past most of the developers via gentoo-portage- dev instead of gentoo-dev? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
Most upstreams and build systems do not make this distinction, so this causes unnecessary hacks in ebuilds. Signed-off-by: William Hubbs --- bin/install-qa-check.d/80libraries | 10 -- 1 file changed, 10 deletions(-) diff --git a/bin/install-qa-check.d/80libraries b/bin/install-qa-check.d/80libraries index d1d2c4fdd..e59369bf6 100644 --- a/bin/install-qa-check.d/80libraries +++ b/bin/install-qa-check.d/80libraries @@ -152,16 +152,6 @@ lib_check() { done [[ ${abort} == "yes" ]] && die "add those ldscripts" - # Make sure people don't store libtool files or static libs in /lib - f=$(ls "${ED%/}"/lib*/*.{a,la} 2>/dev/null) - if [[ -n ${f} ]] ; then - __vecho -ne '\n' - eqawarn "QA Notice: Excessive files found in the / partition" - eqawarn "${f}" - __vecho -ne '\n' - die "static archives (*.a) and libtool library files (*.la) belong in /usr/lib*, not /lib*" - fi - # Verify that the libtool files don't contain bogus $D entries. local abort=no gentoo_bug=no always_overflow=no for a in "${ED%/}"/usr/lib*/*.la ; do -- 2.23.0
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, Oct 27, 2019 at 08:36:47PM +1300, Kent Fredric wrote: > On Sat, 26 Oct 2019 18:55:11 -0500 > William Hubbs wrote: > > > Sure, but rebuild changes are exactly what you would want. that's how > > software written in go gets rebuilt for example, which is exactly what > > you want when go is upgraded. > > > > I agree that some rebuilds might be unnecessary, but if you don't like > > compiling/building software Gentoo isn't for you. > > > > William > > I suspect the problem might be moreso that --with-bdeps=y makes portage > prone to barf in this condition, not try recompiling. No one has said there is a bug in portage in this situation, so I'd rather not speculate until we have a bug report. If a build dep of something changes, the correct response with --with-bdeps=y is to rebuild everything that depends on the changed dep. William signature.asc Description: Digital signature
Re: [gentoo-dev] separate /usr without initramfs
On Sun, 27 Oct 2019 16:17:04 + Michael Everitt wrote: > On 27/10/19 16:12, Matt Turner wrote: > > On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot wrote: > >> On Sun, 27 Oct 2019 05:38:48 -0400 > >> Joshua Kinard wrote: > >> > >>> Why do I not like an initramfs, though? Well, for one, it complicates the > >>> kernel compiles (and it makes them bigger, something which is an issue on > >>> the old SGI systems at times). Two, it's another layer that I have to > >>> maintain. Three, it violates, in my mind, the simplicity of keeping the > >>> kernel and userland separated (e.g., kernel does kernel-y things, userland > >>> does userland-y things). > >> You make it sound like the initramfs has to be built into the kernel > >> image. It can be but it usually isn't. I suspect you know that though? > >> Admittedly that does depend on support from your bootloader. While GRUB > >> and U-Boot have supported this for years, I forget what oddball > >> bootloaders your hardware may be using. > > Though he's likely not using it, GRUB2 supports all the platforms he > > mentioned (x86, amd64, sparc64, [sgi] mips). > > > FWIW, I do believe I saw LILO mentioned .. https://wiki.gentoo.org/wiki/Early_Userspace_Mounting#Configuring_LILO Phew. ;-) Actually I was getting confused between initramfs support and device tree support. I think every bootloader has supported initramfs since forever. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpeQjlpCJruZ.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] separate /usr without initramfs
On 27/10/19 16:12, Matt Turner wrote: > On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot wrote: >> On Sun, 27 Oct 2019 05:38:48 -0400 >> Joshua Kinard wrote: >> >>> Why do I not like an initramfs, though? Well, for one, it complicates the >>> kernel compiles (and it makes them bigger, something which is an issue on >>> the old SGI systems at times). Two, it's another layer that I have to >>> maintain. Three, it violates, in my mind, the simplicity of keeping the >>> kernel and userland separated (e.g., kernel does kernel-y things, userland >>> does userland-y things). >> You make it sound like the initramfs has to be built into the kernel >> image. It can be but it usually isn't. I suspect you know that though? >> Admittedly that does depend on support from your bootloader. While GRUB >> and U-Boot have supported this for years, I forget what oddball >> bootloaders your hardware may be using. > Though he's likely not using it, GRUB2 supports all the platforms he > mentioned (x86, amd64, sparc64, [sgi] mips). > FWIW, I do believe I saw LILO mentioned .. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] separate /usr without initramfs
On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot wrote: > > On Sun, 27 Oct 2019 05:38:48 -0400 > Joshua Kinard wrote: > > > Why do I not like an initramfs, though? Well, for one, it complicates the > > kernel compiles (and it makes them bigger, something which is an issue on > > the old SGI systems at times). Two, it's another layer that I have to > > maintain. Three, it violates, in my mind, the simplicity of keeping the > > kernel and userland separated (e.g., kernel does kernel-y things, userland > > does userland-y things). > > You make it sound like the initramfs has to be built into the kernel > image. It can be but it usually isn't. I suspect you know that though? > Admittedly that does depend on support from your bootloader. While GRUB > and U-Boot have supported this for years, I forget what oddball > bootloaders your hardware may be using. Though he's likely not using it, GRUB2 supports all the platforms he mentioned (x86, amd64, sparc64, [sgi] mips).
[gentoo-dev] gcc-9 will go stable soon (say, in a week)
Hello world! toolchain@ plans to start stabilizing next major gcc version (gcc-9) in about a week at: https://bugs.gentoo.org/698646 Current target is =sys-devel/gcc-9.2.0-r1. If you think your bug should be absolutely addressed before that happens please add it as a blocker. Also feel free to cc toolchain@ explicitly on tricky build failures without clear path to resolution. We will figure something out together. gcc-9 had a few known breakages for existing code: https://wiki.gentoo.org/wiki/Project:Toolchain#gcc-9 (also see tracker below) gcc porting tracker still has 14 unresoved bugs: https://bugs.gentoo.org/685044: [TRACKER] sys-devel/gcc-9 porting [See dependency tree for bug 685044] https://bugs.gentoo.org/685714: sys-fs/bees-0.6 : error.cc:35:54: error: non-local lambda expression cannot have a capture-default [See dependency tree for bug 685714] https://bugs.gentoo.org/685798: sci-physics/lammps-20181212 : /.../kspace.cpp:280:3: error: nlocal not specified in enclosing parallel [See dependency tree for bug 685798] https://bugs.gentoo.org/685810: app-accessibility/speech-tools-2.1-r4 : ../.../EST_String.h:576:16: error: friend declaration of int fcompare(const EST_String&, const EST_String&, const unsigned char*) specifies default arguments and isn t a definition [-fpermissive] [See dependency tree for bug 685810] https://bugs.gentoo.org/685834: media-radio/xwxapt-3.3 : configure:5247: error: possibly undefined macro: AM_INTL_SUBDIR [See dependency tree for bug 685834] https://bugs.gentoo.org/685922: media-gfx/blender-2.79b-r1 : /.../utilities.h:84:67: error: gDebugLevel not specified in enclosing parallel [See dependency tree for bug 685922] https://bugs.gentoo.org/686010: dev-db/cockroach-2.0.1 : /.../version_edit.h:156:33: error: implicitly-declared constexpr rocksdb::FileDescriptor::FileDescriptor(const rocksdb::FileDescriptor&) is deprecated [-Werror=deprecated-copy] [See dependency tree for bug 686010] https://bugs.gentoo.org/686100: sys-fabric/libmlx5-1.0.1 : /.../string_fortified.h:106:10: error: _builtin_strncpy specified bound 1024 equals destination size [-Werror=stringop-truncation] [See dependency tree for bug 686100] https://bugs.gentoo.org/686108: media-sound/helm-0.9.0 : ../.../juce_PixelFormats.h:114:77: error: cannot bind packed field ((juce::PixelARGB*)this)->juce::PixelARGB::.juce::PixelARGBcomps[3] to juce::uint8& {aka unsigned char& [See dependency tree for bug 686108] https://bugs.gentoo.org/686162: sys-devel/byfl-1.6-r1 : helpers.cpp:63:11: error: TerminatorInst does not name a type [See dependency tree for bug 686162] https://bugs.gentoo.org/686228: sci-electronics/librepcb-0.1.0 : ../.../debug_assert.hpp:364:72: error: expected { before noexcept [See dependency tree for bug 686228] https://bugs.gentoo.org/686394: sys-apps/fwupdate-12 : fwupdate.c:529:8: error: taking address of packed member of struct update_info_s may result in an unaligned pointer value [-Werror=address-of-packed-member] [See dependency tree for bug 686394] https://bugs.gentoo.org/688634: app-misc/qlcplus-4.11.1 : qlcfixturemode.cpp:251:26: error: implicitly-declared QLCFixtureHead& QLCFixtureHead::operator=(const QLCFixtureHead&) is deprecated [-Werror=deprecated-copy] [See dependency tree for bug 688634] https://bugs.gentoo.org/690964: =media-libs/libopenshot-0.2.4_pre20190609 stabilization [See dependency tree for bug 690964] https://bugs.gentoo.org/691030: =x11-misc/polybar-3.3.1 stabilization Please give them some love. Otherwise they will not survive the update. Thank you! -- Sergei
Re: [gentoo-dev] separate /usr without initramfs
Joshua Kinard writes: > Put simply, the kernel's single purpose, as nothing more than a > hyper-complex while loop, is to get the hardware up into a usable state and > then hand off to userland, then sit and service userland's needs as called > upon. The kernel should have all of the subsystems loaded into it necessary > to accomplish this task. The fact that the userland, in the current > ill-conceived case, cannot get itself up and running simply because /usr is > on a yet-to-be-mounted partition is not a concern of the kernel's. Thus, > the loading of an initramfs into the kernel to solve this issue is, in > principle, a violation (and a Cthulhu-awful hack). > > Maybe I'm just a old codger who refuses to accept change. I'm fine with > that description. I like things to remain somewhat simple, and my view of > Linux, both kernel and userland, over the last few years is one of growing > dismay due to the constant introduction of subsystem layer atop subsystem > layer for very little gain. How much longer until we need a kernel to boot > the kernel to mount the userland that mounts the userland (yo dawg)? This a very well put argument that I find enjoyable reading. Thank you Joshua. Yours, Benda
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sun, 27 Oct 2019 01:42:48 + Michael Everitt wrote: > > I agree that some rebuilds might be unnecessary, but if you don't like > > compiling/building software Gentoo isn't for you. > > > > William > > > There's a subtle difference between compiling for compiling's sake, and > compiling with good reason .. especially for those who don't have copious > quantities of free cpu resources at their disposal 24/7/365 ... just sayin' > ... > > And not everyone is using rust, go, java and systemd as their prime movers, > even if you are .. *shudders* You do know that Rust code takes an age to compile, right? :P -- James Le Cuirot (chewi) Gentoo Linux Developer pgpCbzezD2Qtw.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] separate /usr without initramfs
On Sun, 27 Oct 2019 05:38:48 -0400 Joshua Kinard wrote: > Why do I not like an initramfs, though? Well, for one, it complicates the > kernel compiles (and it makes them bigger, something which is an issue on > the old SGI systems at times). Two, it's another layer that I have to > maintain. Three, it violates, in my mind, the simplicity of keeping the > kernel and userland separated (e.g., kernel does kernel-y things, userland > does userland-y things). You make it sound like the initramfs has to be built into the kernel image. It can be but it usually isn't. I suspect you know that though? Admittedly that does depend on support from your bootloader. While GRUB and U-Boot have supported this for years, I forget what oddball bootloaders your hardware may be using. > Maybe I'm just a old codger who refuses to accept change. I'm fine with > that description. I like things to remain somewhat simple, and my view of > Linux, both kernel and userland, over the last few years is one of growing > dismay due to the constant introduction of subsystem layer atop subsystem > layer for very little gain. How much longer until we need a kernel to boot > the kernel to mount the userland that mounts the userland (yo dawg)? Isn't that what the BIOS and bootloader do? On the plus side, you can now boot straight from UEFI to kernel without a bootloader but on the other hand, UEFI is horrifically over-complex. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpO0JiOpKI14.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] separate /usr without initramfs
On 10/25/2019 14:14, William Hubbs wrote: > Hey all, > > I have been advised to bring this topic back to the list before taking > any action, so here it is. > > First, I need to clarify what I'm *NOT* talking about. > > This discussion has nothing to do with whether or not you have the > split-usr use flag turned on; all of us officially have that on because > /bin, /lib* and /sbin are directories in the official Gentoo setup. In > other words, I am *not* talking about forcing the /usr merge. > > Unfortunately, the concept of separate usr has gotten wrapped up in the > split-usr use flag and doesn't have to be. For the record, I mean something > very specific when I say "separate usr". I am talking about the situation > where /usr is a mount point separate from /, so in this thread, let's stick > to "separate usr" for that situation. I am *not* even saying that using > separate usr is wrong or unsupported. You can even run separate usr with > split-usr turned off if you would like to do so. > > Now for the use case I want to talk about, and that is using separate > /usr without using an initramfs to boot your system and pre-mount /usr. > > If you do this, many things are broken, and this is why the binary > distros all use an initramfs if you do this. This configuration is also > unsupported officially in Gentoo [1] [2], and it is not shown as the > example setup in our handbook. > > I want to hear from people who have / and /usr on separate partitions > and who are not using an initramfs. > > If you are in this group, I have a very specific question. Why aren't > you using an initramfs? > > Thanks, > > William I use this approach. /usr is its own partition (usually /dev/sda6 in my buildouts), and it mounts a few seconds after init is started. I've been doing it this way on multiple architectures (x86, amd64, sparc64, mips) since pretty much 2003, when I first started experimenting w/ Gentoo and later went on to become a developer. None of my existing Gentoo installs have *ever* needed an initramfs to boot with /usr on a separate partition. Yes, there's a small bit in OpenRC that whines apparently, but I have not seen any ill effects. My hardware layout is fairly static. amd64 box uses hardware RAID5 (LSI/3Ware 9750), and LILO as bootloader, and the SGI machines use MD-RAID in either RAID1 or RAID5 mode, and they all netboot (manually). Maybe it's because I stick to very simplistic builds, that I've avoided problems. :: shrug :: Why do I not like an initramfs, though? Well, for one, it complicates the kernel compiles (and it makes them bigger, something which is an issue on the old SGI systems at times). Two, it's another layer that I have to maintain. Three, it violates, in my mind, the simplicity of keeping the kernel and userland separated (e.g., kernel does kernel-y things, userland does userland-y things). Put simply, the kernel's single purpose, as nothing more than a hyper-complex while loop, is to get the hardware up into a usable state and then hand off to userland, then sit and service userland's needs as called upon. The kernel should have all of the subsystems loaded into it necessary to accomplish this task. The fact that the userland, in the current ill-conceived case, cannot get itself up and running simply because /usr is on a yet-to-be-mounted partition is not a concern of the kernel's. Thus, the loading of an initramfs into the kernel to solve this issue is, in principle, a violation (and a Cthulhu-awful hack). Maybe I'm just a old codger who refuses to accept change. I'm fine with that description. I like things to remain somewhat simple, and my view of Linux, both kernel and userland, over the last few years is one of growing dismay due to the constant introduction of subsystem layer atop subsystem layer for very little gain. How much longer until we need a kernel to boot the kernel to mount the userland that mounts the userland (yo dawg)? And there's that tiny, tiny issue of some kiddos from another, commercial, distribution that just up and declared one day that the idea of /usr-on-another-partition was "broken", and they then used their market position to effectively force all other distributions to bow to their belief. I took, and still to this day, take, great umbrage at that. I'll probably never get over it. Surely, if it works for me on multiple systems *today*, it can't be broken, right? It certainly was *not* broken back then. So why change it? Why completely reinstall all of my systems because non-Gentoo developers said something I did was wrong? No, I don't play that game. Oh, and for a technical reason, I like setting mount flags on partitions like /usr, /var, and /tmp for security. It's really as simple as that. All of the fluff above is just the philosophical pudding that I use to justify my obstinance. --- That all said, I've fallen madly in love with ZFS. I've got two network appliances and an old laptop running FreeBSD
Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual
On Sat, 26 Oct 2019 18:55:11 -0500 William Hubbs wrote: > Sure, but rebuild changes are exactly what you would want. that's how > software written in go gets rebuilt for example, which is exactly what > you want when go is upgraded. > > I agree that some rebuilds might be unnecessary, but if you don't like > compiling/building software Gentoo isn't for you. > > William I suspect the problem might be moreso that --with-bdeps=y makes portage prone to barf in this condition, not try recompiling. pgpwC9Ho96hFA.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: net-analyzer/zabbix
# Michał Górny (2019-10-27) # Unpatched privilege escalation vulnerability for over two years. # A lot of other unresolved bugs. # Removal in 30 days. Bug #629882. net-analyzer/zabbix -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Package up for grabs: x11-misc/revelation
Hi, I've dropped maintainership of x11-misc/revelation (a password manager). I'm no longer using it and it has not seen an active upstream for some time. Compatibility issues with python components have been fixed so the current stable version should be good to go for a bit. Hans signature.asc Description: This is a digitally signed message part