Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 27, 2015 at 04:21:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote: On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. Congratulations. We now have inconsistent behavior if anyone, *ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration Actually it might be considered that we are *starting* to follow FHS. In many (most?) setups /etc/resolv.conf configuration is very dynamic: the set of resolvers depends on dhcp leases, VPNs, network interfaces coming and going. Storing this information in /etc/ is wrong. It's good that this ephmeral content is not backed up. If the machine reboots, you do not want to restore it, you want to recreate it from scratch. If someone has a static setup and a static resolv.conf is fine for them, there's no problem: just create a normal file. The underlying problem here is that it isn't just created when it is missing. It is created *before* other tools have a chance to create it. As I explained in 1197204 the boot.iso is created without a /etc/resolv.conf, this means that NM should create it with whatever content it needs. Except that systemd-tmpfiles comes along first, assumes it can create it and then breaks NM. Upstream has declined to fix this, so we're going to need the patch that's been applied to f21 and f22 carried forward until that changes. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 2015-03-02 at 08:42 -0800, Brian C. Lane wrote: On Fri, Feb 27, 2015 at 04:21:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote: On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. Congratulations. We now have inconsistent behavior if anyone, *ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration Actually it might be considered that we are *starting* to follow FHS. In many (most?) setups /etc/resolv.conf configuration is very dynamic: the set of resolvers depends on dhcp leases, VPNs, network interfaces coming and going. Storing this information in /etc/ is wrong. It's good that this ephmeral content is not backed up. If the machine reboots, you do not want to restore it, you want to recreate it from scratch. If someone has a static setup and a static resolv.conf is fine for them, there's no problem: just create a normal file. The underlying problem here is that it isn't just created when it is missing. It is created *before* other tools have a chance to create it. As I explained in 1197204 the boot.iso is created without a /etc/resolv.conf, this means that NM should create it with whatever content it needs. Except that systemd-tmpfiles comes along first, assumes it can create it and then breaks NM. With NM = 1.0, it will create a tempfile in /etc and then rename that over top of the existing /etc/resolv.conf, though it does try to follow a link (with realpath(2)) and replace that file atomically (with rename(2)). If that's being broken by systemd we should probably handle this case better in NM too, along with whatever systemd changes need to happen. With NM 1.0, NM will stop touching resolv.conf at all if it's a symlink, because that file is owned by some other process. NM will still write out it's own resolv.conf to /var/run. If resolv.conf is a file, and NM is allowed to manage DNS through its config, then NM will make resolv.conf a symlink to its file in /var/run, much like I understand systemd does. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 2 Mar 2015 08:42:25 -0800 Brian C. Lane b...@redhat.com wrote: The underlying problem here is that it isn't just created when it is missing. It is created *before* other tools have a chance to create it. As I explained in 1197204 the boot.iso is created without a /etc/resolv.conf, this means that NM should create it with whatever content it needs. Except that systemd-tmpfiles comes along first, assumes it can create it and then breaks NM. Perhaps the tmpfiles entry for /etc/resolv.conf should be moved to a systemd-networkd tmpfile entry? Then, if you do not install that it's assumed NM or whatever will create the entry, if you do, it can then manage that file that gets created. Upstream has declined to fix this, so we're going to need the patch that's been applied to f21 and f22 carried forward until that changes. Is there an upstream bug or discussion we can look at? Yeah, I was hoping to get a nice rawhide Xfce 4.12 image to test with today, but of course it hit this bug and didn't get created. ;( kevin pgp2J6kiCg3AY.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 27, 2015 at 8:18 AM, Nico Kadel-Garcia nka...@gmail.com wrote: Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration is part of what killed the old daemontools init system replacement. tool. You and the other developers have gone well past that. But these are not tiny surprises, and the anaconda team is far, far, far from the only people who need a heads up on structural surprises like this. I seem to be having trouble with my positive and negative parity this morning. I meant that they've gone well past the stage of acceptance and deployment that daemontools ever reached, so it's unlikely to be effectively abandoned as daemontools has been. I'll restrain my technical comparisons. And you've introduced a permanent inconsistency between systems that were ever touched by an admin or a tool aware of symlinks, and one that has not been so touched. And introduced a backup configuration issue: network configuration backups, or even source control systems that store /etc/resolv.conf, all need to be tweaked. See above. I meant an admin *unaware* of symlinks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. Congratulations. We now have inconsistent behavior if anyone, *ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration is part of what killed the old daemontools init system replacement. tool. You and the other developers have gone well past that. But these are not tiny surprises, and the anaconda team is far, far, far from the only people who need a heads up on structural surprises like this. Hey, if you want to know what's going on in systemd development, then pelase join our upstream mailing list. You probably wouldn't like it. I'd scream about things like this. The time I can spare for this is spent cleaning up the mess when systemd based tools from Fedora are unusable under RHEL 5 or 6 without folks like me putting in hooks to detect and handle real init scripts, and vice versa. It's over hat https://github.com/nkadel/. And no, I will not forward all systemd design discussions to the fedora ML, it has no place there. We don't forward them to the suse, debian, ubuntu MLs either. This wasn't merely a discussion, it was an unexpected behavioral change in a vital system configuration file. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? Nope. All that systemd does is create it as symlinks if it is otherwise missing. If you put something else there, then that's what counts. And you've introduced a permanent inconsistency between systems that were ever touched by an admin or a tool aware of symlinks, and one that has not been so touched. And introduced a backup configuration issue: network configuration backups, or even source control systems that store /etc/resolv.conf, all need to be tweaked. These are not the largest of issues, but they're very real. Personally? I'd say either always use a symlink, or never use one. Please do not try to deduce the sys-admin's intent from which editing tool they happen to use and its secondary behavior. The handling of symlinks can seriously, seriously bite you at odd moments. This is also not a new problem: this is not the first time that out-of-band information got stuck someplace weird and took extra work and knowledge to deal with. When tools like system-config-network started hiding content in /etc/sysconfig/networking/profiles and /etc/sysconfig/networking/devices, some of us had to learn about scrubbing those away or making them consistent in order to make sure that /etc/sysconfig/network-scripts/ifcfg-* changes got propagated reliably in Fedora and RHEL systems. But it's a *surprise* when it happens, and it's extra work in day to day network administration. And yeah, it happened Monday dealing with virtualized OS image given a new MAC address and with old MAC address embedded in weird places. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/27/2015 01:18 PM, Nico Kadel-Garcia wrote: On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is*missing*. Congratulations. We now have inconsistent behavior if anyone,*ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. I guess you missed the part that it did nothing if the file existed. Even after spending what 8 years in Fedora's QA ( longer than any of their so called hired employee working in that area ) as well as handling the systemd integration for wide variety of component I was not even allowed to see RHEL systemd integration bug trackers until in some case other Red Hat employees ranted over their coworkers how stupid they were not allowing the guy handling the integration doing so. I know first hand the state of systemd in Fedora and I have seen the state it's in RHEL and I know Red Hat did nothing to improve the situation from what it was in Fedora not even make some of those implementations enterprise grade so regarding the rest of your rant neither upstream nor Fedora ( despite Red Hat royally abusing it's community and shape it in it's image ) has any control over any decisions Red Hat makes about it's RHEL release so use that support contract you are paying Red Hat for and wreak havoc with them. Hopefully that havoc from you and from other customers will ring some wakeup bells with it's managers and get them thinking. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote: On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: [ notes snipped, ] You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. Congratulations. We now have inconsistent behavior if anyone, *ever*, edits /etc/resolf.conf with 'sed -i', uses rsync -a or cp -a tp reproduce it from a known good repository, and with a symlink in place we're storing absolutely critical system information in a non /etc location, meaning that non-modified backup systems won't get a copy with valid content. Just. great. Look, deciding to ignore the File System Hierarchy for installing config files and creating new locations to store system configuration Actually it might be considered that we are *starting* to follow FHS. In many (most?) setups /etc/resolv.conf configuration is very dynamic: the set of resolvers depends on dhcp leases, VPNs, network interfaces coming and going. Storing this information in /etc/ is wrong. It's good that this ephmeral content is not backed up. If the machine reboots, you do not want to restore it, you want to recreate it from scratch. If someone has a static setup and a static resolv.conf is fine for them, there's no problem: just create a normal file. OK, this change is not transparent to tools that write resolver information. The new scheme requires some changes, but it's not more complicated than the old scheme. It is actually easier for the admin, because it gives full control over the symlink to them, and easier for the tools, because they don't have to fight over the contents of the file. Hey, if you want to know what's going on in systemd development, then pelase join our upstream mailing list. I know that this is not realistic. But it's not really necessary. This issue discussed before F21, and an number of Anaconda people participated in the discussion. The bug was open for the last 6 months. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? Nope. All that systemd does is create it as symlinks if it is otherwise missing. If you put something else there, then that's what counts. The file that is written by systemd-resolved contains the following header: # This file is managed by systemd-resolved(8). Do not edit. # # Third party programs must not access this file directly, but # only through the symlink at /etc/resolv.conf. To manage # resolv.conf(5) in a different way, replace the symlink by a # static file or a different symlink. I'll try to tweak this text a bit to be clearer on the symlink issue. I don't have a NetworkManager generated file at hand to see, but it should probably carry something similar. Personally? I'd say either always use a symlink, or never use one. Please do not try to deduce the sys-admin's intent from which editing tool they happen to use and its secondary behavior. The handling of symlinks can seriously, seriously bite you at odd moments. We need the file to be a symlink for some usecases. We *could* deprecate /etc/resolv.conf as a normal file, and always create it as a symlink. Anaconda would then write (say) /etc/resolv.conf.static, and symlink /etc/resolv.conf → resolv.conf.static. This is really beyond systemd, since systemd does not create the static file ever. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Am 26.02.2015 um 16:37 schrieb Jóhann B. Guðmundsson: On 02/26/2015 02:10 PM, Reindl Harald wrote: really? why? how do you come to that weird conclusion? surely, one can say not my package, not my problem but that's ignorant and needs no guidelines and policies - sanity should be enough I guess you did not grasp I was referring to the ownership model of components in the distribution which are irrelevant to guidelines and policy's i did The fact is the distribution has been using the ownership model since it's interception which means one to one mapping from a component to an individual. As such the thought process of I take care of what I own has been breed into maintainers for the past ten years. and i doubt that this is true in general every maintainer with responsiblity is or should be aware that his piece is *part of a distribution* because otherwise he could just build his package outside for his own There have been several cases where the community has explode due to lack of communications as an result of that with the most notorious of those being the Gnome half of the Red Hat's desktop team where more often than not they have broken bits for other *DE's that have been sharing underlying components in the distribution. ( search this lists archives if you need proof of that ) and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative having everybody mangle every package is also not a solution because you can't expect the needed knowledge for mangle around in a perl package from a java-user and so on On top of that there are around 15k components in the distribution and expecting all maintainers to be able to keep tabs on all packager relations ( to their own or in general ) is ignant or expect them to does so for a single fedora-release rpm after the distribution has been split up again into core ( products ) and extra ( the inferior rest ) where the inevitale outcome is for those products eventually start shipping their own fedora release package... If the PLL had thought though these thing thoroughly through he would have realized that. that's a completly different topic signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 02:10 PM, Reindl Harald wrote: really? why? how do you come to that weird conclusion? surely, one can say not my package, not my problem but that's ignorant and needs no guidelines and policies - sanity should be enough I guess you did not grasp I was referring to the ownership model of components in the distribution which are irrelevant to guidelines and policy's. The fact is the distribution has been using the ownership model since it's interception which means one to one mapping from a component to an individual. As such the thought process of I take care of what I own has been breed into maintainers for the past ten years. There have been several cases where the community has explode due to lack of communications as an result of that with the most notorious of those being the Gnome half of the Red Hat's desktop team where more often than not they have broken bits for other *DE's that have been sharing underlying components in the distribution. ( search this lists archives if you need proof of that ) On top of that there are around 15k components in the distribution and expecting all maintainers to be able to keep tabs on all packager relations ( to their own or in general ) is ignant or expect them to does so for a single fedora-release rpm after the distribution has been split up again into core ( products ) and extra ( the inferior rest ) where the inevitale outcome is for those products eventually start shipping their own fedora release package... If the PLL had thought though these thing thoroughly through he would have realized that. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 03:49 PM, Reindl Harald wrote: and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative I have already mentioned alternative before no need to repeat that proposal to you. Bottom line that model will not be change due to Red Hat requiring to keep components it ships under its own control. Why do you think the distribution has been split into cores and extra again now through products ? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 03:58 PM, Reindl Harald wrote: Am 26.02.2015 um 16:54 schrieb Jóhann B. Guðmundsson: On 02/26/2015 03:49 PM, Reindl Harald wrote: and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative I have already mentioned alternative before no need to repeat that proposal to you. Bottom line that model will not be change due to Red Hat requiring to keep components it ships under its own control. you typical Red Hat flame. s/flame/facts Why do you think the distribution has been split into cores and extra again now through products? that is nonsense and you know that! It is not. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Am 26.02.2015 um 16:54 schrieb Jóhann B. Guðmundsson: On 02/26/2015 03:49 PM, Reindl Harald wrote: and without the ownership model it would have been prevented what model would you use? you can't only say that model is wrong without any alternative I have already mentioned alternative before no need to repeat that proposal to you. Bottom line that model will not be change due to Red Hat requiring to keep components it ships under its own control. you typical Red Hat flame. Why do you think the distribution has been split into cores and extra again now through products? that is nonsense and you know that! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote: Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people Sorry for the somewhat slow reply, but I've been thinking about all of this I guess, primarily, what I'd really hope for is for _all_ Fedora package maintainers to feel like they have a stake in fedora-release.rpm, at least in a symbolic and general sense. As Fedora contributors, we should not just think about individual ownership of the packages we are primarily responsible for, but also how it all fits together. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Am 26.02.2015 um 15:05 schrieb Jóhann B. Guðmundsson: On 02/26/2015 01:29 PM, Matthew Miller wrote: On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote: Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people Sorry for the somewhat slow reply, but I've been thinking about all of this I guess, primarily, what I'd really hope for is for _all_ Fedora package maintainers to feel like they have a stake in fedora-release.rpm, at least in a symbolic and general sense. As Fedora contributors, we should not just think about individual ownership of the packages we are primarily responsible for, but also how it all fits together. You will need to change the ownership model of packages in the distribution if you want to change that and related expectations regarding individual ownership. Until you do you should expect others to expect relevant maintainer(s) be responsible for the component they maintain really? why? how do you come to that weird conclusion? surely, one can say not my package, not my problem but that's ignorant and needs no guidelines and policies - sanity should be enough signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/26/2015 01:29 PM, Matthew Miller wrote: On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote: Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people Sorry for the somewhat slow reply, but I've been thinking about all of this I guess, primarily, what I'd really hope for is for _all_ Fedora package maintainers to feel like they have a stake in fedora-release.rpm, at least in a symbolic and general sense. As Fedora contributors, we should not just think about individual ownership of the packages we are primarily responsible for, but also how it all fits together. You will need to change the ownership model of packages in the distribution if you want to change that and related expectations regarding individual ownership. Until you do you should expect others to expect relevant maintainer(s) be responsible for the component they maintain. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015 at 11:36 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. Yes, and it looks like it affects dhcpd too... just because you notified one dev team on a single bug it's not the same as a wider announcement to the wider community. There's all sorts of things that this can affect, and while yes it may be a bug in their software, it should be as widely notified as possible. People have priorities that may not be the same as yours. Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). You do not know, and cannot know in advance without testing, how many different systems might manipulate or rely on specific resolv.conf changes. This is especially true for VPN based environments where the order of DNS resolvers is critical to correct local and general environment resolution. Puppet, cfengine, chef, tuttle, and many virtualization systems such manipulate entire network stacks by either stabilizing them or resetting them. And now they have to manipulate /etc/resolv.conf as a symlink? It's one of the systemd problems: We know better than the last 30 years of UNIX work how this should be, and will take it over with our own unique, new paradigm. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. OK, got it, will let everybody know now of changes 5 years in advance. Would that suit your needs? Only telling the people who need to know is the problem. You apparently think you know, personally, who those people are. That's not safe or fair to other developers or even to normal admins. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? Anyway, I have the suspicion you just want to make a fuss, and this is where it ends for me hence. And this is the other reason people don't trust your project. Systemd feature growth has been pretty pedal to the metal. Even if the new model is *better* in terms of your or your group's network configuration paradigms, it requires breaking long stable workflows and configurations. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 2015-02-23 at 14:40 +0100, drago01 wrote: On Mon, Feb 23, 2015 at 2:17 PM, David Cantrell dcantr...@redhat.com wrote: That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. Almost every change might affect other components ... it might be obvious to a maintainer of an affected component but not necessarily for the maintainer / developer of the component that got changed. Which is why you should send a message to a general development list for changes that change the semantics of a well established mechanism. If you are changing something internal to your software then the burden of keeping up is with the downstream people that may decide to depend on internal features (assuming private/public interfaces are clearly defined). If you are changing something in the system public interfaces, instead a bit more general and advance notice is necessary. This is a general rule, not specific to systemd, and I am guilty of having changed stuff without a direct message to devel@ in the past. We all need to get better at communicating changes that may affect others, it buys goodwill and understanding, and perhaps the occasional flame, but what was the saying ? Flame early, flame often ? :) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 08:45:56AM -0500, Nico Kadel-Garcia wrote: On Fri, Feb 20, 2015 at 11:36 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. Yes, and it looks like it affects dhcpd too... just because you notified one dev team on a single bug it's not the same as a wider announcement to the wider community. There's all sorts of things that this can affect, and while yes it may be a bug in their software, it should be as widely notified as possible. People have priorities that may not be the same as yours. Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). You do not know, and cannot know in advance without testing, how many different systems might manipulate or rely on specific resolv.conf changes. This is especially true for VPN based environments where the order of DNS resolvers is critical to correct local and general environment resolution. Puppet, cfengine, chef, tuttle, and many virtualization systems such manipulate entire network stacks by either stabilizing them or resetting them. And now they have to manipulate /etc/resolv.conf as a symlink? It's one of the systemd problems: We know better than the last 30 years of UNIX work how this should be, and will take it over with our own unique, new paradigm. There is no need to feed trolls on this list, thank you. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. OK, got it, will let everybody know now of changes 5 years in advance. Would that suit your needs? Only telling the people who need to know is the problem. You apparently think you know, personally, who those people are. That's not safe or fair to other developers or even to normal admins. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? And what makes you think it wasn't? Did you face it yourself and report the bug upstream or are you assuming? I hope for the former, otherwise you're just speculating and it is sad. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 2:17 PM, David Cantrell dcantr...@redhat.com wrote: That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. Almost every change might affect other components ... it might be obvious to a maintainer of an affected component but not necessarily for the maintainer / developer of the component that got changed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20.02.15 11:48, Dennis Gilmore (den...@ausil.us) wrote: While moving it is great, it's not really that important to move it. I mean, moving it is useful in the context of stateless systems that can boot up with empty /etc. However, Fedora is so far away from that, that we have tons of other things to fix first, before the os-release move would start to matter. We haven't posted a feature to make Fedora stateless in this sense, and hence also didn't ask for /etc/os-release to be moved. There are some upstream things to work on before we can propose such a Fedora change. So, thank you very much for moving it! But this is neither a change that would really need coordination, nor something we pushed for from our side. communication would have avoided some of the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided having the bug altogether. regardless of your reasons for making a change or how unimportant you consider it, others follow things that are done and follow up on them when you do not. I for one would appreciate knowing when the allowable fields change in os-release because the first I ever hear is when people file bugs asking for them to be added to Fedora. I then have to chase things down to catch up. Communication is a two way street, and as an upstream I cannot be in the business of pinging every single downstream about every single change individually, in particular if I consider the change unimportant. To learn about changes upstream, please follow the upstream discussions, thank you. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20.02.15 11:49, Dennis Gilmore (den...@ausil.us) wrote: A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release I should add that changing it broke the compose process and was quickly fixed. wider communication means that other effected components have some visibility into things that may effect them. You cannot really blame me for breakages for things I neither asked for nor was involved with at all in Fedora. I am not blaming you for anything here, merely pointing out that if there was better communications we could have likely avoided the breakage while the change was made altogether. Good, please ping me about changes like this next time then, and I am happy to comment! Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 01:23:01PM +0100, Lennart Poettering wrote: On Fri, 20.02.15 11:48, Dennis Gilmore (den...@ausil.us) wrote: While moving it is great, it's not really that important to move it. I mean, moving it is useful in the context of stateless systems that can boot up with empty /etc. However, Fedora is so far away from that, that we have tons of other things to fix first, before the os-release move would start to matter. We haven't posted a feature to make Fedora stateless in this sense, and hence also didn't ask for /etc/os-release to be moved. There are some upstream things to work on before we can propose such a Fedora change. So, thank you very much for moving it! But this is neither a change that would really need coordination, nor something we pushed for from our side. communication would have avoided some of the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided having the bug altogether. regardless of your reasons for making a change or how unimportant you consider it, others follow things that are done and follow up on them when you do not. I for one would appreciate knowing when the allowable fields change in os-release because the first I ever hear is when people file bugs asking for them to be added to Fedora. I then have to chase things down to catch up. Communication is a two way street, and as an upstream I cannot be in the business of pinging every single downstream about every single change individually, in particular if I consider the change unimportant. To learn about changes upstream, please follow the upstream discussions, thank you. This still fails. The expectation here is that downstream consumers know an upstream change is coming. As evidenced by the various bugs mentioned in this thread, the result is surprise, something changed. So the discovery is reactionary rather than coordinated before putting a change in rawhide. It would be a slightly different story if rawhide's systemd was gated by someone doing Fedora integration coordination, but it doesn't appear anyone is doing that. And you say you can't, though I am disappointed with that since you sort of kind of already signed up for that work by starting systemd and getting it in to Fedora in the first place. If it's not you that coordinates this work, someone who works on and/or maintains the systemd package in Fedora should be doing this. That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 23.02.15 08:17, David Cantrell (dcantr...@redhat.com) wrote: Communication is a two way street, and as an upstream I cannot be in the business of pinging every single downstream about every single change individually, in particular if I consider the change unimportant. To learn about changes upstream, please follow the upstream discussions, thank you. This still fails. The expectation here is that downstream consumers know an upstream change is coming. As evidenced by the various bugs mentioned in this thread, the result is surprise, something changed. So the discovery is reactionary rather than coordinated before putting a change in rawhide. Hey, there was no need for Fedora to change the path for /etc/os-release. It was good that it decided to change, but this was done without contacting me, and I didn't push for it, I was not involved at all really, and I cannot read people's minds about it. The change is nothing that would normally considered an incompatible change, it just moved one file from /etc to /usr/lib and replaced it with a symlink. Please find something else to complain about. THis particular case makes a really bad example, since I was hardly involved, it wasn't my side that was communicating badly, but the folks adding this to Fedora, and that wasn't me. It would be a slightly different story if rawhide's systemd was gated by someone doing Fedora integration coordination, but it doesn't appear anyone is doing that. And you say you can't, though I am disappointed with that since you sort of kind of already signed up for that work by starting systemd and getting it in to Fedora in the first place. If it's not you that coordinates this work, someone who works on and/or maintains the systemd package in Fedora should be doing this. That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. David, I see how you would like to pin this all on systemd's supposedly bad communication. But coming back to the /etc/resolv.conf issue: it really just boils down to the fact that you knew the change was coming 6 months ago, but instead of making the necessary one-line fix in your packages, you didn't do anything. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). You do not know, and cannot know in advance without testing, how many different systems might manipulate or rely on specific resolv.conf changes. You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. And it won#t be missing if anaconda copies in its stuff as it currently does. I mean, the issue is really about this copy routine being broken, and not about systemd having a fallback logic to create /etc/resolv.conf if it is missing. If anaconda's file copy routine would not be confused by symlinks in the destination, the issue goes away entirely: it would create its file, and systemd's /etc/resolv.conf logic would never touch anything anymore. This is especially true for VPN based environments where the order of DNS resolvers is critical to correct local and general environment resolution. Puppet, cfengine, chef, tuttle, and many virtualization systems such manipulate entire network stacks by either stabilizing them or resetting them. And now they have to manipulate /etc/resolv.conf as a symlink? No, they don't. Only anaconda has, since it starts with an empty /etc. That said, I think it would be a ton better if those frameworks you list would be able to deal with /etc/resolv.conf being a symlink. It's one of the systemd problems: We know better than the last 30 years of UNIX work how this should be, and will take it over with our own unique, new paradigm. Note that this would matter here at all /etc/resolv.conf being a symlink is hardly a new concept. See Debian's resolvconf package for example... How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. OK, got it, will let everybody know now of changes 5 years in advance. Would that suit your needs? Only telling the people who need to know is the problem. You apparently think you know, personally, who those people are. That's not safe or fair to other developers or even to normal admins. Hey, if you want to know what's going on in systemd development, then pelase join our upstream mailing list. And no, I will not forward all systemd design discussions to the fedora ML, it has no place there. We don't forward them to the suse, debian, ubuntu MLs either. For example, now if I manipulate /etc/resolv.conf for whatever reason, and I edit it with vi or a management tool like chef that is unaware of symlinks, I'll break the link. Will systemd correctly re-establish the link? Will it wipe out my change, Did anyone even *think* about this? Nope. All that systemd does is create it as symlinks if it is otherwise missing. If you put something else there, then that's what counts. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 23.02.15 08:52, Simo Sorce (s...@redhat.com) wrote: On Mon, 2015-02-23 at 14:40 +0100, drago01 wrote: On Mon, Feb 23, 2015 at 2:17 PM, David Cantrell dcantr...@redhat.com wrote: That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. Almost every change might affect other components ... it might be obvious to a maintainer of an affected component but not necessarily for the maintainer / developer of the component that got changed. Which is why you should send a message to a general development list for changes that change the semantics of a well established mechanism. If you are changing something internal to your software then the burden of keeping up is with the downstream people that may decide to depend on internal features (assuming private/public interfaces are clearly defined). If you are changing something in the system public interfaces, instead a bit more general and advance notice is necessary. The /etc/os-release to /usr/lib/os-release is hardly a change in the public interface, it keeps compat by leaving a symlink in /etc. And jeezuz, I didn't push this change into Fedora. Other people did, without talking to me. Really, this is neither much of a compat break, nor is this something I even knew about. Really, find something else to complain about. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 04:27:22PM +0100, Lennart Poettering wrote: On Mon, 23.02.15 08:17, David Cantrell (dcantr...@redhat.com) wrote: Communication is a two way street, and as an upstream I cannot be in the business of pinging every single downstream about every single change individually, in particular if I consider the change unimportant. To learn about changes upstream, please follow the upstream discussions, thank you. This still fails. The expectation here is that downstream consumers know an upstream change is coming. As evidenced by the various bugs mentioned in this thread, the result is surprise, something changed. So the discovery is reactionary rather than coordinated before putting a change in rawhide. Hey, there was no need for Fedora to change the path for /etc/os-release. It was good that it decided to change, but this was done without contacting me, and I didn't push for it, I was not involved at all really, and I cannot read people's minds about it. The change is nothing that would normally considered an incompatible change, it just moved one file from /etc to /usr/lib and replaced it with a symlink. Please find something else to complain about. THis particular case makes a really bad example, since I was hardly involved, it wasn't my side that was communicating badly, but the folks adding this to Fedora, and that wasn't me. Are you the owner of systemd or not? You travel the world giving talks about it, yet when confronted with problems caused by changes in systemd you point to others and say it's not you. What is it? Either you have a stake in systemd or not. It would be a slightly different story if rawhide's systemd was gated by someone doing Fedora integration coordination, but it doesn't appear anyone is doing that. And you say you can't, though I am disappointed with that since you sort of kind of already signed up for that work by starting systemd and getting it in to Fedora in the first place. If it's not you that coordinates this work, someone who works on and/or maintains the systemd package in Fedora should be doing this. That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. David, I see how you would like to pin this all on systemd's supposedly bad communication. But coming back to the /etc/resolv.conf issue: it really just boils down to the fact that you knew the change was coming 6 months ago, but instead of making the necessary one-line fix in your packages, you didn't do anything. OK, if we're speaking specifically about this, what a change like this requires is a heads-up when you are going to commit the change to rawhide. That's it. A six month old bug doesn't count. Fine, we knew about it via the filed bug, but we don't know WHEN you'll be pushing the change. And even if you did mention exactly when that would happen, a heads up to teams to remind them to make their changes is super helpful. Again, *you* are the one who knows this is coming more precisely than we do. Your insistence on not taking responsibility for problems that you directly cause is frustrating. And many people have pointed this out. You are very quick to immediately distance yourself from conflicts caused by systemd by raising any number of flags, such as it's Fedora, not me or that was an upstream decision, Fedora doesn't have to follow it. Come on, seriously? Fedora is all about maximum upstream cooperation and usage, so you cannot seriously think you can distance yourself from Fedora that much. All we want is BETTER COMMUNICATION from you within this project. This project being Fedora. Be a team player, please. -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015 at 11:04:13AM -0600, Dennis Gilmore wrote: On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ Rahul Sundaram and I asked for this change to follow upstream and because it is a step in the right direction and we might just as well make it now. A symlink is both carried by fedora-release.rpm and added automatically by systemd if the file is missing, so most consumers should not be affected. I don't agree with Lennart here there we should delay changes which incrementally move us towards the goal of empty /etc. It's not that far out and with every file moved it becomes easier. We should be changing the mindset of what belong in /etc, and os-release is part of the basic file system and has symbolic importance. I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release It turns out that dracut was affected, but the bug is easy enough to fix. If fedora-devel was used to announce every file move we'd all go crazy. And seriously, Rahul Sundaram is hardly a third party person. He's one of the active maintainers of systemd package, which you can easily check in the pkgdb, as well as your colleague from Red Hat. But even if he was, it should hardly matter. He made a bug report providing the necessary justification (quoting upstream manpage), and it should make no difference whether he is active in other areas or if that bug report was his first contribution to Fedora. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 2015-02-23 at 16:29 +0100, Lennart Poettering wrote: On Mon, 23.02.15 08:52, Simo Sorce (s...@redhat.com) wrote: On Mon, 2015-02-23 at 14:40 +0100, drago01 wrote: On Mon, Feb 23, 2015 at 2:17 PM, David Cantrell dcantr...@redhat.com wrote: That is, and I am trying to be specific here, changes that impact other components in the distribution need to be coordinated in Fedora among the affected components. Almost every change might affect other components ... it might be obvious to a maintainer of an affected component but not necessarily for the maintainer / developer of the component that got changed. Which is why you should send a message to a general development list for changes that change the semantics of a well established mechanism. If you are changing something internal to your software then the burden of keeping up is with the downstream people that may decide to depend on internal features (assuming private/public interfaces are clearly defined). If you are changing something in the system public interfaces, instead a bit more general and advance notice is necessary. The /etc/os-release to /usr/lib/os-release is hardly a change in the public interface, it keeps compat by leaving a symlink in /etc. And jeezuz, I didn't push this change into Fedora. Other people did, without talking to me. Really, this is neither much of a compat break, nor is this something I even knew about. Really, find something else to complain about. If you want to whine for something, at least whine at those that are accusing you of having done something. In my message I accused nobody and made a mea cupla as much as anything. Context boy! Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Hi On Mon, Feb 23, 2015 at 10:35 AM, Zbigniew Jędrzejewski-Szmek wrote: And seriously, Rahul Sundaram is hardly a third party person. He's one of the active maintainers of systemd package, which you can easily check in the pkgdb, as well as your colleague from Red Hat. Neither is correct at this point but as you note below, this isn't the relevant part But even if he was, it should hardly matter. He made a bug report providing the necessary justification (quoting upstream manpage), and it should make no difference whether he is active in other areas or if that bug report was his first contribution to Fedora. FWIW, just in case anyone is curious, I filed a bug report against Google Chrome to drop the dependency on redhat-lsb package since it is a meta package for a while and pulls in a long list of dependencies and the only reason afaik for this dependency is to read the distribution name and version. os-release provides a standard location and format for this information these days but it is confusing to have the system behave differently from how the documentation says it should be setup and I requested the change and it has been subsequently made (not by me). I also independently filed a bug report to deprecate the distro specific file but FESCo has rejected that. I don't believe that having this information in multiple places is a good way to maintain a distribution and we should strive to move to a single canonical location. I don't see a reason not to add some documentation providing an advance notice of this but whatever. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). You do not know, and cannot know in advance without testing, how many different systems might manipulate or rely on specific resolv.conf changes. You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. And it won#t be missing if anaconda copies in its stuff as it currently does. I mean, the issue is really about this copy routine being broken, and not about systemd having a fallback logic to create /etc/resolv.conf if it is missing. If anaconda's file copy routine would not be confused by symlinks in the destination, the issue goes away entirely: it would create its file, and systemd's /etc/resolv.conf logic would never touch anything anymore. As a bystander, I'm lost here. Systemd made a change. I'm not sure what the change is. Anaconda is supposedly confused by destination/etc/resolv.conf being a symlink. What is anaconda *supposed* to do? Options seem to include: 1. Do nothing. 2. Delete the symlink and replace it. 3. Follow the symlink, delete the target, and replace it. 4. Follow the symlink and overwrite the target. Knowing little about what systemd is doing here, I would argue for (1). If it's a symlink, then presumably something manages whatever the symlink points to. OTOH, this is *anaconda* we're talking about. Maybe it should do whatever it needs to do to make the installed Fedora system happy, whatever that is. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, 23.02.15 10:52, David Cantrell (dcantr...@redhat.com) wrote: On Mon, Feb 23, 2015 at 04:27:22PM +0100, Lennart Poettering wrote: On Mon, 23.02.15 08:17, David Cantrell (dcantr...@redhat.com) wrote: Communication is a two way street, and as an upstream I cannot be in the business of pinging every single downstream about every single change individually, in particular if I consider the change unimportant. To learn about changes upstream, please follow the upstream discussions, thank you. This still fails. The expectation here is that downstream consumers know an upstream change is coming. As evidenced by the various bugs mentioned in this thread, the result is surprise, something changed. So the discovery is reactionary rather than coordinated before putting a change in rawhide. Hey, there was no need for Fedora to change the path for /etc/os-release. It was good that it decided to change, but this was done without contacting me, and I didn't push for it, I was not involved at all really, and I cannot read people's minds about it. The change is nothing that would normally considered an incompatible change, it just moved one file from /etc to /usr/lib and replaced it with a symlink. Please find something else to complain about. THis particular case makes a really bad example, since I was hardly involved, it wasn't my side that was communicating badly, but the folks adding this to Fedora, and that wasn't me. Are you the owner of systemd or not? You travel the world giving talks about it, yet when confronted with problems caused by changes in systemd you point to others and say it's not you. What is it? Either you have a stake in systemd or not. Uh? I meant the maintainer of fedora-release.rpm with this. Sure I have a stake in systemd, but certainly none in fedora-release.rpm. But even for systemd, there are a number of people who work on the RPM. And while I feel responsible for it, there will always be changes made without me knowing, or with me even agreeing. But it's *good* that way. I trust Zbigniew, and I am not the control freal who wants to be involved with all choices made... And quite frankly, I think that Zbigniew is a much nicer guy than I am, so you should be happy about this. But anyway, I think it's time to end the discussion, this is pointless. In the case of the /etc/resolv.conf change: The change of behaviour in systemd was simply addition of a fallback code path in case /etc/resolv.conf was missing. This was communicated to you 6 months ago. If anaconda/livecd's copy routine would be fixed, then there would be no issue. This triggered a bug in your package that is all. No other packages would be affected if this one-line fix was made to anaconda/livecd. In the case of the /etc/os-release change: this is actually a minor change, since compat is provided via a symlink. Adoption by Fedora was optional, it is great though it happened, and I am thankful that Zbginiew pushed for it. Neither issue is an API break, and both changes are rather local and minor. I am very sure that neither of this changes require grand theatralic announcements, and in order to keep the noise level low, there wasn't any. And I'd probably handle the same case the same way again. Sorry, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
There are patches waiting in: https://bugzilla.redhat.com/show_bug.cgi?id=1116651 And I think almost every poster so far in this thread has the technical knowledge to review them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 07:56:50AM -0800, Andrew Lutomirski wrote: On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). You do not know, and cannot know in advance without testing, how many different systems might manipulate or rely on specific resolv.conf changes. You know, that systemd creates a symlink if the file is missing is not going to change behaviour of anything, since it will only do something if the file is *missing*. And it won#t be missing if anaconda copies in its stuff as it currently does. I mean, the issue is really about this copy routine being broken, and not about systemd having a fallback logic to create /etc/resolv.conf if it is missing. If anaconda's file copy routine would not be confused by symlinks in the destination, the issue goes away entirely: it would create its file, and systemd's /etc/resolv.conf logic would never touch anything anymore. As a bystander, I'm lost here. Systemd made a change. I'm not sure what the change is. Previously all sources which could provide a list of dns server would fight over /etc/resolv.conf. This includes: explicit configuration by the admin, dhcplient, NetworkManager, systemd-resolved, local dns servers. Additional issue is that the list of dns servers is inherently dynamic, which conflicts with read-only root filesystem. The change: various provides of resolv.conf contents create files in temporary storage (under /run), and the administrator symlinks to the one he or she wants to be used. Anaconda is supposedly confused by destination/etc/resolv.conf being a symlink. What is anaconda *supposed* to do? Options seem to include: 1. Do nothing. 2. Delete the symlink and replace it. 3. Follow the symlink, delete the target, and replace it. 4. Follow the symlink and overwrite the target. Anaconda should do 2. It can either provide a static file, or it can replace the symlink with a symlink of its own choosing. For example, it could symlink to the resolv.conf file provided by NetworkManager if NetworkManager is being installed in the system. It shouldn't do 1., because that would result in broken network, and it shouldn't do 3 or 4 because the target of the symlink is systemd-resolved territory. Knowing little about what systemd is doing here, I would argue for (1). If it's a symlink, then presumably something manages whatever the symlink points to. OTOH, this is *anaconda* we're talking about. Maybe it should do whatever it needs to do to make the installed Fedora system happy, whatever that is. Yes, anaconda is installing the system, and knows how the network is supposed to set up. It should set /etc/resolv.conf accordingly. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Communication is a two way street, and as an upstream I cannot be in the business of pinging every single downstream about every single change individually, in particular if I consider the change unimportant. Sure, that makes sense. To learn about changes upstream, please follow the upstream discussions, thank you. However, this isn’t practical. The 1619! members of the packager group can’t be following every single upstream mailing list of every single project they depend on or they may be affected by. That is why we have http://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages , and why we _need_ that policy; it is not a gratuitous bureaucratic nonsense. Both systemd and Fedora would benefit if this communication were factored out like this, by having a Fedora liaison/“watcher” of systemd¹ that is primarily concerned with needs of Fedora and impact on Fedora. Mirek ¹ The Package maintainer responsibilities document places this on the package maintainers; but this would work equally well if anyone else did this, with or without commit rights to the systemd RPM. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Mon, Feb 23, 2015 at 04:02:50PM -0500, Colin Walters wrote: There are patches waiting in: https://bugzilla.redhat.com/show_bug.cgi?id=1116651 And I think almost every poster so far in this thread has the technical knowledge to review them. Yeah, sorry, I previously looked at the anaconda patch, and they only thing that looked bad was 'except OSError, e' (i.e. python 2.5 syntax). Looking at it again, it might be better to warn and continue if the removal fails. Missing resolv conf is probably not worth breaking installation over. The same applies for the other patch. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/23/2015 05:51 PM, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Feb 23, 2015 at 04:02:50PM -0500, Colin Walters wrote: There are patches waiting in: https://bugzilla.redhat.com/show_bug.cgi?id=1116651 And I think almost every poster so far in this thread has the technical knowledge to review them. Yeah, sorry, I previously looked at the anaconda patch, and they only thing that looked bad was 'except OSError, e' (i.e. python 2.5 syntax). Looking at it again, it might be better to warn and continue if the removal fails. Missing resolv conf is probably not worth breaking installation over. The same applies for the other patch. Zbyszek If this somehow ended up fixing https://bugzilla.redhat.com/show_bug.cgi?id=874806 by making /etc/resolv.conf available before authconfig was run, that would be an added bonus. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20.02.15 16:03, Peter Robinson (pbrobin...@gmail.com) wrote: On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer har...@redhat.com wrote: To prevent surprises on the next systemd updates like in https://bugzilla.redhat.com/show_bug.cgi?id=1116651, we will not apply workarounds anymore in rawhide and track the issues on https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker so, that they are not forgotten. We removed the change for /etc/resolv.conf in F22 again (like in F21), but this time we keep the change for rawhide. Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. There is no news in all of this, I just removed the work-around now, as indicated back then. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? How much time do you think is appropriate for fixing a file copy routine in anaconda? 12 months? 18 months? 2 years? Also, NM fixed a similar issue with /etc/resolve.conf in their code a long time ago, to my knowledge. Am I so misguided to assume that Anaconda can fix a fricking file copy too, in all those months? Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
systemd-219 issues with 22 and Rawhide composes
To prevent surprises on the next systemd updates like in https://bugzilla.redhat.com/show_bug.cgi?id=1116651, we will not apply workarounds anymore in rawhide and track the issues on https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker so, that they are not forgotten. We removed the change for /etc/resolv.conf in F22 again (like in F21), but this time we keep the change for rawhide. Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer har...@redhat.com wrote: To prevent surprises on the next systemd updates like in https://bugzilla.redhat.com/show_bug.cgi?id=1116651, we will not apply workarounds anymore in rawhide and track the issues on https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker so, that they are not forgotten. We removed the change for /etc/resolv.conf in F22 again (like in F21), but this time we keep the change for rawhide. Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015 at 4:11 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:03, Peter Robinson (pbrobin...@gmail.com) wrote: On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer har...@redhat.com wrote: To prevent surprises on the next systemd updates like in https://bugzilla.redhat.com/show_bug.cgi?id=1116651, we will not apply workarounds anymore in rawhide and track the issues on https://bugzilla.redhat.com/show_bug.cgi?id=systemd-other-tracker so, that they are not forgotten. We removed the change for /etc/resolv.conf in F22 again (like in F21), but this time we keep the change for rawhide. Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. Yes, and it looks like it affects dhcpd too... just because you notified one dev team on a single bug it's not the same as a wider announcement to the wider community. There's all sorts of things that this can affect, and while yes it may be a bug in their software, it should be as widely notified as possible. People have priorities that may not be the same as yours. There is no news in all of this, I just removed the work-around now, as indicated back then. Again, I'm not just referring to this single incident, it would be nice if you notified people widely of changes. It's a community, people don't all follow closely the upstream development of all upstream components. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. How much time do you think is appropriate for fixing a file copy routine in anaconda? 12 months? 18 months? 2 years? I'm not just referring to *just* anaconda. This is *one* thing, there's other things that might be broken by this. How long has /etc/resolv.conf been a file in that location? How many things across the distro expect it to be like it is? It's legacy and while I'm not against changing it there may be impact that isn't take into account. Bullying people/process/team just because you've waited 6 months already isn't an appropriate response just because you're impatient and want to move on. We're a community that doesn't revolved around systemd... sorry! Also, NM fixed a similar issue with /etc/resolve.conf in their code a long time ago, to my knowledge. Am I so misguided to assume that Anaconda can fix a fricking file copy too, in all those months? To my knowledge there also looks to be issues with dhcp due to this change as of yesterday so maybe you don't have all the knowledge. What else might be affected in the distro according to your knowledge? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Hi On Fri, Feb 20, 2015 at 11:11 AM, Lennart Poettering wrote: How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? The problem isn't necessarily the speed of change but the amount of caution and attention paid to inform folks affected by such changes. It is a fairly simple change in this case but it affects more than just one component and not everyone is aware of the details in the first place. A simple announcement here or fedora devel announce list would go a long way. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. Yes, and it looks like it affects dhcpd too... just because you notified one dev team on a single bug it's not the same as a wider announcement to the wider community. There's all sorts of things that this can affect, and while yes it may be a bug in their software, it should be as widely notified as possible. People have priorities that may not be the same as yours. Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). There is no news in all of this, I just removed the work-around now, as indicated back then. Again, I'm not just referring to this single incident, it would be nice if you notified people widely of changes. It's a community, people don't all follow closely the upstream development of all upstream components. Ok, then please list all those numerous incidents please. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. OK, got it, will let everybody know now of changes 5 years in advance. Would that suit your needs? Not what I'm saying at all. There's no need to throw toys to the extreme just because someone is asking for a certain level of reason and engagement. Anyway, I have the suspicion you just want to make a fuss, and this is where it ends for me hence. Nope, I don't, I just want engagement, generally and overall I'm actively positive for systemd and a big advocate for it. You just need to engage in the community and if something isn't done in six months because another team has other priorities and other deadlines and people push back because it's actually breaking other areas of the distribution there's no need to throw toys from the pram and storm off. It's a large distro of moving parts and we need flexibility as a result, things get pushed due to delays. It's not the end of the world! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20.02.15 11:07, Dennis Gilmore (den...@ausil.us) wrote: On Fri, 20 Feb 2015 11:04:13 -0600 Dennis Gilmore den...@ausil.us wrote: On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release I should add that changing it broke the compose process and was quickly fixed. wider communication means that other effected components have some visibility into things that may effect them. You cannot really blame me for breakages for things I neither asked for nor was involved with at all in Fedora. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On 02/20/2015 05:11 PM, Lennart Poettering wrote: Also, NM fixed a similar issue with /etc/resolve.conf in their code a long time ago, to my knowledge. Am I so misguided to assume that Anaconda can fix a fricking file copy too, in all those months? Maybe it is time to step back and consider if replacing /etc/resolv.conf with a symbolic link is something that can be reasonably implemented from a backwards compatibility perspective? Usually, if we face this much trouble within Fedora itself, it's a good indicator of the pain that we'll have to deal with downstream. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015 at 04:52:20PM +, Peter Robinson wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. Yes, and it looks like it affects dhcpd too... just because you notified one dev team on a single bug it's not the same as a wider announcement to the wider community. There's all sorts of things that this can affect, and while yes it may be a bug in their software, it should be as widely notified as possible. People have priorities that may not be the same as yours. Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). There is no news in all of this, I just removed the work-around now, as indicated back then. Again, I'm not just referring to this single incident, it would be nice if you notified people widely of changes. It's a community, people don't all follow closely the upstream development of all upstream components. Ok, then please list all those numerous incidents please. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. OK, got it, will let everybody know now of changes 5 years in advance. Would that suit your needs? Not what I'm saying at all. There's no need to throw toys to the extreme just because someone is asking for a certain level of reason and engagement. Anyway, I have the suspicion you just want to make a fuss, and this is where it ends for me hence. Nope, I don't, I just want engagement, generally and overall I'm actively positive for systemd and a big advocate for it. You just need to engage in the community and if something isn't done in six months because another team has other priorities and other deadlines and people push back because it's actually breaking other areas of the distribution there's no need to throw toys from the pram and storm off. It's a large distro of moving parts and we need flexibility as a result, things get pushed due to delays. It's not the end of the world! I think we can do better than this level of communication. Yes, it would have been good to avoid a surprise here. There are issues on both sides. Blaming the situation on either impatience or sloth doesn't do any justice to the good efforts everyone makes. On one side, it may not be reasonable to expect that all teams track or follow up on every bug. It's right to expect some explicit notice and, more importantly, collaboration across teams -- talking to each other, not just filing a bug without clear expectations. On the other hand, Fedora is supposed to be innovative and we need to take a positive approach to change. When teams see a change coming up they know will cause them work or breakage, they can proactively reach out to engage. In fact, anyone can facilitate such a conversation. Also, a side note: A book I read on communication in relationships once (I think it was That's Not What I Meant by Deborah Tannen) said that when one universalizes statements, e.g. you usually do X or you always do Y, it's unlikely to yield any positive results in a discussion. I've seen nothing in open source communication that gives evidence to the contrary. :-) The important thing is that we try to deal constructively with this specific situation, and in learning from it, we can mitigate similar situations in the future. -- Paul W. Frields pfrie...@redhat.com Manager, Fedora Engineering - Emerging Platform http://redhat.com -- http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 2015-02-20 at 17:43 +0100, Florian Weimer wrote: On 02/20/2015 05:11 PM, Lennart Poettering wrote: Also, NM fixed a similar issue with /etc/resolve.conf in their code a long time ago, to my knowledge. Am I so misguided to assume that Anaconda can fix a fricking file copy too, in all those months? Maybe it is time to step back and consider if replacing /etc/resolv.conf with a symbolic link is something that can be reasonably implemented from a backwards compatibility perspective? Usually, if we face this much trouble within Fedora itself, it's a good indicator of the pain that we'll have to deal with downstream. I would love to know the outcome of this discussion, since we just made a change to NetworkManager git master (will be version 1.2, target Fedora 23) to make /etc/resolv.conf a symlink when it's under NM's control. If there are problems here, we want to know too. * NM won't replace a symlinked /etc/resolv.conf that doesn't point to NM's copy in /var * You can disable this behavior with dns=none in /etc/NetworkManager/NetworkManager.conf and manage resolv.conf on your own too Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20 Feb 2015 11:04:13 -0600 Dennis Gilmore den...@ausil.us wrote: On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release I should add that changing it broke the compose process and was quickly fixed. wider communication means that other effected components have some visibility into things that may effect them. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20.02.15 11:04, Dennis Gilmore (den...@ausil.us) wrote: On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release While moving it is great, it's not really that important to move it. I mean, moving it is useful in the context of stateless systems that can boot up with empty /etc. However, Fedora is so far away from that, that we have tons of other things to fix first, before the os-release move would start to matter. We haven't posted a feature to make Fedora stateless in this sense, and hence also didn't ask for /etc/os-release to be moved. There are some upstream things to work on before we can propose such a Fedora change. So, thank you very much for moving it! But this is neither a change that would really need coordination, nor something we pushed for from our side. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? The folks in question knew I would drop the patch. In the original bug I even said I would remove the work-around from systemd.rpm after TC1 of the last cycle. I was nice, left it in for the whole cycle, only dropped it now. Yes, and it looks like it affects dhcpd too... just because you notified one dev team on a single bug it's not the same as a wider announcement to the wider community. There's all sorts of things that this can affect, and while yes it may be a bug in their software, it should be as widely notified as possible. People have priorities that may not be the same as yours. Hey! Come on. Everything that systemd does is create a symlink for /etc/resolv.conf if nothing else has created on for that. If something else created and owned that file, it leaves the thing alone. That's all. It's very defensively written. Anaconda's file copy routine tripped up on it though, since it follows symlinks on the destination (which is a really bad idea, and needs to be fixed). There is no news in all of this, I just removed the work-around now, as indicated back then. Again, I'm not just referring to this single incident, it would be nice if you notified people widely of changes. It's a community, people don't all follow closely the upstream development of all upstream components. Ok, then please list all those numerous incidents please. How many months would you like me to notify people in advance of a simple change like this? Isn't 6 month *ample* time? Likely not, not everyone has the same schedule as upstream systemd, in a lot of cases they don't know it's broken until things land and teams have other priorities. OK, got it, will let everybody know now of changes 5 years in advance. Would that suit your needs? Anyway, I have the suspicion you just want to make a fuss, and this is where it ends for me hence. Good night, Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20 Feb 2015 18:11:38 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 11:04, Dennis Gilmore (den...@ausil.us) wrote: On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release While moving it is great, it's not really that important to move it. I mean, moving it is useful in the context of stateless systems that can boot up with empty /etc. However, Fedora is so far away from that, that we have tons of other things to fix first, before the os-release move would start to matter. We haven't posted a feature to make Fedora stateless in this sense, and hence also didn't ask for /etc/os-release to be moved. There are some upstream things to work on before we can propose such a Fedora change. So, thank you very much for moving it! But this is neither a change that would really need coordination, nor something we pushed for from our side. communication would have avoided some of the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1149568 and likely avoided having the bug altogether. regardless of your reasons for making a change or how unimportant you consider it, others follow things that are done and follow up on them when you do not. I for one would appreciate knowing when the allowable fields change in os-release because the first I ever hear is when people file bugs asking for them to be added to Fedora. I then have to chase things down to catch up. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, Feb 20, 2015, at 12:48 PM, Dennis Gilmore wrote: communication would have avoided some of the discussion in https://bugzilla.redhat.com/show_bug.cgi?id=1149568 Which btw, caused https://bugzilla.redhat.com/show_bug.cgi?id=1192276 Could you review? I'm fixing this in OSTree too, https://github.com/GNOME/ostree/pull/59 but it'd be nice to fix it two ways, and relative symlinks are generally nicer than absolute. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-219 issues with 22 and Rawhide composes
On Fri, 20 Feb 2015 18:12:29 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 11:07, Dennis Gilmore (den...@ausil.us) wrote: On Fri, 20 Feb 2015 11:04:13 -0600 Dennis Gilmore den...@ausil.us wrote: On Fri, 20 Feb 2015 17:36:17 +0100 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote: Sorry for the inconvenience and feel free to add bugs to the tracker, which are caused by systemd changes and have to be fixed in other components. Are you going to start notifying deve@ of upcoming changes that may impact other areas of the distro too rather than just land them without notification or discussion? Oh god, stop this, will you? No, I mean the above in general for general changes you make that affect the distro as a whole. You generally land them without notification. I generally do that? Can you be more precise? A recent example, systemd decided that os-release needed to be moved to /usr/lib/ I did not see any notification on devel@ nor was i contacted directly. the first I heard of it was a third party person filing a bug against fedora-release I should add that changing it broke the compose process and was quickly fixed. wider communication means that other effected components have some visibility into things that may effect them. You cannot really blame me for breakages for things I neither asked for nor was involved with at all in Fedora. Lennart I am not blaming you for anything here, merely pointing out that if there was better communications we could have likely avoided the breakage while the change was made altogether. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
