Re: urw-base35-fonts package missing from f30 and rawhide composes

[Fabio Valentini]

On Sun, Apr 14, 2019 at 5:58 PM Kevin Fenzi  wrote:
>
> This was due to a releng PR I merged yesterday to the script that blocks
> retired packages. ;(
>
> It blocked a bunch of things that are in a weird state (which we should
> totally fix), including that fonts package and all our images. :)

Whoops :)

> I've reverted the PR merge and unblocked all the packages.
> Things should return to normal in a bit here.
>
> Sorry for the troubles...
>
> kevin

No problem, thanks for fixing it!

Fabio

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: urw-base35-fonts package missing from f30 and rawhide composes

[Kevin Fenzi]

This was due to a releng PR I merged yesterday to the script that blocks
retired packages. ;(

It blocked a bunch of things that are in a weird state (which we should
totally fix), including that fonts package and all our images. :)

I've reverted the PR merge and unblocked all the packages.
Things should return to normal in a bit here.

Sorry for the troubles...

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: urw-base35-fonts package missing from f30 and rawhide composes

[Steven A. Falco]

On 4/14/19 10:42 AM, Fabio Valentini wrote:
> On Sun, Apr 14, 2019 at 4:03 PM Fabio Valentini  wrote:
>>
>> Hi everybody,
>>
>> I've noticed today that several of my packages are starting to fail to
>> build in koschei due to missing dependencies - on urw-base35-fonts.
>> Attempting fedpkg scratch builds in koji confirmed the issue.
>>
>> For example:
>>
>> Problem: package doxygen-1:1.8.15-9.fc31.x86_64 requires graphviz, but
>> none of the providers can be installed
>> - conflicting requests
>> - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
>>
>> The same issue makes inkscape and some other packages uninstallable on
>> fedora 30 and rawhide.
>>
>> I've looked at koji, src.fp.org, and the compose report e-mails, but
>> didn't see anything obvious happen to the urw-base35-fonts package,
>> but it seems to be missing from the latest rawhide and f30 composes
>> for some reason.
>>
>> Fabio
> 
> Looking at the koschei status, ~2000 of all ~13000 tracked source
> packages are now reported as un-buildable due to this - and this
> doesn't include the number of un-installable packages.
> 
> Just saying.

I just built KiCad, which uses doxygen, via mock on my local machine.  The 
build was fine.

I'm also building KiCad via Copr, and Copr was able to install doxygen, so I 
expect that build to be fine.

However, I also tried to build via koji, and that one fails with essentially 
the same error that you reported:

Error: 
 Problem 1: package doxygen-1:1.8.15-9.fc31.x86_64 requires graphviz, but none 
of the providers can be installed
  - conflicting requests
  - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
 Problem 2: package asciidoc-8.6.10-0.9.20180605git986f99d.fc30.noarch requires 
graphviz, but none of the providers can be installed
  - conflicting requests
  - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Summary:

mock build - pass
copr build - pass
koji build - fail

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: urw-base35-fonts package missing from f30 and rawhide composes

[Fabio Valentini]

On Sun, Apr 14, 2019 at 4:03 PM Fabio Valentini  wrote:
>
> Hi everybody,
>
> I've noticed today that several of my packages are starting to fail to
> build in koschei due to missing dependencies - on urw-base35-fonts.
> Attempting fedpkg scratch builds in koji confirmed the issue.
>
> For example:
>
> Problem: package doxygen-1:1.8.15-9.fc31.x86_64 requires graphviz, but
> none of the providers can be installed
> - conflicting requests
> - nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64
>
> The same issue makes inkscape and some other packages uninstallable on
> fedora 30 and rawhide.
>
> I've looked at koji, src.fp.org, and the compose report e-mails, but
> didn't see anything obvious happen to the urw-base35-fonts package,
> but it seems to be missing from the latest rawhide and f30 composes
> for some reason.
>
> Fabio

Looking at the koschei status, ~2000 of all ~13000 tracked source
packages are now reported as un-buildable due to this - and this
doesn't include the number of un-installable packages.

Just saying.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

urw-base35-fonts package missing from f30 and rawhide composes

[Fabio Valentini]

Hi everybody,

I've noticed today that several of my packages are starting to fail to
build in koschei due to missing dependencies - on urw-base35-fonts.
Attempting fedpkg scratch builds in koji confirmed the issue.

For example:

Problem: package doxygen-1:1.8.15-9.fc31.x86_64 requires graphviz, but
none of the providers can be installed
- conflicting requests
- nothing provides urw-base35-fonts needed by graphviz-2.40.1-44.fc31.x86_64

The same issue makes inkscape and some other packages uninstallable on
fedora 30 and rawhide.

