[gentoo-user] Re: systemd-boot on an openrc system

2022-09-29 Thread Nikos Chantziaras

On 28/09/2022 15:20, Peter Humphrey wrote:

Looking more carefully, I see only one machine has an /etc/machine-info.


I'm on systemd (openrc is not installed at all), and I don't have 
/etc/machine-info. And /etc/kernel/install.d/ is empty.






Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-19 Thread Neil Bothwick
On Tue, 19 Apr 2022 01:09:02 -0500, Dale wrote:

> > And now it's perfectly all right. What is one supposed to do in the
> > face of such chaos?
> >
> > I confess that the machine is perilously close to being hurled
> > through the window.

There were updates to udev and systemd-utils, I wonder if they fixed it.

> Get sledge hammer, bigger is better.  Place sledge hammer beside
> computer.  Use a camera if the puter has one.  Let computer know that is
> Plan B, there is no Plan C.  :-) 
> 
> I've done it before with hal.  Neil, remember my situation with hal?
> ;-) 

I try not to :-/


-- 
Neil Bothwick

Ninety-Ninety Rule Of Project Schedules - The first ninety percent of
the task takes ninety percent of the time, and the last ten percent
takes the other ninety percent of the time.


pgp0pfOajc8sT.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-19 Thread Dale
Peter Humphrey wrote:
> On Monday, 18 April 2022 16:05:24 -00 Peter Humphrey wrote:
>
>> The machine is sick. I now have no mouse or keyboard after POST. They're
>> fine in UEFI BIOS setup, and they're fine after the default kernel has
>> finished booting - just not at boot menu time.
> And now it's perfectly all right. What is one supposed to do in the face of 
> such chaos?
>
> I confess that the machine is perilously close to being hurled through the 
> window.
>


Get sledge hammer, bigger is better.  Place sledge hammer beside
computer.  Use a camera if the puter has one.  Let computer know that is
Plan B, there is no Plan C.  :-) 

I've done it before with hal.  Neil, remember my situation with hal?  ;-) 

Hope that helps.

Dale

:-)  :-) 



Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-18 Thread Jack

On 4/18/22 22:53, Peter Humphrey wrote:

On Monday, 18 April 2022 16:05:24 -00 Peter Humphrey wrote:

The machine is sick. I now have no mouse or keyboard after POST. They're
fine in UEFI BIOS setup, and they're fine after the default kernel has
finished booting - just not at boot menu time.

And now it's perfectly all right. What is one supposed to do in the face of
such chaos?

I confess that the machine is perilously close to being hurled through the
window.


I generally blame such behavior on "phase of the moon and blue magic 
dust."  Is it time to go to your local church to ask if the priest will 
perform an exorcism?





Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-18 Thread Peter Humphrey
On Monday, 18 April 2022 16:05:24 -00 Peter Humphrey wrote:

> The machine is sick. I now have no mouse or keyboard after POST. They're
> fine in UEFI BIOS setup, and they're fine after the default kernel has
> finished booting - just not at boot menu time.

And now it's perfectly all right. What is one supposed to do in the face of 
such chaos?

I confess that the machine is perilously close to being hurled through the 
window.

-- 
Regards,
Peter.






Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-18 Thread Peter Humphrey
On Sunday, 17 April 2022 20:17:47 -00 Rich Freeman wrote:
> On Sun, Apr 17, 2022 at 1:05 PM Martin Vaeth  wrote:
> > Peter Humphrey  wrote:
> > > On Sunday, 17 April 2022 16:42:35 -00 Martin Vaeth wrote:
> > >> Peter Humphrey  wrote:
> > >> > On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
> > >> >> Can't you just fix your USE flags with systemd-utils?  Why revert?
> > >> > 
> > >> > No, because the flag I'd need is 'boot', and that triggers switching
> > >> > from
> > >> > elogind to systemd.
> > >> 
> > >> No, USE=boot for systemd-util does not trigger anything like that.
> > > 
> > > I meant, if I set that flag, portage wants me to remove elogind
> > > andinstall
> > > systemd.
> > 
> > Maybe, but the fault is certainly not this flag but something else.
> > For instance, that you do not have keyworded something which you should
> > have.
> It would probably be helpful to post more relevant output, like
> portage output including --verbose and so on so that it is clear what
> it is actually doing.
> 
> systemd-utils blocks systemd, so I can't see how it could force you to
> install systemd (after all, it just supplies things that are otherwise
> bundled with systemd already).  Maybe in addition to setting the boot
> USE flag you also changed something else?

The machine is sick. I now have no mouse or keyboard after POST. They're fine 
in UEFI BIOS setup, and they're fine after the default kernel has finished 
booting - just not at boot menu time.

:(

-- 
Regards,
Peter.






Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-17 Thread Rich Freeman
On Sun, Apr 17, 2022 at 1:05 PM Martin Vaeth  wrote:
>
> Peter Humphrey  wrote:
> > On Sunday, 17 April 2022 16:42:35 -00 Martin Vaeth wrote:
> >> Peter Humphrey  wrote:
> >> > On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
> >> >> Can't you just fix your USE flags with systemd-utils?  Why revert?
> >> >
> >> > No, because the flag I'd need is 'boot', and that triggers switching from
> >> > elogind to systemd.
> >>
> >> No, USE=boot for systemd-util does not trigger anything like that.
> >
> > I meant, if I set that flag, portage wants me to remove elogind andinstall
> > systemd.
>
> Maybe, but the fault is certainly not this flag but something else.
> For instance, that you do not have keyworded something which you should have.

It would probably be helpful to post more relevant output, like
portage output including --verbose and so on so that it is clear what
it is actually doing.

systemd-utils blocks systemd, so I can't see how it could force you to
install systemd (after all, it just supplies things that are otherwise
bundled with systemd already).  Maybe in addition to setting the boot
USE flag you also changed something else?

--
Rich

-- 
Rich



Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-17 Thread Peter Humphrey
On Sunday, 17 April 2022 17:05:18 -00 Martin Vaeth wrote:
> Peter Humphrey  wrote:
> > On Sunday, 17 April 2022 16:42:35 -00 Martin Vaeth wrote:
> >> Peter Humphrey  wrote:
> >> > On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
> >> >> Can't you just fix your USE flags with systemd-utils?  Why revert?
> >> > 
> >> > No, because the flag I'd need is 'boot', and that triggers switching
> >> > from
> >> > elogind to systemd.
> >> 
> >> No, USE=boot for systemd-util does not trigger anything like that.
> > 
> > I meant, if I set that flag, portage wants me to remove elogind andinstall
> > systemd.
> 
> Maybe, but the fault is certainly not this flag but something else.
> For instance, that you do not have keyworded something which you should
> have.

Ok. I'll look again in the morning.

-- 
Regards,
Peter.






[gentoo-user] Re: systemd-boot on openrc

2022-04-17 Thread Martin Vaeth
Peter Humphrey  wrote:
> On Sunday, 17 April 2022 16:42:35 -00 Martin Vaeth wrote:
>> Peter Humphrey  wrote:
>> > On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
>> >> Can't you just fix your USE flags with systemd-utils?  Why revert?
>> >
>> > No, because the flag I'd need is 'boot', and that triggers switching from
>> > elogind to systemd.
>>
>> No, USE=boot for systemd-util does not trigger anything like that.
>
> I meant, if I set that flag, portage wants me to remove elogind andinstall
> systemd.

Maybe, but the fault is certainly not this flag but something else.
For instance, that you do not have keyworded something which you should have.




Re: [gentoo-user] Re: systemd-boot on openrc

2022-04-17 Thread Peter Humphrey
On Sunday, 17 April 2022 16:42:35 -00 Martin Vaeth wrote:
> Peter Humphrey  wrote:
> > On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
> >> Can't you just fix your USE flags with systemd-utils?  Why revert?
> > 
> > No, because the flag I'd need is 'boot', and that triggers switching from
> > elogind to systemd.
> 
> No, USE=boot for systemd-util does not trigger anything like that.

I meant, if I set that flag, portage wants me to remove elogind andinstall 
systemd.

-- 
Regards,
Peter.






[gentoo-user] Re: systemd-boot on openrc

2022-04-17 Thread Martin Vaeth
Peter Humphrey  wrote:
> On Sunday, 17 April 2022 14:54:50 -00 Rich Freeman wrote:
>>
>> Can't you just fix your USE flags with systemd-utils?  Why revert?
>
> No, because the flag I'd need is 'boot', and that triggers switching from
> elogind to systemd.

No, USE=boot for systemd-util does not trigger anything like that.




Re: [gentoo-user] Re: "systemd sysv-utils blocker resolution"

2018-02-11 Thread Rich Freeman
On Sun, Feb 11, 2018 at 12:52 PM, Nikos Chantziaras  wrote:
>
> Yes. How else is sys-apps/sysvinit going to be unmerged? Either you let
> portage clean it up (depclean), or you need to do it manually.
>

He already has sysvinit unmerged.  Portage unmerged that because it
was a blocker for systemd[sysv-utils].  Portage doesn't remove
non-blocking packages unless you run emerge --depclean.

-- 
Rich



[gentoo-user] Re: "systemd sysv-utils blocker resolution"

2018-02-11 Thread Nikos Chantziaras

On 11/02/18 05:09, allan gottlieb wrote:

On Sun, Feb 11 2018, Nikos Chantziaras wrote:

When you ran:

   emerge -auDN --changed-deps --with-bdeps=y @world

did you forget to run:

   emerge -a --depclean

afterwards?


I am indeed behind in depcleaning.  Does that explain why
euse doesn't fine sysv-utils
and why
I have the symlinks /sbin/poweroff and friends with systemd-236?


Yes. How else is sys-apps/sysvinit going to be unmerged? Either you let 
portage clean it up (depclean), or you need to do it manually.





Re: [gentoo-user] Re: "systemd sysv-utils blocker resolution"

2018-02-10 Thread allan gottlieb
On Sun, Feb 11 2018, Nikos Chantziaras wrote:

> On 11/02/18 02:16, allan gottlieb wrote:
>> I have a question on this news item.
>>
>> I use systemd (gnome3) on a gentoo stable system.
>> eix reports that sys-apps/systemd-236-r5 is installed
>>
>> But
>> euse -I sysv-utils
>> reports
>> no matching entries found
>>
>> Is something wrong?
>>
>> I do *not* have
>>sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
>> in my world file.
>>
>> However, the last two are installed.
>
> When you ran:
>
>   emerge -auDN --changed-deps --with-bdeps=y @world
>
> did you forget to run:
>
>   emerge -a --depclean
>
> afterwards?

I am indeed behind in depcleaning.  Does that explain why
   euse doesn't fine sysv-utils
and why
   I have the symlinks /sbin/poweroff and friends with systemd-236?

I will be working on depcleans but rather slowly.

thanks for the help.
allan



[gentoo-user] Re: "systemd sysv-utils blocker resolution"

2018-02-10 Thread Nikos Chantziaras

On 11/02/18 02:16, allan gottlieb wrote:

I have a question on this news item.

I use systemd (gnome3) on a gentoo stable system.
eix reports that sys-apps/systemd-236-r5 is installed

But
euse -I sysv-utils
reports
no matching entries found

Is something wrong?

I do *not* have
   sys-apps/sysvinit, sys-apps/openrc, or net-misc/netifrc
in my world file.

However, the last two are installed.


When you ran:

  emerge -auDN --changed-deps --with-bdeps=y @world

did you forget to run:

  emerge -a --depclean

afterwards?




[gentoo-user] Re: Systemd

2017-11-08 Thread Nikos Chantziaras

On 05/11/17 00:02, Canek Peláez Valdés wrote:
On Sat, Nov 4, 2017 at 12:17 PM, Nikos Chantziaras 
 > The only problem I have with systemd is that it's unable 
to reliably restore the ALSA mixer volumes/settings on startup. It fails 
50% of the time. Which is very annoying, but not the end of the world.


Do you have PulseAudio installed? What's the output of 'systemctl status 
alsa-restore.service'? Do you have /var/lib under a "special" (RAID, 
LUKS, whatever) partition?


Yes, I'm using PulseAudio.

The status output is:

$ systemctl status alsa-restore.service
● alsa-restore.service - Save/Restore Sound Card State
   Loaded: loaded (/lib/systemd/system/alsa-restore.service; static; 
vendor preset: disabled)

   Active: active (exited) since Wed 2017-11-08 23:26:55 EET; 14min ago
  Process: 221 ExecStart=/usr/sbin/alsactl restore (code=exited, 
status=0/SUCCESS)

 Main PID: 221 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/alsa-restore.service

Nov 08 23:26:54 gentoopc systemd[1]: Starting Save/Restore Sound Card 
State...

Nov 08 23:26:55 gentoopc systemd[1]: Started Save/Restore Sound Card State.


No special mounts. Everything is a single partition.




[gentoo-user] Re: Systemd

2017-11-08 Thread Nikos Chantziaras

On 04/11/17 21:23, Rich Freeman wrote:

On Sat, Nov 4, 2017 at 2:17 PM, Nikos Chantziaras  wrote:

[...] The only problem I have with systemd is that it's unable to
reliably restore the ALSA mixer volumes/settings on startup. It fails 50% of
the time. Which is very annoying, but not the end of the world.


