Re: Rawhide boot problems
On Tue, 11 Sep 2012 23:50:15 +0200, Kay Sievers wrote: Wouldn't it already help if the build system would just refuse to build newer versions in branches than which are in rawhide at that moment? That would be dangerous with regard to security fixes, for example. Rawhide buildroot contents could cause a build to fail whereas submitting the same build job to a stable branch may succeed. -- Fedora release 18 (Spherical Cow) - Linux 3.6.0-0.rc4.git2.1.fc18.x86_64 loadavg: 0.19 0.11 0.08 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
Am 29.08.2012 00:43, schrieb Jerry James: First, systemd complained about being unable to find systemd-journal-flush.service. Sure enough, it wasn't in the initramfs. So I added $systemdsystemunitdir/systemd-journal-flush.service to /usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated the initramfs. Now the boot gets past that point, but starts doing this over and over, apparently forever, even in emergency mode: Do _not_ do this. This is wrong. There is no place to flush the journal to, as there is no root mounted!!! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
Am 12.09.2012 13:25, schrieb Michael Schwendt:
On Tue, 11 Sep 2012 23:50:15 +0200, Kay Sievers wrote:
Wouldn't it already help if the build system would just refuse to
build newer versions in branches than which are in rawhide at that
moment?
That would be dangerous with regard to security fixes, for example.
Rawhide buildroot contents could cause a build to fail whereas submitting
the same build job to a stable branch may succeed.
Well, it did not help in the systemd case
systemd-188-3.fc18 systemd-188-3.fc19
where as systemd-188-3.fc18 has another fix in than systemd-188-3.fc19 has.
But in general I am all for the idea of not permitting newer packager versions
in older distro version. These happened too often in the past, where we had for
example newer versions in F14 updates than in F16 release, which horribly broke
updates. The only solution for this, is to only allow updates with
%{?dist}.[0-9]+.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Monday 10 September 2012 15:14:26 Adam Williamson wrote: I don't think that's true, actually. There certainly are devs who take advantage of the model. Exactly. Think glibc as another example. Back then when the glibc people did their development work on Branched it was generally viewed as too disruptive. So the current development branch is only in Rawhide. F18 has the 2.16 release instead which matured in Rawhide since right after F17 was branched off. Of course, there's nothing in Lennart's proposal which would prevent that way of work. But still, the early branching model does have its advantages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Tue, 11.09.12 09:52, Kevin Fenzi (ke...@scrye.com) wrote: This would give packagers much more flexibility about branching and would also simplify our model as the master branch would just go away... One branch less that can be confused is a win for everybody. I don't see a problem with that, but then I'm just the monkey :) So, the biggest problem is that in the past, FESCo has said that rawhide should never go back in versions. If we change the inheritance to pull from say f18-updates-testing, it means if an update was pulled it also would 'disappear' from rawhide the next day. If I was wanting a f19 branch for my big library build and I needed to build a new systemd version, could I branch it? or that would only be up to you? (ie, would it be any package maintainer, or just people with acls to the package). Everybody with commit access to he package should be able to create a branch of it I guess. How do we tell pkgdb that there is a new branch? Currently it's done at mass branch time, but in this model there would have to be some way for maintainer/brancher to tell it. Well, maybe the mass branch time should continue to exist, but instead of actually doing any mass branching it would just be the point in time where pkgdb learns that a new branch might now exist in the package repos even though many packages won't have it any time soon. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. But we are not doing two lines of development in systemd or GNOME or other upstream projects. So, why again should we build the same stuff twice ? I personally just don't have the time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
Matthias Clasen (mcla...@redhat.com) said: On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. But we are not doing two lines of development in systemd or GNOME or other upstream projects. So, why again should we build the same stuff twice ? I personally just don't have the time. Honestly, the problem here doesn't really come from a model of building for both, or only building for branched, as both are valid strategies for a maintainer to take. The problem came from a well-intentioned packager who happened to choose one strategy when applying a fix, when the maintainers prefer the other. I'm not sure how to avoid this other than having each package speficy which it prefers (kind of messy) vs. mandating a particular style. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/10/2012 08:35 PM, Matthias Clasen wrote: On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. But we are not doing two lines of development in systemd or GNOME or other upstream projects. So, why again should we build the same stuff twice ? I personally just don't have the time. Well the theory is, all major development should've already landed in rawhide before the time of the mass-branch. When that happens the current setup works smooth as peaches. But rare upstream projects march to Fedora schedules, so you either delay feature/version X to the next Fedora version, introducing it in rawhide right after the mass-branch. Or fight with the branching. And because everybody wants to squeeze in the latest XYZ to this version already so... For example GNOME is AFAICT some two months off the perfect alignment. Me thinks flexibility with the branching-point would help: branching before alpha is far too early for many projects, for others its absolutely necessary. It all depends on what happens to be going on with a given package / package set on a given cycle, one size fits almost everybody poorly. In the squeeze cycles, what I always end up missing most is having rawhide and branched to share the same git (master) branch, but different builds (as you never know what *else* might change on rawhide - binary package inheritance doesn't work well either way) deep in to the release cycle (at least up until beta). Of course syncing from rawhide - branched is no longer root-canal painful with git, merely tedious, but tedious enough that many packagers dont bother, so we end up having this (IMO) twisted situation where active development goes on in a branch and master lags behind. And inevitably bits and patches fall through the cracks when active working moves back to master. Seen my share of it. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Mon, 10.09.12 14:09, Bill Nottingham (nott...@redhat.com) wrote: Matthias Clasen (mcla...@redhat.com) said: On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. But we are not doing two lines of development in systemd or GNOME or other upstream projects. So, why again should we build the same stuff twice ? I personally just don't have the time. Honestly, the problem here doesn't really come from a model of building for both, or only building for branched, as both are valid strategies for a maintainer to take. The problem came from a well-intentioned packager who happened to choose one strategy when applying a fix, when the maintainers prefer the other. I'm not sure how to avoid this other than having each package speficy which it prefers (kind of messy) vs. mandating a particular style. To deal with this I added a small message to the systemd .spec file that explains this. I do hope that people will actually read it before commiting things. Anway, I still believe that the default approach to doing package development should be to focus on F18 as long as it isn't released, and only open F19 for a packge if the packager decides he is ready to. Right now we have the opposite where a package immediately is branched twice and packagers then have to make sure nobody uses the newer branch yet. So yeah, I do acknowledge that both modes of working make sense, I just believe the default approach should be one where focus is on stabilizing things, not on developing new stuff all the time. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/10/2012 10:30 PM, Lennart Poettering wrote: Anway, I still believe that the default approach to doing package development should be to focus on F18 as long as it isn't released, and only open F19 for a packge if the packager decides he is ready to. Right now we have the opposite where a package immediately is branched twice and packagers then have to make sure nobody uses the newer branch yet. So yeah, I do acknowledge that both modes of working make sense, I just believe the default approach should be one where focus is on stabilizing things, not on developing new stuff all the time. This is my view as well. Having two development releases in parallel is confusing for both package maintainers and testers -- everybody should really be focusing on the upcoming F18 release, but instead people are installing rawhide as well. We just don't have the resources to do two parallel development distros at a time. Instead, what we are doing now is splitting the tester base between F18 and rawhide, and this makes F18 quality go down. And also gives rawhide a bad name. Can't we just change the branching to a later date? -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Mon, Sep 10, 2012 at 23:27:43 +0200, Kalev Lember kalevlem...@gmail.com wrote: Can't we just change the branching to a later date? Branching later results in rawhide being frozen during the alpha freeze which breaks things for people doing development. (Note that by alpha people really should be stablizing things and we really don't want disruptive development going on in branched at that time.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Mon, 10.09.12 15:14, Adam Williamson (awill...@redhat.com) wrote: On 2012-09-10 15:03, Kalev Lember wrote: The hard reality is that branched and rawhide are getting pretty much the same set of packages currently. It's a very nice view to let development go ahead in rawhide, and to stabilize branched. But we only have so many developers and everyone is focusing on branched, leaving rawhide broken. I don't think that's true, actually. There certainly are devs who take advantage of the model. Lennart wrote that 'everyone' has to for it to be valuable, but that isn't true at all. I can recall at least two notifications to the list about updates to major libraries happening in Rawhide that aren't happening in F18. One of them is boost: it's up a whole major version in Rawhide compared to F18. That's exactly how the policy is supposed to work. I forget exactly what the other was, but I know there was at least one more. Another example from today - the Postgresql maintainer mailed the list to say that now F18 is delayed he'll be putting the new version in F18, but until then, he was planning to have the newer version in Rawhide only - again, exactly how the policy is supposed to work. Those are just examples from memory, not even looking through the archives. What I am proposing is to get rid of the master branch, so that people can just branch off F-19 as early and as late as they want, and they do it from F-18 on their own. The mass branching would go away this way, (might only be a side-effect of distro-wide rebuilds). This way, Lennart would just maintain systemd in the F-18 branch. And then in a month or two he would branch F-19 off this branch. And then when he is ready to open F-20 he would branch it off F-19. And so on. But the time where Lennart decides to branch off is up to him. In your example above the boost maintainer otoh could branch off F-19 much earlier than Lennart branches off systemd. Both packagers would have full flexibility when to branch off. This would give packagers much more flexibility about branching and would also simplify our model as the master branch would just go away... One branch less that can be confused is a win for everybody. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 2012-09-10 15:22, Lennart Poettering wrote: On Mon, 10.09.12 15:14, Adam Williamson (awill...@redhat.com) wrote: On 2012-09-10 15:03, Kalev Lember wrote: The hard reality is that branched and rawhide are getting pretty much the same set of packages currently. It's a very nice view to let development go ahead in rawhide, and to stabilize branched. But we only have so many developers and everyone is focusing on branched, leaving rawhide broken. I don't think that's true, actually. There certainly are devs who take advantage of the model. Lennart wrote that 'everyone' has to for it to be valuable, but that isn't true at all. I can recall at least two notifications to the list about updates to major libraries happening in Rawhide that aren't happening in F18. One of them is boost: it's up a whole major version in Rawhide compared to F18. That's exactly how the policy is supposed to work. I forget exactly what the other was, but I know there was at least one more. Another example from today - the Postgresql maintainer mailed the list to say that now F18 is delayed he'll be putting the new version in F18, but until then, he was planning to have the newer version in Rawhide only - again, exactly how the policy is supposed to work. Those are just examples from memory, not even looking through the archives. What I am proposing is to get rid of the master branch, so that people can just branch off F-19 as early and as late as they want, and they do it from F-18 on their own. The mass branching would go away this way, (might only be a side-effect of distro-wide rebuilds). This way, Lennart would just maintain systemd in the F-18 branch. And then in a month or two he would branch F-19 off this branch. And then when he is ready to open F-20 he would branch it off F-19. And so on. But the time where Lennart decides to branch off is up to him. In your example above the boost maintainer otoh could branch off F-19 much earlier than Lennart branches off systemd. Both packagers would have full flexibility when to branch off. This would give packagers much more flexibility about branching and would also simplify our model as the master branch would just go away... One branch less that can be confused is a win for everybody. I don't see a problem with that, but then I'm just the monkey :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 10 September 2012 17:16, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) wrote: On 09/10/2012 02:27 PM, Kalev Lember wrote: Can't we just change the branching to a later date? When we used to do that, we frequently had destabilizing changes happening late in the development process, because there was no other place to land them. My suggestion of just letting everybody branch on their own, getting rid of mass branching and gettind rid of the master branch would neatly allow people to push their changes to any later distro they want... I don't see how that can scale to the number of packages in Fedora. It is going to be a combinatorics nightmare especially when a ton of people don't work together and all have their own idea of the RIGHT way to branch, land and build their own packages. It might work for a scaled down OS-tree size distro.. but at 12000 packages.. and things like well you pushed this into X and now A..Z packages need to be rebuilt against it. -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Mon, 10.09.12 17:43, Stephen John Smoogen (smo...@gmail.com) wrote: On 10 September 2012 17:16, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) wrote: On 09/10/2012 02:27 PM, Kalev Lember wrote: Can't we just change the branching to a later date? When we used to do that, we frequently had destabilizing changes happening late in the development process, because there was no other place to land them. My suggestion of just letting everybody branch on their own, getting rid of mass branching and gettind rid of the master branch would neatly allow people to push their changes to any later distro they want... I don't see how that can scale to the number of packages in Fedora. It is going to be a combinatorics nightmare especially when a ton of Nightmare? how so? where would it matter? people don't work together and all have their own idea of the RIGHT way to branch, land and build their own packages. It might work for a scaled down OS-tree size distro.. but at 12000 packages.. and things like well you pushed this into X and now A..Z packages need to be rebuilt against it. I don't follow... what has this to do with whether the master branch exists? Note that if mass rebuilds need to happen then of course this would mean that the respective branch in the respective package would have to create implicitly as part of the rebuild. But that shouldn't be too hard... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 2012-09-10 16:43, Stephen John Smoogen wrote: On 10 September 2012 17:16, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 10.09.12 15:51, Jesse Keating (jkeat...@j2solutions.net) wrote: On 09/10/2012 02:27 PM, Kalev Lember wrote: Can't we just change the branching to a later date? When we used to do that, we frequently had destabilizing changes happening late in the development process, because there was no other place to land them. My suggestion of just letting everybody branch on their own, getting rid of mass branching and gettind rid of the master branch would neatly allow people to push their changes to any later distro they want... I don't see how that can scale to the number of packages in Fedora. It is going to be a combinatorics nightmare especially when a ton of people don't work together and all have their own idea of the RIGHT way to branch, land and build their own packages. It might work for a scaled down OS-tree size distro.. but at 12000 packages.. and things like well you pushed this into X and now A..Z packages need to be rebuilt against it. It doesn't imply any change in policy, it just gives the packager the choice of when to branch for Branched+1. I don't think Lennart meant to imply that devs could choose to continue with unstable development in Branched - just that they could 'opt out' of having a Branched+1 branch until they actually needed one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Sat, 8 Sep 2012 03:33:01 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Sep 07, 2012 at 07:43:32PM -0600, Kevin Fenzi wrote: ...snip... It's a balancing act I fear, nothing will make everyone happy. Inheriting from updates-testing means rawhide can and will 'go backwards' as updates get unpushed/dropped. Dropping inheritance entirely means more work for maintainers. Add a flag to bodhi to let maintainers re-enable inheritance? I think the only way that would work would be to untag all rawhide builds so koji inherts again. I don't think koji has code to selectively inherit. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: Jerry James wrote: I've got two Rawhide VMs, one x86_64, one i686, both otherwise identical. I last booted them yesterday and did a yum repo-sync. Today, neither of them will boot. First, systemd complained about being unable to find systemd-journal-flush.service. Sure enough, it wasn't in the initramfs. So I added $systemdsystemunitdir/systemd-journal-flush.service to /usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated the initramfs. Now the boot gets past that point, but starts doing this over and over, apparently forever, even in emergency mode: Thank you for posting about this, and to everyone who has been working on http://bugzilla.redhat.com/847418. I hit the same bug when my rawhide VM updated to the latest kernel, and you've saved me the trouble of investigating. For now, I get by using the preceding kernel. So this happened because somebody updated the Rawhide package, which disabled package inheritance from F18. I have now untagged the package in Rawhide again, and added a notice to the .spec file so that people don't go and blindly update the package in Rawhide, but instead just let inheritance between F18 and Rawhide do its work. Honestly, I think Fedora got the branches all backwards. Instead of carrying around master all the time we should just have the version branches and whenever somebody needs a new version branch he should just branch of the most recent one. Right now master is for many packages mostly dead territory between the time where a version got forked off (but is not yet released) and the time where people actually start working on the next distribution version. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 18:30:10 +0200, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: So this happened because somebody updated the Rawhide package, which disabled package inheritance from F18. I have now untagged the package in Rawhide again, and added a notice to the .spec file so that people don't go and blindly update the package in Rawhide, but instead just let inheritance between F18 and Rawhide do its work. That won't interact well with mass rebuilds. Honestly, I think Fedora got the branches all backwards. Instead of carrying around master all the time we should just have the version branches and whenever somebody needs a new version branch he should just branch of the most recent one. Right now master is for many packages mostly dead territory between the time where a version got forked off (but is not yet released) and the time where people actually start working on the next distribution version. I actually wish people would stop doing updates just for branched and not doing new rawhide builds. This is especially bad during freezes (and the current one has been very long), as rawhide doesn't inherit from updates-testing, so you don't automagicly get fixes. For now I have enabled updates-testing for 18 in addition to rawhide for my rawhide machine, in order to get a lot of the gnome related stuff. I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 7, 2012 at 11:51 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Sep 07, 2012 at 18:30:10 +0200, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: So this happened because somebody updated the Rawhide package, which disabled package inheritance from F18. I have now untagged the package in Rawhide again, and added a notice to the .spec file so that people don't go and blindly update the package in Rawhide, but instead just let inheritance between F18 and Rawhide do its work. That won't interact well with mass rebuilds. Honestly, I think Fedora got the branches all backwards. Instead of carrying around master all the time we should just have the version branches and whenever somebody needs a new version branch he should just branch of the most recent one. Right now master is for many packages mostly dead territory between the time where a version got forked off (but is not yet released) and the time where people actually start working on the next distribution version. I actually wish people would stop doing updates just for branched and not doing new rawhide builds. This is especially bad during freezes (and the current one has been very long), as rawhide doesn't inherit from updates-testing, so you don't automagicly get fixes. For now I have enabled updates-testing for 18 in addition to rawhide for my rawhide machine, in order to get a lot of the gnome related stuff. I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. I personally always do, and advise it as well. It's not like it wastes space, rawhide gets pruned pretty aggressively. And it saves so much pain later. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 7 Sep 2012 11:51:57 -0500 Bruno Wolff III br...@wolff.to wrote: ...snip... I actually wish people would stop doing updates just for branched and not doing new rawhide builds. This is especially bad during freezes (and the current one has been very long), as rawhide doesn't inherit from updates-testing, so you don't automagicly get fixes. For now I have enabled updates-testing for 18 in addition to rawhide for my rawhide machine, in order to get a lot of the gnome related stuff. I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Is it really that much trouble to commit/build in rawhide first? Thats where you should be doing your development anyhow. Then, only if all looks well, should you push to branched. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 11:00, Kevin Fenzi (ke...@scrye.com) wrote: I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Is it really that much trouble to commit/build in rawhide first? Yes, it effectively doubles my Fedora workload. Thats where you should be doing your development anyhow. Then, only if all looks well, should you push to branched. Dude, I already have to look afer way too many distros at the same time. I see no point at all in developing two development distros simultaneously. As long as I don want my F18 and F19 version of packages diverge I see no point in doing everything twice. It sounds really bogus to me to develop to distros at the same time rather than just focussing on stabilizing one of them and let the other just get a copy of my packages. I mean, I don't really like doing packaging work that much. I do it because it is necessary, not because it is fun. You know what is even less fun? Doing everything twice if things could just as easily be inherited automatically. I really don't intend to spend my life on cherry picking things from one brnach into the other if computers can do that for me. Being a cherry-picking monkey sounds like a fantastic job description for a computer, but not really for a human, thank you very much. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 11:00:07 -0600, Kevin Fenzi ke...@scrye.com wrote: On Fri, 7 Sep 2012 11:51:57 -0500 I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Will that really work as expected? The way we do branching has builds effectively move out of the rawhide branch. So that rawhide would end up not including packages that hadn't been rebuilt since the last branch event. Maybe if we coupled this with mass rebuilds just after branch along with a good job of fixing FTBFS, this could be made to work reasonably. But that's a lot of effort (and rawhide disruption during the branch) that I think we'd have trouble doing. If we want to get draconain about forcing rawhide builds (which I don't feel strongly about), then I think a better route would be enforcing rawhide versions being after any versions accepted by bohdi for a package. (There are complications here as well, but they are probably managable.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 11:51, Bruno Wolff III (br...@wolff.to) wrote: On Fri, Sep 07, 2012 at 18:30:10 +0200, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 29.08.12 08:44, Jim Meyering (j...@meyering.net) wrote: So this happened because somebody updated the Rawhide package, which disabled package inheritance from F18. I have now untagged the package in Rawhide again, and added a notice to the .spec file so that people don't go and blindly update the package in Rawhide, but instead just let inheritance between F18 and Rawhide do its work. That won't interact well with mass rebuilds. I think it would be a good idea to do those only if the previous distro has been finalized, so that people can focus on one devel distribution at a time... I actually wish people would stop doing updates just for branched and not doing new rawhide builds. This is especially bad during freezes (and the current one has been very long), as rawhide doesn't inherit from updates-testing, so you don't automagicly get fixes. For now I have enabled updates-testing for 18 in addition to rawhide for my rawhide machine, in order to get a lot of the gnome related stuff. Maybe rawhide should inherit not only from the most recent distro but also by updates-testing? I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. The latter: yes, please. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 7 Sep 2012 19:16:39 +0200 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 07.09.12 11:00, Kevin Fenzi (ke...@scrye.com) wrote: I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Is it really that much trouble to commit/build in rawhide first? Yes, it effectively doubles my Fedora workload. I don't think it doubles it. I agree it increases it some, but it also adds a layer of smoketesting and doublechecking, so IMHO it's worth it. Thats where you should be doing your development anyhow. Then, only if all looks well, should you push to branched. Dude, I already have to look afer way too many distros at the same time. I see no point at all in developing two development distros simultaneously. As long as I don want my F18 and F19 version of packages diverge I see no point in doing everything twice. But f18 and f19 _are_ diverging behind your package. Some of the time you might not notice, but it's happening. It sounds really bogus to me to develop to distros at the same time rather than just focussing on stabilizing one of them and let the other just get a copy of my packages. Think of rawhide as not another distro, but another packageset/check. I mean, I don't really like doing packaging work that much. I do it because it is necessary, not because it is fun. You know what is even less fun? Doing everything twice if things could just as easily be inherited automatically. Perhaps you could try and find some package maintainers to do that work for you while you work on upstream issues? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 12:03, Kevin Fenzi (ke...@scrye.com) wrote: On Fri, 7 Sep 2012 19:16:39 +0200 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 07.09.12 11:00, Kevin Fenzi (ke...@scrye.com) wrote: I think our policy is that you should do rawhide builds, but at least some significant groups of packagers actively don't do rawhide builds. If that is going to continue, we should consider having rawhide inherit from updates-testing. I'd like to propose the opposite: Lets drop any inheritance between branched and rawhide. Is it really that much trouble to commit/build in rawhide first? Yes, it effectively doubles my Fedora workload. I don't think it doubles it. I agree it increases it some, but it also adds a layer of smoketesting and doublechecking, so IMHO it's worth it. Humm. I don't agree with this. As long as F18 is unreleased Rawhide will be basically untested and I also wonder what testing it at this point would bring, given that it right now is mostly F18 and very far from F19, so why not test the real F18 where we need all testing focussed anyway? Committing this twice brings no benefit really, just doubles the work necessary. Thats where you should be doing your development anyhow. Then, only if all looks well, should you push to branched. Dude, I already have to look afer way too many distros at the same time. I see no point at all in developing two development distros simultaneously. As long as I don want my F18 and F19 version of packages diverge I see no point in doing everything twice. But f18 and f19 _are_ diverging behind your package. Some of the time you might not notice, but it's happening. Well, eventually they will, but I think it would be good to do that as late as possible so that people can focus on F18 to give it the detail love it needs. It sounds really bogus to me to develop to distros at the same time rather than just focussing on stabilizing one of them and let the other just get a copy of my packages. Think of rawhide as not another distro, but another packageset/check. Tests/checks are automized. Cherrypicking/commiting/building things twice is not automized. Tests are automated checks which help finding mistakes in what humans do. Making the human commit/build everything twice is just a way to increase the chance that mistakes are made because humans suck at doing repetitive tasks in comparison to computers which excel at it. I mean, I don't really like doing packaging work that much. I do it because it is necessary, not because it is fun. You know what is even less fun? Doing everything twice if things could just as easily be inherited automatically. Perhaps you could try and find some package maintainers to do that work for you while you work on upstream issues? We already have multiple commiters to the packages. But that doesn't change the fact that you shouldn't throw people at a problem that should be solved with a computer. It's a simple fact that we have too little people working on Free Software, and computers are much better at this specific task than people, so it should be computers doing the job, not humans. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/07/2012 06:54 PM, Jesse Keating wrote: On 09/07/2012 11:48 AM, Lennart Poettering wrote: Humm. I don't agree with this. As long as F18 is unreleased Rawhide will be basically untested and I also wonder what testing it at this point would bring, given that it right now is mostly F18 and very far from F19, so why not test the real F18 where we need all testing focussed anyway? Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. As you know we ( QA Community ) want all the testing to be focused on the release we are about to push out the door and we would like ( and some expect ) that maintainers are keeping the same focus and give what time they have to address the bugs we find in the process as Lennart has correctly pointed out. Now that to me the begs the question with our short release cycles do we have any numbers on how many maintainers have the time to be working on both and are those maintainers that do have that time actually taking advantage of the current model in place? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 11:54:03AM -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. This makes sense, but it runs directly against the current auto-inheritence behaviour. It's unsurprising that people end up with different opinions of the right thing to do here. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On 09/07/2012 02:36 PM, Matthew Garrett wrote: On Fri, Sep 07, 2012 at 11:54:03AM -0700, Jesse Keating wrote: Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. This makes sense, but it runs directly against the current auto-inheritence behaviour. It's unsurprising that people end up with different opinions of the right thing to do here. I'm of the opinion that rawhide should be inheriting from the builds of the previous release, so long as there haven't been any builds directly on rawhide. I'm also of the opinion that the inheritance should happen as early as possible, eg as soon as the package is built, instead of waiting for a bodhi introduced delay. Rawhide works this way, the inheritance into rawhide should work this way too. Getting there is a little complicated due to how the fXX-updates-candidate - fXX-updates-testing - fXX tag dance works, but I'm confident smart people can figure that out if change is desired here. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 20:43:23 +, \Jóhann B. Guðmundsson\ johan...@gmail.com wrote: As you know we ( QA Community ) want all the testing to be focused on the release we are about to push out the door and we would like ( and some expect ) that maintainers are keeping the same focus and give what time they have to address the bugs we find in the process as Lennart has correctly pointed out. While QA is focused on testing for the next release, other testing is still useful. For example testing updates-testing packages for already released versions of Fedora is important. Even testing updates-testing stuff for branched (as opposed to say test / RC composes) is useful as it can keep bad stuff from being pulled in, rather than catching it after the fact. Now that to me the begs the question with our short release cycles do we have any numbers on how many maintainers have the time to be working on both and are those maintainers that do have that time actually taking advantage of the current model in place? It may be the case that some maintainers are actively working on changes in the branch release while a different set of maintainers are working on changes for the next release. It may be hard in some cases for maintainers to work on big changes for both branched and rawhide at the same time, but I expect in many cases two different sets of changes don't hit the same package (or set of packages) at the same time in branched and rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 14:42:20 -0700, Jesse Keating jkeat...@j2solutions.net wrote: I'm of the opinion that rawhide should be inheriting from the builds of the previous release, so long as there haven't been any builds directly on rawhide. I'm also of the opinion that the inheritance should happen as early as possible, eg as soon as the package is built, instead of waiting for a bodhi introduced delay. Rawhide works this way, the inheritance into rawhide should work this way too. That would be my preference as well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, 07.09.12 11:54, Jesse Keating (jkeat...@j2solutions.net) wrote: On 09/07/2012 11:48 AM, Lennart Poettering wrote: Humm. I don't agree with this. As long as F18 is unreleased Rawhide will be basically untested and I also wonder what testing it at this point would bring, given that it right now is mostly F18 and very far from F19, so why not test the real F18 where we need all testing focussed anyway? Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. I totally understand that. However this is not really how many people work. The assumption that everybody actually wants to get started asap with new feature development is simply wrong. I tend to focus on stabilization and bugfixes for quite some time before I switch back to feature development, and I actually believe most people should do it that way. And because I do it that way I want to keep F18 and F19 in sync for as long as I can. I want to decide on my own when we are ready and when I want to have F19 diverge from F18, and it shouldn't be implied that this is immediately done when pre-alpha is branched. Or to put this in other words: The default workflow should be that package developers focus on fixing/polishing the upcoming release. The exception should be that package developers immediately forget about the branch and focus immediately on new features. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 02:42:20PM -0700, Jesse Keating wrote: On 09/07/2012 02:36 PM, Matthew Garrett wrote: This makes sense, but it runs directly against the current auto-inheritence behaviour. It's unsurprising that people end up with different opinions of the right thing to do here. I'm of the opinion that rawhide should be inheriting from the builds of the previous release, so long as there haven't been any builds directly on rawhide. I'm also of the opinion that the inheritance should happen as early as possible, eg as soon as the package is built, instead of waiting for a bodhi introduced delay. Rawhide works this way, the inheritance into rawhide should work this way too. Sure, and that's clearly the behaviour that Lennart wanted as well. But instead there was a mass rebuild that bumped his rawhide nvr and now he needs to do rawhide work manually. If development should be happening in rawhide then why is rawhide inheriting from f18? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Sat, Sep 08, 2012 at 01:28:53AM +0100, Matthew Garrett wrote: Sure, and that's clearly the behaviour that Lennart wanted as well. But instead there was a mass rebuild that bumped his rawhide nvr and now he needs to do rawhide work manually. If development should be happening in rawhide then why is rawhide inheriting from f18? I should clarify that. If there's still feature development then clearly that should happen in rawhide. But if the maintainer is working on stabalisation in f18 then rawhide should still get those packages. Right now what happens is that that's absolutely fine right up until someone decides to do a mass rebuild and suddenly the maintainer has to do active development in rawhide at the same time as they're trying to stabalise f18. That doesn't seem optimal. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Sat, 8 Sep 2012 01:32:55 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: On Sat, Sep 08, 2012 at 01:28:53AM +0100, Matthew Garrett wrote: Sure, and that's clearly the behaviour that Lennart wanted as well. But instead there was a mass rebuild that bumped his rawhide nvr and now he needs to do rawhide work manually. If development should be happening in rawhide then why is rawhide inheriting from f18? I should clarify that. If there's still feature development then clearly that should happen in rawhide. But if the maintainer is working on stabalisation in f18 then rawhide should still get those packages. Right now what happens is that that's absolutely fine right up until someone decides to do a mass rebuild and suddenly the maintainer has to do active development in rawhide at the same time as they're trying to stabalise f18. That doesn't seem optimal. This actually has nothing to do with mass rebuilds (unless I am misunderstanding). Mass rebuilds are done _before_ branching to avoid problems like this. :) In this case a proven packager noticed an issue in systemd, fixed it in rawhide. That breaks inheritence, so it will now always need builds in rawhide, it will not inherit from f18. We have discussed this before, and probibly will again. ;) During freezes (like the especially long one we have right now) this is especially painfull for rawhide, as fewer packages come in and they have to wait for the freeze to be over to get updates for non release blocking issues. It's a balancing act I fear, nothing will make everyone happy. Inheriting from updates-testing means rawhide can and will 'go backwards' as updates get unpushed/dropped. Dropping inheritance entirely means more work for maintainers. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 07:43:32PM -0600, Kevin Fenzi wrote: This actually has nothing to do with mass rebuilds (unless I am misunderstanding). Mass rebuilds are done _before_ branching to avoid problems like this. :) Argh, sorry, I was confusing it with something unrelated. Yeah, not a mass rebuild problem in this case. During freezes (like the especially long one we have right now) this is especially painfull for rawhide, as fewer packages come in and they have to wait for the freeze to be over to get updates for non release blocking issues. It's a balancing act I fear, nothing will make everyone happy. Inheriting from updates-testing means rawhide can and will 'go backwards' as updates get unpushed/dropped. Dropping inheritance entirely means more work for maintainers. Add a flag to bodhi to let maintainers re-enable inheritance? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 8 Sep 2012 01:58:35 +0200 Lennart Poettering mzerq...@0pointer.de wrote: On Fri, 07.09.12 11:54, Jesse Keating (jkeat...@j2solutions.net) wrote: On 09/07/2012 11:48 AM, Lennart Poettering wrote: Humm. I don't agree with this. As long as F18 is unreleased Rawhide will be basically untested and I also wonder what testing it at this point would bring, given that it right now is mostly F18 and very far from F19, so why not test the real F18 where we need all testing focussed anyway? Fedora 18 is basically closed for new feature work, and instead the focus needs to be on integration of the existing feature set and bugfixes. But as you state there is a large amount of time before F18 releases, which means new feature work would have to stall out for months. Instead, new feature work can begin for F19 and get ahead of the game. That's why F18 and F19 are divergent. That's why we went from a single line of development to two. I totally understand that. However this is not really how many people work. The assumption that everybody actually wants to get started asap with new feature development is simply wrong. I tend to focus on stabilization and bugfixes for quite some time before I switch back to feature development, and I actually believe most people should do it that way. And because I do it that way I want to keep F18 and F19 in sync for as long as I can. I want to decide on my own when we are ready and when I want to have F19 diverge from F18, and it shouldn't be implied that this is immediately done when pre-alpha is branched. really what is so hard about commiting to master and building. then doing git checkout f18 git merge master git push fedpkg build fedpkg update its really not much effort to keep them in sync at all if thats what you choose. you dont delay things getting into rawhide and tested by those running rawhide, its win all round. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBKtewACgkQkSxm47BaWffdlQCfeQnSlBx3HbHR1oSrl5Og6F8Z m7YAoMIoCcNbIU7YrHs1P+YQSYJ2nzcS =7QNm -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Fri, Sep 07, 2012 at 19:43:32 -0600, Kevin Fenzi ke...@scrye.com wrote: On Sat, 8 Sep 2012 01:32:55 +0100 This actually has nothing to do with mass rebuilds (unless I am misunderstanding). Mass rebuilds are done _before_ branching to avoid problems like this. :) Yeah this isn't as much of a problem as I first thought. Branched wouldn't be there at that time. There still be cases where updates to the latest release branch would need to be duplicated in rawhide, that wouldn't otherwise, but there wouldn't be that many. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
Kevin Fenzi ke...@scrye.com a écrit: https://bugzilla.redhat.com/show_bug.cgi?id=847418 downgrade to: systemd-188-3.fc18 (NOTE: NOT fc19) Just so that I understand. What version of systemd and kernel should Rawhide users *not* use to avoid the issue? I couldn't figure this out by reading the audit trail of that bug. -- Dodji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
Jerry James wrote: I've got two Rawhide VMs, one x86_64, one i686, both otherwise identical. I last booted them yesterday and did a yum repo-sync. Today, neither of them will boot. First, systemd complained about being unable to find systemd-journal-flush.service. Sure enough, it wasn't in the initramfs. So I added $systemdsystemunitdir/systemd-journal-flush.service to /usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated the initramfs. Now the boot gets past that point, but starts doing this over and over, apparently forever, even in emergency mode: Thank you for posting about this, and to everyone who has been working on http://bugzilla.redhat.com/847418. I hit the same bug when my rawhide VM updated to the latest kernel, and you've saved me the trouble of investigating. For now, I get by using the preceding kernel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Wed, Aug 29, 2012 at 12:30 AM, Dodji Seketeli do...@seketeli.org wrote: Kevin Fenzi ke...@scrye.com a écrit: https://bugzilla.redhat.com/show_bug.cgi?id=847418 downgrade to: systemd-188-3.fc18 (NOTE: NOT fc19) Just so that I understand. What version of systemd and kernel should Rawhide users *not* use to avoid the issue? The kernel version doesn't matter. Just don't use systemd-188-3.fc19 (note the fc19; the fc18 version is okay). I still needed to add this line: $systemdsystemunitdir/systemd-journal-flush.service to /usr/lib/dracut/modules.d/98systemd/module-setup.sh and regenerate the initramfs before I could get a good boot with systemd-188-3.fc18, however. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Wed, 29 Aug 2012 08:30:34 +0200 Dodji Seketeli do...@seketeli.org wrote: Kevin Fenzi ke...@scrye.com a écrit: https://bugzilla.redhat.com/show_bug.cgi?id=847418 downgrade to: systemd-188-3.fc18 (NOTE: NOT fc19) Just so that I understand. What version of systemd and kernel should Rawhide users *not* use to avoid the issue? Do not use: systemd-188-3.fc19 Or anything older than systemd-188-3.fc18 Currently, systemd-188-3.fc18 is your best and I think only choice. I couldn't figure this out by reading the audit trail of that bug. sorry if it was unclear. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide boot problems
I've got two Rawhide VMs, one x86_64, one i686, both otherwise identical. I last booted them yesterday and did a yum repo-sync. Today, neither of them will boot. First, systemd complained about being unable to find systemd-journal-flush.service. Sure enough, it wasn't in the initramfs. So I added $systemdsystemunitdir/systemd-journal-flush.service to /usr/lib/dracut/modules.d/98systemd/module-setup.sh, and regenerated the initramfs. Now the boot gets past that point, but starts doing this over and over, apparently forever, even in emergency mode: [ OK ] Reached target Basic System. [ 5.337054] systemd-journald[722]: Received SIGUSR1 [ 5.364465] systemd-udevd[763]: worker [817] did not accept message -1 (Connection refused), kill it [ 5.372587] systemd-udevd[763]: worker [821] did not accept message -1 (Connection refused), kill it [ 5.373956] systemd-udevd[763]: worker [823] did not accept message -1 (Connection refused), kill it [ 5.375104] systemd-udevd[763]: worker [824] did not accept message -1 (Connection refused), kill it [ 5.376358] systemd-udevd[763]: worker [826] did not accept message -1 (Connection refused), kill it [ 5.377670] systemd-udevd[763]: worker [829] did not accept message -1 (Connection refused), kill it [ 5.378890] systemd-udevd[763]: worker [831] did not accept message -1 (Connection refused), kill it [ 5.380187] systemd-udevd[763]: worker [834] did not accept message -1 (Connection refused), kill it [ 5.381802] systemd-udevd[763]: worker [837] did not accept message -1 (Connection refused), kill it [ 5.383105] systemd-udevd[763]: worker [838] did not accept message -1 (Connection refused), kill it [ 5.386671] systemd-udevd[763]: worker [786] did not accept message -1 (Connection refused), kill it [ 35.340097] systemd-journald[722]: Received SIGTERM [ 35.356677] systemd[1]: Running in intial RAM disk. Welcome to Fedora 19 (Rawhide) dracut-023-2.fc18 (Initramfs)! Starting Journal Service... Starting Dracut cmdline hook... [ OK ] Reached target Sockets. [ OK ] Listening on udev Kernel Socket. [ OK ] Listening on udev Control Socket. [ OK ] Reached target Encrypted Volumes. Starting Setup Virtual Console... [ OK ] Reached target Swap. [ OK ] Reached target Local File Systems. Starting Tell Plymouth To Write Out Runtime Data... [ 35.531873] systemd[1]: systemd-journald.service holdoff time over, scheduling restart. [ OK ] Started Tell Plymouth To Write Out Runtime Data. [ OK ] Stopped Trigger Flushing of Journal to Persistent Storage. Stopping Journal Service... [ OK ] Stopped Journal Service. Starting Journal Service... [ OK ] Started Journal Service. Starting Trigger Flushing of Journal to Persistent Storage... [ 35.884485] systemd-journald[881]: Fixed max_use=48.9M max_size=6.1M min_size=64.0K keep_free=24.4M [ 35.895630] systemd-journald[881]: Vacuuming... [ OK ] Started Trigger Flushing of Journal to Persistent Storage. [ 35.945177] systemd-journald[881]: Received SIGUSR1 [ OK ] Started Setup Virtual Console. [ OK ] Reached target System Initialization. dracut-cmdline[885]: Warning: Option 'KEYTABLE' is deprecated, use 'KEYMAP' instead. dracut-cmdline[885]: Warning: Option 'SYSFONT' is deprecated, use 'FONT' instead. [ OK ] Started Dracut cmdline hook. Starting Dracut pre-udev hook... [ OK ] Started Dracut pre-udev hook. Starting udev Kernel Device Manager... [ 36.107496] system-udevd[948]: starting version 188 [ OK ] Started udev Kernel Device Manager. Starting Dracut pre-trigger hook... [ OK ] Reached target Basic System. [ 36.691716] systemd-journald[881]: Received SIGUSR1 ... Does anybody recognize the problem? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Tue, 28 Aug 2012 16:43:14 -0600 Jerry James loganje...@gmail.com wrote: I've got two Rawhide VMs, one x86_64, one i686, both otherwise identical. I last booted them yesterday and did a yum repo-sync. Today, neither of them will boot. ...snip... Does anybody recognize the problem? Yes. https://bugzilla.redhat.com/show_bug.cgi?id=847418 downgrade to: systemd-188-3.fc18 (NOTE: NOT fc19) then rebuild your initramfs with dracut kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide boot problems
On Tue, Aug 28, 2012 at 4:54 PM, Kevin Fenzi ke...@scrye.com wrote: Yes. https://bugzilla.redhat.com/show_bug.cgi?id=847418 downgrade to: systemd-188-3.fc18 (NOTE: NOT fc19) then rebuild your initramfs with dracut Thank you, Kevin! I was hunting through dracut bugs looking for this, instead of systemd bugs -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