I've looked at koji, src.fp.org, and the compose report e-mails, but
didn't see anything obvious happen to the urw-base35-fonts package,
but it seems to be missing from the latest rawhide and f30 composes
for some reason.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Adam Williamson]

On Wed, 2017-06-14 at 16:43 +0100, Peter Robinson wrote:
> 
> Yes, I'm well aware of the plans but it doesn't help us now. There was
> over 3500 package updates in the compose, it shows how quickly we got
> behind.

FWIW I really see this as a resource/priority problem, not a process
problem. We just don't have enough people to care about everything all
at once; when there are other emergencies, 'Rawhide didn't compose'
tends to get kicked down the priority list. If we had someone whose
main job was to care about Rawhide, then that person would jump on it
the moment any Rawhide compose failed. Instead what tends to happen is
that multiple problems build up because we don't have enough person-
time to really roll the trucks every time Rawhide fails to compose, so
we wind up with six different things to fix when we eventually do get
to fixing it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Martin Kolman]

On Wed, 2017-06-14 at 14:58 +0100, Daniel P. Berrange wrote:
> On Tue, Jun 13, 2017 at 07:11:21AM -0600, Kevin Fenzi wrote:
> > Greetings.
> > 
> > Some folks may have noticed that there have been no completed
> > rawhide
> > composes in a while (13 days as of today).
> > 
> > This has been due to a variety of bugs and issues, along with pungi
> > now
> > failing composes that don't have all required release blocking
> > items.
> > 
> > Here's a partial list:
> > 
> > 2017-06-01 - lorax traceback, bug 1457055
> > 2017-06-02 - another lorax issue, bug 1457906
> > 2017-06-03 - cloud base failed in anaconda, bug 1458509
> > 2017-06-04 - ditto
> > 2017-06-05 - ditto
> > 2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
> > 2017-06-07 - ditto
> > 2017-06-08 - ditto
> > 2017-06-09 - ditto
> > 2017-06-10 - ditto
> > 2017-06-11 - ditto
> > 2017-06-12 - ditto
> > 2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in
> > metacity
> > that failed the comppose. I fixed those (and control-center) last
> > night.
> > 2017-06-13 - still running, cross your fingers.
> 
> [snip]
> 
> > Anyhow, hopefully we will have a rawhide compose today, and if not
> > I
> > will keep poking it to get it going...
> 
> Unfortunately while the latest compose succeeded, actually trying to
> use the installer resulted in a python traceback pretty much
> immediately
> 
>https://bugzilla.redhat.com/show_bug.cgi?id=1461469
Should be fixed once anaconda-27.13-1 hits a compose.

Best Wishes
Martin Kolman

> 
> Regards,
> Daniel
> -- 
> > : https://berrange.com  
> > -o-https://www.flickr.com/photos/dberrange :|
> > : https://libvirt.org 
> > -o-https://fstop138.berrange.com :|
> > : https://entangle-photo.org
> > -o-https://www.instagram.com/dberrange :|
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/14/2017 10:00 AM, Jonathan Dieter wrote:
> On Wed, 2017-06-14 at 09:36 -0600, Kevin Fenzi wrote:
>> * Composes are really slow (likely related to storage slowness), if they
>> were faster or could fail faster we could untag/fix/iterate more. Right
>> now we are lucky to get 2 chances a day.
> 
> When you're mentioning storage slowness, are we talking a distributed
> filesystem?  If so, is this an issue with metadata lookups being slow
> or is it slow data access?

Nope, it's storage provided by our primary sponsor (Red Hat) via netapp.
I'm working with them to try and track down what the issue is...
starting around may or so things just got slower and we have not yet
been able to tell why. ;(
> The only reason I ask is that we switched over to LizardFS because its
> metadata lookups were *much* faster than what I'd seen from any of the
> alternatives.

Good to know. ;)

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/14/2017 04:16 AM, Martin Kolman wrote:

> I agree with that - for example the Anaconda installer CI broke due to
> a rawhide package change in the last "working" compose. There is a
> fixed package available and built in Koji, but it's not reaching the
> Rawhide repos due to the broken composes. In this case we can fix the
> CI by using a COPR build of the package, but in other cases it could be
> more difficult.
> 
> BTW, when was the change to only release packages to repositories once
> a compose succeeds introduced ? I kinda always thought packages go to
> the Rawhide repos almost immediately - mirroring machinery permitting.

Rawhide has always been a daily compose of things that built in the last
day.

I'm not sure when the change to fail composes when blocking deliverables
failed landed. I want to say the Beginning of may, but I could be wrong.
Dennis should know more..

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Jonathan Dieter]

On Wed, 2017-06-14 at 09:36 -0600, Kevin Fenzi wrote:
> * Composes are really slow (likely related to storage slowness), if they
> were faster or could fail faster we could untag/fix/iterate more. Right
> now we are lucky to get 2 chances a day.