Out of curiosity - are you using alsa-state or alsa-restore?
Apparently alsa provides two different ways of preserving state.  You
might consider switching them (which is triggered by the existence of
/etc/alsa/state-daemon.conf - but it might have some other
requirements which I didn't bother to check on).


alsa-restore. It claims to do exactly what I want, run:

  /usr/sbin/alsactl restore

at startup.



With any save/restore tool like these I always keep a copy of the
state somewhere where it doesn't get overwritten at shutdown if I have
a complex configuration.
Well, the thing is that the state is not getting overwritten. When 
during boot systemd fails to restore the volumes, the state is still 
fine and I can manually run:


  /usr/sbin/alsactl restore

and restore the volumes. This sounds like some sort of race condition 
where something else is calling "alsactl init", so sometimes "restore" 
happens after "init", which results in my volumes getting restores, and 
sometimes "init" happens after "restore", which gives me default volume 
levels.





Re: [gentoo-user] Re: Systemd

2017-11-05 Thread Mick
On Saturday, 4 November 2017 19:23:40 GMT Rich Freeman wrote:
> On Sat, Nov 4, 2017 at 2:17 PM, Nikos Chantziaras  wrote:
> > On 04/11/17 18:15, siefke_lis...@web.de wrote:
> >> I have a short question to systemd. I would like to ask your experience
> >> in the changeover. Was it easy? Were there problems?
> >> Change or reinstall? What mean the profis here?
> > 
> > I did both. Changed one system to systemd, re-installed one from scratch
> > with systemd.
> > 
> > Both worked. The only problem I have with systemd is that it's unable to
> > reliably restore the ALSA mixer volumes/settings on startup. It fails 50%
> > of the time. Which is very annoying, but not the end of the world.
> 
> Out of curiosity - are you using alsa-state or alsa-restore?
> Apparently alsa provides two different ways of preserving state.  You
> might consider switching them (which is triggered by the existence of
> /etc/alsa/state-daemon.conf - but it might have some other
> requirements which I didn't bother to check on).

I am using alsasound as a boot service, but in openrc - see below.


> I've seen similar issues with iptables-restore.  To be fair those are
> rare and I've also seen issues with that under openrc.

I have the same issue on one of my Gentoo systems, but I use openrc.  It seems 
to me this is occurring some times only, because the system is trying to read 
/usr when it has not yet been fully mounted, but I'm not sure.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: Systemd

2017-11-04 Thread Canek Peláez Valdés
On Sat, Nov 4, 2017 at 12:17 PM, Nikos Chantziaras  wrote:
>
> On 04/11/17 18:15, siefke_lis...@web.de wrote:
>>
>> I have a short question to systemd. I would like to ask your experience
>> in the changeover. Was it easy? Were there problems?
>> Change or reinstall? What mean the profis here?
>
>
> I did both. Changed one system to systemd, re-installed one from scratch
with systemd.
>
> Both worked. The only problem I have with systemd is that it's unable to
reliably restore the ALSA mixer volumes/settings on startup. It fails 50%
of the time. Which is very annoying, but not the end of the world.

Do you have PulseAudio installed? What's the output of 'systemctl status
alsa-restore.service'? Do you have /var/lib under a "special" (RAID, LUKS,
whatever) partition?

Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México


Re: [gentoo-user] Re: Systemd

2017-11-04 Thread Rich Freeman
On Sat, Nov 4, 2017 at 2:17 PM, Nikos Chantziaras  wrote:
> On 04/11/17 18:15, siefke_lis...@web.de wrote:
>>
>> I have a short question to systemd. I would like to ask your experience
>> in the changeover. Was it easy? Were there problems?
>> Change or reinstall? What mean the profis here?
>
>
> I did both. Changed one system to systemd, re-installed one from scratch
> with systemd.
>
> Both worked. The only problem I have with systemd is that it's unable to
> reliably restore the ALSA mixer volumes/settings on startup. It fails 50% of
> the time. Which is very annoying, but not the end of the world.
>

Out of curiosity - are you using alsa-state or alsa-restore?
Apparently alsa provides two different ways of preserving state.  You
might consider switching them (which is triggered by the existence of
/etc/alsa/state-daemon.conf - but it might have some other
requirements which I didn't bother to check on).

I've seen similar issues with iptables-restore.  To be fair those are
rare and I've also seen issues with that under openrc.

With any save/restore tool like these I always keep a copy of the
state somewhere where it doesn't get overwritten at shutdown if I have
a complex configuration.  If you get one of those situations where
something isn't detected by the kernel/udev/etc and then your state
gets blown away it is really nice to be able to run iptables-restore <
backupfile.

I believe the way alsa-restore operates is frowned upon in Gentoo
systemd circles, though to be honest I'm not sure what the specific
concern is.  The oneshot/RemainAfterExit approach seems
straightforward enough, and it is my guess that it is the upstream way
of doing things...

--
Rich



[gentoo-user] Re: Systemd

2017-11-04 Thread Nikos Chantziaras

On 04/11/17 18:15, siefke_lis...@web.de wrote:

I have a short question to systemd. I would like to ask your experience
in the changeover. Was it easy? Were there problems?
Change or reinstall? What mean the profis here?


I did both. Changed one system to systemd, re-installed one from scratch 
with systemd.


Both worked. The only problem I have with systemd is that it's unable to 
reliably restore the ALSA mixer volumes/settings on startup. It fails 
50% of the time. Which is very annoying, but not the end of the world.





Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-11-01 Thread Daniel Frey

On 11/01/2017 02:12 PM, Wols Lists wrote:

What's the problem with mdadm and openrc?



openrc terminates mdmon too early and so every time I rebooted this 
machine when it had a RAID it marked the array as dirty and rebuilt it. 
The PC was not usable while it was rebuilding, it was so dang slow, not 
to mention extra wear and tear on the drives. I had a workaround to this 
but it stopped working so I went to systemd, which helped that problem, 
but systemd gave me new problems... like the inability to wait for a 
network to be up before mounting remote nfs drives. openrc handles this 
just fine, I have an old Mint install and it too worked fine without 
intervention. I spent a couple weeks trying to figure out why systemd 
refused to wait for networkmanager to bring the network up, I gave up.


The thing is it used to work with systemd, then there was a couple 
updates and it stopped working. I unmasked a newer version with the same 
results.


The best I got was systemd would sometimes mount half the remote nfs 
mounts and timeout on the other half.


Dan



Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-11-01 Thread Rich Freeman
On Wed, Nov 1, 2017 at 2:12 PM, Wols Lists  wrote:
>
> Windows WON'T SHUT DOWN PROPERLY most of the time.
>
> And something messed up /home.
>
> Easy enough to fix, when I eventually found out the cause. Run fsck on
> /dev/sda8. Re-configure windows to tell it "shut down does NOT mean
> hibernate, damn you!", and finally reboot actually got me into SUSE proper.
>
> But I wish they'd document - and fix!!! - how to get systemd to mount
> drives properly!!!
>

By "properly" it sounds like you want it to mount filesystems that
were not cleanly unmounted without user intervention, or ignore a
failure to do so?

I think I'll stick with the way it works now.

However, if you want it to boot without warnings if the drive won't
cleanly mount you can just add a nofail option to fstab for the
filesystem.  Then your system will just continue booting without the
filesystem mounted if the linux mount command wouldn't mount it with
the normal invocation.  And then you get to clean up after whatever
daemon goes writing stuff in the empty mountpoint.

I imagine systemd is dropping to a recovery console in these
situations because most sysadmins want to know when a filesystem is
not cleanly mounting, and continued operation in this state is
unpredictable.  I'm sure it could be overriden if you really wanted
to...

-- 
Rich



Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-11-01 Thread Wols Lists
On 01/11/17 20:25, Daniel Frey wrote:
> On 10/29/2017 08:15 AM, Daniel Frey wrote:
>> Come to think of it, I'm going to look back and see if there was an
>> update around the time I started having problems. Maybe there was a
>> regression of some sort.
>>
> 
> So I bought a large SSD, and cloned to it. I'm not stuck with IMSM any
> more, but systemd still doesn't mount properly. Now that I don't have to
> deal with mdadm, I went back to openrc, and all is will. Although... it
> did take me a while to get rid of networkmanager.
> 
What's the problem with mdadm and openrc?

That said, I've just been troubleshooting a right pain in the neck with
SUSE, Windows, and systemd on my laptop.

ANY trouble with your hard drives, and systemd dumps you in the recovery
console.

Windows WON'T SHUT DOWN PROPERLY most of the time.

And something messed up /home.

Easy enough to fix, when I eventually found out the cause. Run fsck on
/dev/sda8. Re-configure windows to tell it "shut down does NOT mean
hibernate, damn you!", and finally reboot actually got me into SUSE proper.

But I wish they'd document - and fix!!! - how to get systemd to mount
drives properly!!!

Cheers,
Wol




Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-11-01 Thread Daniel Frey

On 10/29/2017 08:15 AM, Daniel Frey wrote:
Come to think of it, I'm going to look back and see if there was an 
update around the time I started having problems. Maybe there was a 
regression of some sort.




So I bought a large SSD, and cloned to it. I'm not stuck with IMSM any 
more, but systemd still doesn't mount properly. Now that I don't have to 
deal with mdadm, I went back to openrc, and all is will. Although... it 
did take me a while to get rid of networkmanager.


Dan




Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-10-29 Thread Daniel Frey

On 10/28/2017 05:18 PM, Adam Carter wrote:


I'm still having this issue, anyone have any ideas? I can see that
NetworkManager-Wait-Online finishes, and that the mounting starts
immediately after, but I don't think the network is quite up yet,
resulting an all nfs mounts to timeout.

The computer is using a static IP, so it shouldn't even be waiting
for dhcp...

I booted into openrc, and they all mount properly. Does anyone have
any idea even how to start troubleshooting this?


I had this issue through some versions of systemd - but its fixed now 
(i'm on ~adm64). Version is systemd-235-r1.


Are you ~arch?


No, I run stable. Currently running:

[IP-] [  ] sys-apps/systemd-233-r4:0/2

Come to think of it, I'm going to look back and see if there was an 
update around the time I started having problems. Maybe there was a 
regression of some sort.


Dan



Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-10-28 Thread Adam Carter
> I'm still having this issue, anyone have any ideas? I can see that
> NetworkManager-Wait-Online finishes, and that the mounting starts
> immediately after, but I don't think the network is quite up yet, resulting
> an all nfs mounts to timeout.
>
> The computer is using a static IP, so it shouldn't even be waiting for
> dhcp...
>
> I booted into openrc, and they all mount properly. Does anyone have any
> idea even how to start troubleshooting this?
>

I had this issue through some versions of systemd - but its fixed now (i'm
on ~adm64). Version is systemd-235-r1.

Are you ~arch?


[gentoo-user] Re: systemd fails to mount nfs4 mounts

2017-10-28 Thread Daniel Frey

On 10/13/2017 03:13 PM, Daniel Frey wrote:
I discovered that after my update the other day (systemd is up to date 
as of Wednesday) that my remote nfs mounts are failing on startup.


(Note: as per my other thread, I haven't tried to disable ipv6 yet. I 
want to figure this out first.)


I use an IMSM raid with an initramfs provided by dracut.

I have also set:

  NetworkManager-wait-online.service
loaded active exited    Network Manager Wait Online


to wait until networkmanager starts up, and it appears to be working.

When booting, something complains about the module sunrpc not being able 
to be loaded. However, everything I've selected relating to nfs is built 
directly into the kernel, so there shouldn't be external modules to 
begin with.


After logging in, dropping to the shell and manually mounting these nfs 
mounts work.


systemctl status:
● mnt-nas-Pictures.mount    loaded failed 
failed /mnt/nas/Pictures


status:

# systemctl status mnt-nas-Pictures.mount
● mnt-nas-Pictures.mount - /mnt/nas/Pictures
    Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
    Active: failed (Result: timeout) since Fri 2017-10-13 14:51:08 PDT; 
17min ago

     Where: /mnt/nas/Pictures
  What: nas:/Pictures
  Docs: man:fstab(5)
    man:systemd-fstab-generator(8)
   Process: 781 ExecMount=/bin/mount nas:/Pictures /mnt/nas/Pictures -t 
nfs4 -o rw,defaults,_netdev,intr,bg (code=killed, signal=TERM)


Oct 13 14:49:37 myboringpc systemd[1]: Mounting /mnt/nas/Pictures...
Oct 13 14:51:08 myboringpc systemd[1]: mnt-nas-Pictures.mount: Mounting 
timed out. Stopping.
Oct 13 14:51:08 myboringpc systemd[1]: mnt-nas-Pictures.mount: Mount 
process exited, code=killed status=15

Oct 13 14:51:08 myboringpc systemd[1]: Failed to mount /mnt/nas/Pictures.
Oct 13 14:51:08 myboringpc systemd[1]: mnt-nas-Pictures.mount: Unit 
entered failed state.


So it is saying it was killed. When booting up, systemd sits waiting for 
a start job for two minutes. I rebooted and checked again, and it said 
it timed out. I can see it's waiting for Network Manager Wait Online, 
then it tries to mount the nfs shares.


I presume this means the network is not ready. As I mentioned above, 
logging in and manually mounting is working fine.


Anyone have any suggestions? Of course I didn't notice this until I 
tried to sync pictures from my phone...


Dan


I'm still having this issue, anyone have any ideas? I can see that 
NetworkManager-Wait-Online finishes, and that the mounting starts 
immediately after, but I don't think the network is quite up yet, 
resulting an all nfs mounts to timeout.


The computer is using a static IP, so it shouldn't even be waiting for 
dhcp...


I booted into openrc, and they all mount properly. Does anyone have any 
idea even how to start troubleshooting this?


Dan





[gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

2017-10-28 Thread Nikos Chantziaras
Alright, thanks. Looks like I'll have to live with that message for a 
while. Which isn't a big deal.



On 28/10/17 21:58, Canek Peláez Valdés wrote:
On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras > wrote:

 >
 > There is no such kernel option.

Yes, there is[1]. However, there is no such option for kernel version 
4.9[2], although there is for 4.10[3]. I think that's the problem, for 
using the firewall BPF options of systemd, you'll need to use kernel 
version >= 4.10.


Regards.

[1] https://github.com/torvalds/linux/blob/master/init/Kconfig#L848
[2] https://github.com/torvalds/linux/blob/v4.9/init/Kconfig
[3] https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México






Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

2017-10-28 Thread mad.scientist.at.large
you should probably update your' kernel anyway, a lot of recent security fixes 
in the newer kernels.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 12:58 by can...@gmail.com:


> On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras <> rea...@gmail.com> > 
> wrote:
> >
> > There is no such kernel option.
>
> Yes, there is[1]. However, there is no such option for kernel version 4.9[2], 
> although there is for 4.10[3]. I think that's the problem, for using the 
> firewall BPF options of systemd, you'll need to use kernel version >= 4.10.
> Regards.
> [1] > https://github.com/torvalds/linux/blob/master/init/Kconfig#L848> [2] > 
> https://github.com/torvalds/linux/blob/v4.9/init/Kconfig> [3] > 
> https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
> --
> Dr. Canek Peláez Valdés
> Profesor de Carrera Asociado C
> Departamento de Matemáticas
> Facultad de Ciencias
> Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

2017-10-28 Thread mad.scientist.at.large
you should update the kernel anyway.  some serious security holes have recently 
been found and corrected in the newest kernel.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 12:58 by can...@gmail.com:


> On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras <> rea...@gmail.com> > 
> wrote:
> >
> > There is no such kernel option.
>
> Yes, there is[1]. However, there is no such option for kernel version 4.9[2], 
> although there is for 4.10[3]. I think that's the problem, for using the 
> firewall BPF options of systemd, you'll need to use kernel version >= 4.10.
> Regards.
> [1] > https://github.com/torvalds/linux/blob/master/init/Kconfig#L848> [2] > 
> https://github.com/torvalds/linux/blob/v4.9/init/Kconfig> [3] > 
> https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
> --
> Dr. Canek Peláez Valdés
> Profesor de Carrera Asociado C
> Departamento de Matemáticas
> Facultad de Ciencias
> Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

2017-10-28 Thread mad.scientist.at.large
updating the kernel is a really good idea, recent kernels have corrected a 
number of serious security issues that are definitely  real and exploitable.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 12:58 by can...@gmail.com:


> On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras <> rea...@gmail.com> > 
> wrote:
> >
> > There is no such kernel option.
>
> Yes, there is[1]. However, there is no such option for kernel version 4.9[2], 
> although there is for 4.10[3]. I think that's the problem, for using the 
> firewall BPF options of systemd, you'll need to use kernel version >= 4.10.> 
> 
> --
> Dr. Canek Peláez Valdés
> Profesor de Carrera Asociado C
> Departamento de Matemáticas
> Facultad de Ciencias
> Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

2017-10-28 Thread Canek Peláez Valdés
On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras  wrote:
>
> There is no such kernel option.

Yes, there is[1]. However, there is no such option for kernel version
4.9[2], although there is for 4.10[3]. I think that's the problem, for
using the firewall BPF options of systemd, you'll need to use kernel
version >= 4.10.

Regards.

[1] https://github.com/torvalds/linux/blob/master/init/Kconfig#L848
[2] https://github.com/torvalds/linux/blob/v4.9/init/Kconfig
[3] https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México


[gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

2017-10-28 Thread Nikos Chantziaras

There is no such kernel option.


On 28/10/17 21:21, Canek Peláez Valdés wrote:

Do you have CONFIG_CGROUP_BPF enabled?

Regards.

On Sat, Oct 28, 2017 at 1:03 PM, Nikos Chantziaras > wrote:


I'm getting these at startup:

systemd[1]: File /lib/systemd/system/systemd-journald.service:33
configures an IP firewall (IPAddressDeny=any), but the local system
does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-udevd.service:32
configures an IP firewall (IPAddressDeny=any), but the local system
does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-logind.service:34
configures an IP firewall (IPAddressDeny=any), but the local system
does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect!

What do I need to make this work? I found this:

https://github.com/systemd/systemd/issues/7188


But CONFIG_BPF_SYSCALL is enabled and I still get that message.

This is on kernel 4.9.59 with systemd 235.





[gentoo-user] Re: systemD?

2017-08-31 Thread Nikos Chantziaras

On 30/08/17 23:39, mad.scientist.at.la...@tutanota.com wrote:
I do not want to start a whole systemd storm, glad i was offline for 
that.  however, in my case i'd really like to avoid systemd.  can i 
setup with out systemd, or do i need to remove and patch later.


As others mentioned, openrc is the default. If you just do a default 
install, you won't be using systemd.


However, make sure that you don't intend to use something that requires 
systemd. Like Gnome, for example. You then will need to convert to 
systemd rather than having started out with it.





[gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

2017-04-11 Thread Kai Krakow
Am Tue, 11 Apr 2017 09:40:04 +0200
schrieb Raffaele Belardi :

> Kai Krakow wrote:
>  [...]  
> >>
> >> You might want to also look at sys-process/systemd-cron as a
> >> bridge. It basically generates timer units from your crontab and
> >> also runs the stuff in /etc/cron.*.d/.  But, timer scripts also
> >> work just fine and I do that for stuff that I want a bit more
> >> control over.  
> >
> > I don't suggest so. Services don't spawn session which cronjobs may
> > depend upon (most don't, tho). Cron spawns a session in the system
> > context. Both is not the same, so you should carefully decide which
> > cronjob to convert to a timer. Everything in /etc/cron* should work,
> > but timers are not a replacement for cron.
> >  
> 
> Thanks for all the hints, I'll test them in the next weeks.
> 
> I used cron mainly for backup scripts and log rotation, it should be
> fairly easy to convert to one of the above (cron session vs. timer)
> once I fully digest the implications.

I'm doing so, too: I use the timers for backup.

-- 
Regards,
Kai

Replies to list-only preferred.




Re: [gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

2017-04-11 Thread Raffaele Belardi

Kai Krakow wrote:

- cron/anacron after transition to systemd timers


You might want to also look at sys-process/systemd-cron as a bridge.
It basically generates timer units from your crontab and also runs the
stuff in /etc/cron.*.d/.  But, timer scripts also work just fine and I
do that for stuff that I want a bit more control over.


I don't suggest so. Services don't spawn session which cronjobs may
depend upon (most don't, tho). Cron spawns a session in the system
context. Both is not the same, so you should carefully decide which
cronjob to convert to a timer. Everything in /etc/cron* should work,
but timers are not a replacement for cron.



Thanks for all the hints, I'll test them in the next weeks.

I used cron mainly for backup scripts and log rotation, it should be fairly easy to 
convert to one of the above (cron session vs. timer) once I fully digest the implications.


raffaele



Re: [gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

2017-04-11 Thread Raffaele Belardi

Kai Krakow wrote:

Am Mon, 10 Apr 2017 09:27:57 +0200
schrieb Raffaele Belardi :


Looks like systemd does not provide a unit file for hdparm yet,
right? If so I suppose I'll have to write my own.
In general I suppose the same holds for everything that was
under /etc/local.d/


I've put the hdparm stuff in /etc/local.d:

$ cat /etc/local.d/hdparm.start
#!/bin/sh

for device in /sys/bus/scsi/devices/[012345]:0:0:0/block/*; do
hdparm -W1B254S241M254 /dev/$(basename $device)
done

Make it chmod +x.

Then install the gentoo integration packet for systemd which creates
the proper units on the fly during boot:

$ emerge -a sys-apps/gentoo-systemd-integration

After restart, you should see units started for each local.d script.
It's implemented as a systemd generator. To see how it works, look at
"equery f gentoo-systemd-integration" and have a look at the generator
files.


Worked perfectly, thank you. gentoo-systemd-integration was already present in the system, 
I just invoked directly the generator script that it installs.


raffaele



Re: [gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

2017-04-10 Thread Neil Bothwick
On Mon, 10 Apr 2017 17:45:59 +0200, Kai Krakow wrote:

> All those services are well integrated with each other and suitable for
> most stuff. Tho, systemd-networkd is not explicitly developed as a
> desktop daemon currently, systemd folks still tend to recommend
> NetworkManager to get all features. The systemd replacement perfectly
> works for me, tho: My desktop PC is a stationary PC with wired network.
> If you're mobile or use wifi, ymmv.

I use systemd-networkd with WiFi. It's just a case of running wpa_gui
when I want to connect to a new network.


-- 
Neil Bothwick

No, you *can't* call 999 now. I'm downloading my mail.


pgpx9f6hWiuhq.pgp
Description: OpenPGP digital signature


[gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

2017-04-10 Thread Kai Krakow
Am Mon, 10 Apr 2017 10:48:48 -0400
schrieb Rich Freeman :

> On Mon, Apr 10, 2017 at 3:27 AM, Raffaele Belardi
>  wrote:
> > After 10+ years of LXDE/OpenRC I decided to give Gnome/systemd a
> > try.
> >
> > 1. With OpenRC I used hdparm to put an external USB disk to sleep:
> >
> > $ cat /etc/conf.d/hdparm
> > sdb_args="-S24"
> >
> > Looks like systemd does not provide a unit file for hdparm yet,
> > right? If so I suppose I'll have to write my own.
> > In general I suppose the same holds for everything that was under
> > /etc/local.d/  
> 
> As Kai pointed out there are units/generators to run the stuff under
> local.d.  You could certainly create a unit for hdparm but a local.d
> script is probably fine for something done once like this, especially
> if there is no need to maintain any kind of state and undo it later.

KISS principle... ;-)

> > 2. Which OpenRC-related packages can I unmerge?
> > - sys-apps/sysvinit
> > - sys-apps/openrc  

Oh I totally left that out...

> This stuff ends up being pulled in by the system set, but you can
> eliminate it if you create a symlink from /lib/gentoo/functions.sh to
> /etc/init.d/functions.sh.

I instead made a file there with the following contents to spot the
broken packages:

$ cat /etc/init.d/functions.sh
source /lib/gentoo/functions.sh
ewarn "Usage of /etc/init.d/functions.sh is deprecated"

>  Don't ask me why stuff STILL sources the
> old location, other than it being so trivial that nobody cares that
> much.  I've put openrc in package.provided just to avoid the needless
> upgrades.  You can ditch sysvinit if you set USE=sysv-utils on systemd
> (so that you still get stuff like reboot/halt/poweroff, though I'm not
> sure how essential those actually are these days).

Use the following instead if you don't want to fiddle around with
versioning in package.provided:

$ cat /etc/portage/profile/packages
-*sys-apps/openrc

This removes openrc from the system set. You can then use depclean to
get rid of the rest but carefully check not to remove essential stuff.

Thus, I also strongly recommend USE=sysv-utils.

This is something like:

> > - app-admin/sysklogd  
> 
> Never used it, so obviously you can live without that.

Indeed not needed.

> > - cron/anacron after transition to systemd timers  
> 
> You might want to also look at sys-process/systemd-cron as a bridge.
> It basically generates timer units from your crontab and also runs the
> stuff in /etc/cron.*.d/.  But, timer scripts also work just fine and I
> do that for stuff that I want a bit more control over.

I don't suggest so. Services don't spawn session which cronjobs may
depend upon (most don't, tho). Cron spawns a session in the system
context. Both is not the same, so you should carefully decide which
cronjob to convert to a timer. Everything in /etc/cron* should work,
but timers are not a replacement for cron.

> > - sys-apps/debianutils provides savelog functionality also provided
> > by systemd but also installkernel so I shall not remove it  
> 
> I use logrotate personally, and I still need it for stuff that doesn't
> use syslog.

I've ditched all oldschool text log and only use journal now. This made
logrotate obsolete (which hardly managed to get all logfiles correctly
anyways due to changes in packages default configuration).

> > - others?  
> 
> That depends how far down the rabbit hole you want to go.  Systemd has
> semi-replacements for stuff like ntpd, dns, etc.  They're not intended
> as full replacements.  If you're serving time/dns/etc then you
> probably won't want it.  If you just want something to manage it
> locally on the host then these are fairly viable replacements.  There
> is also networkd, which I use on systems that don't have wifi.

All replacements except systemd-resolved work flawless for me. I'm
currently using the systemd resolver but it has its hickups from time
to time. This has become much better with the latest systemd version.

All those services are well integrated with each other and suitable for
most stuff. Tho, systemd-networkd is not explicitly developed as a
desktop daemon currently, systemd folks still tend to recommend
NetworkManager to get all features. The systemd replacement perfectly
works for me, tho: My desktop PC is a stationary PC with wired network.
If you're mobile or use wifi, ymmv.

> Systemd basically tries to provide all the essential services from a
> client-only perspective.

Yes, and that's sufficient. It doesn't have to be a server, meta
server, or proxy server. And it shouldn't be.

-- 
Regards,
Kai

Replies to list-only preferred.




[gentoo-user] Re: systemd questions: hdparm unit file, OpenRC packages

2017-04-10 Thread Kai Krakow
Am Mon, 10 Apr 2017 09:27:57 +0200
schrieb Raffaele Belardi :

> After 10+ years of LXDE/OpenRC I decided to give Gnome/systemd a try.
> 
> 1. With OpenRC I used hdparm to put an external USB disk to sleep:
> 
> $ cat /etc/conf.d/hdparm
> sdb_args="-S24"
> 
> Looks like systemd does not provide a unit file for hdparm yet,
> right? If so I suppose I'll have to write my own.
> In general I suppose the same holds for everything that was
> under /etc/local.d/
> 
> 2. Which OpenRC-related packages can I unmerge?
> - sys-apps/sysvinit
> - sys-apps/openrc
> - app-admin/sysklogd
> - cron/anacron after transition to systemd timers
> - sys-apps/debianutils provides savelog functionality also provided
> by systemd but also installkernel so I shall not remove it
> - others?

I've put the hdparm stuff in /etc/local.d:

$ cat /etc/local.d/hdparm.start
#!/bin/sh

for device in /sys/bus/scsi/devices/[012345]:0:0:0/block/*; do
hdparm -W1B254S241M254 /dev/$(basename $device)
done

Make it chmod +x.

Then install the gentoo integration packet for systemd which creates
the proper units on the fly during boot:

$ emerge -a sys-apps/gentoo-systemd-integration

After restart, you should see units started for each local.d script.
It's implemented as a systemd generator. To see how it works, look at
"equery f gentoo-systemd-integration" and have a look at the generator
files.

-- 
Regards,
Kai

Replies to list-only preferred.




Re: [gentoo-user] Re: systemd, libgudev and bug 552036

2015-12-19 Thread Mike Gilbert
On Fri, Dec 18, 2015 at 10:51 PM, Jonathan Callen  wrote:
> The python USE flag has been removed
> from newer stable versions of sys-apps/systemd (in favor of
> dev-python/python-systemd), but dev-python/python-systemd is not yet
> stable.

Thanks for catching that; I will file a stablereq right away.



[gentoo-user] Re: systemd, libgudev and bug 552036

2015-12-18 Thread Jonathan Callen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/18/2015 07:43 PM, Adam Carter wrote:
> emerge -1avt systemd
> 
> These are the packages that would be merged, in reverse order:
> 
> Calculating dependencies... done! [ebuild   R]
> sys-apps/systemd-218-r5:0/2::gentoo  USE="acl gudev introspection
> kmod lz4 pam policykit python seccomp ssl (-apparmor) -audit 
> -cryptsetup -curl -doc -elfutils -gcrypt -http -idn -kdbus -lzma
> -qrcode (-selinux) -sysv-utils -terminal {-test} -vanilla -xkb"
> ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python2_7
> -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_4
> -python3_3" 0 KiB
> 
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> 
> WARNING: One or more updates/rebuilds have been skipped due to a
> dependency conflict:
> 
> sys-apps/systemd:0
> 
> (sys-apps/systemd-226-r2:0/2::gentoo, ebuild scheduled for merge) 
> conflicts with
>> =sys-apps/systemd-212-r5:0/2[abi_x86_64(-),gudev(-),introspection(-)]
>
>> 
required by (virtual/libgudev-215-r3:0/0::gentoo, installed)
> 
> 
> sys-apps/systemd[python(-),python_targets_python2_7(-),python_single_t
arget_python2_7(+),python_targets_python3_4(-)]
>
> 
required by (net-analyzer/fail2ban-0.9.2:0/0::gentoo, installed)
> 
> 
> 
> 
> Would you like to merge these packages? [Yes/No]
> 

There are a couple of issues here, which appear to be caused by some
mismatched keywords in the tree. Your issue is that
net-analyzer/fail2ban[python] requires either sys-apps/systemd[python]
or dev-python/python-systemd. The python USE flag has been removed
from newer stable versions of sys-apps/systemd (in favor of
dev-python/python-systemd), but dev-python/python-systemd is not yet
stable. Therefore, portage is keeping the older version of systemd
installed, as that is the only way it could find to keep all deps
satisfied. If you want to keep fail2ban, the easiest method may be to
keyword dev-python/python-systemd-230 locally, and file a bug
requesting its stabilization.

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWdNRQAAoJEEIQbvYRB3mgy4MP/0iX59YRMQgC0su8YwLeCiBF
vbypMwDxhmJ3ZYYLcAcUzY2oGleiRZyShtyym8JB5MdG8z5G5qMkwTdaVByqOFa0
muC6qHL4nNNumNA5h2kqZoswCqLPqYclDj3P++oFlaDM0SiDzU5VrEz6CXTKn6bB
/FjmwuRq1SWAGH+ecloypOEZsy4UFaVM66MvydN+XRTS3R7ybhB+dHFUcsGjokTJ
GP9BsmxBanOgV79r90XwK4/+Zt/b6r4JvN7xuT81MOHTzeParD9fjmMVl68AX7YB
k1roVJPJLTQHnwurzwjjxAz6/8BwgzofADIw/FKqcuiIdRWc8KxgvsVl7ykdNuF4
kW1T2EMoCHbi5iQABTPzZsobrtolHhqZ0qn4mCw4VOuQ8zTgFUkg1rUUOmDurxrD
n3OEphcZRoTs4NJRicJs5omxWIFHpH571X3xI3MOM9W5n4mqTw6yYAlVWV730zU+
wIMl60SMHRnidJO7uCG/8JkAulw4/lkC6jWWFcY5HM2sXzy7W7hrKDZqPMMZ7WjA
gNd4hnUpUvJZsDe+hfAgehz3zh3pq0/GdI/sR9VUYC04NZESdS+LVe17V/RTVjJb
e0vpyR4HbwmrArVx1/m7DZuK19cdmOAT54aCV0LEbE+PK+4nflXwVjFpJiw5zdXV
+rUd4D8a3sY/eTe9cCnJ
=LYWj
-END PGP SIGNATURE-



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-06 Thread Alan McKinnon
On 06/08/2015 20:28, J. Roeleveld wrote:
 On Thursday, August 06, 2015 02:59:09 PM Mick wrote:
 On Wednesday 05 Aug 2015 22:47:43 Alan McKinnon wrote:
 On 05/08/2015 23:12, J. Roeleveld wrote:
 On Wednesday, August 05, 2015 06:20:17 PM Mick wrote:
 On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
 Much of what makes programming work has been dumbed down in recent
 years so that employable persons without imagination[1] can have jobs
 and do something useful. I'm reminded of an old saw about PHP:

 The nice thing about php is it let's everyone and their dog write
 code.
 The bad thing about php is that they do.

 Your imagination[1] footnote didn't make it to the list.  I thought for
 a minute that you used some php parser ...  :p

 It's not that old for an old saying.
 I can't find a reference to that saying older then august 2014 using
 Google.

 And all those are links to the same email written by our own Alan
 McKinnon

 Ah! That's because it was I who made it up years ago and have told it to
 lots of people.

 About a year ago is obviously the first time I wrote it down :-)

 Run the same search for perl - it's probably more appropriate than php and
 may find older samples of the same ol' saying.
 
 Nope, can't find a single hit with either line.
 
 Also would surprise me, as the largest part of the massive amount of bad code 
 (mostly copy/pasted from each other) arrived after PHP appeared.

It works just as well for php, perl, basic, VB, J2EE frameworks and any
draggy-droppy workflow thing that claims to produce runnable code.

It seems that only C is immune, probably because of the high barrier to
entry that must be climbed before writing something useful (and hello
world is not useful :-) )


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-06 Thread J. Roeleveld
On Thursday, August 06, 2015 02:59:09 PM Mick wrote:
 On Wednesday 05 Aug 2015 22:47:43 Alan McKinnon wrote:
  On 05/08/2015 23:12, J. Roeleveld wrote:
   On Wednesday, August 05, 2015 06:20:17 PM Mick wrote:
   On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
   Much of what makes programming work has been dumbed down in recent
   years so that employable persons without imagination[1] can have jobs
   and do something useful. I'm reminded of an old saw about PHP:
   
   The nice thing about php is it let's everyone and their dog write
   code.
   The bad thing about php is that they do.
   
   Your imagination[1] footnote didn't make it to the list.  I thought for
   a minute that you used some php parser ...  :p
   
   It's not that old for an old saying.
   I can't find a reference to that saying older then august 2014 using
   Google.
   
   And all those are links to the same email written by our own Alan
   McKinnon
  
  Ah! That's because it was I who made it up years ago and have told it to
  lots of people.
  
  About a year ago is obviously the first time I wrote it down :-)
 
 Run the same search for perl - it's probably more appropriate than php and
 may find older samples of the same ol' saying.

Nope, can't find a single hit with either line.

Also would surprise me, as the largest part of the massive amount of bad code 
(mostly copy/pasted from each other) arrived after PHP appeared.

--
Joost



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-06 Thread Mick
On Wednesday 05 Aug 2015 22:47:43 Alan McKinnon wrote:
 On 05/08/2015 23:12, J. Roeleveld wrote:
  On Wednesday, August 05, 2015 06:20:17 PM Mick wrote:
  On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
  Much of what makes programming work has been dumbed down in recent
  years so that employable persons without imagination[1] can have jobs
  and do something useful. I'm reminded of an old saw about PHP:
  
  The nice thing about php is it let's everyone and their dog write code.
  The bad thing about php is that they do.
  
  Your imagination[1] footnote didn't make it to the list.  I thought for
  a minute that you used some php parser ...  :p
  
  It's not that old for an old saying.
  I can't find a reference to that saying older then august 2014 using
  Google.
  
  And all those are links to the same email written by our own Alan
  McKinnon
 
 Ah! That's because it was I who made it up years ago and have told it to
 lots of people.
 
 About a year ago is obviously the first time I wrote it down :-)

Run the same search for perl - it's probably more appropriate than php and may 
find older samples of the same ol' saying.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread Fernando Rodriguez
On Wednesday, August 05, 2015 6:18:07 AM Franz Fellner wrote:
 walt wrote:
  On Tue, 04 Aug 2015 08:19:37 +0200
  Franz Fellner alpine.art...@gmail.com wrote:
  
   Fernando Rodriguez wrote:
On Monday, August 03, 2015 6:41:22 PM walt wrote:
 That line declares *hostname as a constant and then the statement
 below proceeds to assign a value to the 'constant'.  I wonder how
 many hours of frustration have been suffered by student
 programmers while trying to understand the logic behind that.

Because it's not a constant, it's a pointer-to-constant :)
   Both of you are right, you can read the declaration in both ways:
   hostname is of type pointer to const char.
   *hostname is of type const char.
   
   But in this case it is not *hostname, that get's a value assigned,
   it's simply hostname. If you do not set hostname to NULL it stays
   uninitialised, which means its value is what the actual memory is set
   to - quite undefined. Correct initialization is really important and
   should be done consequently so it gets an automatism ;) (would avoid
   issues like this)
   

const char *hostname; /* pointer to constant char */
char *const hostname; /* constant pointer to char */
const char *const hostname; /* constant pointer to constant char */

Is that confusing enough?
  
  confusing++
  
  Thank you both for being patient enough to teach the ineducable :)
  
  Let me give you one more example of syntax that I find unreasonable,
  and then I'll ask my *real* question, about which I hope you will have
  opinions.
  
  Okay, the statement I referred to above uses this notation:
  
   if (!link-network-hostname)  this notation makes sense to me
   r = sd_dhcp_lease_get_hostname(lease, hostname); this doesn't
 
 The -operator returns the address of the object, in this case of 
hostname.
 If you would just pass hostname the function would receive a _copy_ of the 
object.
 hostname is an out-argument, the function writes to it. That is needed 
sometimes
 as C only can return one value, if you need to return more things you need 
to pass
 them as out-args. But for that to work you need to operate on the actual 
object and
 not a copy of it, so you need to pass the address to the actual object.
 The declaration of the function of course needs to specify the arg as 
pointer to
 the actual type, here pointer to a pointer to char.

You can look at it like that, but more technically it's because C doesn't 
support out arguments, or reference arguments, or objects. All arguments are 
passed by value. You can return multiple values in a struct but it's not very 
convenient both in terms of usability (you need to store the result in a 
variable before you can use it unless you only care about one member) and 
performance since everything needs to be copied. Plus the implementation may 
vary significantly between compilers and architectures

So in order to get a value back from the function (other than the return) you 
pass the address (a pointer) where you want that data to be written. Things 
like that make C seem primitive if your coming from a higher level language 
but it is what makes C so powerful. Once you get the hang of it and understand 
how everything works it's actually simpler than higher level languages because 
C doesn't do stuff behind you back (or does very little) so you can read C code 
a understand what's going on under the hood. Most Java and .NET developers for 
example have no clue about what goes on in their own programs under the hood.

  
  In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
  charstring we actually need?
  
  Doesn't this code seem needlessly complicated?
  
  okay, screed over, thanks for listening
  
  Somewhere I read that there was really only *one* java program ever
  written, and every subsequent java program was written by cut-and-paste
  from the first one.
  
  Is that how professional developers learn the art of programming?

That's how you write bugs :) There's nothing wrong with it if you take the 
take to understand what it's doing but it's too often done blindly.

  I really would like to hear your opinions on that question because I
  feel it's an important topic.
  
  Thanks guys.
  
  
  
 
 
 

-- 
Fernando Rodriguez



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread Alan McKinnon
On 05/08/2015 10:18, Fernando Rodriguez wrote:
 You can look at it like that, but more technically it's because C doesn't 
 support out arguments, or reference arguments, or objects. All arguments are 
 passed by value. You can return multiple values in a struct but it's not very 
 convenient both in terms of usability (you need to store the result in a 
 variable before you can use it unless you only care about one member) and 
 performance since everything needs to be copied. Plus the implementation may 
 vary significantly between compilers and architectures
 
 So in order to get a value back from the function (other than the return) you 
 pass the address (a pointer) where you want that data to be written. Things 
 like that make C seem primitive if your coming from a higher level language 
 but it is what makes C so powerful. Once you get the hang of it and 
 understand 
 how everything works it's actually simpler than higher level languages 
 because 
 C doesn't do stuff behind you back (or does very little) so you can read C 
 code 
 a understand what's going on under the hood. Most Java and .NET developers 
 for 
 example have no clue about what goes on in their own programs under the hood.

Thanks for the reminder. I'd forgotten much about C (not needing to read
or write it much these days)
 
   
   In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
   charstring we actually need?
   
   Doesn't this code seem needlessly complicated?
   
   okay, screed over, thanks for listening
   
   Somewhere I read that there was really only *one* java program ever
   written, and every subsequent java program was written by cut-and-paste
   from the first one.
   
   Is that how professional developers learn the art of programming?

Looking back 12 months to some former colleagues, that is *exactly* how
the Java ecosystem works. I haven't seen anyone write Java from scratch
in *years* now, all of them seem to twiddle little bits inside some huge
framework and have zero concept about what is going on.

So you get anomolies like a giant payroll/compensation/commission
reporting tool thingamagic from Oracle that does everything imaginable
about sales commissions, except actually report on them. True fax - ask
my wife


 That's how you write bugs :) There's nothing wrong with it if you take the 
 take to understand what it's doing but it's too often done blindly.
 
   I really would like to hear your opinions on that question because I
   feel it's an important topic.

Much of what makes programming work has been dumbed down in recent years
so that employable persons without imagination[1] can have jobs and do
something useful. I'm reminded of an old saw about PHP:

The nice thing about php is it let's everyone and their dog write code.
The bad thing about php is that they do.

I suppose there's a place for that kind of thing, a lot of corporate
systems are mostly boilerplate where a huge framework (and equally huge
expensive over-specced hardware) gets the job done. The thing that
really changes is the exact calculations in the business-logic
middleware layer, someone else did the heavy lifting of joining all the
modules together to resemble the real-world workflow.

It's not my way of working though, and I suspect most Gentooers tend the
same way if they get the chance.


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread Mick
On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
 Much of what makes programming work has been dumbed down in recent years
 so that employable persons without imagination[1] can have jobs and do
 something useful. I'm reminded of an old saw about PHP:
 
 The nice thing about php is it let's everyone and their dog write code.
 The bad thing about php is that they do.

Your imagination[1] footnote didn't make it to the list.  I thought for a 
minute that you used some php parser ...  :p

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread Alan McKinnon
On 05/08/2015 19:20, Mick wrote:
 On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
 Much of what makes programming work has been dumbed down in recent years
 so that employable persons without imagination[1] can have jobs and do
 something useful. I'm reminded of an old saw about PHP:

 The nice thing about php is it let's everyone and their dog write code.
 The bad thing about php is that they do.
 
 Your imagination[1] footnote didn't make it to the list.  I thought for a 
 minute that you used some php parser ...  :p
 


That's what happens when you make a typo after a thinko


-- 
Alan McKinnon
alan.mckin...@gmail.com




Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread J. Roeleveld
On Wednesday, August 05, 2015 12:47:58 PM Alan McKinnon wrote:
 On 05/08/2015 10:18, Fernando Rodriguez wrote:
In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
charstring we actually need?

Doesn't this code seem needlessly complicated?

okay, screed over, thanks for listening

Somewhere I read that there was really only *one* java program ever
written, and every subsequent java program was written by
cut-and-paste
from the first one.

Is that how professional developers learn the art of programming?
 
 Looking back 12 months to some former colleagues, that is *exactly* how
 the Java ecosystem works. I haven't seen anyone write Java from scratch
 in *years* now, all of them seem to twiddle little bits inside some huge
 framework and have zero concept about what is going on.

Only 12 months?
Most IDEs and/or frameworks basically set up everything and just add bits like 
// Write your code here
Problems start when these ama...eerh... programmers put there code in other 
locations...

 So you get anomolies like a giant payroll/compensation/commission
 reporting tool thingamagic from Oracle that does everything imaginable
 about sales commissions, except actually report on them. True fax - ask
 my wife

Don't need to ask her, seen it with my own eyes...

It keeps amazing me that the software actually does work most of the time.

  That's how you write bugs :) There's nothing wrong with it if you take the
  take to understand what it's doing but it's too often done blindly.
  
I really would like to hear your opinions on that question because I
feel it's an important topic.
 
 Much of what makes programming work has been dumbed down in recent years
 so that employable persons without imagination[1] can have jobs and do
 something useful. I'm reminded of an old saw about PHP:
 
 The nice thing about php is it let's everyone and their dog write code.
 The bad thing about php is that they do.

Couldn't find that particular quote, but the following page should be required 
study for everyone starting with programming. (It's for PHP, but should work 
for ALL languages):
http://code.tutsplus.com/tutorials/why-youre-a-bad-php-programmer--net-18384


 I suppose there's a place for that kind of thing, a lot of corporate
 systems are mostly boilerplate where a huge framework (and equally huge
 expensive over-specced hardware) gets the job done.

Well, when you have a big rocketbooster for propulsion, why not build a car 
from solid rock without wheels?

 The thing that
 really changes is the exact calculations in the business-logic
 middleware layer, someone else did the heavy lifting of joining all the
 modules together to resemble the real-world workflow.

And then these same corporates want to add new features and such which means 
improving the codebase. Breaking the badly (or not at all) understood logic in 
the process.

 It's not my way of working though, and I suspect most Gentooers tend the
 same way if they get the chance.

++ this is why I still use Gentoo...



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread J. Roeleveld
On Wednesday, August 05, 2015 06:20:17 PM Mick wrote:
 On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
  Much of what makes programming work has been dumbed down in recent years
  so that employable persons without imagination[1] can have jobs and do
  something useful. I'm reminded of an old saw about PHP:
  
  The nice thing about php is it let's everyone and their dog write code.
  The bad thing about php is that they do.
 
 Your imagination[1] footnote didn't make it to the list.  I thought for a
 minute that you used some php parser ...  :p

It's not that old for an old saying.
I can't find a reference to that saying older then august 2014 using Google.

And all those are links to the same email written by our own Alan McKinnon

--
Joost



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread Alan McKinnon
On 05/08/2015 23:12, J. Roeleveld wrote:
 On Wednesday, August 05, 2015 06:20:17 PM Mick wrote:
 On Wednesday 05 Aug 2015 11:47:58 Alan McKinnon wrote:
 Much of what makes programming work has been dumbed down in recent years
 so that employable persons without imagination[1] can have jobs and do
 something useful. I'm reminded of an old saw about PHP:

 The nice thing about php is it let's everyone and their dog write code.
 The bad thing about php is that they do.

 Your imagination[1] footnote didn't make it to the list.  I thought for a
 minute that you used some php parser ...  :p
 
 It's not that old for an old saying.
 I can't find a reference to that saying older then august 2014 using Google.
 
 And all those are links to the same email written by our own Alan McKinnon


Ah! That's because it was I who made it up years ago and have told it to
lots of people.

About a year ago is obviously the first time I wrote it down :-)


-- 
Alan McKinnon
alan.mckin...@gmail.com




[gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread walt
On Wed, 05 Aug 2015 23:00:36 +0200
J. Roeleveld jo...@antarean.org wrote:

 the following page should be required 
 study for everyone starting with programming. (It's for PHP, but
 should work for ALL languages):
 http://code.tutsplus.com/tutorials/why-youre-a-bad-php-programmer--net-18384

Excellent article, thanks, and interesting website.  I've been looking
for a good javascript tutorial and I see they offer several of them.





Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-05 Thread Fernando Rodriguez
On Wednesday, August 05, 2015 12:47:58 PM Alan McKinnon wrote:
 Much of what makes programming work has been dumbed down in recent years
 so that employable persons without imagination[1] can have jobs and do
 something useful. I'm reminded of an old saw about PHP:

It may be that in recent years the trend has made it to the FOSS community, 
but I'd say it goes to the mid to early 90s with Microsoft's Visual IDEs. 

By the late 90s you could write a Windows GUI application in VisualBasic 6 
mostly by drag and drop on the visual designer. With Visual Studio .NET in 
2000/1 your could do it for a web application (ASP.NET) as well and you could 
design a database driven web app without writing a single line of code. In 
VS2008 they came up with a designer where you write the program by dragging 
blocks into a flowchart[1].

These tools are nice (at least the ones for GUI apps). I wish we had similar 
tools of the same quality in the FOSS world. The problem is that you'll get 
programmers that only know how to drag and drop and when it comes to the 10% 
of the program that needs to be coded they do a horrible job.


1. https://msdn.microsoft.com/en-us/library/gg983474%28v=vs.110%29.aspx

-- 
Fernando Rodriguez



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-04 Thread Franz Fellner
Fernando Rodriguez wrote:
 On Monday, August 03, 2015 6:41:22 PM walt wrote:
  That line declares *hostname as a constant and then the statement below
  proceeds to assign a value to the 'constant'.  I wonder how many hours
  of frustration have been suffered by student programmers while trying to
  understand the logic behind that.
 
 Because it's not a constant, it's a pointer-to-constant :)
Both of you are right, you can read the declaration in both ways:
hostname is of type pointer to const char.
*hostname is of type const char.

But in this case it is not *hostname, that get's a value assigned, it's 
simply hostname. If you do not set hostname to NULL it stays uninitialised, 
which means its value is what the actual memory is set to - quite undefined.
Correct initialization is really important and should be done consequently so 
it gets an automatism ;) (would avoid issues like this)

 
 const char *hostname; /* pointer to constant char */
 char *const hostname; /* constant pointer to char */
 const char *const hostname; /* constant pointer to constant char */
 
 Is that confusing enough?
 
 -- 
 Fernando Rodriguez
 





RE: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-04 Thread Franz Fellner
walt wrote:
 On Tue, 04 Aug 2015 08:19:37 +0200
 Franz Fellner alpine.art...@gmail.com wrote:
 
  Fernando Rodriguez wrote:
   On Monday, August 03, 2015 6:41:22 PM walt wrote:
That line declares *hostname as a constant and then the statement
below proceeds to assign a value to the 'constant'.  I wonder how
many hours of frustration have been suffered by student
programmers while trying to understand the logic behind that.
   
   Because it's not a constant, it's a pointer-to-constant :)
  Both of you are right, you can read the declaration in both ways:
  hostname is of type pointer to const char.
  *hostname is of type const char.
  
  But in this case it is not *hostname, that get's a value assigned,
  it's simply hostname. If you do not set hostname to NULL it stays
  uninitialised, which means its value is what the actual memory is set
  to - quite undefined. Correct initialization is really important and
  should be done consequently so it gets an automatism ;) (would avoid
  issues like this)
  
   
   const char *hostname; /* pointer to constant char */
   char *const hostname; /* constant pointer to char */
   const char *const hostname; /* constant pointer to constant char */
   
   Is that confusing enough?
 
 confusing++
 
 Thank you both for being patient enough to teach the ineducable :)
 
 Let me give you one more example of syntax that I find unreasonable,
 and then I'll ask my *real* question, about which I hope you will have
 opinions.
 
 Okay, the statement I referred to above uses this notation:
 
  if (!link-network-hostname)  this notation makes sense to me
  r = sd_dhcp_lease_get_hostname(lease, hostname); this doesn't

The -operator returns the address of the object, in this case of hostname.
If you would just pass hostname the function would receive a _copy_ of the 
object.
hostname is an out-argument, the function writes to it. That is needed 
sometimes
as C only can return one value, if you need to return more things you need to 
pass
them as out-args. But for that to work you need to operate on the actual object 
and
not a copy of it, so you need to pass the address to the actual object.
The declaration of the function of course needs to specify the arg as pointer 
to
the actual type, here pointer to a pointer to char.

 
 In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
 charstring we actually need?
 
 Doesn't this code seem needlessly complicated?
 
 okay, screed over, thanks for listening
 
 Somewhere I read that there was really only *one* java program ever
 written, and every subsequent java program was written by cut-and-paste
 from the first one.
 
 Is that how professional developers learn the art of programming?
 
 I really would like to hear your opinions on that question because I
 feel it's an important topic.
 
 Thanks guys.
 
 
 





[gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-04 Thread walt
On Tue, 04 Aug 2015 08:19:37 +0200
Franz Fellner alpine.art...@gmail.com wrote:

 Fernando Rodriguez wrote:
  On Monday, August 03, 2015 6:41:22 PM walt wrote:
   That line declares *hostname as a constant and then the statement
   below proceeds to assign a value to the 'constant'.  I wonder how
   many hours of frustration have been suffered by student
   programmers while trying to understand the logic behind that.
  
  Because it's not a constant, it's a pointer-to-constant :)
 Both of you are right, you can read the declaration in both ways:
 hostname is of type pointer to const char.
 *hostname is of type const char.
 
 But in this case it is not *hostname, that get's a value assigned,
 it's simply hostname. If you do not set hostname to NULL it stays
 uninitialised, which means its value is what the actual memory is set
 to - quite undefined. Correct initialization is really important and
 should be done consequently so it gets an automatism ;) (would avoid
 issues like this)
 
  
  const char *hostname; /* pointer to constant char */
  char *const hostname; /* constant pointer to char */
  const char *const hostname; /* constant pointer to constant char */
  
  Is that confusing enough?

confusing++

Thank you both for being patient enough to teach the ineducable :)

Let me give you one more example of syntax that I find unreasonable,
and then I'll ask my *real* question, about which I hope you will have
opinions.

Okay, the statement I referred to above uses this notation:

 if (!link-network-hostname)  this notation makes sense to me
 r = sd_dhcp_lease_get_hostname(lease, hostname); this doesn't

In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
charstring we actually need?

Doesn't this code seem needlessly complicated?

okay, screed over, thanks for listening

Somewhere I read that there was really only *one* java program ever
written, and every subsequent java program was written by cut-and-paste
from the first one.

Is that how professional developers learn the art of programming?

I really would like to hear your opinions on that question because I
feel it's an important topic.

Thanks guys.





Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-04 Thread Mike Gilbert
On Tue, Aug 4, 2015 at 7:56 PM, walt w41...@gmail.com wrote:
 Let me give you one more example of syntax that I find unreasonable,
 and then I'll ask my *real* question, about which I hope you will have
 opinions.

 Okay, the statement I referred to above uses this notation:

  if (!link-network-hostname)  this notation makes sense to me
  r = sd_dhcp_lease_get_hostname(lease, hostname); this doesn't

 In this context does 'hostname' mean a-pointer-to-a-pointer-to-the-
 charstring we actually need?

 Doesn't this code seem needlessly complicated?

Nope, looks like standard C to me. If you want a function to update an
argument, you need to pass a pointer to said argument. If you want to
update a pointer, you need to pass a pointer to a pointer.



[gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-03 Thread walt
On Mon, 3 Aug 2015 14:23:18 -0400
Mike Gilbert flop...@gentoo.org wrote:

 On Sun, Aug 2, 2015 at 11:16 AM, walt w41...@gmail.com wrote:
  On Sun, 2 Aug 2015 08:03:11 -0700
  walt w41...@gmail.com wrote:

  Oops, journalctl tells me that systemd-networkd is segfaulting
  repeatedly during boot.  I'm reverting back to systemd-222-r1 until
  this gets sorted out.
 
 Fixed in systemd-224-r1. Next time file a bug; I don't always read
 this list.

Thanks Mike.  The fix is amazingly simple but looking at the patch
makes me realize how little I understand the c language after years
of reading c code but not writing any :/

const char *hostname = NULL;  (upstream apparently forgot the = NULL)

That line declares *hostname as a constant and then the statement below
proceeds to assign a value to the 'constant'.  I wonder how many hours
of frustration have been suffered by student programmers while trying to
understand the logic behind that.

coughing from the dust on my 40-year-old Kernighan and Ritchie I see
that they didn't include the 'const' keyword at all.  That was a later
change introduced by some ANSI committee, bless them.

sigh I truly don't understand how any working code get written.

Anyway, thanks again for the fix :)




Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior [FIXED]

2015-08-03 Thread Fernando Rodriguez
On Monday, August 03, 2015 6:41:22 PM walt wrote:
 That line declares *hostname as a constant and then the statement below
 proceeds to assign a value to the 'constant'.  I wonder how many hours
 of frustration have been suffered by student programmers while trying to
 understand the logic behind that.

Because it's not a constant, it's a pointer-to-constant :)

