Bouncing messages from gentoo-dev@lists.gentoo.org

2019-10-27 Thread gentoo-dev+owner


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

2019-10-27 Thread Andreas Sturmlechner
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

2019-10-27 Thread Robin H. Johnson
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

2019-10-27 Thread Kent Fredric
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

2019-10-27 Thread Joshua Kinard
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

2019-10-27 Thread Joshua Kinard
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 /

2019-10-27 Thread Michał Górny
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

2019-10-27 Thread Rolf Eike Beer
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)

2019-10-27 Thread Zac Medico
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 /

2019-10-27 Thread William Hubbs
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 /

2019-10-27 Thread Michał Górny
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 /

2019-10-27 Thread William Hubbs
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

2019-10-27 Thread William Hubbs
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

2019-10-27 Thread James Le Cuirot
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

2019-10-27 Thread Michael Everitt
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

2019-10-27 Thread Matt Turner
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)

2019-10-27 Thread Sergei Trofimovich
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

2019-10-27 Thread Benda Xu
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

2019-10-27 Thread James Le Cuirot
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

2019-10-27 Thread James Le Cuirot
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

2019-10-27 Thread Joshua Kinard
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

2019-10-27 Thread Kent Fredric
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

2019-10-27 Thread Michał Górny
# 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

2019-10-27 Thread Hans de Graaff
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