When you're mentioning storage slowness, are we talking a distributed
filesystem?  If so, is this an issue with metadata lookups being slow
or is it slow data access?

The only reason I ask is that we switched over to LizardFS because its
metadata lookups were *much* faster than what I'd seen from any of the
alternatives.

Jonathan

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Peter Robinson]

On Wed, Jun 14, 2017 at 4:36 PM, Kevin Fenzi  wrote:
> On 06/13/2017 03:47 PM, Peter Robinson wrote:
>>
>> For actual artifacts such as cloud/disk/installer images I agree but
>> at least pushing out individual packages so people can do "dnf
>> upgrade" picks up issues such as dependency issues that also kill the
>> compose and allows people to still test explicit parts and have the
>> composite parts of a "rolling release" and get things fixed I feel
>> that's better than dragging everything to a blinding halt like we have
>> for the last 13... or is it 14 days?
>
> Perhaps so. Note that I personally have been updating from the koji
> repo, but I know that has some limitations (no multiarch, etc).
>
>> I can't help but feel this is like British politics is ATM where
>> people are claiming everything is "strong and stable" while the wheels
>> have fallen off and are rolling down the road. I don't think pushing
>> out the Everything repo stops the "kill off Alpha" process from
>> happening, in fact I believe it means it's more likely to happen
>> because if the last two weeks shows anything all that happens is that
>> if we wait for a "everything is perfect ship it" we never will and
>> because nothing is shipped nothing is tested so once we get to the
>> "computer thinks it's good" we can get to the actual testing and then
>> we get to "what the hell changed in the last two weeks broke X, Y and
>> Z, are they related or completely independent?" process.
>>
>> I think the all or nothing actually makes it less likely for us to
>> ever ship anything! I don't think shipping the traditional
>> "Everything" repo breaks the "kill Alpha" proposal, I think we need to
>> be pragmatic and realise that people actually consuming content helps
>> that.
>>
>> Peter "yes I live in the as strong and stable as a house of cards
>> country so I can joke/comment on it" R
>
> Well, I am not even an owner of that Change, so I will leave it to Adam
> and Dennis to chime in on the no alpha part.
>
> I do think now that we do have a compose that worked we are in a better
> place and can now do what Colin was suggesting (If something fails now,
> just untag the offending thing and file a bug on it and recompose).
>
> There's definitely tons of room for improvement all around here including:
>
> * Composes are really slow (likely related to storage slowness), if they
> were faster or could fail faster we could untag/fix/iterate more. Right
> now we are lucky to get 2 chances a day.
>
> * There's plans pretty far along to 'pre test' base stuff with test
> composes, that should help a lot. ie, new anaconda or lorax or whatever
> arrives, a test compose is done and openqa tests it. If it fails we know
> we can't use that in the main compose.

Yes, I'm well aware of the plans but it doesn't help us now. There was
over 3500 package updates in the compose, it shows how quickly we got
behind.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/13/2017 03:47 PM, Peter Robinson wrote:
>
> For actual artifacts such as cloud/disk/installer images I agree but
> at least pushing out individual packages so people can do "dnf
> upgrade" picks up issues such as dependency issues that also kill the
> compose and allows people to still test explicit parts and have the
> composite parts of a "rolling release" and get things fixed I feel
> that's better than dragging everything to a blinding halt like we have
> for the last 13... or is it 14 days?

Perhaps so. Note that I personally have been updating from the koji
repo, but I know that has some limitations (no multiarch, etc).

> I can't help but feel this is like British politics is ATM where
> people are claiming everything is "strong and stable" while the wheels
> have fallen off and are rolling down the road. I don't think pushing
> out the Everything repo stops the "kill off Alpha" process from
> happening, in fact I believe it means it's more likely to happen
> because if the last two weeks shows anything all that happens is that
> if we wait for a "everything is perfect ship it" we never will and
> because nothing is shipped nothing is tested so once we get to the
> "computer thinks it's good" we can get to the actual testing and then
> we get to "what the hell changed in the last two weeks broke X, Y and
> Z, are they related or completely independent?" process.
> 
> I think the all or nothing actually makes it less likely for us to
> ever ship anything! I don't think shipping the traditional
> "Everything" repo breaks the "kill Alpha" proposal, I think we need to
> be pragmatic and realise that people actually consuming content helps
> that.
> 
> Peter "yes I live in the as strong and stable as a house of cards
> country so I can joke/comment on it" R

Well, I am not even an owner of that Change, so I will leave it to Adam
and Dennis to chime in on the no alpha part.

I do think now that we do have a compose that worked we are in a better
place and can now do what Colin was suggesting (If something fails now,
just untag the offending thing and file a bug on it and recompose).

There's definitely tons of room for improvement all around here including:

* Composes are really slow (likely related to storage slowness), if they
were faster or could fail faster we could untag/fix/iterate more. Right
now we are lucky to get 2 chances a day.

* There's plans pretty far along to 'pre test' base stuff with test
composes, that should help a lot. ie, new anaconda or lorax or whatever
arrives, a test compose is done and openqa tests it. If it fails we know
we can't use that in the main compose.

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Daniel P. Berrange]

On Tue, Jun 13, 2017 at 07:11:21AM -0600, Kevin Fenzi wrote:
> Greetings.
> 
> Some folks may have noticed that there have been no completed rawhide
> composes in a while (13 days as of today).
> 
> This has been due to a variety of bugs and issues, along with pungi now
> failing composes that don't have all required release blocking items.
> 
> Here's a partial list:
> 
> 2017-06-01 - lorax traceback, bug 1457055
> 2017-06-02 - another lorax issue, bug 1457906
> 2017-06-03 - cloud base failed in anaconda, bug 1458509
> 2017-06-04 - ditto
> 2017-06-05 - ditto
> 2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
> 2017-06-07 - ditto
> 2017-06-08 - ditto
> 2017-06-09 - ditto
> 2017-06-10 - ditto
> 2017-06-11 - ditto
> 2017-06-12 - ditto
> 2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
> that failed the comppose. I fixed those (and control-center) last night.
> 2017-06-13 - still running, cross your fingers.

[snip]

> Anyhow, hopefully we will have a rawhide compose today, and if not I
> will keep poking it to get it going...

Unfortunately while the latest compose succeeded, actually trying to
use the installer resulted in a python traceback pretty much immediately

   https://bugzilla.redhat.com/show_bug.cgi?id=1461469

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Martin Kolman]

On Tue, 2017-06-13 at 22:47 +0100, Peter Robinson wrote:
> > > > > Greetings.
> > > > > 
> > > > > Some folks may have noticed that there have been no completed
> > > > > rawhide
> > > > > composes in a while (13 days as of today).
> > > > > 
> > > > > This has been due to a variety of bugs and issues, along with
> > > > > pungi now
> > > > > failing composes that don't have all required release
> > > > > blocking items.
> > > > 
> > > > Is there a way we can loosen that up for rawhide and have it
> > > > tightened
> > > > down for branched. I think it's worth while to have at least a
> > > > flow of
> > > > the everything repository out on a regular basis like the old
> > > > pre
> > > > pungi-4 use to do.
> > > 
> > > Possibly yes. But I think the idea was to do it for rawhide as
> > > well and
> > > thus always be at least "Alpha" quality so we could not do alpha
> > > anymore.
> > 
> > That was my take on the "no more alphas". If we can't do this then
> > we
> > are going to have to look at doing an alpha in the schedule because
> > it
> > is clear we aren't able to stabilize enough for that promise to
> > exist.
> 
> For actual artifacts such as cloud/disk/installer images I agree but
> at least pushing out individual packages so people can do "dnf
> upgrade" picks up issues such as dependency issues that also kill the
> compose and allows people to still test explicit parts and have the
> composite parts of a "rolling release" and get things fixed I
> feel
> that's better than dragging everything to a blinding halt like we
> have
> for the last 13... or is it 14 days?
> 
> I can't help but feel this is like British politics is ATM where
> people are claiming everything is "strong and stable" while the
> wheels
> have fallen off and are rolling down the road. I don't think pushing
> out the Everything repo stops the "kill off Alpha" process from
> happening, in fact I believe it means it's more likely to happen
> because if the last two weeks shows anything all that happens is that
> if we wait for a "everything is perfect ship it" we never will and
> because nothing is shipped nothing is tested
I agree with that - for example the Anaconda installer CI broke due to
a rawhide package change in the last "working" compose. There is a
fixed package available and built in Koji, but it's not reaching the
Rawhide repos due to the broken composes. In this case we can fix the
CI by using a COPR build of the package, but in other cases it could be
more difficult.

BTW, when was the change to only release packages to repositories once
a compose succeeds introduced ? I kinda always thought packages go to
the Rawhide repos almost immediately - mirroring machinery permitting.


>  so once we get to the
> "computer thinks it's good" we can get to the actual testing and then
> we get to "what the hell changed in the last two weeks broke X, Y and
> Z, are they related or completely independent?" process.
> 
> I think the all or nothing actually makes it less likely for us to
> ever ship anything! I don't think shipping the traditional
> "Everything" repo breaks the "kill Alpha" proposal, I think we need
> to
> be pragmatic and realise that people actually consuming content helps
> that.
> 
> Peter "yes I live in the as strong and stable as a house of cards
> country so I can joke/comment on it" R
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Matthew Miller]

