Re: [gentoo-user] Machine hangs up with out of memory

[Kai Peter]

On 2021-04-30 12:09, Michael wrote:


However, the OP problem here seems to be with a leaky BIND?

I found this mentioned upstream - but have not check BGO:

https://gitlab.isc.org/isc-projects/bind9/-/issues/446


Thanks for reply. rndc runs on other machines daily, but not on this 
one.


Right now I have corrected my bind config and the memory usage is stable 
by 700MB. The issue here was the statement "listen-on-v6 { any; };". 
bind was trying repeatedly to bind ipv6 to br0 and tap{0,1} devices - 
and fails.


The memory usage is stable since 3 days:

$>ps axuww | grep named
named14414  0.2  1.4 735040 116952 ?   Ssl  Apr29   4:38 
/usr/sbin/named -u named


$>free -h
   totalusedfree  shared  buff/cache   
available
Mem:   7.5Gi   480Mi55Mi   0.0Ki   7.0Gi 
  6.9Gi

Swap:   23Gi   378Mi23Gi

Lets see what happens after the next update cycle.

Re: [gentoo-user] Machine hangs up with out of memory

[Kai Peter]

On 2021-04-29 08:59, J.O. Aho wrote:

Your named is taking up 7G or memory, are you sure your configuration
is correct?
Thanks, good point. There were errors in the logs. I will investigate 
and monitor it.



--

 //Aho

[gentoo-user] Machine hangs up with out of memory

[Kai Peter]

Hi,

I have an issue with a machine where I'm not able to detect the real 
root cause. It hangs up totally. It seems like it was running out of 
memory - but why? Hopefully somebody can give me some insight. As far I 
can see right now, it hangs up a few hours after an `emerge --update 
--newuse --deep --with-bdeps=y @world`.


The machine is an Intel Atom with 8 GB RAM (physical, max) and 24 GB 
swap (a file). So 32 GB RAM in total. It has a 250GB SSD. It runs 
gentoo-sources-4.14.83 build with genkernel. Portage uses the stable 
tree only. It basically provides the hardware for a qemu VM which does 
the network management: primary ns, dhcp, apache ssl proxy. This VM uses 
4 GB RAM and has 8 GB swap file. The VM works smoothly. The atom machine 
itself acts further as basic nfs server to an independent dedicated 
server - which does the (re)exports - and as secondary ns. For this I'm 
convinced that 32GB RAM total have to be enough - correct me if I'm 
wrong!


The issue starts round about in February (IIRC). The update of gcc-10.2 
did fail. I have /var/tmp/portage on tmpfs - I did increase the size in 
fstab from 8 to 16 GB. Afterwards gcc build successfully.


After two hang-ups I did increase the swap from 8 to 24 GB. It doesn't 
help. Here is a complete log from /var/log/messages:


Apr 28 05:35:57 Syrin kernel: [1454017.499919] isc-net- invoked 
oom-killer: gfp_mask=0x14201ca(GFP_HIGHUSER_MOVABLE|__GFP_COLD), 
nodemask=(null),  order=0, oom_score_adj=0
Apr 28 05:35:57 Syrin kernel: [1454017.499925] isc-net- cpuset=/ 
mems_allowed=0
Apr 28 05:35:57 Syrin kernel: [1454017.499933] CPU: 0 PID: 27685 Comm: 
isc-net- Not tainted 4.14.83-gentoo #1
Apr 28 05:35:57 Syrin kernel: [1454017.499935] Hardware name: MSI 
MS-7877/J1900I, BIOS V1.2 03/25/2014

Apr 28 05:35:57 Syrin kernel: [1454017.499936] Call Trace:
Apr 28 05:35:57 Syrin kernel: [1454017.499948]  dump_stack+0x67/0x98
Apr 28 05:35:57 Syrin kernel: [1454017.499954]  dump_header+0x94/0x20c
Apr 28 05:35:57 Syrin kernel: [1454017.499958]  
oom_kill_process+0x24a/0x420
Apr 28 05:35:57 Syrin kernel: [1454017.499962]  ? 
oom_badness.part.9+0xd3/0x150

Apr 28 05:35:57 Syrin kernel: [1454017.499965]  out_of_memory+0xf9/0x290
Apr 28 05:35:57 Syrin kernel: [1454017.499968]  
__alloc_pages_nodemask+0xf48/0xff0
Apr 28 05:35:57 Syrin kernel: [1454017.499974]  
filemap_fault+0x294/0x4c0
Apr 28 05:35:57 Syrin kernel: [1454017.499979]  
ext4_filemap_fault+0x2c/0x40

Apr 28 05:35:57 Syrin kernel: [1454017.499983]  __do_fault+0x1f/0xb0
Apr 28 05:35:57 Syrin kernel: [1454017.499986]  
__handle_mm_fault+0x3ed/0xad0
Apr 28 05:35:57 Syrin kernel: [1454017.41]  
handle_mm_fault+0xaa/0x1f0
Apr 28 05:35:57 Syrin kernel: [1454017.46]  
__do_page_fault+0x250/0x4f0

Apr 28 05:35:57 Syrin kernel: [1454017.50]  ? page_fault+0x2f/0x50
Apr 28 05:35:57 Syrin kernel: [1454017.53]  page_fault+0x45/0x50
Apr 28 05:35:57 Syrin kernel: [1454017.55] RIP: :  
(null)
Apr 28 05:35:57 Syrin kernel: [1454017.57] RSP: 
12f83750:0001 EFLAGS: 7ffa12f837a0

Apr 28 05:35:57 Syrin kernel: [1454017.500010] Mem-Info:
Apr 28 05:35:57 Syrin kernel: [1454017.500017] active_anon:1694713 
inactive_anon:211859 isolated_anon:0
Apr 28 05:35:57 Syrin kernel: [1454017.500017]  active_file:328 
inactive_file:344 isolated_file:32
Apr 28 05:35:57 Syrin kernel: [1454017.500017]  unevictable:1374 dirty:0 
writeback:0 unstable:0
Apr 28 05:35:57 Syrin kernel: [1454017.500017]  slab_reclaimable:4480 
slab_unreclaimable:7449
Apr 28 05:35:57 Syrin kernel: [1454017.500017]  mapped:1071 shmem:3 
pagetables:16352 bounce:0
Apr 28 05:35:57 Syrin kernel: [1454017.500017]  free:11655 free_pcp:534 
free_cma:0
Apr 28 05:35:57 Syrin kernel: [1454017.500021] Node 0 
active_anon:6778852kB inactive_anon:847436kB active_file:1312kB 
inactive_file:1376kB unevictable:5496kB isolated(anon):0kB 
isolated(file):128kB mapped:4284kB dirty:0kB writeback:0kB shmem:12kB 
writeback_tmp:0kB unstable:0kB all_unreclaimable? yes
Apr 28 05:35:57 Syrin kernel: [1454017.500026] DMA free:15836kB min:20kB 
low:32kB high:44kB active_anon:0kB inactive_anon:0kB active_file:0kB 
inactive_file:0kB unevictable:0kB writepending:0kB present:15920kB 
managed:15836kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB 
free_pcp:0kB local_pcp:0kB free_cma:0kB
Apr 28 05:35:57 Syrin kernel: [1454017.500027] lowmem_reserve[]: 0 2664 
7647 7647
Apr 28 05:35:57 Syrin kernel: [1454017.500036] DMA32 free:23732kB 
min:3892kB low:6620kB high:9348kB active_anon:2319992kB 
inactive_anon:363260kB active_file:0kB inactive_file:92kB 
unevictable:0kB writepending:0kB present:2825512kB managed:2734888kB 
mlocked:0kB kernel_stack:140kB pagetables:22572kB bounce:0kB 
free_pcp:1136kB local_pcp:476kB free_cma:0kB
Apr 28 05:35:57 Syrin kernel: [1454017.500037] lowmem_reserve[]: 0 0 
4982 4982
Apr 28 05:35:57 Syrin kernel: [1454017.500045] Normal free:7052kB 
min:7284kB low:12384kB high:17484kB active_anon:4458860kB 