const char *hostname; /* pointer to constant char */
char *const hostname; /* constant pointer to char */
const char *const hostname; /* constant pointer to constant char */

Is that confusing enough?

-- 
Fernando Rodriguez



Re: [gentoo-user] Re: systemd-224 Look out for new networking behavior

2015-08-03 Thread Mike Gilbert
On Sun, Aug 2, 2015 at 11:16 AM, walt w41...@gmail.com wrote:
 On Sun, 2 Aug 2015 08:03:11 -0700
 walt w41...@gmail.com wrote:

 I've been running systemd for a long time without needing to enable
 the dhcpcd service at boot time.  Starting with systemd-224 that is no
 longer true.

 Oops, journalctl tells me that systemd-networkd is segfaulting
 repeatedly during boot.  I'm reverting back to systemd-222-r1 until
 this gets sorted out.

Fixed in systemd-224-r1. Next time file a bug; I don't always read this list.



[gentoo-user] Re: systemd-224 Look out for new networking behavior

2015-08-02 Thread walt
On Sun, 2 Aug 2015 08:03:11 -0700
walt w41...@gmail.com wrote:

 I've been running systemd for a long time without needing to enable
 the dhcpcd service at boot time.  Starting with systemd-224 that is no
 longer true. 

Oops, journalctl tells me that systemd-networkd is segfaulting
repeatedly during boot.  I'm reverting back to systemd-222-r1 until
this gets sorted out.