On Tue, Jun 13, 2017 at 03:31:37PM -0600, Kevin Fenzi wrote:
> > I know we're already at new-deliverable explosion, but this seems like
> > a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
> > want to call "tested and believed-to-be basically functional Rawhide").
> (Side note: I am not sure why we can't just make these the same thing...
> ie, always have rawhide basically functional).

Well... I guess because the reason it isn't functional right now is
non-trivial?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Peter Robinson]

>>>> Greetings.
>>>>
>>>> Some folks may have noticed that there have been no completed rawhide
>>>> composes in a while (13 days as of today).
>>>>
>>>> This has been due to a variety of bugs and issues, along with pungi now
>>>> failing composes that don't have all required release blocking items.
>>>
>>> Is there a way we can loosen that up for rawhide and have it tightened
>>> down for branched. I think it's worth while to have at least a flow of
>>> the everything repository out on a regular basis like the old pre
>>> pungi-4 use to do.
>>
>> Possibly yes. But I think the idea was to do it for rawhide as well and
>> thus always be at least "Alpha" quality so we could not do alpha anymore.
>
> That was my take on the "no more alphas". If we can't do this then we
> are going to have to look at doing an alpha in the schedule because it
> is clear we aren't able to stabilize enough for that promise to exist.

For actual artifacts such as cloud/disk/installer images I agree but
at least pushing out individual packages so people can do "dnf
upgrade" picks up issues such as dependency issues that also kill the
compose and allows people to still test explicit parts and have the
composite parts of a "rolling release" and get things fixed I feel
that's better than dragging everything to a blinding halt like we have
for the last 13... or is it 14 days?

I can't help but feel this is like British politics is ATM where
people are claiming everything is "strong and stable" while the wheels
have fallen off and are rolling down the road. I don't think pushing
out the Everything repo stops the "kill off Alpha" process from
happening, in fact I believe it means it's more likely to happen
because if the last two weeks shows anything all that happens is that
if we wait for a "everything is perfect ship it" we never will and
because nothing is shipped nothing is tested so once we get to the
"computer thinks it's good" we can get to the actual testing and then
we get to "what the hell changed in the last two weeks broke X, Y and
Z, are they related or completely independent?" process.

I think the all or nothing actually makes it less likely for us to
ever ship anything! I don't think shipping the traditional
"Everything" repo breaks the "kill Alpha" proposal, I think we need to
be pragmatic and realise that people actually consuming content helps
that.

Peter "yes I live in the as strong and stable as a house of cards
country so I can joke/comment on it" R
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Stephen John Smoogen]

On 13 June 2017 at 17:28, Kevin Fenzi  wrote:
> On 06/13/2017 08:10 AM, Peter Robinson wrote:
>> On Tue, Jun 13, 2017 at 2:11 PM, Kevin Fenzi  wrote:
>>> Greetings.
>>>
>>> Some folks may have noticed that there have been no completed rawhide
>>> composes in a while (13 days as of today).
>>>
>>> This has been due to a variety of bugs and issues, along with pungi now
>>> failing composes that don't have all required release blocking items.
>>
>> Is there a way we can loosen that up for rawhide and have it tightened
>> down for branched. I think it's worth while to have at least a flow of
>> the everything repository out on a regular basis like the old pre
>> pungi-4 use to do.
>
> Possibly yes. But I think the idea was to do it for rawhide as well and
> thus always be at least "Alpha" quality so we could not do alpha anymore.

That was my take on the "no more alphas". If we can't do this then we
are going to have to look at doing an alpha in the schedule because it
is clear we aren't able to stabilize enough for that promise to exist.

> kevin
>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/13/2017 08:43 AM, Matthew Miller wrote:
> On Tue, Jun 13, 2017 at 03:10:58PM +0100, Peter Robinson wrote:
>>> This has been due to a variety of bugs and issues, along with pungi now
>>> failing composes that don't have all required release blocking items.
>>
>> Is there a way we can loosen that up for rawhide and have it tightened
>> down for branched. I think it's worth while to have at least a flow of
>> the everything repository out on a regular basis like the old pre
>> pungi-4 use to do.
> 
> I know we're already at new-deliverable explosion, but this seems like
> a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
> want to call "tested and believed-to-be basically functional Rawhide").

(Side note: I am not sure why we can't just make these the same thing...
ie, always have rawhide basically functional).

> That doesn't seem imminent, though, so Peter's suggestion seems
> reasonable. Then maybe we could ask Jan as FPgM to keep track of what's
> working and what's broken and help make sure the right people are on
> it.

Well, it's sometimes not easy to tell where something is broken, it
takes a human to look and dig around and see where the failure is.

Example: Today's rawhide compose I had hopes for failed.

Turns out it was a koji bug we already fixed and we didn't hit it
yesterday because we didn't have the same fixed koji version on all the
builders. It took me and Patrick a while to track down what was
happening there. There's also another compose running now. Fingers
crossed. :)

