From jwboyer at jdub.homelinux.org Mon Oct 10 20:02:45 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 10 Oct 2005 15:02:45 -0500 Subject: License for FE infrastructure? Message-ID: <1128974565.32503.16.camel@windu.rchland.ibm.com> Hi All, I was wondering if there is a license for the infrastructure code (Makefiles, scripts, etc) in the common directory. I believe the intention of the Extras project was that all of the infrastructure would be fully open source, however there is no explicit license statement. So my questions are: 1) Is there a license, if so what is it? 2) If 1 is yes, would a simply LICENSE file in the common directory suffice? We obviously don't package and release this stuff, so I'm just looking for some indication we can have to let people know if there is a license or not. thx, josh From gdk at redhat.com Mon Oct 10 20:04:04 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 10 Oct 2005 16:04:04 -0400 (EDT) Subject: License for FE infrastructure? In-Reply-To: <1128974565.32503.16.camel@windu.rchland.ibm.com> References: <1128974565.32503.16.camel@windu.rchland.ibm.com> Message-ID: Good question. We'll get an answer to you soon. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Mon, 10 Oct 2005, Josh Boyer wrote: > Hi All, > > I was wondering if there is a license for the infrastructure code > (Makefiles, scripts, etc) in the common directory. I believe the > intention of the Extras project was that all of the infrastructure would > be fully open source, however there is no explicit license statement. > > So my questions are: > > 1) Is there a license, if so what is it? > 2) If 1 is yes, would a simply LICENSE file in the common directory > suffice? > > We obviously don't package and release this stuff, so I'm just looking > for some indication we can have to let people know if there is a license > or not. > > thx, > josh > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From sundaram at redhat.com Thu Oct 13 18:55:48 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 14 Oct 2005 00:25:48 +0530 Subject: List of rejected packages Message-ID: <434EADB4.4000605@redhat.com> Hi Packages in Fedora Extras are on occasions rejected due to licensing, patents or other such restrictions. Forbidden Items* documents the reason behind some of them which are frequently asked for but a more comprehensive list of all such rejected packages with the reason they have been rejected from Fedora Extras repository would be useful. Once we create such a list, we can add it to the packages and reviewers check list for things to avoid. The list can be kept updated by reviewers and other contributors.As the number of packages in the repository increase rapidly a list of such rejected packages would also be useful to end users to understand what packages not to request for inclusion and the reason behind them. regards Rahul * http://fedoraproject.org/wiki/ForbiddenItems From bnocera at redhat.com Thu Oct 13 19:28:47 2005 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 13 Oct 2005 20:28:47 +0100 Subject: List of rejected packages In-Reply-To: <434EADB4.4000605@redhat.com> References: <434EADB4.4000605@redhat.com> Message-ID: <1129231727.3062.12.camel@randel.hadess.net> On Fri, 2005-10-14 at 00:25 +0530, Rahul Sundaram wrote: > Hi "DVD playback * DVD playback (of CSS encrypted DVDs) may be a violation of the [WWW]US DMCA, because it may be considered circumventing a copyright protection mechanism. Additionally, MPEG2 is a patented codec, so even DVDs without encryption cannot be played. Fedora Suggests: Using patent-free formats such as Ogg Theora is highly recommended. " Arf, arf, arf. Would something like this "Sorry, you can't play your audio CDs, please consider downloading them from a dodgy Korean website as Ogg Vorbis files instead" make sense to you? In this case, I'd say: Fedora Suggests: "Donate money to the EFF, and lobby your local political leaders to abolish software patents", or even removing the suggestion. -- Bastien Nocera From sundaram at redhat.com Thu Oct 13 19:34:55 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 14 Oct 2005 01:04:55 +0530 Subject: List of rejected packages In-Reply-To: <1129231727.3062.12.camel@randel.hadess.net> References: <434EADB4.4000605@redhat.com> <1129231727.3062.12.camel@randel.hadess.net> Message-ID: <434EB6DF.9040800@redhat.com> Bastien Nocera wrote: >On Fri, 2005-10-14 at 00:25 +0530, Rahul Sundaram wrote: > > >>Hi >> >> > > >"DVD playback > > * DVD playback (of CSS encrypted DVDs) may be a violation of the > [WWW]US DMCA, because it may be considered circumventing a > copyright protection mechanism. Additionally, MPEG2 is a > patented codec, so even DVDs without encryption cannot be > played. > > Fedora Suggests: Using patent-free formats such as Ogg Theora is > highly recommended. >" > >Arf, arf, arf. Would something like this "Sorry, you can't play your >audio CDs, please consider downloading them from a dodgy Korean website >as Ogg Vorbis files instead" make sense to you? > >In this case, I'd say: >Fedora Suggests: "Donate money to the EFF, and lobby your local >political leaders to abolish software patents", or even removing the >suggestion. > > > You have a point and its a wiki. go ahead and edit it. http://fedoraproject.org/wiki/WikiEditing regards Rahul From dwmw2 at infradead.org Fri Oct 14 14:05:37 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Oct 2005 16:05:37 +0200 Subject: List of rejected packages In-Reply-To: <1129231727.3062.12.camel@randel.hadess.net> References: <434EADB4.4000605@redhat.com> <1129231727.3062.12.camel@randel.hadess.net> Message-ID: <1129298737.5051.0.camel@localhost.localdomain> On Thu, 2005-10-13 at 20:28 +0100, Bastien Nocera wrote: > Arf, arf, arf. Would something like this "Sorry, you can't play your > audio CDs, please consider downloading them from a dodgy Korean > website as Ogg Vorbis files instead" make sense to you? > > In this case, I'd say: > Fedora Suggests: "Donate money to the EFF, and lobby your local > political leaders to abolish software patents", or even removing the > suggestion. In the specific case of items sold as audio CDs but which turn out _not_ to comply with that specification, the suggestion should be to report the problem to local trading standards officials. -- dwmw2 From pjones at redhat.com Fri Oct 14 19:14:08 2005 From: pjones at redhat.com (Peter Jones) Date: Fri, 14 Oct 2005 15:14:08 -0400 Subject: List of rejected packages In-Reply-To: <1129298737.5051.0.camel@localhost.localdomain> References: <434EADB4.4000605@redhat.com> <1129231727.3062.12.camel@randel.hadess.net> <1129298737.5051.0.camel@localhost.localdomain> Message-ID: <1129317248.5334.4.camel@localhost.localdomain> On Fri, 2005-10-14 at 16:05 +0200, David Woodhouse wrote: > On Thu, 2005-10-13 at 20:28 +0100, Bastien Nocera wrote: > > Arf, arf, arf. Would something like this "Sorry, you can't play your > > audio CDs, please consider downloading them from a dodgy Korean > > website as Ogg Vorbis files instead" make sense to you? > > > > In this case, I'd say: > > Fedora Suggests: "Donate money to the EFF, and lobby your local > > political leaders to abolish software patents", or even removing the > > suggestion. > > In the specific case of items sold as audio CDs but which turn out _not_ > to comply with that specification, the suggestion should be to report > the problem to local trading standards officials. Except that won't do much good -- usually they're clever enough not o use the CD logo or call it a CD. The most common example these days is DualDisc, which is roughly CDDA-like on one side, but the substrate is too thin, so some drives can't focus on it. On the other side it's a perfectly valid DVD. They, like most of the "we'll mess with the Table of Contents so things read it wrong", generally don't use the Compact Disc term or logos. -- Peter From dwmw2 at infradead.org Fri Oct 14 20:06:15 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Oct 2005 22:06:15 +0200 Subject: List of rejected packages In-Reply-To: <1129317248.5334.4.camel@localhost.localdomain> References: <434EADB4.4000605@redhat.com> <1129231727.3062.12.camel@randel.hadess.net> <1129298737.5051.0.camel@localhost.localdomain> <1129317248.5334.4.camel@localhost.localdomain> Message-ID: <1129320376.5051.34.camel@localhost.localdomain> On Fri, 2005-10-14 at 15:14 -0400, Peter Jones wrote: > They, like most of the "we'll mess with the Table of Contents so things > read it wrong", generally don't use the Compact Disc term or logos. Nevertheless, the shops tend to put them on the shelves with real CDs and don't clearly mark the fact that they are _not_ CDs. The shops have a duty of care to their customers, which they are failing to fulfil. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Oct 17 14:06:56 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 17 Oct 2005 16:06:56 +0200 Subject: License for FE infrastructure? In-Reply-To: References: <1128974565.32503.16.camel@windu.rchland.ibm.com> Message-ID: <20051017160656.55e78a42@python2> Greg DeKoenigsberg wrote : > Josh Boyer wrote : > > > I was wondering if there is a license for the infrastructure code > > (Makefiles, scripts, etc) in the common directory. I believe the > > intention of the Extras project was that all of the infrastructure would > > be fully open source, however there is no explicit license statement. > > > > So my questions are: > > > > 1) Is there a license, if so what is it? > > 2) If 1 is yes, would a simply LICENSE file in the common directory > > suffice? > > > > We obviously don't package and release this stuff, so I'm just looking > > for some indication we can have to let people know if there is a license > > or not. > > Good question. We'll get an answer to you soon. Seems like the situation was taken care of but the answer wasn't posted here. Take a look at the top of the latest Makefile.common and you'll see that it's "newBSD" licensed ;-) Thanks for raising the initial concern. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.13-1.1526_FC4 Load : 0.06 0.27 0.35 From dcbw at redhat.com Mon Oct 17 18:08:57 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Oct 2005 14:08:57 -0400 Subject: Extras build system back up Message-ID: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> Hi, We're back up and using the latest plague code. yum update your plague-client and you should be good to go. Dan From chrisw at osdl.org Mon Oct 17 20:16:19 2005 From: chrisw at osdl.org (Chris Wright) Date: Mon, 17 Oct 2005 13:16:19 -0700 Subject: Extras build system back up In-Reply-To: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> Message-ID: <20051017201619.GB30904@shell0.pdx.osdl.net> * Dan Williams (dcbw at redhat.com) wrote: > We're back up and using the latest plague code. yum update your > plague-client and you should be good to go. Anything else that needs to be done? w at vas devel]$ plague-client build git-core git-core-0_99_8d-1_fc5 devel Traceback (most recent call last): File "/usr/bin/plague-client", line 426, in ? cli.dispatch(cmd, sys.argv[2:]) File "/usr/bin/plague-client", line 372, in dispatch func(args) File "/usr/bin/plague-client", line 172, in _cmd_build self._enqueue(is_srpm, package, source, target_alias) File "/usr/bin/plague-client", line 197, in _enqueue if self._cfg.get_bool("Server", "allow_uploads"): File "/usr/lib/python2.3/site-packages/plague/BaseConfig.py", line 51, in get_bool opt = self.get_option(section, name) File "/usr/lib/python2.3/site-packages/plague/BaseConfig.py", line 45, in get_option raise ConfigError("Config file %s does not have option: %s/%s" % (self._filename, section, name)) plague.BaseConfig.ConfigError: Config file /home/chrisw/.plague-client.cfg does not have option: Server/allow_uploads [chrisw at vas devel]$ vim /home/chrisw/.plague-client.cfg [chrisw at vas devel]$ plague-client build git-core git-core-0_99_8d-1_fc5 devel Error connecting to build server: '' From dcbw at redhat.com Mon Oct 17 21:15:51 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Oct 2005 17:15:51 -0400 Subject: Extras build system back up In-Reply-To: <20051017201619.GB30904@shell0.pdx.osdl.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> Message-ID: <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> On Mon, 2005-10-17 at 13:16 -0700, Chris Wright wrote: > * Dan Williams (dcbw at redhat.com) wrote: > > We're back up and using the latest plague code. yum update your > > plague-client and you should be good to go. > > Anything else that needs to be done? > > w at vas devel]$ plague-client build git-core git-core-0_99_8d-1_fc5 devel > Traceback (most recent call last): > File "/usr/bin/plague-client", line 426, in ? > cli.dispatch(cmd, sys.argv[2:]) > File "/usr/bin/plague-client", line 372, in dispatch > func(args) > File "/usr/bin/plague-client", line 172, in _cmd_build > self._enqueue(is_srpm, package, source, target_alias) > File "/usr/bin/plague-client", line 197, in _enqueue > if self._cfg.get_bool("Server", "allow_uploads"): > File "/usr/lib/python2.3/site-packages/plague/BaseConfig.py", line 51, in get_bool > opt = self.get_option(section, name) > File "/usr/lib/python2.3/site-packages/plague/BaseConfig.py", line 45, in get_option > raise ConfigError("Config file %s does not have option: %s/%s" % (self._filename, section, name)) > plague.BaseConfig.ConfigError: Config file /home/chrisw/.plague-client.cfg does not have option: Server/allow_uploads > [chrisw at vas devel]$ vim /home/chrisw/.plague-client.cfg > [chrisw at vas devel]$ plague-client build git-core git-core-0_99_8d-1_fc5 devel > Error connecting to build server: '' As I see you've figured out, it should be fixed now. Server-side issue with some database fields being way too small. They are larger now :) Dan From chrisw at osdl.org Mon Oct 17 21:28:01 2005 From: chrisw at osdl.org (Chris Wright) Date: Mon, 17 Oct 2005 14:28:01 -0700 Subject: Extras build system back up In-Reply-To: <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> Message-ID: <20051017212801.GJ5856@shell0.pdx.osdl.net> * Dan Williams (dcbw at redhat.com) wrote: > As I see you've figured out, it should be fixed now. Server-side issue > with some database fields being way too small. They are larger now :) Yes, thanks. Is [Server] ... allow_uploads = True the recommended change to config? I notice plague list once creates config with allow_uploads = no thanks, -chris From dcbw at redhat.com Tue Oct 18 01:56:52 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Oct 2005 21:56:52 -0400 Subject: Extras build system back up In-Reply-To: <20051017212801.GJ5856@shell0.pdx.osdl.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> Message-ID: <1129600612.8182.1.camel@localhost.localdomain> On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > * Dan Williams (dcbw at redhat.com) wrote: > > As I see you've figured out, it should be fixed now. Server-side issue > > with some database fields being way too small. They are larger now :) > > Yes, thanks. Is > > [Server] > ... > allow_uploads = True > > the recommended change to config? > > I notice plague list once creates config with > > allow_uploads = no It's a feature that requires server-side support too, which is currently disabled on the Extras server since we build from CVS. Therefore, for Extras, it has no effect either way. What this option does, if you've enabled server-side support though, is to allow users to upload SRPMs to the build server via 'scp', providing you have an account there. Dan From rc040203 at freenet.de Tue Oct 18 02:40:19 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 18 Oct 2005 04:40:19 +0200 Subject: Extras build system back up In-Reply-To: <1129600612.8182.1.camel@localhost.localdomain> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> <1129600612.8182.1.camel@localhost.localdomain> Message-ID: <1129603219.5390.237.camel@mccallum.corsepiu.local> On Mon, 2005-10-17 at 21:56 -0400, Dan Williams wrote: > On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > > * Dan Williams (dcbw at redhat.com) wrote: > > > As I see you've figured out, it should be fixed now. Server-side issue > > > with some database fields being way too small. They are larger now :) > > > > Yes, thanks. Is > > > > [Server] > > ... > > allow_uploads = True > > > > the recommended change to config? > > > > I notice plague list once creates config with > > > > allow_uploads = no > > It's a feature that requires server-side support too, which is currently > disabled on the Extras server since we build from CVS. Therefore, for > Extras, it has no effect either way. Well, apparently it does have an effect: # make plague Enter passphrase for key '/users/xxxx/.ssh/id_dsa': /usr/bin/plague-client build perl-Business-Hours perl-Business-Hours-0_07-1_fc5 devel Traceback (most recent call last): File "/usr/bin/plague-client", line 426, in ? cli.dispatch(cmd, sys.argv[2:]) File "/usr/bin/plague-client", line 372, in dispatch func(args) File "/usr/bin/plague-client", line 172, in _cmd_build self._enqueue(is_srpm, package, source, target_alias) File "/usr/bin/plague-client", line 197, in _enqueue if self._cfg.get_bool("Server", "allow_uploads"): File "/usr/lib/python2.4/site-packages/plague/BaseConfig.py", line 51, in get_bool opt = self.get_option(section, name) File "/usr/lib/python2.4/site-packages/plague/BaseConfig.py", line 45, in get_option raise ConfigError("Config file %s does not have option: %s/%s" % (self._filename, section, name)) plague.BaseConfig.ConfigError: Config file /users/xxxx/.plague-client.cfg does not have option: Server/allow_uploads make: *** [plague] Error 1 Ralf From dcbw at redhat.com Tue Oct 18 16:22:45 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 18 Oct 2005 12:22:45 -0400 Subject: Extras build system back up In-Reply-To: <1129603219.5390.237.camel@mccallum.corsepiu.local> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> <1129600612.8182.1.camel@localhost.localdomain> <1129603219.5390.237.camel@mccallum.corsepiu.local> Message-ID: <1129652565.9685.3.camel@localhost.localdomain> On Tue, 2005-10-18 at 04:40 +0200, Ralf Corsepius wrote: > On Mon, 2005-10-17 at 21:56 -0400, Dan Williams wrote: > > On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > > > * Dan Williams (dcbw at redhat.com) wrote: > > > > As I see you've figured out, it should be fixed now. Server-side issue > > > > with some database fields being way too small. They are larger now :) > > > > > > Yes, thanks. Is > > > > > > [Server] > > > ... > > > allow_uploads = True > > > > > > the recommended change to config? > > > > > > I notice plague list once creates config with > > > > > > allow_uploads = no > > > > It's a feature that requires server-side support too, which is currently > > disabled on the Extras server since we build from CVS. Therefore, for > > Extras, it has no effect either way. > > Well, apparently it does have an effect: It has an no effect _as long as its there_, once you've added it to the config file. Dan From skvidal at phy.duke.edu Wed Oct 19 07:23:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 19 Oct 2005 03:23:32 -0400 Subject: failed builds and logs Message-ID: <1129706612.30517.105.camel@cutter> Hi Everyone, Just a heads up - I made a minor change to the buildsys log retention. Up to this point we were keeping build logs around pretty much forever. Well, yah, that gets big. Really big. So we're keeping them for 15 days and then they'll be tmpwatch reaped away. I figure if you haven't been able to look at your extras failed build report w/i 2 weeks then you can just request the build again. :) -sv From kwade at redhat.com Thu Oct 20 07:44:56 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Oct 2005 00:44:56 -0700 Subject: List of rejected packages In-Reply-To: <1129231727.3062.12.camel@randel.hadess.net> References: <434EADB4.4000605@redhat.com> <1129231727.3062.12.camel@randel.hadess.net> Message-ID: <1129794296.18168.460.camel@erato.phig.org> On Thu, 2005-10-13 at 20:28 +0100, Bastien Nocera wrote: > Arf, arf, arf. Would something like this "Sorry, you can't play your > audio CDs, please consider downloading them from a dodgy Korean website > as Ogg Vorbis files instead" make sense to you? > > In this case, I'd say: > Fedora Suggests: "Donate money to the EFF, and lobby your local > political leaders to abolish software patents", or even removing the > suggestion. Yes, as an addition, but not instead of the previous statement. We are providing alternative technology suggestions from the stand point that we have no clue what they intend to do with the technology. Just like we won't say to do such-and-so to avoid DVD encryption, we won't go suggesting how to rip DVD to Ogg, or find Ogg files for download. For those with legitimate video codec needs, we are doing them the favor of making it clear what is the most supportable format. In fact, that is the only thing we can safely tell them. Well, aside from the EFF pitch. :) - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Oct 20 07:49:11 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 20 Oct 2005 00:49:11 -0700 Subject: Handling mandatory config file updates In-Reply-To: <1128015418.2458.4.camel@localhost.localdomain> References: <1128007943.6688.13.camel@wombat.tiptoe.de> <1128015418.2458.4.camel@localhost.localdomain> Message-ID: <1129794551.18168.463.camel@erato.phig.org> On Thu, 2005-09-29 at 20:36 +0300, Ville Skytt? wrote: > Also, dunno if there will be release notes for FE. There _could_ be. That is, there are appropriate sections within the existing release notes, such as the Packages beat, that could have some FE discussions. OTOH, the beats are fluid. If someone is interested in wrangling content for FE as a beat writer, step up and take the reins. It certainly makes sense to me that a section of the FC relnotes would be devoted to FE. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alexl at redhat.com Fri Oct 21 16:30:33 2005 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 21 Oct 2005 18:30:33 +0200 Subject: Moving packages from extras to core Message-ID: <1129912233.13150.43.camel@greebo> I'm packaging Avahi for Fedora Core, and it depends on libdaemon, so we have to ship that in Core too. However, this already exists in extras (although the version is too old for Avahi) so we need to actually move it into core. I can do the Core side of the work, in fact I have already updated the package to a more recent version and made a few changes to the specfile. The question is, how do we handle removing the version in extras, in favour of the core version? Has this been done before? Also, how will this work wrt maintainership of the package? I'm fine with owning this package inside redhat, but I don't want to steal it from the current extras maintainer (cc:ed). I just needed it in core due to the Avahi dependency. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scrappy zombie vampire hunter who hangs with the wrong crowd. She's a green-fingered punk mechanic who can talk to animals. They fight crime! From dwmw2 at infradead.org Fri Oct 21 17:11:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 21 Oct 2005 18:11:14 +0100 Subject: Moving packages from extras to core In-Reply-To: <1129912233.13150.43.camel@greebo> References: <1129912233.13150.43.camel@greebo> Message-ID: <1129914674.15431.151.camel@baythorne.infradead.org> On Fri, 2005-10-21 at 18:30 +0200, Alexander Larsson wrote: > I'm packaging Avahi for Fedora Core, and it depends on libdaemon, so we > have to ship that in Core too. However, this already exists in extras > (although the version is too old for Avahi) so we need to actually move > it into core. On a similar note, we need to move apmud into Core too. -- dwmw2 From ville.skytta at iki.fi Fri Oct 21 20:04:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 21 Oct 2005 23:04:27 +0300 Subject: Moving packages from extras to core In-Reply-To: <1129912233.13150.43.camel@greebo> References: <1129912233.13150.43.camel@greebo> Message-ID: <1129925067.24295.32.camel@localhost.localdomain> On Fri, 2005-10-21 at 18:30 +0200, Alexander Larsson wrote: > I can do the Core side of the work, in fact I have already updated the > package to a more recent version and made a few changes to the specfile. > The question is, how do we handle removing the version in extras, in > favour of the core version? Has this been done before? Yes, one recent example off the top of my head would be icu. Going from extras to core should be pretty straightforward; it's just a matter of letting the extras maintainer know about the plan, importing the package to core, bumping the release so that it updates the extras one, 'cvs rm'ing the devel branch of the package from extras CVS, and finally requesting removal from the extras devel repository, currently: http://fedoraproject.org/wiki/Extras/FC5Status > Also, how will this work wrt maintainership of the package? I'm fine > with owning this package inside redhat, but I don't want to steal it > from the current extras maintainer (cc:ed). Usually that question reduces to figuring out whether the new core maintainer of the package wishes to maintain the extras packages too or not. That can be decided between the core/extras maintainers however they see fit. From bugs.michael at gmx.net Sat Oct 22 07:43:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 22 Oct 2005 09:43:30 +0200 Subject: Moving packages from extras to core In-Reply-To: <1129912233.13150.43.camel@greebo> References: <1129912233.13150.43.camel@greebo> Message-ID: <20051022094330.37d1044f.bugs.michael@gmx.net> On Fri, 21 Oct 2005 18:30:33 +0200, Alexander Larsson wrote: > I'm packaging Avahi for Fedora Core, and it depends on libdaemon, so we > have to ship that in Core too. However, this already exists in extras > (although the version is too old for Avahi) so we need to actually move > it into core. > > I can do the Core side of the work, in fact I have already updated the > package to a more recent version and made a few changes to the specfile. > The question is, how do we handle removing the version in extras, in > favour of the core version? Has this been done before? > > Also, how will this work wrt maintainership of the package? I'm fine > with owning this package inside redhat, but I don't want to steal it > from the current extras maintainer (cc:ed). I just needed it in core due > to the Avahi dependency. You didn't Cc the right package maintainer. Don't rely on the spec %changelog. Rely on bugzilla's "Components" list or the owners.list file in Fedora Extras CVS. ifplugd in Extras buildrequires libdaemon, but according to the %changelog I can't tell what its status is. Cannot reach the accounts system and query it. In general, moving a package from Extras into Core is not a problem, provided that the Core package is newer (in Epoch:version-release) than the Extras package and still works with any dependencies it has in Extras. Potential problem with moved packages: A package moved into Core cannot be updated in Extras for older distributions, because that would violate the upgrade path. From nphilipp at redhat.com Tue Oct 25 07:52:24 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 25 Oct 2005 09:52:24 +0200 Subject: Moving packages from extras to core In-Reply-To: <20051022094330.37d1044f.bugs.michael@gmx.net> References: <1129912233.13150.43.camel@greebo> <20051022094330.37d1044f.bugs.michael@gmx.net> Message-ID: <1130226744.19582.8.camel@wombat.tiptoe.de> On Sat, 2005-10-22 at 09:43 +0200, Michael Schwendt wrote: > Potential problem with moved packages: A package moved into Core > cannot be updated in Extras for older distributions, because that would > violate the upgrade path. ... only unless the Extras and Core maintainers talk to each other -- if they do, they can easily sort things out between themselves. This is actually an argument in favour of "Core maintainer == Extras maintainer" (barring certain mental sanity issues which are out of scope for this posting). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From icon at linux.duke.edu Tue Oct 25 18:38:43 2005 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Tue, 25 Oct 2005 14:38:43 -0400 Subject: email address change Message-ID: <1130265523.4620.7.camel@localhost.localdomain> Summary: Request to change icon at linux.duke.edu to icon at fedoraproject.org. Long: Since I'm no longer at Duke, I've been trying to change my various subscriptions to icon at fedoraproject.org from icon at linux.duke.edu. The latter will still work for the forseable future, but I'd like to have a more generic address to be visible on Fedora. I've changed it in RH bugzilla, but apparently I'm now being spammed from cron to open a bugzilla account, which is, well, annoying. :) Could I have it changed globally to icon at fedoraproject.org? Thanks! Cheers, --icon From skvidal at phy.duke.edu Tue Oct 25 18:45:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Oct 2005 14:45:29 -0400 Subject: email address change In-Reply-To: <1130265523.4620.7.camel@localhost.localdomain> References: <1130265523.4620.7.camel@localhost.localdomain> Message-ID: <1130265929.18955.125.camel@cutter> On Tue, 2005-10-25 at 14:38 -0400, Konstantin Ryabitsev wrote: > Summary: > Request to change icon at linux.duke.edu to icon at fedoraproject.org. > > Long: > Since I'm no longer at Duke, I've been trying to change my various > subscriptions to icon at fedoraproject.org from icon at linux.duke.edu. The > latter will still work for the forseable future, but I'd like to have a > more generic address to be visible on Fedora. I've changed it in RH > bugzilla, but apparently I'm now being spammed from cron to open a > bugzilla account, which is, well, annoying. :) Could I have it changed > globally to icon at fedoraproject.org? > actually, I wouldn't mind having all of my account info switched to skvidal at fedoraproject.org, too. Should we write up the process to make this switch in the wiki somewhere? 1. bugzilla change. 2. change owners.list 3. ..... profit? -sv From sopwith at redhat.com Tue Oct 25 18:48:25 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 25 Oct 2005 14:48:25 -0400 (EDT) Subject: email address change In-Reply-To: <1130265929.18955.125.camel@cutter> References: <1130265523.4620.7.camel@localhost.localdomain> <1130265929.18955.125.camel@cutter> Message-ID: On Tue, 25 Oct 2005, seth vidal wrote: > On Tue, 2005-10-25 at 14:38 -0400, Konstantin Ryabitsev wrote: > > Summary: > > Request to change icon at linux.duke.edu to icon at fedoraproject.org. > > > > Long: > > Since I'm no longer at Duke, I've been trying to change my various > > subscriptions to icon at fedoraproject.org from icon at linux.duke.edu. The > > latter will still work for the forseable future, but I'd like to have a > > more generic address to be visible on Fedora. I've changed it in RH > > bugzilla, but apparently I'm now being spammed from cron to open a > > bugzilla account, which is, well, annoying. :) Could I have it changed > > globally to icon at fedoraproject.org? > > > > actually, I wouldn't mind having all of my account info switched to > skvidal at fedoraproject.org, too. > > Should we write up the process to make this switch in the wiki > somewhere? > > 1. bugzilla change. 1.1 Fedora Account System change. > 2. change owners.list -- Elliot From alexl at redhat.com Wed Oct 26 07:06:42 2005 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 26 Oct 2005 09:06:42 +0200 Subject: Moving packages from extras to core In-Reply-To: <1129925067.24295.32.camel@localhost.localdomain> References: <1129912233.13150.43.camel@greebo> <1129925067.24295.32.camel@localhost.localdomain> Message-ID: <1130310402.13150.113.camel@greebo> On Fri, 2005-10-21 at 23:04 +0300, Ville Skytt? wrote: > On Fri, 2005-10-21 at 18:30 +0200, Alexander Larsson wrote: > > > I can do the Core side of the work, in fact I have already updated the > > package to a more recent version and made a few changes to the specfile. > > The question is, how do we handle removing the version in extras, in > > favour of the core version? Has this been done before? > > Yes, one recent example off the top of my head would be icu. > > Going from extras to core should be pretty straightforward; it's just a > matter of letting the extras maintainer know about the plan, importing > the package to core, bumping the release so that it updates the extras > one, 'cvs rm'ing the devel branch of the package from extras CVS, and > finally requesting removal from the extras devel repository, currently: > http://fedoraproject.org/wiki/Extras/FC5Status > > > Also, how will this work wrt maintainership of the package? I'm fine > > with owning this package inside redhat, but I don't want to steal it > > from the current extras maintainer (cc:ed). > > Usually that question reduces to figuring out whether the new core > maintainer of the package wishes to maintain the extras packages too or > not. That can be decided between the core/extras maintainers however > they see fit. I have now build libdaemon in Fedora Core. How do we move on from here? I don't actually have an extras account right now. (CC:in the right extras maintainer (i hope) this time). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scarfaced soccer-playing filmmaker for the 21st century. She's a tortured kleptomaniac schoolgirl living on borrowed time. They fight crime!