[gentoo-user] Re: systemd-224 Look out for new networking behavior

2015-08-02 Thread Martin Vaeth
walt w41...@gmail.com wrote:

 Oops, journalctl tells me that systemd-networkd is segfaulting
 repeatedly during boot.

systemd has become very picky on cflags; e.g. -DNDEBUG
and friends cause strange behaviour and segfaults.




Re: [gentoo-user] Re: systemd: incorrect behavior when doing poweroff/reboot

2015-03-22 Thread Alan McKinnon
On 22/03/2015 03:32, Hans wrote:
 On 22/03/15 08:44, walt wrote:
 I'd be 100% sure this is a systemd bug except that the problem is so
 obvious and (I think) so common that I can't believe I'm the only
 systemd user seeing it:

 I routinely share /usr/portage over NFS between several gentoo boxes
 on my wireless network.  When I poweroff or reboot the NFS client
 machines, systemd tears down the wireless connection *before* it
 unmounts the /usr/portage share, and so the umount command hangs and
 the machine won't shut down.

 I'd think people that hang out in this list must do the same thing,
 surely?  No one else here running into this silly problem?



 Had the same and various other problem. Resolved it by giving systemd
 the boot. No more problems with after I changed to openrc.
 

Surely that's a simple matter of adjusting the shutdown order in the
unit files for those packages?

Open a bug and the package maintainer will correct it.


-- 
Alan McKinnon
alan.mckin...@gmail.com




[gentoo-user] Re: systemd: incorrect behavior when doing poweroff/reboot

2015-03-21 Thread Hans

On 22/03/15 08:44, walt wrote:

I'd be 100% sure this is a systemd bug except that the problem is so
obvious and (I think) so common that I can't believe I'm the only
systemd user seeing it:

I routinely share /usr/portage over NFS between several gentoo boxes
on my wireless network.  When I poweroff or reboot the NFS client
machines, systemd tears down the wireless connection *before* it
unmounts the /usr/portage share, and so the umount command hangs and
the machine won't shut down.

I'd think people that hang out in this list must do the same thing,
surely?  No one else here running into this silly problem?



Had the same and various other problem. Resolved it by giving systemd 
the boot. No more problems with after I changed to openrc.





Re: [gentoo-user] Re: systemd + openvpn

2015-02-13 Thread Rich Freeman
On Thu, Feb 12, 2015 at 11:37 PM, Joseph syscon...@gmail.com wrote:
 No, the problem in Fedora was thier selinux. I suppose to be some extra
 security, but it seems to me it creates only more problems.

A common observation with SELinux.  Even so, it definitely DOES
provide additional security.  It is a standard Linux feature and
available on Gentoo as well.  If the configuration isn't right (and it
is easy to get it wrong) then you'll have problems.

I forget all the details of SELinux, but you should be able to put it
in a mode that logs but does not enforce.  Using those logs you should
be able to determine exactly what roles/permissions/labels/etc are
missing.  I suspect that if you just dumped the relevant logs on
Fedora's bugzilla that they'd fix their openvpn package for you.  If I
had a working SELinux setup I wouldn't be too quick to just completely
disable it over one package.

-- 
Rich



Re: [gentoo-user] Re: systemd + openvpn

2015-02-12 Thread Joseph

On 02/11/15 19:26, Rich Freeman wrote:

On Wed, Feb 11, 2015 at 6:26 PM, walt w41...@gmail.com wrote:


Yes, I see the same, which I feel is a systemd bug.  The escaping
trick works only with the 'enable' command, not stop or start. Dumb.



It seems more likely to be an error with the unit, which has nothing
to do with systemd.  As I mentioned already, I had to make some
changes in mine.

If you write a bad init.d scripts, that isn't an openrc bug either.  :)

--
Rich


No, the problem in Fedora was thier selinux. I suppose to be some extra 
security, but it seems to me it creates only more problems.
So I disabled it, and openvpn connects just fine.
I was able to install on it nxclient-3.5 as well, it works fine.

--
Joseph



Re: [gentoo-user] Re: systemd not starting wpa_supplicant after last update

2015-02-11 Thread Rich Freeman
On Wed, Feb 11, 2015 at 5:37 PM, walt w41...@gmail.com wrote:

 Yes, thank you!  Did you use systemctl to make all the symlinks?  I just did 
 it
 all manually and it works, but I'm not sure how I would have done it using 
 systemctl.


systemctl enable service

That looks in the unit's install section to see what target it should
be associated with.  This is actually a nice feature - with openrc it
wasn't always obvious when things should go in the boot vs default
runlevel, etc.  But, all that command does is create the symlinks in
the target.wants directory, so you can just create those yourself if
you want to.  That actually works for anything - you can effectively
add a dependency to a unit by creating a directory of the appropriate
name and symlinking the dependency inside.

-- 
Rich



Re: [gentoo-user] Re: systemd + openvpn

2015-02-11 Thread Joseph

On 02/11/15 15:26, walt wrote:

On 02/11/2015 02:38 PM, Joseph wrote:

On 02/11/15 13:52, walt wrote:

On 02/11/2015 10:58 AM, Joseph wrote:

on Fedora when I do systemctl enable openvpn@eeepc.service

I get:
Failed to execute operation: No such file or directory.


You need to escape the @ by typing openvpn\@eeepc.service,
which is not clear from the error message.


I'm still getting the same failed error message.

systemctl start openvpn\@eeepc.service


Yes, I see the same, which I feel is a systemd bug.  The escaping
trick works only with the 'enable' command, not stop or start. Dumb.

As an experiment you might try systemctl start openvpn\*  or even
openvpn[@]eeepc  in case regexps might work.

BTW the .service is optional, systemd assumes it as the default.


Thanks for trying to help.
I'm getting the same error message :-/
Trying to install Gentoo on it will take me 1-2 weeks :-/ so I was looking for 
an alternative.

--
Joseph



[gentoo-user] Re: systemd + openvpn

2015-02-11 Thread walt
On 02/11/2015 10:58 AM, Joseph wrote:
 on Fedora when I do systemctl enable openvpn@eeepc.service
 
 I get:
 Failed to execute operation: No such file or directory.

You need to escape the @ by typing openvpn\@eeepc.service,
which is not clear from the error message.



[gentoo-user] Re: systemd + openvpn

2015-02-11 Thread walt
On 02/11/2015 02:38 PM, Joseph wrote:
 On 02/11/15 13:52, walt wrote:
 On 02/11/2015 10:58 AM, Joseph wrote:
 on Fedora when I do systemctl enable openvpn@eeepc.service

 I get:
 Failed to execute operation: No such file or directory.

 You need to escape the @ by typing openvpn\@eeepc.service,
 which is not clear from the error message.
 
 I'm still getting the same failed error message.
 
 systemctl start openvpn\@eeepc.service

Yes, I see the same, which I feel is a systemd bug.  The escaping
trick works only with the 'enable' command, not stop or start. Dumb.

As an experiment you might try systemctl start openvpn\*  or even
openvpn[@]eeepc  in case regexps might work.

BTW the .service is optional, systemd assumes it as the default.





Re: [gentoo-user] Re: systemd + openvpn

2015-02-11 Thread Joseph

On 02/11/15 13:52, walt wrote:

On 02/11/2015 10:58 AM, Joseph wrote:

on Fedora when I do systemctl enable openvpn@eeepc.service

I get:
Failed to execute operation: No such file or directory.


You need to escape the @ by typing openvpn\@eeepc.service,
which is not clear from the error message.


I'm still getting the same failed error message.

systemctl start openvpn\@eeepc.service

--
Joseph



[gentoo-user] Re: systemd not starting wpa_supplicant after last update

2015-02-11 Thread walt
On 02/11/2015 03:20 PM, Rich Freeman wrote:
 On Wed, Feb 11, 2015 at 5:37 PM, walt w41...@gmail.com wrote:

 Yes, thank you!  Did you use systemctl to make all the symlinks?  I just did 
 it
 all manually and it works, but I'm not sure how I would have done it using 
 systemctl.

 
 systemctl enable service
 
 That looks in the unit's install section to see what target it should
 be associated with.  This is actually a nice feature - with openrc it
 wasn't always obvious when things should go in the boot vs default
 runlevel, etc.  But, all that command does is create the symlinks in
 the target.wants directory, so you can just create those yourself if
 you want to.  That actually works for anything - you can effectively
 add a dependency to a unit by creating a directory of the appropriate
 name and symlinking the dependency inside.

The symlink that was puzzling me is this one:

wpa_supplicant@wlan0.service - 
/usr/lib64/systemd/system/wpa_supplicant@.service

The name of the symlink is not the same as the .service file it points to.
Is there a systemctl command that would do that for me?




Re: [gentoo-user] Re: systemd not starting wpa_supplicant after last update

2015-02-11 Thread Rich Freeman
On Wed, Feb 11, 2015 at 6:37 PM, walt w41...@gmail.com wrote:
 On 02/11/2015 03:20 PM, Rich Freeman wrote:
 On Wed, Feb 11, 2015 at 5:37 PM, walt w41...@gmail.com wrote:

 Yes, thank you!  Did you use systemctl to make all the symlinks?  I just 
 did it
 all manually and it works, but I'm not sure how I would have done it using 
 systemctl.


 systemctl enable service

 That looks in the unit's install section to see what target it should
 be associated with.  This is actually a nice feature - with openrc it
 wasn't always obvious when things should go in the boot vs default
 runlevel, etc.  But, all that command does is create the symlinks in
 the target.wants directory, so you can just create those yourself if
 you want to.  That actually works for anything - you can effectively
 add a dependency to a unit by creating a directory of the appropriate
 name and symlinking the dependency inside.

 The symlink that was puzzling me is this one:

 wpa_supplicant@wlan0.service - 
 /usr/lib64/systemd/system/wpa_supplicant@.service

 The name of the symlink is not the same as the .service file it points to.
 Is there a systemctl command that would do that for me?

systemctl enable wpa_supplicant@wlan0

That is an instanced service.  It is a bit like creating a symlink
from net.lo to net.eth0 in openrc.  If you read the service file
you'll see that all it does is takes whatever is to the right of the
@, tacks on a .conf, and uses that as the openvpn config file.
Another example is getty@ - you want to run 6 gettys and they all
start/stop independently, so instead of copying the same file 6 times
you just parameterize it.

-- 
Rich



[gentoo-user] Re: systemd not starting wpa_supplicant after last update

2015-02-11 Thread walt
On 02/11/2015 01:05 PM, Neil Bothwick wrote:
 On Wed, 11 Feb 2015 13:22:13 -0600, Canek Peláez Valdés wrote:
 
 I use NetworkManager for wireless connections, and systemd-networkd for
 static ethernet, so I don't use wpa_supplicant directly. However, I
 would suggest to simply enable
 wpa_supplicant@your-wireless-device.service.
 
 I have it set up like this
 
 % cat /etc/systemd/network/20-wlan0.network
 [Match]
 Name=wlan0
 
 [Network]
 Description=Wireless network
 DHCP=yes
 
 
 % ls -l /etc/systemd/system/systemd-networkd.service.wants/
 systemd-resolved.service - /usr/lib/systemd/system/systemd-resolved.service
 wpa_supplicant@wlan0.service - 
 /usr/lib64/systemd/system/wpa_supplicant@.service

Yes, thank you!  Did you use systemctl to make all the symlinks?  I just did it
all manually and it works, but I'm not sure how I would have done it using 
systemctl.