kevin






signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

On 06/13/2017 08:10 AM, Peter Robinson wrote:
> On Tue, Jun 13, 2017 at 2:11 PM, Kevin Fenzi  wrote:
>> Greetings.
>>
>> Some folks may have noticed that there have been no completed rawhide
>> composes in a while (13 days as of today).
>>
>> This has been due to a variety of bugs and issues, along with pungi now
>> failing composes that don't have all required release blocking items.
> 
> Is there a way we can loosen that up for rawhide and have it tightened
> down for branched. I think it's worth while to have at least a flow of
> the everything repository out on a regular basis like the old pre
> pungi-4 use to do.

Possibly yes. But I think the idea was to do it for rawhide as well and
thus always be at least "Alpha" quality so we could not do alpha anymore.

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Kaleb S. KEITHLEY]

You keep using that word — where for [sic] — I do not think it means 
what you think it means. (As inconceivable as it may seem.)


--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Colin Walters]

On Tue, Jun 13, 2017, at 10:43 AM, Matthew Miller wrote:

> I know we're already at new-deliverable explosion, but this seems like
> a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
> want to call "tested and believed-to-be basically functional Rawhide").
> That doesn't seem imminent, though, so Peter's suggestion seems
> reasonable. Then maybe we could ask Jan as FPgM to keep track of what's
> working and what's broken and help make sure the right people are on
> it.

An alternative to creating *even more* streams is to *revert* broken
things in existing streams.  lorax didn't work on arm?   Revert, don't
just file a bugzilla and have everyone sitting around wait for a patch.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Matthew Miller]

On Tue, Jun 13, 2017 at 03:10:58PM +0100, Peter Robinson wrote:
> > This has been due to a variety of bugs and issues, along with pungi now
> > failing composes that don't have all required release blocking items.
> 
> Is there a way we can loosen that up for rawhide and have it tightened
> down for branched. I think it's worth while to have at least a flow of
> the everything repository out on a regular basis like the old pre
> pungi-4 use to do.

I know we're already at new-deliverable explosion, but this seems like
a place where it'd be nice to have Rawhide and Bikeshed (or whatever we
want to call "tested and believed-to-be basically functional Rawhide").
That doesn't seem imminent, though, so Peter's suggestion seems
reasonable. Then maybe we could ask Jan as FPgM to keep track of what's
working and what's broken and help make sure the right people are on
it.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Peter Robinson]

On Tue, Jun 13, 2017 at 2:11 PM, Kevin Fenzi  wrote:
> Greetings.
>
> Some folks may have noticed that there have been no completed rawhide
> composes in a while (13 days as of today).
>
> This has been due to a variety of bugs and issues, along with pungi now
> failing composes that don't have all required release blocking items.

Is there a way we can loosen that up for rawhide and have it tightened
down for branched. I think it's worth while to have at least a flow of
the everything repository out on a regular basis like the old pre
pungi-4 use to do.

> Here's a partial list:
>
> 2017-06-01 - lorax traceback, bug 1457055
> 2017-06-02 - another lorax issue, bug 1457906
> 2017-06-03 - cloud base failed in anaconda, bug 1458509
> 2017-06-04 - ditto
> 2017-06-05 - ditto
> 2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
> 2017-06-07 - ditto
> 2017-06-08 - ditto
> 2017-06-09 - ditto
> 2017-06-10 - ditto
> 2017-06-11 - ditto
> 2017-06-12 - ditto
> 2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
> that failed the comppose. I fixed those (and control-center) last night.
> 2017-06-13 - still running, cross your fingers.
>
> All of this has been made a bit worse by us having some storage slowness
> which means you can really only do about 2 rawhide compose attempts a
> day. Thats being worked on and hopefully we will get it fixed soon.
>
> You can also see here there were some gaps where we didn't yet have the
> bug tracked down or didn't yet have a fix in place. We need to try and
> do better there. (I was out on vacation last week, so it can't always be
> me).
>
> Anyhow, hopefully we will have a rawhide compose today, and if not I
> will keep poking it to get it going...
>
> kevin
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Rawhide: where for art thou? (why no rawhide composes recently)

[Kevin Fenzi]

Greetings.

Some folks may have noticed that there have been no completed rawhide
composes in a while (13 days as of today).

This has been due to a variety of bugs and issues, along with pungi now
failing composes that don't have all required release blocking items.

Here's a partial list:

2017-06-01 - lorax traceback, bug 1457055
2017-06-02 - another lorax issue, bug 1457906
2017-06-03 - cloud base failed in anaconda, bug 1458509
2017-06-04 - ditto
2017-06-05 - ditto
2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
2017-06-07 - ditto
2017-06-08 - ditto
2017-06-09 - ditto
2017-06-10 - ditto
2017-06-11 - ditto
2017-06-12 - ditto
2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
that failed the comppose. I fixed those (and control-center) last night.
2017-06-13 - still running, cross your fingers.