Re: [gentoo-user] swaps mounted randomly

[Kai Peter]

On 2020-03-05 21:01, n952162 wrote:

On 2020-03-05 18:26, Wols Lists wrote:

On 04/03/20 10:19, n952162 wrote:
Yes, everything mounts when I explicitly say swapon -a. No problems 
in

/var/log/messages.

I wonder. Is mount order deterministic at boot? Is it possible that
you're trying to activate the swap files before the underlying file
systems are mounted?

Cheers,
Wol



Yes, that's an issue ... there's two swap files.  One is on the root 
dir

and that one is the only one that came up active when I started the
system this morning.

The other one is on a mounted fs.  Earlier, I'd had it on the following
line to that fs, and as an admittedly feeble attempt, I moved that
swapon to the bottom of the file - who knows if those lines are
processed sequentially.  But it didn't help.

But, the thing is, the swap partition is also not mounted by its fstab
entry.  That wouldn't need an fs to be mounted.


As a workaround you can add swapon -a to local.start ...
--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] Number of open Bugzilla bugs

[Kai Peter]

On 2020-02-15 01:46, Rich Freeman wrote:

On Fri, Feb 14, 2020 at 7:25 PM Marc Joliet  wrote:


personally, I care about closing bugs that are done with or
can't be acted upon.


As do I.


I honestly think it would
be best to close bugs that are just not applicable anymore, e.g., for 
ebuilds
or versions of packages that have not been in the tree for a looong 
time,


Certainly.


like, say, HAL: https://bugs.gentoo.org/401257.


That isn't a HAL bug - it is a bug for a relatively recent version of 
pm-utils.
This is one of the issues with a general discussion of overridden 
points: switch to an unimportant detail (of an example).


I'm not sure if the bug is still an issue, but it could very well be.
You don't know, I don' know, nobody is sure, so maybe it could be 
possible (perhaps) that it could be happen (under some circumstances) 
that the package with major version 2 - which is replaced by major 
version 3 already (since some time) - ...  hm, in the meanwhile I did 
forget what I wanted to say. So keep all like it is (sarcasm).


And that is the issue with just closing bugs because they're old.
They can still be issues.
Seeing this as an issue is less than ...  - to me it is wasted time and 
resources(?). Just as above.


My way was (and is?) similar to Marc's and Mark's one. I couldn't agree 
with some changes in the direction Gentoo is going. It looks a bit like 
swarm intelligence. I don't make everything right, but I do think - NOT 
believe!. And I'm able to see/correct the cases when I did things wrong.


Nothing personal, just IMHO. Will I get banned from this list now?



If an issue no longer exists then of course the bug should be closed.

Why doesn't this not happen?

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] Number of open Bugzilla bugs

[Kai Peter]

On 2020-02-11 00:06, Rich Freeman wrote:



Nevertheless, thank you for discussing it with me



You're welcome.  You're hardly the first person to disagree with me.  
:)


I'm also not in any particular position of power when it comes to how
bugs are handled.  You can always make a proposal to automatically
close old bugs.  I'd probably start with the Bug Wranglers, though you
could always bring an issue to the Council if you don't feel you're
getting the desired response there.  They've certainly been known to
disagree with me at times too.  :)


Interesting discussion. To bad that it's over. Not so much from the 
technical site, but the different POV's. Michael tries to improve 
things, make things better. Rich stays with the common 'it is like it is 
and it is good'. An example to the big view:


https://web.archive.org/web/20080331092730/http://www.linux.com/articles/60124

Even if I tend to Michael's side, I don't say Rich is wrong. To me the 
truth is in the middle, always.


--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Kai Peter]

On 2019-08-08 09:43, Neil Bothwick wrote:

On Wed, 07 Aug 2019 14:24:22 +0100, Mick wrote:


> As opposed to splitting binaries across four directories based on
> arbitrary decisions made in the last century? :P

LOL!  You're missing the most important part:  across different fs and
partition layouts.

Look, the pyramids were built before the last century, but that 
doesn't

mean we should try to balance them upside down if they work fine as
they are.


Why not? As long as it's optional and controlled by a USE flag :)


Clearly different use cases have different requirements and
correspondingly different optimal solutions.  Can I please keep my
bin/sbin directories separate and ditto for /usr and its subbies?  :-)


The /usr / split makes sense when you want different filesystems,
something I used to do but don't have any need for now. I've yet to see 
a

convincing argument for the bin/sbin split in either location.


Let me jump back into this hi-jacked thread somewhere. Unfortunately I 
didn't found an answer to the future directions at gentoo regarding the 
usr merge. And my fear is that the merge will be forced. As I use gentoo 
as a meta distro really, this change _could_ be put _me_ into trouble. 
But my 'gentoo-lfs' is not the typical use case.


Now, even that there are my individual requirements behind, some short 
points of my POV to some points in the whole thread. All IMHO.


An initramfs is a elegant and - more important - a very flexible 
solution. It is not required, but it makes things easier. It could solve 
more things than having /usr at a separate fs or loading drivers. I 
would also define it as a bootloader (like Rich) in a chain. More 
abstract I would see a classical bootloader like grub as a kernel by 
itself.


I see 3 stages of security concerns of an initramfs:

1. trust yourself and build your own one
2. trust gentoo and use gentoo's initramfs
3. download one (from a warez site) and stay hacked

The usr merge itself is questionable workaround to consolidate things. 
Now, a consolidation is a good thing in general. But what is the real 
difference to have a symlink /bin against having a folder? I couldn't 
follow the given arguments.


The core issue is the under laying folder structure. And depending on 
this hard coded path's. We still relying at a 50 years old concept - and 
time was moving on. Don't ask, I haven't a solution (yet). Just the 
dream/vision of the perfect system :). One point of the vision is to 
have a core (linux) OS (e.g. an extended stage3) separated from all user 
programs (similar to a ring0 kernel isolation).


From all exiting concepts and implementations the best parts should be 
used. Not sure if this is ever possible. But forcing users to use a 
solution which is not required by 99% of them is a very bad thing. These 
'1-percent-solutions' have to be optional.


Anyway, just an opinion beside the mainstream. I encourage people to 
have their own. :) It is not hard to create pro and con arguments. And I 
left enough room for misunderstandings.



--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Kai Peter]

On 2019-08-04 20:01, Dale wrote:


It was discussed on -dev in at least a couple threads I think.  I sort


Thanks for that good hint. I did browse through the archives.

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

[gentoo-user] USE flag 'split-usr' is now global

[Kai Peter]