I just discovered I needed to create a symlink from 
/run/systemd/resolve/resolv.conf
to /etc/resolv.conf.  Had to resort to reading a man page :(




Re: [gentoo-user] Re: systemd + openvpn

2015-02-11 Thread Rich Freeman
On Wed, Feb 11, 2015 at 6:26 PM, walt w41...@gmail.com wrote:

 Yes, I see the same, which I feel is a systemd bug.  The escaping
 trick works only with the 'enable' command, not stop or start. Dumb.


It seems more likely to be an error with the unit, which has nothing
to do with systemd.  As I mentioned already, I had to make some
changes in mine.

If you write a bad init.d scripts, that isn't an openrc bug either.  :)

-- 
Rich



Re: [gentoo-user] Re: systemd not starting wpa_supplicant after last update

2015-02-11 Thread Neil Bothwick
On Wed, 11 Feb 2015 14:37:22 -0800, walt wrote:

  % ls -l /etc/systemd/system/systemd-networkd.service.wants/
  systemd-resolved.service
  - /usr/lib/systemd/system/systemd-resolved.service
  wpa_supplicant@wlan0.service
  - /usr/lib64/systemd/system/wpa_supplicant@.service  
 
 Yes, thank you!  Did you use systemctl to make all the symlinks?  I
 just did it all manually and it works, but I'm not sure how I would
 have done it using systemctl.

I see Rich has already answered this because, ironically, I was unable to
after a kernel update stopped my wireless from working :(

Sod's Law determined that the kernel that broke thing was the one that I
decided to try using dracut instead of my home-brewed initramfs, so I
started off blaming that for the failure.


-- 
Neil Bothwick

You are a completely unique individual, just like everybody else.


pgpn4olVW_JzQ.pgp
Description: OpenPGP digital signature


[gentoo-user] Re: systemd not starting wpa_supplicant after last update

2015-02-11 Thread walt
On 02/11/2015 04:30 PM, Rich Freeman wrote:
 On Wed, Feb 11, 2015 at 6:37 PM, walt w41...@gmail.com wrote:
 On 02/11/2015 03:20 PM, Rich Freeman wrote:
 On Wed, Feb 11, 2015 at 5:37 PM, walt w41...@gmail.com wrote:

 Yes, thank you!  Did you use systemctl to make all the symlinks?  I just 
 did it
 all manually and it works, but I'm not sure how I would have done it using 
 systemctl.


 systemctl enable service

 That looks in the unit's install section to see what target it should
 be associated with.  This is actually a nice feature - with openrc it
 wasn't always obvious when things should go in the boot vs default
 runlevel, etc.  But, all that command does is create the symlinks in
 the target.wants directory, so you can just create those yourself if
 you want to.  That actually works for anything - you can effectively
 add a dependency to a unit by creating a directory of the appropriate
 name and symlinking the dependency inside.

 The symlink that was puzzling me is this one:

 wpa_supplicant@wlan0.service - 
 /usr/lib64/systemd/system/wpa_supplicant@.service

 The name of the symlink is not the same as the .service file it points to.
 Is there a systemctl command that would do that for me?
 
 systemctl enable wpa_supplicant@wlan0
 
 That is an instanced service.  It is a bit like creating a symlink
 from net.lo to net.eth0 in openrc.  If you read the service file
 you'll see that all it does is takes whatever is to the right of the
 @, tacks on a .conf, and uses that as the openvpn config file.
 Another example is getty@ - you want to run 6 gettys and they all
 start/stop independently, so instead of copying the same file 6 times
 you just parameterize it.

Many thanks, I'll try it tomorrow morning when I'm fresh enough to deal
with any disaster I may cause :)





[gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-17 Thread walt
On 10/16/2014 04:34 PM, Canek Peláez Valdés wrote:
 At
 some point NM had integration with the OpenRC network configuration,
 and (AFAIR) sometimes it made a mess inside /etc/conf.d. I don't know
 if such integration exists anymore; nowadays I don't even have
 /etc/{conf,init}.d, and everything works so much better.

Bingo.  I renamed conf.d and init.d and now NM works perfectly during
bootup.  Now that you mention it, journalctl did print messages about
/etc/init.d  and I thought it was a bit strange.

Thanks Canek and Tom for the excellent help.





Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-17 Thread Canek Peláez Valdés
Be aware that /etc/init.d/functions.sh is still required by a lot of
things (gcc-config, python-updater, perl-cleaner, stuff like
that).They are trying to move that file to a more reasonable location;
I expect it to be done in five or six years.

Regards.

On Fri, Oct 17, 2014 at 10:00 AM, walt w41...@gmail.com wrote:
 On 10/16/2014 04:34 PM, Canek Peláez Valdés wrote:
 At
 some point NM had integration with the OpenRC network configuration,
 and (AFAIR) sometimes it made a mess inside /etc/conf.d. I don't know
 if such integration exists anymore; nowadays I don't even have
 /etc/{conf,init}.d, and everything works so much better.

 Bingo.  I renamed conf.d and init.d and now NM works perfectly during
 bootup.  Now that you mention it, journalctl did print messages about
 /etc/init.d  and I thought it was a bit strange.

 Thanks Canek and Tom for the excellent help.






-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México



Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-17 Thread Rich Freeman
On Fri, Oct 17, 2014 at 11:18 AM, Canek Peláez Valdés can...@gmail.com wrote:
 Be aware that /etc/init.d/functions.sh is still required by a lot of
 things (gcc-config, python-updater, perl-cleaner, stuff like
 that).They are trying to move that file to a more reasonable location;
 I expect it to be done in five or six years.

FYI - patches are welcome on that.  I suspect that at some time we'll
start pushing them through if maintainers drag their feet.  This
should be a pretty easy/safe change, but obviously we want to be
careful since it seems to be fairly important packages that abuse this
file.

Once this is done users should be able to remove openrc safely if they
aren't using it.  At that point we might take up whether it makes
sense to just make the init system like the
bootloader/syslog/cron/kernel/etc in the handbook and have the user
choose which one they want.

--
Rich



Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-17 Thread Canek Peláez Valdés
On Fri, Oct 17, 2014 at 12:14 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Oct 17, 2014 at 11:18 AM, Canek Peláez Valdés can...@gmail.com 
 wrote:
 Be aware that /etc/init.d/functions.sh is still required by a lot of
 things (gcc-config, python-updater, perl-cleaner, stuff like
 that).They are trying to move that file to a more reasonable location;
 I expect it to be done in five or six years.

 FYI - patches are welcome on that.  I suspect that at some time we'll
 start pushing them through if maintainers drag their feet.  This
 should be a pretty easy/safe change, but obviously we want to be
 careful since it seems to be fairly important packages that abuse this
 file.

There is a tracker bug for the packages still sourcing
/etc/init.d/functions.sh, instead of /lib/gentoo/functions.sh:

https://bugs.gentoo.org/show_bug.cgi?id=504116

My comment was tongue-in-cheek, although the change has taken years already.

 Once this is done users should be able to remove openrc safely if they
 aren't using it.  At that point we might take up whether it makes
 sense to just make the init system like the
 bootloader/syslog/cron/kernel/etc in the handbook and have the user
 choose which one they want.

Looking forward to that.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México



[gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-16 Thread walt
On 10/15/2014 08:23 PM, Tom H wrote:
 On Mon, Oct 13, 2014 at 7:39 PM, walt w41...@gmail.com wrote:

 I just switched my home LAN from wired to all wifi and I'm having trouble
 with NetworkManager at boot time.

 I have systemd start NetworkManager at boot because I need the internet
 for ntpdate and to start the nfs server for the LAN. Before I switched
 to all-wireless this method worked perfectly, but no longer.

 After bootup I see that NetworkManager started wpa_supplicant in the
 background, but apparently does *not* run dhcpcd. (The wlan0 is up
 but it has no IP address and the routing table is empty.)

 As an alternative to NetworkManager I can have systemd start dhcpcd
 at boot, which almost (but not quite) works well enough. This
 causes a race condition because wlan0 takes several seconds to come
 up properly and by then both ntpdate and nfs-server have already
 run and failed.

 So, I asked myself, why not have systemd start dhcpcd at boot in
 addition to NetworkManager?

 The reason that fails is that they both start wpa_supplicant in
 the background and the two instances interfere with each other.

 Anyone see a way around this catch22?
 
 Do you have All users may connect unticked in the NM applet or
 permissions=user:walt:; in the NM connection's config?

After studying the logs I'm beginning to think that NM is actually
trying to start wlan0 at boot time but failing with this message:
'no secrets', which I assume means no password, maybe?

Yes, I do have the all-users box ticked.  Question:  I've set up the
wlan0 connection (as root) several times using nmtui, including the
SSID password, yet each time I start nmtui the password field is blank
again.  Is this normal behavior?  How can I tell if the password is
actually being stored somewhere?

Thanks.






Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-16 Thread Canek Peláez Valdés
On Thu, Oct 16, 2014 at 3:53 PM, walt w41...@gmail.com wrote:
 On 10/15/2014 08:23 PM, Tom H wrote:
 On Mon, Oct 13, 2014 at 7:39 PM, walt w41...@gmail.com wrote:

 I just switched my home LAN from wired to all wifi and I'm having trouble
 with NetworkManager at boot time.

 I have systemd start NetworkManager at boot because I need the internet
 for ntpdate and to start the nfs server for the LAN. Before I switched
 to all-wireless this method worked perfectly, but no longer.

 After bootup I see that NetworkManager started wpa_supplicant in the
 background, but apparently does *not* run dhcpcd. (The wlan0 is up
 but it has no IP address and the routing table is empty.)

 As an alternative to NetworkManager I can have systemd start dhcpcd
 at boot, which almost (but not quite) works well enough. This
 causes a race condition because wlan0 takes several seconds to come
 up properly and by then both ntpdate and nfs-server have already
 run and failed.

 So, I asked myself, why not have systemd start dhcpcd at boot in
 addition to NetworkManager?

 The reason that fails is that they both start wpa_supplicant in
 the background and the two instances interfere with each other.

 Anyone see a way around this catch22?

 Do you have All users may connect unticked in the NM applet or
 permissions=user:walt:; in the NM connection's config?

 After studying the logs I'm beginning to think that NM is actually
 trying to start wlan0 at boot time but failing with this message:
 'no secrets', which I assume means no password, maybe?

 Yes, I do have the all-users box ticked.  Question:  I've set up the
 wlan0 connection (as root) several times using nmtui, including the
 SSID password, yet each time I start nmtui the password field is blank
 again.  Is this normal behavior?  How can I tell if the password is
 actually being stored somewhere?

As I said some messages ago, check:

/etc/NetworkManager/system-connections

In that directory should be all the system-wide network
configurations. Also, check

/etc/NetworkManager/NetworkManager.conf

and make sure you have plugins=keyfile in the [main] section. At
some point NM had integration with the OpenRC network configuration,
and (AFAIR) sometimes it made a mess inside /etc/conf.d. I don't know
if such integration exists anymore; nowadays I don't even have
/etc/{conf,init}.d, and everything works so much better.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México



Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-16 Thread Tom H
On Thu, Oct 16, 2014 at 4:53 PM, walt w41...@gmail.com wrote:
 On 10/15/2014 08:23 PM, Tom H wrote:
 On Mon, Oct 13, 2014 at 7:39 PM, walt w41...@gmail.com wrote:

 I just switched my home LAN from wired to all wifi and I'm having trouble
 with NetworkManager at boot time.

 I have systemd start NetworkManager at boot because I need the internet
 for ntpdate and to start the nfs server for the LAN. Before I switched
 to all-wireless this method worked perfectly, but no longer.

 After bootup I see that NetworkManager started wpa_supplicant in the
 background, but apparently does *not* run dhcpcd. (The wlan0 is up
 but it has no IP address and the routing table is empty.)

 As an alternative to NetworkManager I can have systemd start dhcpcd
 at boot, which almost (but not quite) works well enough. This
 causes a race condition because wlan0 takes several seconds to come
 up properly and by then both ntpdate and nfs-server have already
 run and failed.

 So, I asked myself, why not have systemd start dhcpcd at boot in
 addition to NetworkManager?

 The reason that fails is that they both start wpa_supplicant in
 the background and the two instances interfere with each other.

 Anyone see a way around this catch22?

 Do you have All users may connect unticked in the NM applet or
 permissions=user:walt:; in the NM connection's config?

 After studying the logs I'm beginning to think that NM is actually
 trying to start wlan0 at boot time but failing with this message:
 'no secrets', which I assume means no password, maybe?

 Yes, I do have the all-users box ticked. Question: I've set up the
 wlan0 connection (as root) several times using nmtui, including the
 SSID password, yet each time I start nmtui the password field is blank
 again. Is this normal behavior? How can I tell if the password is
 actually being stored somewhere?

I've never used nmtui (I didn't even know about it).

This the config that I use when i visit my parents (I use a static
address at home so this corresponds to your use-case). It has to be in
0600 mode for NM to use it.

# cat /etc/NetworkManager/system-connections/mumdad
[connection]
id=mumdad
uuid=da59ada3-1349-49fe-b63b-bc68f67b6f89
type=802-11-wireless

[802-11-wireless]
ssid=number96
mode=infrastructure
security=802-11-wireless-security

[802-11-wireless-security]
key-mgmt=wpa-psk
psk=x

[ipv4]
method=auto
dns=8.8.8.8;8.8.4.4;

[ipv6]
method=link-local

You have to have plugins=keyfile in the [main] section of
/etc/NetworkManager/NetworkManager.conf for the above to work.



Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-15 Thread Jc García
2014-10-14 16:54 GMT-06:00 Canek Peláez Valdés can...@gmail.com:
 On Tue, Oct 14, 2014 at 5:48 PM, walt w41...@gmail.com wrote:
 [ snip ]
 Lots of great information, thanks.  What I learned while following up
 on your hints is that the NM behavior I thought was a bug is merely
 a feature ;)

 After boot, but before startx, wlan0 exists but is not properly set
 up.  After X is running I can use the nm-applet to click on the name
 of my wireless network and *then* NM runs dhcpcd to configure wlan0
 and set up the routing table.  It works, but I need to do that manually
 after every boot, not really optimal for my purpose.

I had this problem, but, with a Ethernet connection, I wanted NM to
connect it via dhcp at boot, but didn't happen, and the same as you,
once logged-in just 2 clicks and the connection worked, after digging
a little the configs, I found, somehow this line got into my
/etc/NetworkManager/NetworkManager.conf
no-auto-default=p2p1
I removed that and now It works as it should, maybe something like
this is your problem.

 I've seen this behavior before (that you need to manually enable the
 wireless connection), but never on my machines. On my two wireless
 systems (laptop and desktop), NM enables the connection by default. I
 don't think I did anything special for this to happen, it just does.

 I tried Neil's suggestion to use systemd-networkd and it works perfectly
 for this (desktop) machine.  (BTW enabling systemd-networkd also pulls
 in systemd-timesyncd, which works great, just as you said.)

 Good to know.

 Regards.
 --
 Canek Peláez Valdés
 Profesor de asignatura, Facultad de Ciencias
 Universidad Nacional Autónoma de México




[gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-14 Thread walt
On 10/13/2014 04:56 PM, Canek Peláez Valdés wrote:
 On Mon, Oct 13, 2014 at 6:39 PM, walt w41...@gmail.com wrote:
 I just switched my home LAN from wired to all wifi and I'm having trouble
 with NetworkManager at boot time.

 I have systemd start NetworkManager at boot because I need the internet
 for ntpdate and to start the nfs server for the LAN.  Before I switched
 to all-wireless this method worked perfectly, but no longer.

 After bootup I see that NetworkManager started wpa_supplicant in the
 background, but apparently does *not* run dhcpcd.  (The wlan0 is up
 but it has no IP address and the routing table is empty.)
 
 Do you have a system-wide connection for the wireless network? They
 live in /etc/NetworkManager/system-connections. Also, what does nmcli
 -p general says? In my case is:
 
 centurion ~ # nmcli -p general
 =
 NetworkManager status
 =
 STATE  CONNECTIVITY  WIFI-HW  WIFI WWAN-HW  WWAN
 -
 connected  full  enabled  enabled  enabled  enabled
 
 As an alternative to NetworkManager I can have systemd start dhcpcd
 at boot, which almost (but not quite) works well enough.  This
 causes a race condition because wlan0 takes several seconds to come
 up properly and by then both ntpdate and nfs-server have already
 run and failed.

 So, I asked myself, why not have systemd start dhcpcd at boot in
 addition to NetworkManager?
 
 NetworkManager starts wpa_supplicant, but it does *NOT* use
 wpa_supplicant.conf. If you do
 
 systemctl status wpa_supplicant.service
 
 you will see that wpa_supplicant runs with the -u flag; that enables
 the DBus control interface, and it's through this that NetworkManager
 controls wpa_supplicant. If you do not  have system-wide connections,
 NM will ask wpa_supplicant to *not* enable any connection. NM calls
 the shots in this case.
 
 The reason that fails is that they both start wpa_supplicant in
 the background and the two instances interfere with each other.

 Anyone see a way around this catch22?
 
 If I'm not mistaken, you need a system-wide NM connection enabled. You
 can use nm-connection-editor (included with nm-applet), or nmtui
 (ncurses interface since 0.9.10.0).
 
 Also, and orthogonal to almost all of this; I switched from ntp to
 systemd-timesyncd, and it works *great*, specially in my laptop. With
 my laptop, changing networks all the time, ntpd never quite worked.

Lots of great information, thanks.  What I learned while following up
on your hints is that the NM behavior I thought was a bug is merely
a feature ;)

After boot, but before startx, wlan0 exists but is not properly set
up.  After X is running I can use the nm-applet to click on the name
of my wireless network and *then* NM runs dhcpcd to configure wlan0
and set up the routing table.  It works, but I need to do that manually
after every boot, not really optimal for my purpose.

I tried Neil's suggestion to use systemd-networkd and it works perfectly
for this (desktop) machine.  (BTW enabling systemd-networkd also pulls
in systemd-timesyncd, which works great, just as you said.)

Great advice Canek and Neil, and very much appreciated.




Re: [gentoo-user] Re: [systemd] Is this a NetworkManager bug?

2014-10-14 Thread Canek Peláez Valdés
On Tue, Oct 14, 2014 at 5:48 PM, walt w41...@gmail.com wrote:
[ snip ]
 Lots of great information, thanks.  What I learned while following up
 on your hints is that the NM behavior I thought was a bug is merely
 a feature ;)

 After boot, but before startx, wlan0 exists but is not properly set
 up.  After X is running I can use the nm-applet to click on the name
 of my wireless network and *then* NM runs dhcpcd to configure wlan0
 and set up the routing table.  It works, but I need to do that manually
 after every boot, not really optimal for my purpose.

I've seen this behavior before (that you need to manually enable the
wireless connection), but never on my machines. On my two wireless
systems (laptop and desktop), NM enables the connection by default. I
don't think I did anything special for this to happen, it just does.

 I tried Neil's suggestion to use systemd-networkd and it works perfectly
 for this (desktop) machine.  (BTW enabling systemd-networkd also pulls
 in systemd-timesyncd, which works great, just as you said.)

Good to know.

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México



[gentoo-user] Re: Systemd and PyTimeChart

2014-09-24 Thread James
Mark David Dumlao madumlao at gmail.com writes:

  PyTimeChart is another wonderful tool that complements
  Ftrace/trace-cmd/KernelShark. 

  PyTimeChart is also wonderful in that it provides a graphical way to
  spot problems quickly. Most major (linux) distros have both PyTimeChart
  and Ftrace/trace-cmd/KernelShark. Together folks use PyTimeChart to
  monitor and identify low-level or low-level-application-interaction
  problems, and then use Ftrace/trace-cmd/KernelShark for fine grain
  filtering, collection and analysis of those 
  low-level-application-interaction issues.

 Im just going to go out on a limb here, but is it possible that you 
 dont understand what either systemd or pytimechart do?

Huh? Extolling validation tools indicates a lack of understanding?
Perhaps you ought to repond to what's written, rather than interpreting
the tea leaves? The issue is other distros have tools to evaluate
kernel performance, yet there seems to be a  lack of those tools in gentoo;
why?

 both your description of pytimechart and the rejection of intel's 
 claim... seem to point to a lack of understanding.

False. You are reading something else into the response.

 Intel isnt saying systemd is amazing only that it doesnt operate by  
 spawning many short-lived processes in the same way as upstart or
 sysvinit (which start shell scripts which start programs). systemd 
 starts the services directly based on the contents of the units.

You are making way to many assumptions about what I actually wrote. I did
not even distinguish between the types of events you are using to
to discredit a posting that does not require discredit. It's merely
imformative an yet another suggestion to get a tool into portage
where folks that use gentoo, can tremendously benefit. Todays
kernel development tools are tomorrows kernel/system debug tools, often
imho.


 pytimechart cannot be used to monitor events - its just a visualizer  
 for existing trace mechanisms.

