Re: [gentoo-dev] BOINC needs maintainer
Am Mittwoch, 17. Februar 2016, 15:20:56 CET schrieb Justin Lecher (jlec): > currently BOINC supposed to be maintained by the science team, but we > are not really carrying about it. Is there anyone around whole likes to > take this over? I have a sci-misc/boinc-7.6 ebuild in my overlay "seden" (via layman). Feel free to use it. Works fine, at least on my system. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] BOINC needs maintainer
On Do, 2016-02-18 at 09:29 +0100, Sven Eden wrote: > Am Mittwoch, 17. Februar 2016, 15:20:56 CET schrieb Justin Lecher > (jlec): > > currently BOINC supposed to be maintained by the science team, but > > we > > are not really carrying about it. Is there anyone around whole > > likes to > > take this over? > > I have a sci-misc/boinc-7.6 ebuild in my overlay "seden" (via > layman). > > Feel free to use it. Works fine, at least on my system. > > Cheers > > Sven Sven, would you be willing to maintain it as a proxy maintainer? David
[gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
Rich Freeman posted on Wed, 17 Feb 2016 08:46:34 -0500 as excerpted: > On Tue, Feb 16, 2016 at 9:20 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> >> Initial shutdown is via two targets (as opposed to specific services), > > Since not everybody in this thread may be familiar with systemd, I'll > just add a quick definition. Thanks for this followup. =:^) > When systemd says "target" - think "virtual service." The equivalent in > openrc would be an init.d script that has dependencies but which doesn't > actually launch any processes. > > Targets also take the place of runlevels in systemd. The systemd official comparison of targets is to runlevels, except much more flexible as it's actually possible for multiple targets to be in the process of being reached at once, not services or "virtual services", and indeed, my immediate internal reaction at seeing the "virtual services" definition was "no, they're like runlevels", before I even reached the next paragraph, where you add that. Basically, I'd put the runlevel comparison first and primary, as systemd documentation does, tho now that I've seen the usage, "virtual services" /does/ add some richness to the definition, helping to accent the fact that multiple targets can be processed at once. So it's a difference in emphasis, while agreeing in general. > Just as with runlevels in openrc they are used to synchronize milestones > during bootup, but the design is much more generic. Presumably openrc > hard-codes runlevels like sysinit, boot, and default. In systemd I > believe it just looks at the config file and directly launches the > desired target, and then the dependency chain for that pulls in all the > targets that precede it. Targets can depend on other targets, and > services can depend on previous targets. > > The other dimension is that unit files describe what target they are > typically associated with if it isn't the default. So, you don't run > into the sorts of situations you have with openrc that if you want to > enable mdraid support you need to remember to add it to the boot > runlevel. That might be a relatively-easy thing to add support for in > openrc actually. > > Hopefully that makes Dunan's summary easier to read for anybody who > doesn't speak systemdese. Again, thanks. =:^) > Another bit of background that might be helpful is that systemd also > manages mounts directly. After actually looking into how systemd processes mounts as I wrote the earlier post, I believe it's safe to say this is a much bigger difference than it might seem on the surface, and it was certainly one of the biggest challenges I faced in attempting to explain systemd's mount processing in sysvinit/openrc terms. Even with a reasonable level of personal admin-level systemd familiarity, I kept expecting and looking for systemd to hand off the unmounting to a service, which I expected would simply call one of the separate from systemd itself executables (for example journald, networkd, etc, I was expecting a mount helper or mountd as well), only after seeing the shutdown flowchart and looking into each individual component, I still couldn't find it, which is why I ultimately had to go diving directly into the systemd sources themselves, which is when I found what I was looking for! =:^) But in hindsight, while there are various non-systemd-binary executables that ship with systemd, systemd itself directly processes all unit files, including mount units, so I should have known that it'd handle umounting directly. But I simply didn't make that connection, until it became obvious after the fact, and indeed, it didn't actually solidify in my mind until just now as I wrote about it, tho certainly, after writing the earlier post, all the pieces were there to be assembled, and this simply triggered it. =:^) > It parses fstab and creates a network of mount > units with appropriate dependencies. Whether you unmount /var/tmp using > "umount /var/tmp" or "systemctl stop var-tmp.mount" systemd updates the > status of the var-tmp.mount unit to a stopped status. I believe if you > add a noauto line to fstab it will create a mount unit automatically and > not start it, and if you made it mount on boot I think it would actually > be mounted as soon as you save the file in your editor (systemd can > monitor config files for changes - all of this is governed by > scripts/software called generators). I'm not sure of the last -- systemd does let you mount and umount at will [1], and there are enough cases where an admin might setup the fstab entry before he's actually prepared for the mount to go ahead, that I don't believe it would be wise for systemd to try to jump the gun. OTOH, it's possible to setup corresponding *.automount units as well, with the purpose there being to trigger mounting (using the kernel's automount services, which of course would have to be enabled -- they aren't here) as soon as something tries to stat/open
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
On Wed, 17 Feb 2016 22:11:42 -0500 Richard Yao wrote: > dracut does not assist those who do not want generic kernel > configurations. Unfortunately, the handbook does not do a good job in > saying that the initramfs generation and generic kernel configurations > are optional. Does Dracut's hostonly mode not count? I think this is even the default as I don't specify it here and I had to temporarily force non-hostonly mode on Fedora in order to fix a broken system. I certainly keep my Gentoo kernel configuration to a minimum. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpHzJLhLKgbr.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] BOINC needs maintainer
Am Donnerstag, 18. Februar 2016, 09:37:28 CET schrieb David Seifert: > On Do, 2016-02-18 at 09:29 +0100, Sven Eden wrote: > > Am Mittwoch, 17. Februar 2016, 15:20:56 CET schrieb Justin Lecher > > > > (jlec): > > > currently BOINC supposed to be maintained by the science team, but > > > we > > > are not really carrying about it. Is there anyone around whole > > > likes to > > > take this over? > > > > I have a sci-misc/boinc-7.6 ebuild in my overlay "seden" (via > > layman). > > > > Feel free to use it. Works fine, at least on my system. > > > > Sven, would you be willing to maintain it as a proxy maintainer? > Sure. I am using it several times a week, and I am watching their repo, so I normally learn about new versions rather fast. And since the client_release tags now sport 7.6 subversions, I just pushed boinc-7.6.25.ebuild. Cheers Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
On Wed, Feb 17, 2016 at 10:02 PM, Richard Yao wrote: > > Dracut handling it well is not up for dispute. When I checked last year, > dracut simply did not tell systemd to use this functionality because it > was unnecessary functionality that only served to slowed down the > shutdown process. It only enables it when a driver indicates an actual > need, which is the way that it should be. You might want to check again. As far as I can tell systemd has been pivoting back to dracut for a while now by default. -- Rich
[gentoo-dev] Last rites: media-video/stk11xx
# Michael Palimaka (18 Feb 2016) # Fails to build with recent kernels. Dead upstream. # Masked for removal in 30 days. Bug 488128. media-video/stk11xx
[gentoo-dev] Last rites: media-tv/wis-go7007
# Michael Palimaka (18 Feb 2016) # Fails to build with recent kernels. Dead upstream. # Use kernel driver VIDEO_GO7007 instead. # Masked for removal in 30 days. Bug 482120.
[gentoo-dev] Last rites: gnome-extra/connman-gnome
# Michael Palimaka (18 Feb 2016) # Fails to build. Dead upstream. Use net-misc/connman-gtk instead. # Masked for removal in 30 days. Bug 502552. gnome-extra/connman-gnome
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
On Wed, Feb 17, 2016 at 10:11 PM, Richard Yao wrote: > > dracut does not assist those who do not want generic kernel > configurations. Unfortunately, the handbook does not do a good job in > saying that the initramfs generation and generic kernel configurations > are optional. > No argument that this section of the handbook couldn't be improved. Generic kernel configs are actually not a bad starting point, though the reality is that you don't really need a fancy tool to have them. Just stick some config files on a webpage and tell users to download them to .config and run make oldconfig. Heck, you can just zcat /proc/config.gz from the install CD most likely, though you'll want to edit out the initramfs filename in the config if you do this or it won't build. Dracut works fine with just about any kernel configuration. It doesn't really have anything to do with configuring the kernel. You run it after you've built and installed your kernel. I didn't want to split this reply up too much but I'm not sure what you meant in your other email about it not configuring the bootloader - with grub2 the bootloader generally configures itself. > > There is no default and system boot without an initramfs not only works, > but is advisable for faster boot unless something fancy is being done > that needs it. > Booting without an initramfs is supported on Gentoo as long as you don't have /usr on a separate partition. If you do have /usr on a separate partition this is considered an unsupported configuration (unless you're using some other mechanism to get /usr mounted early in boot). However, even if it is optional I'd still recommend it. I'll grant that it will add a few seconds to the boot process in many cases, but it is far more robust than booting without one. In general the kernel developers have been moving more towards depending more on userspace for initialization where in the past the kernel did more to autodetect and configure userspace. I think there is recognition that putting this functionality in userspace gives everybody more flexibility in initializing the system. One big benefit of using an initramfs is more robust root detection. They typically support labels and uuids for identifying a root filesystem, while the kernel itself only supports device names. Before I was using an initramfs I can't tell you how many times I'd add a hard drive and have the kernel detect them in a different order, causing my boot to break. With just one drive this is of course a lower risk. Of course once you start making your environment more complex (RAID, LUKS, LVM, zfs/btrfs with multiple disks, network filesystems, etc) an initramfs can easily become required. I tend to just use them routinely - it is trivial to do and they rarely cause problems. I'll admit that on a VM with one partition they're probably overkill. I guess one area where they add a bit of complexity is if you're using UEFI without some kind of intermediate bootloader, since a kernel can be directly booted with EFI and using an initramfs in this configuration is a bit of a pain in the rear. It certainly can be done but it becomes a bit of a chicken/egg putting it all together (you want the modules in the initramfs, but the initramfs has to be built before the final kernel itself). > Claiming to pick a default between genkernel and dracut when both are > optional makes no sense, especially since dracut's capabilities > (initramfs generation) are a subset of genkernel's (initramfs generation > and kernel builds). dracut could replace genkernel's initramfs > generation capabilities, but it simply cannot replace genkernel for > building a generic kernel. It was never intended to do that. So, again the page could probably be cleaned up in how it presents all of this. I'll agree that both should stay optional, but I'd suggest listing dracut first for initramfs generation. That is the only sense that I'd make it a "default." > By the way, pver the course of time, there have been things genkernel > did better and things dracut did better. That doesn't surprise me - dracut is newew, and as something new I'm sure there was a point in time where it didn't do everything more established solutions already did. > It is unlikely one will ever be superior to the other. This is pretty speculative, and any opinion I offer is only going to be more speculation. However, I'm not aware of anything a genkernel initramfs does that dracut doesn't already handle. It has the advantage of being a more generic tool, and thus likely to have a broader development community. I guess I'm a fan of cross-distro solutions in general, but it would be fair to say that the fact that something is broadly used doesn't automatically make it better. The reality is that Gentoo's approach to package management is completely different from how almost everybody does things but we wouldn't be here if we didn't like it. > However, some feedback on what genkernel does > p
[gentoo-dev] Last rites: dev-util/vdkbuilder
# Michael Palimaka (18 Feb 2016) # Fails to build. Dead upstream. # Masked for removal in 30 days. Bug 574248. dev-util/vdkbuilder
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
On Thu, Feb 18, 2016 at 3:57 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Wed, 17 Feb 2016 08:46:34 -0500 as excerpted: > >> When systemd says "target" - think "virtual service." The equivalent in >> openrc would be an init.d script that has dependencies but which doesn't >> actually launch any processes. >> >> Targets also take the place of runlevels in systemd. > > The systemd official comparison of targets is to runlevels, except much > more flexible as it's actually possible for multiple targets to be in the > process of being reached at once, not services or "virtual services", and > indeed, my immediate internal reaction at seeing the "virtual services" > definition was "no, they're like runlevels", before I even reached the > next paragraph, where you add that. > > Basically, I'd put the runlevel comparison first and primary, as systemd > documentation does, tho now that I've seen the usage, "virtual services" > /does/ add some richness to the definition, helping to accent the fact > that multiple targets can be processed at once. So it's a difference in > emphasis, while agreeing in general. So, perhaps this is getting a bit off-topic, and a bit theoretical. I've found that in general you aren't going to be effective with systemd until you grok some of its basic concepts, and this is one of them. And, frankly, I've never found the "target = runlevel" analogy very helpful when it comes to understanding just what systemd is doing. It is true that systemd uses targets to accomplish what other solutions use runlevels for. However, runlevels are used for things that have nothing to do with traditional runlevels. Here are a few cases where the runlevel analogy fails: 1. In most service manager / rc implementations the system is at only one runlevel at any time (of course it might be transitioning between two). In systemd targets can be started independent of the overall "runlevel" and targets that are dependencies of the main runlevel can be reached in parallel at any order semi-independently. 2. Targets are used for many intermediate states that most sane rc implementations would never make a separate runlevel, such as gettys running, local filesystems mounted, remote filesystems mounted, network interfaces exist, network is online, name resolution working, swap running, etc. These really don't work like runlevels, and there is no strict sequential order that these get loaded in. 3. Targets can be used for convenience just as virtual packages are in most distros. For example, I have an nfs-client target (which just runs whatever daemons are needed to mount remote nfs shares). While upstream doesn't do it this way you could define a samba target that starts both nmbd and smbd. I use targets to group services that get launched together by cron jobs, and so on. 4. In the runlevel paradigm you usually think of services running inside a runlevel (perhaps this isn't strictly true, but most people think this way, in part because runlevels don't change much). In systemd this really isn't the case. Services run before targets, or after them. A target won't be considered running if anything it depends on isn't running. 5. I'd have to check, but I wouldn't be surprised if systemd doesn't actually require specifying a target at all. Your default "runlevel" could be apache2.service, which means the system would boot and launch everything necessary to get apache working, and it probably wouldn't even spawn a getty. This is NOT analogous to just putting only apache2 in /etc/runlevels/default, because in that example openrc is running the default runlevel, and it only pulls in apache2. Systemd is purely dependency driven and when you tell it to make graphical.target the default runlevel it is like running emerge kde-meta. If all you wanted was kde-runtime you wouldn't redefine kde-meta to pull in only kde-runtime, you'd just run emerge kde-runtime. Again, I haven't tested this, but I'd be shocked if it didn't work. Of course, specifying a service as a default instead of a target is very limiting, but it would probably work. Heck, you could probably specify a mount as the default and the system would just boot and mount something and sit there. Or you could make it a socket and all it would do is sit and listen for a connection inetd-style. I find it more helpful to think of targets as just units that don't do anything. We don't use them in openrc but I suspect it would work out of the box, and maybe we should even consider doing it in at least some cases. For example, right now /etc/init.d/samba uses some scripting to launch both nmbd/smbd and fancy config file parsing to let the users control which ones launch. You could instead break that into three files - smbd, nmbd, and samba. The first two would launch one daemon each, and the samba init.d script wouldn't actually launch anything, but would just depend on the others. That would be the systemd target ap
[gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
Rich Freeman posted on Thu, 18 Feb 2016 07:22:36 -0500 as excerpted: > 4. In the runlevel paradigm you usually think of services running > inside a runlevel (perhaps this isn't strictly true, but most people > think this way, in part because runlevels don't change much). In > systemd this really isn't the case. Services run before targets, or > after them. A target won't be considered running if anything it depends > on isn't running. Some minor additional notes, with the first one being here. Systemd target units are analogous to edge-triggered interrupts, which they resemble in that they are simply "synchronization points" (the term used in the systemd.target (5) manpage itself). Level-triggered interrupts can be held on or held off (high or low), but edge-triggered a re simply events that occur and then are passed as time moves on. As such, targets can be started, but not normally (while the job queue is idle) stopped, as they de-assert as soon as they are actually reached, tho many of their requirements generally continue to run until stopped by some other event, often conflicts= against some other target or general unit being started, or specific admin systemctl stop. Tho the systemd FAQ suggests this wasn't always so, as it suggests using systemctl list-units --type=target in answer to a question about how to find what "runlevel" you're in. That command seems to return nothing, here, tho, at least while no target is actively starting, so it would seem that answer's a bit dated. It can be noted, however, that certain units, most often specific targets intended to be specifically invokable by users, can be "isolated", as they have the AllowIsolate unit setting. Systemctl isolate will then cause it to be started exclusively, stopping anything that's not a dependency of that unit. The systemctl emergency, rescue, reboot, shutdown, etc, commands, then become effectively shortcuts to the longer systemctl isolate command form. > 5. I'd have to check, but I wouldn't be surprised if systemd doesn't > actually require specifying a target at all. Your default "runlevel" > could be apache2.service, which means the system would boot and launch > everything necessary to get apache working, and it probably wouldn't > even spawn a getty. This is NOT analogous to just putting only apache2 > in /etc/runlevels/default, because in that example openrc is running the > default runlevel, and it only pulls in apache2. Systemd is purely > dependency driven and when you tell it to make graphical.target the > default runlevel it is like running emerge kde-meta. If all you wanted > was kde-runtime you wouldn't redefine kde-meta to pull in only > kde-runtime, you'd just run emerge kde-runtime. Again, I haven't tested > this, but I'd be shocked if it didn't work. Of course, specifying a > service as a default instead of a target is very limiting, but it would > probably work. Heck, you could probably specify a mount as the default > and the system would just boot and mount something and sit there. Or > you could make it a socket and all it would do is sit and listen for a > connection inetd-style. As mentioned both in the systemd FAQ and in the systemd.special (7) manpage, under default.target, this is the default unit started at bootup. Normally, it'll be a symlink to either multi-user.target (analogous to sysvinit semi-standard runlevel 3, CLI, no X), or graphical.target (analogous to sysvinit semi-standard runlevel 5, launching X and and a graphical *DM login). I don't see specific documentation of whether symlinking to a non-target unit is allowed, but systemd does have a commandline option --unit=, which is explicitly documented to take a _unit_, default.target being the default, but other non-target units being possible as well. Presumably systemd would examine said unit, looking for DefaultDependencies=no, and if not specifically set, would start the early "system level" targets, before starting the named unit in place of the normal default.target. So it's definitely possible to do via systemd commandline, but I'm not sure if default.target is followed if it doesn't symlink a target unit, or not. I'd guess yes, but have neither seen it specifically documented nor tested it myself, nor read of anyone else actually testing it. > > I find it more helpful to think of targets as just units that don't do > anything. We don't use them in openrc but I suspect it would work out > of the box, and maybe we should even consider doing it in at least some > cases. For example, right now /etc/init.d/samba uses some scripting to > launch both nmbd/smbd and fancy config file parsing to let the users > control which ones launch. You could instead break that into three > files - smbd, nmbd, and samba. The first two would launch one daemon > each, and the samba init.d script wouldn't actually launch anything, but > would just depend on the others. That would be the system