Hi,

now, upstream made the USE flag 'split-usr' global. This puts me a bit 
in a state of uncertainty :(.


What is the reason or goal behind this change? I did read something 
about the flag itself but it wasn't really clear to me. What does this 
mean:


"Enable behavior to support maintaining /bin and /lib separately from 
/usr/bin and /usr/lib"


Maybe I have overseen some documentation?

regards
Kai

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] 17.1 profiles and no-multilib layout

[Kai Peter]

On 2019-06-21 10:44, Mick wrote:

On Friday, 21 June 2019 08:56:34 BST Kai Peter wrote:

Hi,

I couldn't find an appropriate documentation for this, so it is not
clear to me how a __no-multilib__ layout looks like with 17.1 
profiles.

All for amd64.

With 17.0-no-multilib '/lib' is a symlink to '/lib64'. For
17.1-no-multilib I see 4 possibilities:

1. no change

2. both '/lib' and '/lib64' are directories (don't expect this, but 
it's

possible)

3. 'lib64' is a symlink to '/lib'

4. only one folder '/lib' __OR__ 'lib64' exists

With an eye to lfs I would expect to have one '/lib' only. Did anybody
the switch already and can tell me what happens?

Thanks
Kai


On my amd64 no-multilib system there is of course no /lib32 or 
/usr/lib32.


There are:

$ ls -ld /lib*
drwxr-xr-x 11 root root  4096 Jun  7 13:23 /lib
drwxr-xr-x  8 root root 12288 Jun 14 23:42 /lib64

and

$ ls -ld /usr/lib*
drwxr-xr-x  21 root root   4096 Jun 15 00:06 /usr/lib
drwxr-xr-x 104 root root 159744 Jun 19 08:15 /usr/lib64
drwxr-xr-x  18 root root   4096 Jun 14 23:54 /usr/libexec

all of which as you can see are real directories.


Thanks.
--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

[gentoo-user] 17.1 profiles and no-multilib layout

[Kai Peter]

Hi,

I couldn't find an appropriate documentation for this, so it is not 
clear to me how a __no-multilib__ layout looks like with 17.1 profiles. 
All for amd64.


With 17.0-no-multilib '/lib' is a symlink to '/lib64'. For 
17.1-no-multilib I see 4 possibilities:


1. no change

2. both '/lib' and '/lib64' are directories (don't expect this, but it's 
possible)


3. 'lib64' is a symlink to '/lib'

4. only one folder '/lib' __OR__ 'lib64' exists

With an eye to lfs I would expect to have one '/lib' only. Did anybody 
the switch already and can tell me what happens?


Thanks
Kai

--
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

Re: [gentoo-user] Preventing new versions of gentoo-sources…

[Kai Peter]

On 2019-06-20 20:10, Dale wrote:

Kai Peter wrote:


The bad thing about this, sometimes I have to use exclude 
gentoo-sources
from things such as --depclean.  It's annoying but it's the only way 
I

could come up with to do this. 


You can do an 'emerge --noreplace' - one time.




I read the man page for this option, I'm not sure how it would help. 
All that does is prevent it from recording that it is installed in the
world file.  Since I have -1 set as a default, it does that when I
emerge single packages already.  If I want to keep it and it not be
--depcleaned, then I use -n --select y to add it to the world file. 
Thing is, some packages require some sort of kernel to be installed as 
a

dependency last I checked. 

Or am I missing something?

Dale

:-)  :-) 
It is just to exclude a gentoo-sources version from depclean. I assumed 
you do something like this:


$> emerge -c --exclude=gentoo-sources:4.14.83

and may be multiple times. With --noreplace the corresponding version 
will be omitted, so a simple 'emerge -c' would be enough.


Anyway, I did struggle with this gentoo-sources thing a long time ago. I 
want to have the latest stable (minor) version (patch) of the running 
kernel installed as well the newest stable one. As long as it is not 
compiled and booted is uses only some disk space. If I have compiled the 
kernel I use e.g. 'emerge --noreplace gentoo-sources:4.14.83' to keep 
it.


To get the latest patch version I have ...package.mask/gentoo-sources. 
For the latest stable sources I remove the file and re-create it 
afterwards. This is done by a cron job automatically. A little bit like 
this ('gentoo-sources' contains: ">=sys-kernel/gentoo-sources-4.15")


FN="${PORTAGE_CONFIGROOT}/etc/portage/package.mask/gentoo-sources"
emerge -u gentoo-sources
TMP=`cat $FN`
rm -f $FN
emerge -u gentoo-sources
echo $TMP > $FN

Just my way. To me it is important to have a high level of automation. 
With automation it is unimportant how many gentoo-sources kernels are 
installed. I remove obsolete ones periodically by hand.


Kai
--
Sent with eQmail-1.10.2 - a fork of djb's famous qmail

Re: [gentoo-user] Preventing new versions of gentoo-sources…

[Kai Peter]

The bad thing about this, sometimes I have to use exclude 
gentoo-sources

from things such as --depclean.  It's annoying but it's the only way I
could come up with to do this. 


You can do an 'emerge --noreplace' - one time.

--
Sent with eQmail-1.10.1 beta - a fork of djb's famous qmail

Re: [gentoo-user] Not enough RAM for dev-qt/qtwebengine build

[Kai Peter]

It's the first time when I encountered a problem like this on my
system and now I'm thinking how to deal with it. Has anyone dealt with
this? Is there any solutions other than buying more RAM  (I don't need
more RAM for my work/entertainment right now)?

Thanks in advance.


You can use more swap (files) before buying more RAM.

--
Sent with eQmail-1.10.2 - a fork of djb's famous qmail

Re: [gentoo-user] Re: Coming up with a password that is very strong.

[Kai Peter]

On 2019-02-05 22:17, Neil Bothwick wrote:

On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote:


My own solution is actually very simple. I have a "secret algorithm"
that incorporates several secrets with a predictable way to generate a
site-specific secret. The end result is a 100% predictable way to
generate unique passwords for every site that are cryptographically
secure from each other (you cannot derive
one from the other) which can be generated by any device using the
appropriate tools.


The was a tool in portage this did this. I tried it but it did not work
in the real world because you couldn't set a rule for generated 
passwords

that matched the requirements of all sites, for example some require a
non-alphanumeric character while other sites only allow alphanumerics.

I can remember what the tools was called, although I'm pretty sure it
was written in Python. I'd be interested to know how you get around the
conflicting restrictions as this seems a good way to do things.


By using an existing tool you have to live with its restrictions always. 
But who says that it could not be done? At least Mark's solution will 
(maybe) not work for everybody (yet), but he did think about an issue 
and found a way/solution which sounds really reasonable.


--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Pick your hypothesis:

[Kai Peter]

On 2019-01-24 21:59, Michael Jones wrote:



You really can't run Gentoo safely for very long without paying

close attention to what you are doing - with both installs and
upgrades.

I don't know that this is true. I've had the same set of use flags
configured on all of my Gentoo computers for 5-ish years now, and I've
only very rarely messed with them. For the most part, running
"eix-sync && emerge --update --newuse --deep @world" once a week has
allowed me to have unattended upgrades for many months at a time, only
needing to adjust one or two things every several months. Needing to
tweak something is my exception, not my rule.
+1. That's a core point to me. An update once a week and adjusting USE 
flags (down) to the _real_ requirements makes multiple Gentoo 
installations long term stable.


Happy compiling :-)


--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: OT scripting - strip zero if between period and digit

[Kai Peter]

On 2019-01-25 18:31, Michael Orlitzky wrote:

On 1/25/19 11:32 AM, Kai Peter wrote:


Really interesting _how_ people think. Find the error:



You're not even trying:

  $ echo 0.0.0.0 | sed 's/\.0/\./g' | sed 's/^0//g' | \
sed 's/\.0/\./g' | sed 's/\.\./.0./g' | sed 's/^0//g'
  .0..


True, but that wasn't requested.


It's trivial to enumerate all "valid" (that is, without leading zeros)
IP addresses. The most basic test that any regex should pass is that it
should do nothing on those examples.

+1

--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: OT scripting - strip zero if between period and digit

[Kai Peter]

On 2019-01-24 17:40, Michael Orlitzky wrote:

On 1/24/19 4:00 AM, Gerrit Kühn wrote:


---
[me@you ~]# ip=01.02.00.0004; for d in $(echo "${ip}"|tr '.' '\n');
do myip="${myip}"$(printf "%i" "${d}")"." ; done; echo ${myip%.}
1.2.0.4


That turns "010" into "8". Using a real programming language with a
parser is only heavyweight compared to solutions that don't work.

  $ ip=01.02.00.010; for d in $(echo "${ip}"|tr '.' '\n'); \
do myip="${myip}"$(printf "%i" "${d}")"." ; done; echo ${myip%.}
  1.2.0.8

Really interesting _how_ people think. Find the error:

echo 01.02.00.010 | sed 's/\.0/\./g' | sed 's/^0//g' | sed 's/\.0/\./g' 
| sed 's/\.\./.0./g' | sed 's/^0//g'




--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: OT scripting - strip zero if between period and digit

[Kai Peter]

On 2019-01-23 18:26, Neil Bothwick wrote:

On Wed, 23 Jan 2019 14:09:45 - (UTC), Grant Edwards wrote:


> How about this one?
>
> echo '198.088.0.01
> 198.088.062.01' | sed 's/\.0\([0-9][0-9]*\)/.\1/g'
> 198.88.0.1
> 198.88.62.1

Also no.

$ echo 198.088.0.001 |   sed 's/\.0\([0-9][0-9]*\)/.\1/g'
198.88.0.01


This is like playing Whack-a-Mole with sed ;-)


That's the fun ;-)

I think the truth is in the middle between a twelve-pages-script and a 
one-liner. Split it, 'sed' it, check result, correct result if required, 
combine it.


--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Emerge --sync fails on excluded stuff

[Kai Peter]

On 2018-10-22 16:26, Walter Dnes wrote:

I have a 10 year old Core2 as an emergency backup machine.  Let's just
say it's not as fast as modern machines.  To speed up "emerge --sync". 
I

put a bunch of unneeded stuff in an "rsync_excludes" file (attached).
Now "emerge --sync" has started failing, because it obviously can't
verify the missing directories/files.  Here's the error message...

 * Manifest timestamp: 2018-10-22 13:08:41 UTC
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
 * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
 * - timestamp: 2018-10-22 13:08:41 UTC
 * Verifying /usr/portage/.tmp-unverified-download-quarantine ...!!!
Manifest verification failed:
Manifest mismatch for app-dicts/Manifest.gz
  __exists__: expected: True, have: False


  app_dicts is the first entry in my "rsync_excludes", and I assume 
that

all the other entries would be problematic too.  How do I turn off this
bleeping "helpful" verification feature?


It fails at the first exclude entry always - I wrote this already. The 
whole manifest verification is buggy like hell - not well deliberated. 
Even if you sync from a local mirror it loads the key from the default 
key server. My suggestion is to disable it if you don't stay with the 
default.


--
Sent with eQmail-1.11 beta - a fork of djb's famous qmail

Re: [gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Kai Peter]

On 2018-07-22 12:24, Ralph Seichter wrote:

On 22.07.2018 09:27, Kai Peter wrote:


A bit more easier is to create an 'empty' virtual ebuild which at
least does nothing but tells portage the dependency is fulfilled.


Not a good choice, IMO. Portage has its own mechanism for that:
https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided

-Ralph


It was related to Ian's suggestion of an extra ebuild. And 
package.provided have to be configured at each host by hand wich is a 
big effort if you have a lot of boxes.

--
Sent with eQmail-1.11 beta - a fork of the djb's famous qmail

Re: [gentoo-user] Re: Heads up: Gentoo fouls up mail transport agent.

[Kai Peter]

On 2018-07-22 04:11, Ian Zimmerman wrote:

On 2018-07-21 23:04, Grant Edwards wrote:


Manually installing things in /usr/bin or /usr/sbin will often cause
problems because Portage assumes that it controls those directories.

So don't do that: you should manually install things in /usr/local.

Or, install qmail using portage, so that the system knows you have an
MTA. If you don't like the default qand make both available in a local 
repo.mail ebuild for some reason, you

can use your own.

Or, tell Portage you have an MTA by adding an appropriate line to
/etc/portage/profie/package.provided.  See portage(5).

Or, don't use Gentoo if you don't want to do things the way Gentoo
does things.


I agree than one should not normally install hand-compiled programs in
the normal directories controlled by portage.  I can see how the case 
of


+1, this should (MUST) be a general rule.


MTA can tempt someone into violating that rule, though:  unlike most of
all other cases where a program is called by other programs, the path 
to

/usr/sbin/sendmail is usually hardcoded, and there is no well known
environment variable either (like EDITOR or PAGER). mutt has a runtime
configuration option for the MTA but that's unusual.



The /usr/sbin/sendmail convention is one of the parts of Unix that,
honestly, sucks.  With repeated and prolonged exposure one can get
irritated enough to turn Poettering :-P


Really true, but it is like it is :(


On Gentoo the best way is to make your own package from your favorite


The effort for an ebuild of an individual package is usually to high.

MTA _and_ your own virtual/mta, and make both available in a local 
repo.

Recently I discovered dma[1] which IMHO is the _best_ lightweight MTA
for client machines, so now I have a Gentoo package for it.


A bit more easier is to create an 'empty' virtual ebuild which at least 
does nothing but tells portage the dependency is fulfilled. This can be 
done in general for each unwanted dependency/package. For sure 
self-compiled programs have to be installed outside of portage 
controlled directories.


Alternative one can use in this particular case nail (or mailx) to 
fulfil the virtual/mta dep. It doesn't listen on port(s), provides all 
expected binaries and usually doesn't conflict with an individual mta. 
As a side effect scripts can be written more portable.



--
Sent with eQmail-1.11 beta - a fork of the djb's famous qmail

Re: [gentoo-user] Multilib blues continues

[Kai Peter]

On 2018-07-05 09:09, Zoltán Kócsi wrote:

The */* x86_ ... in the use file and asking emerge to re-build the
libraries is pretty cool for building both 64 and 32 bit libs.

But it has it's problems, it seems.
The library libcap fails to compile with some spectacular errors:

--
x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -Wall -Wwrite-strings
-Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -Wall
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline
-Wshadow -g  -fPIC
-I/var/tmp/portage/sys-libs/libcap-2.24-r2/work/libcap-2.24-abi_x86_32.x86/libcap/../libcap/include/uapi
-I/var/tmp/portage/sys-libs/libcap-2.24-r2/work/libcap-2.24-abi_x86_32.x86/libcap/../libcap/include
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -c cap_file.c -o
cap_file.o
In file included from :0:0:
./_caps_output.gperf:71:80: error: unknown type name 'size_t'
 gperf_case_strncmp (register const char *s1, register const char *s2,
register size_t n)

 ^~
./_caps_output.gperf:96:53: error: unknown type name 'size_t'
 __cap_hash_name (register const char *str, register size_t len)
 ^~
./_caps_output.gperf:197:55: error: unknown type name 'size_t'
 __cap_lookup_name (register const char *str, register size_t len)
   ^~
./_caps_output.gperf:197:1: error: conflicting types for 
'__cap_lookup_name'

 __cap_lookup_name (register const char *str, register size_t len)
 ^
./_caps_output.gperf:33:29: note: previous declaration of
'__cap_lookup_name' was here
 const struct __cap_token_s *__cap_lookup_name(const char *, unsigned 
int);

 ^
cap_text.c: In function 'cap_to_name':
cap_text.c:291:2: warning: ignoring return value of 'asprintf',
declared with attribute warn_unused_result [-Wunused-result]
  asprintf(, "%u", cap);
  ^
make[1]: *** [Makefile:84: cap_text.o] Error 1


If it can't find size_t then for some reason it fails to include
pretty much any standard header. Which is supported by the
"included from " pip from gcc. Obviously, whatever
generates the _caps_output.gperf file made a mistake, both not
including the standard headers and also with declaration of the
__cap_lookup_name() function.

Considering that libcap builds happily on a 64-bit system and I assume
would also build on 32-bit one, the problem must be with the magic
required to build a 32-bit version on a 64-bit machine.

Should it be considered a bug worthy of reporting?

Thanks,

Zoltan


See bug 604802 (https://bugs.gentoo.org/604802).

Workaround: unmerge gperf, merge libpcap, afterwards merge gperf again.

For an 'emerge -e @world', temporarily downgrade to gperf-3.0.4 before.

--
Sent with eQmail-1.11 beta

Re: [gentoo-user] Re: default CONFIG_PROTECT behavior

[Kai Peter]

On 2018-06-19 17:15, Ian Zimmerman wrote:

On 2018-06-18 11:34, Rich Freeman wrote:


Oh, the other tool you'll want to use is etckeeper to manage /etc in a
git repo and auto-commit changes/etc with package manager hooks.  That
is a cross-distro tool, and will save your butt if you mess something
up.


I already do this, only without any packaging/wrapping like etckeeper,
just bare git.  It's why I want to skip all the the gentoo merge
thingies, get a crack at the updated file shipped with a package, 
insert

this into git on a parallel branch, then merge in the git way.


Not sure that it could solve your issue ... but I wrote a tool that - at 
least for me - solves all the issues with etc-update and friends.


In general the usage of sdiff is terrible to me. So I did my own 
solution. Unfortunately it is not ready to publish it, but if it is 
perhaps of interest to you have a look at 
http://gentoo.dyndn.es/doku.php/utils:qrtconf. This page describes 
mainly the concept and isn't really finished. If it would be worth to 
give it a try to you let me know and I will share it. For me it works 
since a few years with some development.


Kai
--
Sent with eQmail-1.11 beta

Re: [gentoo-user] Portage verification fails on games-action

[Kai Peter]

On 2018-06-07 23:05, Neil Bothwick wrote:

On Wed, 06 Jun 2018 16:38:52 +0100, Mick wrote:


Your pointer for RSYNC* proved useful.  At some point in the past I
must have decided rsync was taking an awful long time sync'ing the
games directories. Since I don't emerge or play games I had added this
entry in my make.conf:

$ grep RSYNC_ /etc/make.conf
PORTAGE_RSYNC_RETRIES="3"
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

$ cat /etc/portage/rsync_excludes
games-*/*


I wondered if it might be something like that.


Once I commented this option out the verification succeeded.  So ...
this verification problem seems to be caused by my intentional
exclusion of games from sync'ing.

Does this mean I won't be able to exclude games hereafter if I want to
verify portage's contents, or is there a different approach required?


As long as it only fails on verification of games-* I don't see a
problem, unless you are relying on a zero return code from emerge 
--sync.


Does gasmes-* still take a long time to sync? I wouldn't have thought
there would be a lot of changes in there compared with other sections,
such as kde-*.


I got the same issue and it doesn't depend on games*. Verification fails 
at the first excluded category in the order listed in the metamanifest.


regards
Kai
--
Sent with eQmail-1.11 beta

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Kai Peter]

On 2017-12-13 20:37, Alan Mackenzie wrote:


What have I done to deserve this abusive style of repartee?  I have 
never

You did post your opinion which doesn't fit with others.


I use Gentoo, partly because here I have a deal of choice.

Isn't it better to say you have partly a choice? ;-)

--
Sent with eQmail-1.10

Re: [gentoo-user] Re: Is gnome becoming obligatory?

[Kai Peter]

On 2017-12-11 13:39, Mick wrote:

On Monday, 11 December 2017 11:59:03 GMT Jorge Almeida wrote:
On Sun, Dec 10, 2017 at 7:31 PM, Canek Peláez Valdés 


wrote:


> Just my two cents. I will not answer any reply to my little contribution
> to
> this thread;

Good. I can't remember any intervention from you that I would miss. Of
course, I wouldn't dream of telling people how they should think, nor
would I deny anyone the right to be an activist.

> Enjoy your echo chamber.

Thank you for your contribution, Dr. Yes, we know you're a Dr. We know
it because:


Crikey!  I didn't expect my question to trigger yet another thread of 
'systemd
Vs freedom of choice (non-systemd)' arguments.  Dr. Canek has been an 
advocate

This is the nature of a mailing list ... ;-)

of systemd for years now and has posted his views on this topic more 
than
once.  He has tried hard to make gentoo users see the light in the 
superiority

of systemd and put his arguments across.  He has also done a lot of
development work to establish systemd in Gentoo.  His views are 
somewhat
parochial - only those who (can) code have an influence if not a right 
to
determine the direction of travel - I paraphrase of course.  There is 
truth in
this and anyone can recognise that money can buy developer hours and 
direct

their development effort.

The facts remain that RHL and their employees have shaped the Linux 
eco-system
to suit their business interests;  spinning predictably and reliably 
thousands
of identical VMs in data centres.  The MSWindows monolithic stack 
architecture

is something they wanted/needed and this is what they developed.

The fact also remains that binary distros and other development 
projects
decided to gravitate towards major development areas (cloud and 
embedded
computing) where commercial interest and development demand has been 
greater.
Lack of devs and maintainers especially for smaller distros means they 
decided
to ride on the back of systemd and minimise their own development load. 
 Linux
IMHO there isn't a lack of devs and/or maintainers. To me the issue is 
that they doesn't work as good together as they should. To less 
compromises. To many forks. Thus, unfortunately, leads into more market 
fragmentation. It is good to have a choice, but it is not good to have a 
lot - to many - choices. And this is not limited to init systems.


exists on the desktop too, but this represents a really small 
percentage of PC
users.  Linux desktop users on Gentoo systems is an even smaller number 
and I

am guessing of an increasingly advanced age demographic.

I am grateful that Gentoo has retained openrc and provides a choice for 
those
of us who would prefer to not use systemd.  I use systemd on a couple 
of

systems out of necessity/convenience, but I would not like it on my PC
systems.  If I wanted this opaque Just Works™ philosophy I would have 
stayed
with MSWindows or AppleMac, both of which I have used for years and 
frustrated
me to hell - well MSWindows definitely does.  However, for the majority 
of the
population these OS remain the best suited choice.  So, I think we 
should live
& let live, but as gentoo users at least try to influence gentoo to 
retain a

freedom of choice most binary distros have walked away from.

Just my 2c's.
+1 in general ;-), even if I'm pretty sure some people will interpret 
something different.


--
Sent with eQmail-1.10

Re: [gentoo-user] grub-0.97-r16 and profile 17.0 change

[Kai Peter]

On 2017-12-07 15:22, Peter Humphrey wrote:

On Thursday, 7 December 2017 12:04:08 GMT Kai Peter wrote:

On 2017-12-06 13:28, Peter Humphrey wrote:
> On Sunday, 3 December 2017 15:12:21 GMT Mick wrote:
>> On 03-12-2017 ,10:57:33, Peter Humphrey wrote:


--->8


> Sys-boot/grub-0.97-r17 compiled and installed all right, as a package,
> but when I went to install it to the MBR I got an error complaining of a
> mismatch or corruption in stage X. The wording was something like that,
> and I forget the value of X. There was no mention of disk space, and the
> boot partition is 2GB, so I think it's something else.
>
> Installing sys-boot/grub-static-0.97-r12 instead went smoothly, so I've
> left it like that for the moment.
>
> Does the team think I should go back to grub-0.97-r17, take proper
> records and file a bug report?

I question if this makes sense for a masked ebuild.


Masked? Not here, it isn't.

In the meaning of 'keyworded':
KEYWORDS="~amd64 ~x86 ~x86-fbsd"
(Why i did know that this will be misunderstood?)

Anyway, it's your choice to file a bug.



I'm curious about what was discussed until now. The issue seems to be
quite simple to solve.

The build fails but portage/gcc does give clear info in this case: the
option "-nopie" have to be changed to "-no-pie". This option is set in
860_all_grub-0.97-pie.patch. Here is a diff:


--->8

Yes, this has been made clear already, but it's not the problem I had.
Didn't find it in this thread - my fault. Btw. kernels haven't to be 
stored in /boot necessarily - related to the posts of the size of the 
boot partition. And maybe related to your problem: the r17 ebuild 
differs by the use of patches heavily.


Maybe the easiest way is to create a new grub-patches package, but 
there
are other ways to change this too. I'm expected the upstream will 
change

this soon - within the remaining 5 weeks ;-).

Another thing is I question that grub-legacy have to be rebuild at 
all.

I'm pretty sure it is save to remove it from the world file or comment
it out.


Then the first emerge -c will remove it from the system.
Does anybody run emerge -c blindly w/o reviewing the packages before? If 
yes compile it outside of portage. Or backup the required files, do 
emerge -c and restore the backup'd files afterwards. Or ...



Anyhow, upgrading to grub2 is IMHO the right way. There are some
examples given in parallel threads how to write a grub.cfg by hand - 
and

keep it simple :-). Then nothing else then the grub2 binary and
grub2-install is required usually.


Long-standing readers may remember that I have reasons for avoiding 
grub-2.

I still think it's a monstrosity and I'd much prefer never to have to
wrestle with it again.
Now, AFAIK, grub2 wants to be a universal boot loader for different 
architectures against grub-legacy is for PC's only. If you still want to 
rely on grub-legacy it would be the best solution to take over the 
project or fork it.


On the other hand, I suppose I could have another go at writing my own
grub.cfg, just for the one little Atom box, if only for a quiet life.


--
Sent with eQmail-1.10

Re: [gentoo-user] grub-0.97-r16 and profile 17.0 change

[Kai Peter]

On 2017-12-06 13:28, Peter Humphrey wrote:

On Sunday, 3 December 2017 15:12:21 GMT Mick wrote:

On 03-12-2017 ,10:57:33, Peter Humphrey wrote:
> On Saturday, 2 December 2017 12:30:57 GMT Mick wrote:
> > I'm getting this error after I changed my profile as per
> > '2017-11-30-new-17-
> >
> > profiles' news item:
> > >>> Compiling source in
> > >>> /data/tmp_var/portage/sys-boot/grub-0.97-r16/work/
>
> [...]
>
> > However, sys-boot/grub-0.97-r17 installed fine once keyworded on this
> > (mostly) stable system.  This may save time for others who come across
> > the same problem.
> sys-boot/grub-0.97-r17
> It has. Thanks Mick.

Unfortunately, an older system with only 50MB /boot partition did not
have enough space to allow sys-boot/grub-0.97-r17 to install all its
files and fs drivers.  I ended up restoring /boot from a back up.  
YMMV.


I spoke too soon, too. Sys-boot/grub-0.97-r17 compiled and installed 
all
right, as a package, but when I went to install it to the MBR I got an 
error

complaining of a mismatch or corruption in stage X. The wording was
something like that, and I forget the value of X. There was no mention 
of
disk space, and the boot partition is 2GB, so I think it's something 
else.


Installing sys-boot/grub-static-0.97-r12 instead went smoothly, so I've 
left

it like that for the moment.

Does the team think I should go back to grub-0.97-r17, take proper 
records

and file a bug report?


I question if this makes sense for a masked ebuild.

I'm curious about what was discussed until now. The issue seems to be 
quite simple to solve.


The build fails but portage/gcc does give clear info in this case: the 
option "-nopie" have to be changed to "-no-pie". This option is set in 
860_all_grub-0.97-pie.patch. Here is a diff:


--- a/860_all_grub-0.97-pie.patch   2012-05-31 01:00:13.0 
+0200
+++ b/860_all_grub-0.97-pie.patch   2017-12-07 11:28:57.536089642 
+0100

@@ -17,8 +17,8 @@
 +grub_cv_cc_fpie=no)
 +])
 +if test "x$grub_cv_cc_fpie" = xyes; then
-+  STAGE1_CFLAGS="$STAGE1_CFLAGS -nopie"
-+  STAGE2_CFLAGS="$STAGE2_CFLAGS -nopie"
++  STAGE1_CFLAGS="$STAGE1_CFLAGS -no-pie"
++  STAGE2_CFLAGS="$STAGE2_CFLAGS -no-pie"
 +fi
fi
  fi

Maybe the easiest way is to create a new grub-patches package, but there 
are other ways to change this too. I'm expected the upstream will change 
this soon - within the remaining 5 weeks ;-).


Another thing is I question that grub-legacy have to be rebuild at all. 
I'm pretty sure it is save to remove it from the world file or comment 
it out.


Anyhow, upgrading to grub2 is IMHO the right way. There are some 
examples given in parallel threads how to write a grub.cfg by hand - and 
keep it simple :-). Then nothing else then the grub2 binary and 
grub2-install is required usually.


Kai
--
Sent with eQmail-1.10

Re: [gentoo-user] is multi-core really worth it?

[Kai Peter]

On 2017-12-06 16:34, Alan McKinnon wrote:


And just to round off a mostly pointless discussion with little real
merit, the really stupid thing about portage is why oh why are ports 
and

distfiles in /usr?
I'm really surprised that someone recognized this or may be does 
question this. Fortunately it is easy to change for the user on a per 
installation base, but not for the upstream because of the things which 
follows.


I'll tell you why, it's because that's where FreeBSD puts them, and
drobbins built Gentoo back in the day heavily borrowing from his
pleasant FreeBSD experience (he went there for 6 months recovering from
his departure from another distro, the one with the "toxic
personality"). And no-one ever bothered changing that initial decision 
-

a classic case of cargo cult
That you not aware of it doesn't indicate that it wasn't bothered. 
Perhaps people will not waste (any more) time with senseless discussions 
...


--
Sent with eQmail-1.10

Re: [gentoo-user] Why do systemd scripts get installed with USE="-systemd"?

[Kai Peter]

On 2017-11-12 12:47, Neil Bothwick wrote:

On Sun, 12 Nov 2017 10:55:04 +, Akater wrote:

It looks like systemd scripts often (always?) get installed, 
regardless

of USE flag settings.


Because they are tiny so impact of them is negligible. On the other 
hand,

if you don't have them and want to switch to systemd, you would end up
having to recompile half of world just to get the service files.
As long the ebuild doesn't have a USE flag "systemd" - may be. If the 
(local) USE flag is for service files only, it could may be considered 
as overhead. But if there is a USE flag "system" - doesn't have the 
package to be rebuild somehow or other?



Why would they? Is this a policy?


AFAIK, yes.


--
Sent with eQmail-1.10

[gentoo-user] Update of glibc-2.23 to 2.25

[Kai Peter]

From the "cron" thread:

On 2017-11-05 18:12, Neil Bothwick wrote:

On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:


OT: Seems that since the last update of my MUA the formatting of my

mails is broken - at least at reply's. There are extra line breaks.

G - if you not do everything by yourself ...   ;-)


... at least you have someone else to blame.


Unfortunately it would be possible. The issue did appear after the 
update of glibc. Under some circumstances the shell text processing 
could be broken. In this case it was DKIM signing, but I recognized 
another issue too. It was not hard to fix it and it's not worth the time 
to investigate further to me. It looks to me they reversed a change in 
glibc which was made a long time ago.


PS: I bet that the formatting is correct now ...  :-)
--
Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-11-05 18:12, Neil Bothwick wrote:


On Sun, 05 Nov 2017 17:56:56 +0100, Kai Peter wrote:







OT: Seems that since the last update of my MUA the formatting of my







mails is broken - at least at reply's. There are extra line breaks.







G - if you not do everything by yourself ...   ;-)







... at least you have someone else to blame.




Nobody to blame, it's more to excuse me.

--

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

There are other schedulers out there that succeed where cron fails (eg



Control-M, chronos, quartz), but those are all large, bulky, designed


for big complex installs/requirements and probably not suited for 



simple



things you'd deploy out of a base in portage






Long time ago I decided to use fcron only. The reasons doesn't matter, 

but thus I can talk about fcron only. But you are right, there are a lot 

of others. At least I tried to answer Ian's question as exact as 

possible. I realized the inaccuracy in it too. Wasn't it to me? Than 


sorry for the noise.



cron is stupid and deliberately so. We really ought to let it remain 



stupid







The decision what have to be done MUST be made by the user/sysadmin



first. Than you can do the config to reach your goal. But that does go



to far now.







+1 agreed.







I've always maintained that cron cannot possibly know what the scripts



it launches deem to be correct. It's a countdown time and launcher, not


an orchestrator. It can figure out what to do if 2am happens twice 



(just



don't do it the second time), but not what should happen if 2am was



missed for any reason, including DST or poweroff or overeager ntpdate






The simplest approach to fixing missed jobs is to have the script 



itself


track what is correct. If it's lock and records files indicate 



something



didn't happen when it should, the script can do it's own repair or do



it's work twice. Or whatever else is appropriate.




@Alan, I like your writings. Unfortunately I'm not able to do so, thus 


my (very seldom) answers are sometimes to short. ;-)



OT: Seems that since the last update of my MUA the formatting of my 

mails is broken - at least at reply's. There are extra line breaks. 


G - if you not do everything by yourself ...   ;-)



--

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-11-04 18:42, Ian Zimmerman wrote:


On 2017-11-04 01:39, Kai Peter wrote:







> If you want to run a monthly job on a host that is not always on, do



> you have to pretend it's an hourly job and check in the script



> itself?







This is a special case to me. IMHO special cases have to be handled



special or much better: avoid it.







Sorry, I don't get this.  How do you avoid this situation?  By not



having any monthly jobs?


No, monthly jobs are fine, but you mentioned a special case as the host 

is may be off at that time. Perhaps you can do: run all jobs which 

didn't run because the host was off at next startup once. fcron has such 

an option. Depending on the exact situation it could require additional 


configuration/checks.



The decision what have to be done MUST be made by the user/sysadmin 

first. Than you can do the config to reach your goal. But that does go 


to far now.



--

Sent with eQmail-1.10

Re: [gentoo-user] Re: FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-11-03 18:21, Ian Zimmerman wrote:


On 2017-11-03 02:53, Kai Peter wrote:







2. the shell script have to do some checks, e.g. the last run - I did



wrote a small 'include' script for that






Isn't your 'small include script' just another implementation of 



run-crons?


No.






If not: how does it handle _missed_ jobs, if at all?


Whatever _missed_ means - at least it's 
a question of error handling.





If you want to run a monthly job on a host that is not always on, do 



you



have to pretend it's an hourly job and check in the script itself?


This is a special case to me. IMHO special cases have to be handled 


special or much better: avoid it.






Thus it's portable. The job have to be done once.






If you want your _entire_ configuration to be portable, and my above 



point



about monthly schedule sticks, then you have to ignore the monthly


feature of all the crons on all your systems, because you cannot rely 



on



it in any one system.


My _entire_ config isn't portable, but some
 (important) parts of it.



--

Sent with eQmail-1.10

Re: [gentoo-user] FYI: Daily / weekly / monthly cron jobs run twice on DST - non-DST transition

[Kai Peter]

On 2017-10-29 14:16, Michael Orlitzky wrote:


On 10/29/2017 07:46 AM, Remy Blank wrote:







I attached a patch to the bug, but considering how old the bug is, and



from the tone of the discussion there, I have little hope that it gets


applied. If you would like to see this fixed, it may be worth chiming 



in



on the bug. Or if you're a kind Gentoo developer listening to affected



users, to take action.











If only it were that easy. First: vapier is the only member of the cron



project, and he's happy with the way cronbase works.




This shows the lack of maintainers only. Don't wanna start a discussion 


about the reasons. IMHO the cronbase ebuild is faulty by design - sorry.





And then the real issue: no one knows what our cronbase is doing, and 



it



does whatever it does all wrong -- but some people are probably relying



on it. My proposal was to make cronbase stupider, with something like







  9  5  * * *   root   find /etc/cron.daily -execdir '{}' \;







That says: run everthing in cron.daily[0], every day, at 05:09. It does



exactly that: it has DST issues, if your machine is off the jobs won't



run, etc. But it's predictably stupid and works as advertised, unlike



the run-crons shell script we have now.




Looks a bit like a concept. As I have to work with different OS's I 


defined for me:



1. a crontab entry have to call a shell script always, at least a 


(minimal) wrapper

2. the shell script have to do some checks, e.g. the last run - I did 


wrote a small 'include' script for that



Thus it's portable. The job have to be done once.








Do you need something smarter? Install anacron, fcron, cronie, or



whatever. But the worst thing we can do is try to mimic those



intelligent crons and have it fail to do so randomly. That's still your



best option, by the way: rewrite your crontab to avoid run-crons, and



install a smart cron implementation that does what you want.




*I* recommend fcron, it is a bit under estimated. Beside its progressive 

design and w/o consulting the man page now again - AFAIR it can handle 

DST issues like above through options in fcrontab. But with my concept I 

don't need/use it. Be aware that some options could show an unexpected 

behavior too - nothing is perfect. Anyhow, by using fcron it is possible 

to eliminate the whole cronbase ebuild - it is part of the 20 percent 


(round about) which are faulty in Gentoo.



Just an opinion.














[0] In practice, you would want to pass "-type f", "-executable", and



"-maxdepth 1" to the "find" command as well.




--

Sent with eQmail-1.10

Re: [gentoo-user] x11-apps/xinit-1.3.4-r2 is broken

[Kai Peter]

On 2017-10-19 16:00, Rich Freeman wrote:

On Thu, Oct 19, 2017 at 2:15 AM, Peter Humphrey  



wrote:



Hello list,






In case anyone else trips over this, as I did today in my routine 



update,



see https://bugs.gentoo.org/634706. I followed comment 2.






The symptom is that sddm cannot start KDE, so you have to log in and 



startx.











The bug is a bit noisy, but it isn't clear to me what is actually



wrong with /lib/gentoo/functions.sh.  I do see that there is a



dependency on gentoo-functions which should install it, though it is



odd that it is only pulled in for USE=-systemd.  Perhaps they need to



use an openrc-specific functions.sh.  One of the issues is that



historically this file was packaged by openrc but wasn't entirely



openrc-specific, so we're trying to split out the stuff that applies



no matter what service manager you use from the stuff that actually is



related to openrc.




I'm really tired of such kind of bugs. IMHO the quality management 

should have to - at least - identify it. Otherwise it shows to me that 

the USE flag feature is going out-of-control once more. Fortunately 

people on the list prevent me to waste my time for such things quite 


often.



Call me the bad guy.



--

Sent with eQmail-1.10

Re: [gentoo-user] New box

[Kai Peter]

On 2016-12-30 03:23, the...@sys-concept.com wrote:

I'm putting a new system, it will be running mainly, VirtualBox,
Asterisk, Hylafax etc. (nothing graphic intensive).

- IN WIN BL631 Low Profile Micro ATX Case w/ 300W Power Supply,
- AMD FX-8350 Processor 4.0GHz w/ 16MB Cache
- Gigabyte GA-78LMT-USB3 w/ DDR3, 7.1 Audio, Gigabit Lan
- Kingston HyperX Fury 16GB DDR3-1866MHz CL10 Dual Channel Kit
- Samsung 850 EVO Series mSATA Solid State Drive, 1TB
- Asus GeForce GT 720 Silent CSM, 2GB, PCI-E w/ D-Sub VGA, DVI, HDMI

Will I have any problems installing Gentoo on this configuration, eg.
with Video Card etc.?


Short answer: no.


Do I need more RAM?


Hmm..., I couldn't see a general answer here. From the above it depends 
on the number of VM's and how many RAM you (have to) give them. Maybe as 
a reference, my actual plasma session uses 13 GB of RAM. But having more 
RAM is never a bad thing. If the system starts to swap then you need 
more.


--
Sent with eQmail-1.10-dev

Re: [gentoo-user] New box

[Kai Peter]

- 8 core CPU: nice


Makes me drool a bit here.  I want a 8 core CPU.  The only downside,


Have had such CPU (AMD FX8350) and wasn't satisfied really. It wasn't 
powerful as *I* expected. I didn't get it cool and quiet as I wanted to 
in my desktop. Even not with water cooling. IMO more RAM is better than 
more cores.


--
Sent with eQmail-1.10-dev

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Kai Peter]

On 2016-12-27 21:31, Neil Bothwick wrote:


Put this script in /etc/portage/postsync.d and make it executable

#!/bin/sh

if [ $( eselect news count new ) != "0" ]; then
   eselect news list | mail y...@wherever.you.are
   fi


Nice hint, really. I did a similar thing in my emerge wrapper script, 
but this looks more efficient. Thanks.

(Btw, knowing all about portage/emerge isn't a high priority by me ;))

--
Sent with eQmail-1.10-dev

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Kai Peter]

On 2016-12-20 18:57, Rich Freeman wrote:



No, your opinion doesn't affect me because the only thing you've been
contributing is noise.

That's a true word ...


If anything it works the other way around.  There seem to be a lot
more Gentoo devs who run systemd who are actively contributing openrc
scripts than Gentoo devs who run openrc who are actively contributing
systemd units.  I haven't actually done a poll but I see a lot more
people asking the systemd team to help them write systemd units than
people asking the openrc team to help them write init.d scripts.
This sounds a bit dangerous to me :( from the point that I **don't 
want** to use systemd (as of now).


--
Sent with eQmail-1.10-dev

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Kai Peter]

On 2016-12-20 17:21, Heiko Baums wrote:

Am 20.12.2016 um 05:23 schrieb Andrej Rode:
Yeah they make life easier. From your talk you never had a problem 
with
eth<0,10> switching names after boot. Everyone who had them 
appreciates

predictable network interfaces.


Everyone who had them could learn how to write simple udev rules to get
fixed eth<0,10> names after every boot. No systemd and no "predictable"
names necessary.

right


Nevertheless I'm still wondering what's so predictable at those
incomprehensible, cryptic device names anyway. And I don't want to know
that.
Maybe there are different opinions, but what is cryptic on - as a 
typical one - enp3s0?:

e - ethernet
n - network
p - pci (port) ...
3 - ... 3
s - slot ...
0 - ... 0

Just an example. The real mess with systemd is that it violates the good 
ol' Unix culture. Especially by "capturing" udev. Thanks to Gentoo for 
eudev!!!




Heiko Baums


--
Sent with eQmail-1.10-dev

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Kai Peter]

On 2016-12-20 05:23, Andrej Rode wrote:

Why

Or can you explain how unrecognisable names make things easier?


Yeah they make life easier.

Not in any case. Otherwise it is a name only.

From your talk you never had a problem with

eth<0,10> switching names after boot. Everyone who had them appreciates
predictable network interfaces.


Predictable names are not limited to network if's. Just the (first?) 
point where most users comes in touch with it. And claiming about 
changes which seems to break some human logic.


--
Sent with eQmail-1.10-dev

Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No

[Kai Peter]

The last time I got a board that didn't have two ports is about 20 
years

ago, and I never bought one for 400.  They all just have 2, needed or
not, even cheap ones.


However, checking out the consumer market (Europe) shows that 1 out of 
10 mobo's has 2 ports usually. I always add(ed) a separate network card, 
even to have better control.


--
Sent with eQmail-1.10-dev