Here you go again, reading more into what was posted than what is acutally
said. Furthermore, if you do not like what others write, you twist your
interpretation around by denegrading others. Why? I specifically did
not use the term real time so that it could be batch monitoring.  I did
not drill down to that level of differentialtions. Most monitoring is
not real time. RT monitoring is a special case of monitoring. If a
parent gets up every so often to look at the child processes and then
relaxes for a while, sure it's not real time (constant) with microsecond
delays, but it is still monitoring. In fact if you want to break it down
(split hairs) humans are not capable of real-time monitoring, as our
naturaly delay in everything we do is mostly 200-500 ms, which definately
does not count as RT.

I've previously used a very loose application of monitoring; perhaps
you should be a bit more charitable (non-assuming) in your responses
and stay focused on the desired focus of the original poster's thread;
or just not respond at all? Maybe start your on thread on low-level
kernel tools for (gentoo) folks to use to evaluation kernel tweaks?


  I have not opened a bug requesting PyTimeChart.
 perhaps you should.

Perhaps someone capable should work on the Ftrace/trace-cmd/kerneshark
bug first, before the community asks for ancillary tools?

Often, I write generalize viewpoints, soliciting folks to respond
based on there leanings, prejudices or some other form of inate-bias-tilting
in their response. What I wrote is actually complementary to Intel and
systemd. Go read it again; and stop jumping all over what I write. It would
be better for some low-level tools to be put into portage, so
folks can convince themselves on many blind issues about *their kernels*.

What I do not understand is why the resistance to these low-level tools?
If I had the skills to put Ftrace/trace-cmd/kernelshark into an ebuild
I would have done that already.  If you follow this list there are many
issues that Ftrace/trace-cmd/kernelshark and pytimechart would be useful for
kernel users to see what is going on with *their kernels*.

This ought to get you started:

http://zougloub.eu/overlay/sys-kernel/trace-cmd/

hth,
James




Re: [gentoo-user] Re: Systemd upower

2014-06-06 Thread Rich Freeman
On Fri, Jun 6, 2014 at 1:46 AM, Mick michaelkintz...@gmail.com wrote:
 On Friday 06 Jun 2014 00:15:02 Peter Humphrey wrote:

 I bet you have quite a lot of systemd components lurking in the background
 though, ready to take over the world the next time you aren't looking :-)

 Ha! I can already see this one:

   338 ?Ss 0:00 /lib/systemd/systemd-udevd --daemon

 I have set USE=-systemd, but if/when Gentoo migrates to systemd as the
 default startup I will probably have to remove it and then learn how to use
 systemd.

That would be udev.  It has been around long before systemd, and you
must have missed the huge flamewar when they renamed it to
systemd-udevd.  Maybe we'll see java renamed to
java-by-oracle-with-ask-toolbar next.  :)

If you ever migrate to systemd you really just need to set USE=systemd
and install systemd.  Portage will swap out your udev in the process,
though nothing there will really change as systemd and udev install
the same udev components.  There is a guide for installing systemd
that you should follow which gets into all the details.

Rich



Re: [gentoo-user] Re: Systemd upower

2014-06-06 Thread Mick
On Friday 06 Jun 2014 12:18:09 Rich Freeman wrote:

 That would be udev.  It has been around long before systemd, and you
 must have missed the huge flamewar when they renamed it to
 systemd-udevd.  Maybe we'll see java renamed to
 java-by-oracle-with-ask-toolbar next.  :)

TBH I wouldn't be surprised.  At least java offers a choice of avoiding it.  
;-)


 If you ever migrate to systemd you really just need to set USE=systemd
 and install systemd.  Portage will swap out your udev in the process,
 though nothing there will really change as systemd and udev install
 the same udev components.  There is a guide for installing systemd
 that you should follow which gets into all the details.

I didn't miss the flamewar.  Actually I recall joining in the fun and posting 
the odd message about systemd.  I know that I could use eudev or systemd-udev 
(or even mdev as kindly shared in this list by Walter).

I am mostly happy with openrc and therefore have no reason to move to the 
systemd monoculture, unless gentoo falls in line with Debian et al. and leaves 
me no choice.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: Systemd upower

2014-06-06 Thread Rich Freeman
On Fri, Jun 6, 2014 at 3:13 PM, Mick michaelkintz...@gmail.com wrote:

 I am mostly happy with openrc and therefore have no reason to move to the
 systemd monoculture, unless gentoo falls in line with Debian et al. and leaves
 me no choice.


I don't really see that happening anytime soon - it will be more
likely to become an issue for the more complex desktop environments
(Gnome is already going this way - KDE may very well go this way
later).  Historically they're the first packages to require things
like HAL, udev, dbus, pulseaudio, etc (and on Gentoo the maintainers
tend to do a good job of minimizing dependencies).

I think many will switch to systemd anyway, simply because that is the
way the wind is blowing and it does have some benefits depending on
your situation (but so do a number of other configurations).  I tend
to use it by default on new installs, and anytime I find myself
tweaking my monit rules I keep bumping up migrating entirely to
systemd a little higher on my to-do list.

Rich



Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Samuli Suominen

On 05/06/14 08:23, Mick wrote:
 On Wednesday 04 Jun 2014 23:27:05 Samuli Suominen wrote:
 On 05/06/14 01:14, »Q« wrote:
 On Tue, 03 Jun 2014 22:06:07 +0200

 Alan McKinnon alan.mckin...@gmail.com wrote:
 The good news is that the version of upower prior to this decision
 still works fine and likely will for ages to come. That code has been
 bundled into a new package upower-pm-utils.

 Anyone that feels like doing it can now step up to the plate and
 continue the work upower was doing earlier.
 I don't understand the development status of upower-pm-utils.  Is there
 someone either upstream or with Gentoo committed to maintaining it?
 No, nobody is actively working on it, it's the abandoned upstream git
 branch that used to be master before 0.99.0's release:

 Current sys-power/upower-pm-utils is same as latest code from
 http://cgit.freedesktop.org/upower/log/?h=0.9
 And last commit is 2013

 I might backport some fixes from git master over at some point later,
 but I won't do any promises

 Or
 is it a git branch created just to meet the current needs of
 non-systemd Gentoo users?
 It's to be considered as a temporary solution for applications that need
 the Hibernate and Suspend functionality
 from UPower for non-systemd users, applications like
 mate-session-manager, lxsession, uevt, and so forth

 Migrating to =sys-power/upower-0.99.0 is the recommended path to take
 if at all possible. It's possible for eg.
 Xfce users, because Xfce in ~arch integrated sys-power/pm-utils support
 directly for Hibernate and Suspend
 Also, GNOME 3.12 requires 0.99.0
 Hi Samuli,

 Are you saying that as things stand it is a matter of time before a gentoo 
 user will have to switch from openrc to systemd, if they want/need to 
 continue 
 using sleep and hibernate?


For those tasks you mentioned...

...if other desktops don't migrate like Xfce, then something like:

Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
support in session and power managers),
OR c) switching to command line pm-* utilities directly from pm-utils

...might be inevitable

And if Linux kernel does changes that break pm-utils, which haven't had
a single commit since 2010
in upstream repository:

Switching to a) systemd, OR, b) wait, no other possibilities

Yes, that's really how poor the situation is, and don't shoot me, I'm
only the messenger :-)

- Samuli



Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Mick
On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote:
 On 05/06/14 08:23, Mick wrote:

  Are you saying that as things stand it is a matter of time before a
  gentoo user will have to switch from openrc to systemd, if they
  want/need to continue using sleep and hibernate?
 
 For those tasks you mentioned...
 
 ...if other desktops don't migrate like Xfce, then something like:
 
 Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
 support in session and power managers),
 OR c) switching to command line pm-* utilities directly from pm-utils
 
 ...might be inevitable
 
 And if Linux kernel does changes that break pm-utils, which haven't had
 a single commit since 2010
 in upstream repository:
 
 Switching to a) systemd, OR, b) wait, no other possibilities
 
 Yes, that's really how poor the situation is, and don't shoot me, I'm
 only the messenger :-)

Thanks Samuli, I don't shoot people, especially when they try to help me!  :-)

I use enlightenment on most machines and KDE on a couple of desktops, so I 
guess these would be the only two desktops that may be an issue for me.  
However, I had forgotten about the pm-* commands.  I just tried:

pm-is-supported --suspend-hybrid

and didn't get anything ... what am I missing?

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Samuli Suominen

On 05/06/14 12:03, Mick wrote:
 On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote:
 On 05/06/14 08:23, Mick wrote:
 Are you saying that as things stand it is a matter of time before a
 gentoo user will have to switch from openrc to systemd, if they
 want/need to continue using sleep and hibernate?
 For those tasks you mentioned...

 ...if other desktops don't migrate like Xfce, then something like:

 Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
 support in session and power managers),
 OR c) switching to command line pm-* utilities directly from pm-utils

 ...might be inevitable

 And if Linux kernel does changes that break pm-utils, which haven't had
 a single commit since 2010
 in upstream repository:

 Switching to a) systemd, OR, b) wait, no other possibilities

 Yes, that's really how poor the situation is, and don't shoot me, I'm
 only the messenger :-)
 Thanks Samuli, I don't shoot people, especially when they try to help me!  :-)

 I use enlightenment on most machines and KDE on a couple of desktops, so I 
 guess these would be the only two desktops that may be an issue for me.  
 However, I had forgotten about the pm-* commands.  I just tried:

 pm-is-supported --suspend-hybrid

 and didn't get anything ... what am I missing?


null ssuominen # pm-is-supported --suspend
null ssuominen # echo $?
0
null ssuominen # pm-is-supported --hibernate
null ssuominen # echo $?
0
null ssuominen # pm-is-supported --suspend-hybrid
null ssuominen # echo $?
0

see `man pm-is-supported`, this particular command is silent, and only
returns
return codes, and 0 means it succeeded

- Samuli



Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Mick
On Thursday 05 Jun 2014 10:08:53 Samuli Suominen wrote:
 On 05/06/14 12:03, Mick wrote:
  On Thursday 05 Jun 2014 08:25:30 Samuli Suominen wrote:
  On 05/06/14 08:23, Mick wrote:
  Are you saying that as things stand it is a matter of time before a
  gentoo user will have to switch from openrc to systemd, if they
  want/need to continue using sleep and hibernate?
  
  For those tasks you mentioned...
  
  ...if other desktops don't migrate like Xfce, then something like:
  
  Switching to a) systemd, OR b) switching to Xfce (direct pm-utils
  support in session and power managers),
  OR c) switching to command line pm-* utilities directly from pm-utils
  
  ...might be inevitable
  
  And if Linux kernel does changes that break pm-utils, which haven't had
  a single commit since 2010
  in upstream repository:
  
  Switching to a) systemd, OR, b) wait, no other possibilities
  
  Yes, that's really how poor the situation is, and don't shoot me, I'm
  only the messenger :-)
  
  Thanks Samuli, I don't shoot people, especially when they try to help me!
   :-)
  
  I use enlightenment on most machines and KDE on a couple of desktops, so
  I guess these would be the only two desktops that may be an issue for
  me. However, I had forgotten about the pm-* commands.  I just tried:
  
  pm-is-supported --suspend-hybrid
  
  and didn't get anything ... what am I missing?
 
 null ssuominen # pm-is-supported --suspend
 null ssuominen # echo $?
 0
 null ssuominen # pm-is-supported --hibernate
 null ssuominen # echo $?
 0
 null ssuominen # pm-is-supported --suspend-hybrid
 null ssuominen # echo $?
 0
 
 see `man pm-is-supported`, this particular command is silent, and only
 returns
 return codes, and 0 means it succeeded

Yes, I had seen the man page and was expecting a return code, your echo string 
worked.  Thank you.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Tom Wijsman
On Thu, 5 Jun 2014 06:23:38 +0100
Mick michaelkintz...@gmail.com wrote:

 Are you saying that as things stand it is a matter of time before a
 gentoo user will have to switch from openrc to systemd, if they
 want/need to continue using sleep and hibernate?

For them to have support for sleep and hibernate, someone needs to
develop / maintain it in order to adapt to kernel API changes; as long
as the only one doing this is systemd, you'll work towards only it
being supported there in the future.

In other words, if people want to see this be continued in other places
than systemd; they need to either be verbal enough to convince someone
to do the work, or do the work involved themselves.

There are easily at least 100 users interested in further support.

So, if some developers and/or users can find the time, will and
interest to do so the cost to implement it; it will certainly be worth
to do for the benefit of making a ton of users happy in the future.

TL;DR: A simple equation: If someone stops development upstream,
someone else needs to start developing to keep that work{,ing}.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature


Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Samuli Suominen

On 05/06/14 13:47, Tom Wijsman wrote:
 On Thu, 5 Jun 2014 06:23:38 +0100
 Mick michaelkintz...@gmail.com wrote:

 Are you saying that as things stand it is a matter of time before a
 gentoo user will have to switch from openrc to systemd, if they
 want/need to continue using sleep and hibernate?
 For them to have support for sleep and hibernate, someone needs to
 develop / maintain it in order to adapt to kernel API changes; as long
 as the only one doing this is systemd, you'll work towards only it
 being supported there in the future.

Correct, and to name an example, pm-utils is still using the old
wireless stack and
'wireless-utils' instead of 'iw'
As in, pm-utils is using kernel options that are marked as DEPRECATED in the
menuconfig, and DEPRECATED means they are going away at some point
So it won't be long the package is broken for every machine that has
wireless
card
I'm sure there are multiple other examples available, but this one pops
up to
mind immediately




Re: [gentoo-user] Re: Systemd upower

2014-06-05 Thread Mick
On Thursday 05 Jun 2014 12:26:09 Samuli Suominen wrote:
 On 05/06/14 13:47, Tom Wijsman wrote:
  On Thu, 5 Jun 2014 06:23:38 +0100
  
  Mick michaelkintz...@gmail.com wrote:
  Are you saying that as things stand it is a matter of time before a
  gentoo user will have to switch from openrc to systemd, if they
  want/need to continue using sleep and hibernate?
  
  For them to have support for sleep and hibernate, someone needs to
  develop / maintain it in order to adapt to kernel API changes; as long
  as the only one doing this is systemd, you'll work towards only it
  being supported there in the future.
 
 Correct, and to name an example, pm-utils is still using the old
 wireless stack and
 'wireless-utils' instead of 'iw'
 As in, pm-utils is using kernel options that are marked as DEPRECATED in
 the menuconfig, and DEPRECATED means they are going away at some point So
 it won't be long the package is broken for every machine that has wireless
 card
 I'm sure there are multiple other examples available, but this one pops
 up to
 mind immediately

Fair enough, I've keyworded sys-power/upower-0.99.0 for now on one machine and 
it seems to work fine, without imposing systemd at the moment.  :-)

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.


  1   2   3   >