All of this has been made a bit worse by us having some storage slowness
which means you can really only do about 2 rawhide compose attempts a
day. Thats being worked on and hopefully we will get it fixed soon.

You can also see here there were some gaps where we didn't yet have the
bug tracked down or didn't yet have a fix in place. We need to try and
do better there. (I was out on vacation last week, so it can't always be
me).

Anyhow, hopefully we will have a rawhide compose today, and if not I
will keep poking it to get it going...

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd-219 issues with 22 and Rawhide composes

[Kevin Fenzi]

On Mon, 2 Mar 2015 08:42:25 -0800
"Brian C. Lane"  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

[Dan Williams]

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
> > >  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

[Brian C. Lane]

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
> >  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

[Zbigniew Jędrzejewski-Szmek]

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
>  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

[Jóhann B. Guðmundsson]

On 02/27/2015 01:18 PM, Nico Kadel-Garcia wrote:

On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
  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

[Nico Kadel-Garcia]

On Fri, Feb 27, 2015 at 8:18 AM, Nico Kadel-Garcia  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

[Nico Kadel-Garcia]

On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
 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

[Jóhann B. Guðmundsson]

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

[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.


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

[Reindl Harald]

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

[Reindl Harald]

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

[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.


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

[Reindl Harald]

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

[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.


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

[Matthew Miller]

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

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

[Orion Poplawski]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Colin Walters]

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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 23, 2015 at 07:56:50AM -0800, Andrew Lutomirski wrote:
> On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering
>  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

[Miloslav Trmač]

> 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

[Simo Sorce]

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  
> > > 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

[Lennart Poettering]

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

[Andrew Lutomirski]

On Mon, Feb 23, 2015 at 7:43 AM, Lennart Poettering
 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

[Rahul Sundaram]

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

[David Cantrell]

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 
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

[Lennart Poettering]

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Feb 20, 2015 at 11:04:13AM -0600, Dennis Gilmore wrote:
> On Fri, 20 Feb 2015 17:36:17 +0100
> Lennart Poettering  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

[Lennart Poettering]

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  
> > 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

[Lennart Poettering]

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

[Pierre-Yves Chibon]

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
>  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

[Nico Kadel-Garcia]

On Fri, Feb 20, 2015 at 11:36 AM, Lennart Poettering
 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

[Simo Sorce]

On Mon, 2015-02-23 at 14:40 +0100, drago01 wrote:
> On Mon, Feb 23, 2015 at 2:17 PM, David Cantrell  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

[drago01]

On Mon, Feb 23, 2015 at 2:17 PM, David Cantrell  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

[David Cantrell]

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 
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

[Lennart Poettering]

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

[Lennart Poettering]

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

[Colin Walters]

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

[Dennis Gilmore]

On Fri, 20 Feb 2015 18:12:29 +0100
Lennart Poettering  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  wrote:
> > 
> > > On Fri, 20 Feb 2015 17:36:17 +0100
> > > Lennart Poettering  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

Re: systemd-219 issues with 22 and Rawhide composes

[Dennis Gilmore]

On Fri, 20 Feb 2015 18:11:38 +0100
Lennart Poettering  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  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

[Lennart Poettering]

On Fri, 20.02.15 11:04, Dennis Gilmore (den...@ausil.us) wrote:

> On Fri, 20 Feb 2015 17:36:17 +0100
> Lennart Poettering  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

[Paul W. Frields]

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 " or
"you always do ," 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  
Manager, Fedora Engineering - Emerging Platform
http://redhat.com  --  http://opensource.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://

Re: systemd-219 issues with 22 and Rawhide composes

[Lennart Poettering]

On Fri, 20.02.15 11:07, Dennis Gilmore (den...@ausil.us) wrote:

> On Fri, 20 Feb 2015 11:04:13 -0600
> Dennis Gilmore  wrote:
> 
> > On Fri, 20 Feb 2015 17:36:17 +0100
> > Lennart Poettering  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

[Dennis Gilmore]

On Fri, 20 Feb 2015 11:04:13 -0600
Dennis Gilmore  wrote:

> On Fri, 20 Feb 2015 17:36:17 +0100
> Lennart Poettering  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

[Dennis Gilmore]

On Fri, 20 Feb 2015 17:36:17 +0100
Lennart Poettering  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

[Dan Williams]

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

[Peter Robinson]

>> >> > 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

[Florian Weimer]

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

[Rahul Sundaram]

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

[Lennart Poettering]

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

[Peter Robinson]

On Fri, Feb 20, 2015 at 4:11 PM, Lennart Poettering
 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  wrote:
>> > To prevent surprises on the next systemd updates like in
>> > , we will not apply
>> > workarounds anymore in rawhide and track the issues on
>> >  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

[Lennart Poettering]

On Fri, 20.02.15 16:03, Peter Robinson (pbrobin...@gmail.com) wrote:

> On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer  wrote:
> > To prevent surprises on the next systemd updates like in
> > , we will not apply
> > workarounds anymore in rawhide and track the issues on
> >  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

Re: systemd-219 issues with 22 and Rawhide composes

[Peter Robinson]

On Fri, Feb 20, 2015 at 3:47 PM, Harald Hoyer  wrote:
> To prevent surprises on the next systemd updates like in
> , we will not apply
> workarounds anymore in rawhide and track the issues on
>  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

systemd-219 issues with 22 and Rawhide composes

[Harald Hoyer]

To prevent surprises on the next systemd updates like in
, we will not apply
workarounds anymore in rawhide and track the issues on
 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

rawhide composes

[Kevin Fenzi]

Greetings. 

Some of you may have noted that there was no rawhide compose pushed out
saturday or today. 

The compose is failing and I think it's related to the createrepo
update that landed in rawhide on friday:

https://bugzilla.redhat.com/show_bug.cgi?id=1021162

Has the details. 

More eyes on the errors or code welcome. 

kevin


signature.asc
Description: PGP 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: Wrong packages in F14/rawhide composes

[Adam Tkac]

On Tue, Aug 24, 2010 at 01:54:25PM +0100, Paul Howarth wrote:
> On 24/08/10 13:45, Adam Tkac wrote:
> > Hello,
> >
> > it seems there are some issues with recent mass rebuilds for perl
> > 5.12.0 in F14/rawhide.
> >
> > Some packages were rebuilt against new perl and then were built again.
> > However koji exposes only the older build.
> >
> > This is list of affected packages which I discovered during work on
> > FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35:
> >
> > nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client,
> > perl-PAR and perl-PAR-Packer.
> >
> > For example when I visit koji via https://kojiweb.fedoraproject.org/koji
> > web interface and search for example for "nagios" package, then I can
> > see there is "nagios-3.2.1-5.fc14" package with dist-f14 tag. However
> > when I run "$ koji latest-pkg dist-f14 nagios" I get:
> >
> > Build Tag   Built by
> >    
> > nagios-3.2.1-4.fc14   dist-f14 mmaslano
> >
> > This is really odd, what would be the best way to fix this issue?
> > Rebuild of affected packages?
> 
> Yes, because the "newer" builds have probably been built against the 
> older perl.

Right you are, thanks for the pointing out the root cause. I will
rebuild discussed packages.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Wrong packages in F14/rawhide composes

[Paul Howarth]

On 24/08/10 13:45, Adam Tkac wrote:
> Hello,
>
> it seems there are some issues with recent mass rebuilds for perl
> 5.12.0 in F14/rawhide.
>
> Some packages were rebuilt against new perl and then were built again.
> However koji exposes only the older build.
>
> This is list of affected packages which I discovered during work on
> FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35:
>
> nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client,
> perl-PAR and perl-PAR-Packer.
>
> For example when I visit koji via https://kojiweb.fedoraproject.org/koji
> web interface and search for example for "nagios" package, then I can
> see there is "nagios-3.2.1-5.fc14" package with dist-f14 tag. However
> when I run "$ koji latest-pkg dist-f14 nagios" I get:
>
> Build Tag   Built by
>    
> nagios-3.2.1-4.fc14   dist-f14 mmaslano
>
> This is really odd, what would be the best way to fix this issue?
> Rebuild of affected packages?

Yes, because the "newer" builds have probably been built against the 
older perl.

Paul.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Wrong packages in F14/rawhide composes

[Adam Tkac]

Hello,

it seems there are some issues with recent mass rebuilds for perl
5.12.0 in F14/rawhide.

Some packages were rebuilt against new perl and then were built again.
However koji exposes only the older build.

This is list of affected packages which I discovered during work on
FES ticket https://fedorahosted.org/fedora-engineering-services/ticket/35:

nagios, perl-DBD-SQLite, perl-HTTP-DAV, perl-Net-STOMP-Client,
perl-PAR and perl-PAR-Packer.

For example when I visit koji via https://kojiweb.fedoraproject.org/koji
web interface and search for example for "nagios" package, then I can
see there is "nagios-3.2.1-5.fc14" package with dist-f14 tag. However
when I run "$ koji latest-pkg dist-f14 nagios" I get:

Build Tag   Built by
   
nagios-3.2.1-4.fc14   dist-f14 mmaslano

This is really odd, what would be the best way to fix this issue?
Rebuild of affected packages?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel