Re: [Spacewalk-devel] fedora Support
On Monday 19 April 2010 02:44:36 am Miroslav Suchý wrote: On 04/16/2010 05:16 PM, Dennis Gilmore wrote: Hey All, We should drop support for Fedora 11 and add Fedora 13. Fedora 11 will be EOL in ~2 months, -1, when it will eol in 2 months, why drop it now. We will delete it when it will die, but why do it sooner? We have in the past, and it wont get support for most of the life of 1.0 to that end ive started building 0.9 for F-13 most of it is built. -1 I do not like the fact that packages for F-13 will be built on some not-yet-released packages. Unless we will distinguished it by some dist tag, which will be overwriten by normal dist tag and we rebuild all packages after release of F-13. F-13 is post Beta now. its feature complete, the only changes now should be bug fixes. again this is how we have done things in the past. I do not want to build our packages on top of rawhide or beta. If it some packages are part of Fedora, then good. But most of our packages are not there. Yet. there are some supporting deps that need building. Do you mind to share with us? Which deps? jpam, oscache, redstone-xmlrpc, ehcache, and a few others I would like to make the switch to only build for EL-5 F-12 and F-13 but wante dto run it by everyone first. Commiting this changes 3 hours after sending this proposal is not enough. IMO. I reverted this commit in master. I leave fate of you commit in SPACEWALK-1.0 branch in hand of release nanny and on the opinion of others. I find that to be unacceptable. Adding back F-11 would be ok but just reverting is downright rude. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] fedora Support
On Monday 19 April 2010 10:53:39 am Miroslav Suchý wrote: On 04/19/2010 03:43 PM, Dennis Gilmore wrote: We have in the past, and it wont get support for most of the life of 1.0 We done it *once* in past. But not always. For F-12 we built packages month after release. For F-11 month before release. For F-10 three month after release And even if we did it only once ... I do not think it was wise movement. And F-11 will be supported for more then 2 months, but we are releasing Spacewalk now. Commiting this changes 3 hours after sending this proposal is not enough. IMO. I reverted this commit in master. I leave fate of you commit in SPACEWALK-1.0 branch in hand of release nanny and on the opinion of others. I find that to be unacceptable. Adding back F-11 would be ok but just reverting is downright rude. This comes to two thing: a) do we want to build F-13 packages on beta? Unless we have some tool for rebuild after F-13, I'm strongly against it. It can broke functionality later if not rebuilt. We can discuss it, but until majority agree, I think we should not add it. Or unless it is released. b) do we want to remove support of F-11, when it has still 1/6 of its life remaining? Again we can discuss it, but removing it now would cut off those who are still using F-11. adding F-11 back is simple, I probably should have just kept it also So I decided that without prior discussion I want to have F-13 removed and F-11 added. Which leads to complete revert of your commit. Do not take it personally. If others will disagree with me, I will be first who will revert my own revert. I would like to ask others for their opinion. You also switched master from building in the 1.1 tags to the 0.9 tags in your revert. And there was one other reason, if you look on Koji: http://koji.rhndev.redhat.com/koji/tasks?state=failedview=treemethod=all; order=-completion_time Your step has as consequence completely overfilled koji with failing tasks. Doing such change on Friday is really not good thing. None of those failures were any of my doing. it looks like Shannon does not have the proper permissions to do a build from SRPM. I just now fixed his permissions. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] fedora Support
Hey All, We should drop support for Fedora 11 and add Fedora 13. Fedora 11 will be EOL in ~2 months, to that end ive started building 0.9 for F-13 most of it is built. there are some supporting deps that need building. I would like to make the switch to only build for EL-5 F-12 and F-13 but wante dto run it by everyone first. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] F-13 support
Has anyone done any work to buildspacewalk for Fedora 13 yet? Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Tuesday 08 September 2009 11:52:43 am Brandon Perkins wrote: Jesus M. Rodriguez wrote: 2009/9/8 Dennis Gilmore den...@ausil.us: On Friday 04 September 2009 07:33:36 am Miroslav Suchý wrote: Today, we have both Spacewalk (and proxy) packages together in one repo with client packages. If somebody will install Spacewalk on RHEL he will get as side effect all those client packages (rhnlib, yum-rhn-plugin, rhn-client-tools), which will get him to unsupported state. I'm not sure if this is what we wanted. In fast, we probably do not want this. I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. It sounds like a nightmare on the koji side. So what is it that we're trying to resolve with this change? I know from a user's point of view it makes sense to see a client and a server repo. But what pain is really being caused with the current setup? As I understand it, the main concern that Miroslav was having in this case was avoiding installing new versions of packages from Spacewalk that are also shipped with RHEL or RHN Client Tools. Basically, wanting to avoid someone accidentally upgrading a Red Hat shipped package with a Spacewalk package and making support a little more cumbersome. Making sure we dont ship those packages I think is the right answer. There a few we need to not ship as fedora/EPEL ships them. I will work on blocking the packages that we should not ship. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Friday 04 September 2009 07:33:36 am Miroslav Suchý wrote: Today, we have both Spacewalk (and proxy) packages together in one repo with client packages. If somebody will install Spacewalk on RHEL he will get as side effect all those client packages (rhnlib, yum-rhn-plugin, rhn-client-tools), which will get him to unsupported state. I'm not sure if this is what we wanted. In fast, we probably do not want this. I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Add spacewalk-backend Requires on python-pgsql.
On Friday 14 August 2009 09:03:38 am Devan Goodwin wrote: On Fri, 14 Aug 2009 15:00:12 +0200 For the record I like the idea of: yum install spacewalk spacewalk-oracle yum install spacewalk spacewalk-postgresql I personally prefer yum install spacewalk-postgresql yum install spacewalk-oracle drop the spacewalk package from the command to install. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: rel-eng/build-missing-builds-in-brew.sh rel-eng/build- missing-builds-in-koji.sh
On Wednesday 12 August 2009 02:31:51 am Miroslav Suchý wrote: Dennis Gilmore wrote: rel-eng/build-missing-builds-in-brew.sh | 22 -- rel-eng/build-missing-builds-in-koji.sh | 30 -- 2 files changed, 52 deletions(-) New commits: commit 549493f74c548084400913a104bafc2ac632c38f Author: Dennis Gilmore den...@ausil.us Date: Tue Aug 11 15:43:50 2009 -0500 remove outdated build missing scripts diff --git a/rel-eng/build-missing-builds-in-brew.sh b/rel-eng/build-missing-builds-in-brew.sh deleted file mode 100755 ... diff --git a/rel-eng/build-missing-builds-in-koji.sh b/rel-eng/build-missing-builds-in-koji.sh deleted file mode 100755 Whoa! These scripts are outdated? I use them for building packages for nightly. So what I should build instead of them? Can you please ask, if somebody is using it, before removing scripts from rel-eng next time? sorry i messed up. i thought they were different old scripts. I put them back and forgot to send this email. I also set them up for 0.7 Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnpush error from latest 0.6 packages
On Thursday 06 August 2009 08:36:15 pm Jesus M. Rodriguez wrote: On Thu, Aug 6, 2009 at 8:46 PM, John Matthewsjmatt...@redhat.com wrote: I installed our latest 0.6 packages from koji and am seeing a problem with rhnpush. from rhnpush Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exceptions.AttributeError' ignored Hrm. That's not cool. Do we have the latest clients built? in my testing i got that message but could push just fine Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Off Topic: Command Line Fu
On Monday 20 July 2009 11:58:00 am Jesus M. Rodriguez wrote: Jesus i cant decrypt your encrypted message Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: spacewalk-setup-0.5.24-1.el5 successfully untagged from dist-5E-sw-0.5-candidate by dgilmore
On Tuesday 31 March 2009 03:11:29 am Miroslav Suchý wrote: And all others packages have been untagged. Which effectively broken down rel-eng/build-missing-builds-in-koji.sh script. May I propose to create 0.6 tags and/or not move the tags, but only copy them? Thx build missing packages script is not broken. there was one package that i missed untagging all builds. that has been fixed. and everything is now fine and hunky dory. I will be setting up 0.6 tags today. since weonly want to build critical fixes for 0.5 all new development is will be targeted at the next release. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-commits
On Thursday 26 March 2009 07:19:17 pm Dennis Gilmore wrote: would anyone object to me creating a spacewalk-comm...@lists.fedorahosted.org and having all commits pushed to fedorahosted emailed there? https://fedorahosted.org/mailman/listinfo/spacewalk-commits its all setup. I've not subscribed anybody to the list. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] spacewalk-commits
would anyone object to me creating a spacewalk-comm...@lists.fedorahosted.org and having all commits pushed to fedorahosted emailed there? Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] 0.5 State of the Union
On Wednesday 25 March 2009 11:00:37 am Devan Goodwin wrote: dgilmore fixed up our jabber configs to work on 2.2 yesterday, so updated spacewalk-config and spacewalk-setup packages correct this, but you probably need to be on a fresh system before it will work. (i.e. not a system where you tried and failed to setup spacewalk, not sure why but Dennis can probably clarify) the issue was that there were inconsistent passwords in jabber config files. jabberd randomly generates a password in %post so we cantdefault ours. we write out our own randomly generated password when we install the package. but you really don't want updates to mess with it. so it only happens on package install. a less hackish way to deal with it would be to generate the password in spacewalk-setup and write it out to the configs when you setup spacewalk. this would involve alot more work but ultimately would be cleaner, its something we should look at post 0.5 Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] editarea .RPM
On Monday 09 March 2009 03:57:16 am Miroslav Suchý wrote: Colin Coe wrote: Some time ago I submitted a patch to make use of EditArea (http://www.cdolivet.net/editarea/) in Spacewalk. I was asked to make an RPM for EditArea which I've now done. I think that I need to get a Do you have the BZ number? sponsor to get the RPM into Fedora. Is there anyone on the list that can sponsor me? The list of sponsor is here: https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor Dennis can sponsor you. Dennis can you? If he do not want to do, I can ask two other collegues. Sure. if the package meets the packaging guidelines. cc me on the bug and ill review and sponsor I've taken the liberty of uploading the SRPM. Uploading where? You should create BZ with Review Request first and in that BZ indicate that you need Sponsor. Full process is described here: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk on Fedora 10 Notes
On Sunday 15 February 2009 11:54:48 am Devan Goodwin wrote: I've done a little hacking on this system before so not sure if there's any deps still missing that I'd previously installed manually, but today it was only missing perl-Apache-Admin-Config, manually installing it got spacewalk deps to resolve and install: http://ftp.belnet.be/packages/dries.ulyssis.org/fedora/fc8/i386/RPMS.dries/ perl-Apache-Admin-Config-0.94-1.fc8.rf.noarch.rpm Note this is using the Fedora 10 nightly devel repo at: http://miroslav.suchy.cz/spacewalk/nightly-candidate-f10/i386/os/ Dennis any luck establishing what the deal is with this package and how we plan to tackle it? perl-Apache-Admin-Config builds fine on RHEL 5 which uses perl 5.8.8 but the test suit fails with perl-5.10.0 used in fedora there is something between the two versions of perl that it doesnt like. ive not yet worked out what exactly, if someone better at perl than me could work out that would be awesome. I expect that putting that package in will result in whatever uses it to be horribly broken. considering its from a place of unknown quality and appears to be built for fedora-8 which had perl 5.8.8 Once packages are installed the real fun begins, during spacewalk-setup I get a problem: signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fedora Status
On Thursday 29 January 2009 09:12:07 am Miroslav Suchý wrote: Dennis Gilmore wrote: All but 2 packages in git are built for fedora. I changed rel-eng/build-missing-builds-in-koji.sh so it now automatically builds all tagged packages in tag dist-f10-sw-0.5-candidate as well. Dennis is the F-10 repo available on koji for rsync too? What is the url? I would like to add it to public nightly repo as well. Hi Miroslav, thanks in advance its at rsync://koji.rhndev.redhat.com/spacewalk/spacewalk- f10/spacewalk-f10-0.5/ it update at the same times as the EL-5 repos Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: tagger.py: make email in changelog optional
On Monday 19 January 2009 04:03:28 am Jan Pazdziora wrote: Hello Devan, I tried build.py --tag-release and it complained that there is no email address in the changelog entry line. I do not want to put my email address there. This patch makes that part optional. I would ask that we not apply the patch. Just because when we do get packages into fedora there must be an email address in the changelog it can be obsfucated but needs to be there https://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs I would really like for our packages to comply with the packaging guidelines. I know they currently do not comply. but it would be good to be working towards complicance. it will make things smoother when we get to review time. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: [Spacewalk-list] Spacewalk 0.4 is here!
On Friday 16 January 2009 08:47:19 am Michael Mraka wrote: Miroslav Suchý wrote: % E. The builds failed: % GenericError: Unable to complete build: release mismatch (build: 1.el5, % rpm: 1) % % Dennis, is it possible that you removed buildsys-macros from % dist-5E-sw-0.4-candidate ? IMO this is a very good reason not to move packages between tags but have them tagged to more locations simultaneously. Dennis, please could you tell me the reason why do you insist on moving them? (Other than We always do it this way in Fedora because it isn't a reason.) I move packages because they are no longer candidates they are now released the tags reflect such. buildsys-macros is not and has never been in dist-5E- sw-0.4-candidate or any tag that it inherits from. it gets inherited in dist-5E-sw-0.4-build from dist-5E-sw-0.3-build, dist-5E-sw-0.4-build is used to populate the buildroots. it seems that the inheritance was removed. ive now fixed that up. once https://koji.rhndev.redhat.com/koji/taskinfo?taskID=4579 is complete you will be able to build. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Wednesday 26 November 2008 04:29:25 am Miroslav Suchý wrote: Dennis Gilmore wrote: I think we can assume if its not tagged that means that the work is not complete and not ready to be built or tested. I spoke about make tag-release, which make git tag. Do not mistake it for koji tag. 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. Im assuming that you mean moving successful builds into dist-5E-sw-0.4 No I meant koji tag-pkg dist-5E-sw-0.4 sucessfull-build I really do not see benefit of moving in compare to tag it to final tag as well (beside the -candidate one) tagging packages like that is the completely wrong thing to do. we should run koji move-tag dist-5E-sw-0.4-candidate dist-5E-sw-0.4 successful build you said unsuucessful build initially which is why i assumed successful build. moving the package out of the candidate tag lets us know that its been though some level of checking. I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make make tag do the build also. Are we still speaking about nightly builds? Now I only care about final release that way that I do not want to break process of final release. Ok. So make the question straight: Will I break something in your rel-eng realm, if I start building testing packages (like SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636.s rc.rpm) in dist-5E-sw-0.4-candidate? If you do that it wont break anything but I really would prefer that you do not do that. packages built in candidate should be builds that could be considered for the final release. how about we set up a dist-5E-sw-0.4- snapshot tag? you can freely build whatever you want in it. since it will not be in consideration for the release. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Wednesday 26 November 2008 06:24:48 am Jan Pazdziora wrote: On Wed, Nov 26, 2008 at 11:29:25AM +0100, Miroslav Suchý wrote: Are we still speaking about nightly builds? Now I only care about final release that way that I do not want to break process of final release. Ok. So make the question straight: Will I break something in your rel-eng realm, if I start building testing packages (like SatConfig-installer-3.24.4-1.git.a352eaab737b87fd46849a6e982c096aa99cc636 .src.rpm) in dist-5E-sw-0.4-candidate? You are likely to break the nightly repos for other people. The developer / maintainer of SatConfig-installer had a reason not to his/her changes that are there on top of SatConfig-installer-3.24.4-1. Why not wait till the developer / maintainer is confident with the code and then build from new tag that he/she will create? that is my thoughts. if its untagged its likely on purpose and we should ignore it until a deliberate action by a developer Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Reason why we should use dist-5E-sw-0.4
On Tuesday 25 November 2008 04:56:36 am Miroslav Suchý wrote: Right now we build into tag dist-5E-sw-0.4-candidate. When I have been working on that nightly repo I find one good reason why we should use tag dist-5E-sw-0.4 and only successful builds tagged there from dist-5E-sw-0.4-candidate. The reason are nightly builds. Now the package get into nightly repo only if you tagged that package in git. If you do not tagged it there we have two possibility how to build the package. I think we can assume if its not tagged that means that the work is not complete and not ready to be built or tested. 1) Automatically tag the package in git and current script will then automatically pick it up for rebuild. Honestly - I do not like such option. I do not like that either 2) Create tag dist-5E-sw-0.4. Normally build into dist-5E-sw-0.4-candidate as now and unsuccessful builds tag into dist-5E-sw-0.4. Final Spacewalk create from dist-5E-sw-0.4 tag. For nightly builds, let call make test-srpm on untagged packages and build in koji the packages with .git.longsha1 dist tag. This way you make sure when somebody finally tag the package (which bump up the version automatically) such package will be upgraded to last version. I prefer this option. Im assuming that you mean moving successful builds into dist-5E-sw-0.4 I honestly do not like how when you tag something it bumps the release. I fell that when we do a release all tarballs should be that release so for 0.4 we should have spacewalk-java-0.4.0.tar.gz or spacewalk-java-0.4.0.tar.bz2 and bug fixes in the 0.4 series get 0.4.1 etc every other open source project ive worked with (mysql does something simmiliar to how spacewalk is working) uses RCS snapshots for prerelease testingor in the case of gnome and KDE for 0.4 they would use 0.3.85 etc, I can live with how it currently is though. 3) OK. There is third option. To build .git.longsha1 packages in dist-5E-sw-0.4-candidate and not creating dist-5E-sw-0.4. But it will create only mess. I'm scratching such option. How do you like it? Or do you have another idea how to implement nightly builds? tag dist-5E-sw-0.4 already exists once we get closer to release and start doing QA on the release, i envisioned running koji move-tag on everything in candidate at that time to dist-5E-sw-0.4. we would then sign the packages and do the composes on dist-5E-sw-0.4 which would be what gets pushed out as 0.4. the composes from the candidate tags are testing repos. I expect that the repos from the candidate tags can be used to prove that your build fixes the bugs or adds the features that they are supposed to. and once proven we will move to dist-5E-sw-0.4, sign the package and push it out. I do not thing we are that far away from teh same goals. I just think that doing builds needs to be the deliberate action of an engineer. We can and should make make tag do the build also. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Rebuild of packages in Koji - some problems
On Monday 24 November 2008 02:55:30 am Miroslav Suchý wrote: Last friday I let rebuild of all packages which has tag in git and has not been builded in Koji. Two problems has been found: perl-DBD-Oracle: http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9271 I will take care about it. I thought i fixed it at some point by exporting the path for ORACLE_HOME in both build and install sections stringtree-json http://koji.rhndev.redhat.com/koji/buildinfo?buildID=9307 Missing requires for unzip. Can you - Jesus or Partha - fix it? thats missing BuildRequires unzip its not included in the minimal buildroot ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] API version
On Wednesday 19 November 2008 11:03:45 am Miroslav Suchý wrote: Can we create new API call which add something to distinguish between satellite versioning and spacewalk versioning? I have problem that I want to call proxy.isProxy() which will be only in 0.4+. But the expression if api 0.4 is true for old satellites (like 5.0) as well. I suggest to add some kind of epoch, but I have no idea how to make it compatible with olders api. Any idea? I would suggest using an internal API number that is different from release start with 1.0 and if there is minor changes resultin in incompatabilities just to 1.1 but major changes result in 2.0 or even just start at 100 Personally i do not think it needs to be tied to the spacewalk/satellite release. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Getting Packages Into Fedora
On Monday 13 October 2008 03:16:33 pm Miroslav Suchy wrote: Here comes reminder: https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora Please guys, pick up at least one package and go through Fedora Package Review. Guide: http://fedoraproject.org/wiki/Package_Review_Process#Contributor Feel free to ping me once you create BZ. I can give you review too. or CC me on the bug, if you need a sponsor and you do a good job of packaging i can sponsor you for packager. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Re: Status of monitoring packages
On Monday 29 September 2008 10:28:14 am you wrote: please don't CC me on list email I just today finished cleaning up monitoring packages: spacewalk-proxy-monitoring ConfigPusher-general eventReceivers NOCpulsePlugins NPalert nocpulse-common perl-NOCpulse-CLAC perl-NOCpulse-Debug perl-NOCpulse-Gritch perl-NOCpulse-Object perl-NOCpulse-OracleDB perl-NOCpulse-PersistentConnection perl-NOCpulse-Probe perl-NOCpulse-ProcessPool perl-NOCpulse-Scheduler perl-NOCpulse-SetID perl-NOCpulse-Utils ssl_bridge scdb SNMPAlerts SatConfig-bootstrap SatConfig-bootstrap-server SatConfig-cluster SatConfig-dbsynch SatConfig-general SatConfig-generator SatConfig-installer SatConfig-spread SputLite-client SputLite-server status_log_acceptor tsdb ProgAGoGo NPalert MessageQueue oracle_perl -- renamed to nocpulse-db-perl nslogs -- removed logrotate is defined in nocpulse-common I did: - getting rid of /opt/nocpulse and /opt/notification directories. If you are curious what went where, you can get good overview from sql upgrade script in schema definition, where are all changes together. But basically home dir of nocpulse is now /usr/lib/nocpulse. Configuration this is wrong it should be /var/lib/nocpulse files are in /etc/nocpulse/ and logs are in /var/log/nocpulse. - changes to Makefile, getting rid of source and version files, so packages can actually be built using current infrastructure. - changes to comply with Fedora Guidelines. With those exceptions: ** most of packages are missing documentation. We can either write propper POD section in perl modules or just put in some simple README. ** some packages (especial SatConfig-*) have code in /etc/rc.d/ I did not move it out. I thing I break enough things for now. ** sys.v init scripts need probably some care, to comply with Fedora. Again, I have no morale to break too much stuff. better to break things once and have it right than have to break things multiple times. Several packages are built. But most of them need to be rebuild - Dennis, can you rebuild them in Brew for RHEL (probably in spacewalk-5E-0.3-candidate) [1]? And for Fedora in Koji? Builds should be ok, I tested all packages using make test-rpm, but if there will be some probleme just write me off-list. Nothing spacewalk should be built in brew. it should all be done in koji. Dennis ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
