FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 12-02-2010, 03:02 AM
Douglas McClendon
 
Default Reality V/s Fantasy

On 12/01/2010 08:29 PM, Karanbir Singh wrote:
> On 11/30/2010 02:33 AM, Douglas McClendon wrote:
>> "And you can still file such issues against centos-5, its an ongoing
>> effort not a open/shut situation. So we can still fix stuff in the next
>> version"
>> Note my very intentional use of the phrase "good-faith". It's as
>> legaleze as I get, but I think that is the heart of it.
>
> ah ok, what I meant to say was that if someone finds an issue even after
> release, we would try and fix that right away. Didnt mean to imply that
> we're lax or dont take the initial audit seriously.

And that's what I thought you meant, and what I meant as well. Perhaps
the illustration of our disagreement, is my belief that upstream legal
would indeed be more forgiving of packages 'published' to the
development community, as development packages, versus packages
published as a product for end users. I.e. that it is not necessary for
legal purposes to keep development behind closed doors _as long as a
good-faith effort is made_.


>
>>> http://wiki.centos.org/QaWiki/6/AuditStatus is a brief report I put
>>> together yesterday, I will try and get it finished up in a few hours time.
>> Looks good, though as with the method of gleaming the progress-meter
>> number via the bug system, it is the closed section of that list that I
>> would get excited about seeing growing day by day.
>
> There are a few more additions to the page i need to roll out, will try
> and do that in the morning.

Ok. What I couldn't understand before (and now), is whether or not a
package being on the closed list (which is currently still at 0/XXXX)
can be inferred from a state in the bug system. I.e. was a single bug
created by default for every package?

>
>> source control tree somewhere? Or I'm just being stupid and lazy and
>> for the majority of cases your srpms are literally renames of binary
>> srpms that have no branding to strip even in the specfile because that
>> all gets added to the binary rpm during build.
>
> not at all sure what you mean by 'srpms are literally renames of binary
> srpms'. I did read it a few times
>
> Think about this :
>
> Patches for branding issues need to be done at the srpm payload level,
> and not as a patch in the .spec

Yeah I could have been clearer. I understand this. My question would
be- Suppose package xyz requires 3 text changes to the specfile, 2
images removed from the srpm payload, 2 images added to the srpm
payload, and 1 extra patch to source with accompanying specfile
application. That set of things is the delta from upstream. Is that
set of things stored in source control? Or is the only place it is
stored in the srpm that you publish in your repository?

As a person with an esoteric interest in forking of distros, I've often
considered such systems. I.e. I imagine it might be useful to encode
the above in a kind of .dsrpm, i.e. 'delta srpm', which could be applied
to an srpm, and then in the best case, when an upstream update comes to
that srpm, can be trivially reapplied via some utility, as opposed to a
person doing a manual rpm -i .srpm, commands on commandline, rpmbuild
-bs ...



>
>> But even so, I think you weren't seeing that I was talking about going
>> beyond auditing, and toward fixing. I.e. someones first pass at a fix
>> needs to be visible to a second person to do a second check of it.
>
> but isnt all that public in the bugs.c.o interface ? We just havent had
> too many patches

Where/how would one submit a candidate package? And continuing what I
said above, it seems it would be better to submit some kind of
standardized delta instead of a package. Realize I do know how noob
those questions sound. And how passive-agressive that sounds. I guess
what is missing is the wiki walkthrough description of how
brandstripping one example package goes. And you've mentioned I think
why you don't want to invest time in such a tutorial, though I suspect
you've wasted more time discussing it with me already

>
>> I guess seems odd asking for work from contributors, and giving them
>> less 'inside access' than the qa team. I posit that perhaps your
>
> One of the main things that the QA team needs to work with is
> whitelisting for release, the branding stuff. That intself means the qa
> team needs to stay small, non public access to early code builds.

Right there you draw a conclusion in the second sentence from the first.
But I don't follow the reasoning. I would even reach the opposite
conclusion, but I do defer to your authority and experience.


Also
> the QA team are small, perhaps 10 people in all. Which means we find the
> main issues quickly and can work on very basic communication means.
>
>> so all you have in source control is srpms?
>
> pretty much
>
>> are many of them 100% unmodified from upstream other than renaming the
>> file (if that)?
>
> renaming what file ?

Again, a noob question.

(from rhel5server)
anaconda-11.1.2.209-1.src.rpm
to
(centos5)
anaconda-11.1.2.209-1.el5.centos.src.rpm


i.e. in what percent of these instances, do these two files not contain
identical bits? My first presumption would have been 0%, but then I
started thinking maybe it was 90%. (obviously anaconda would have brand
to strip, or at least I strongly presume so)

-dmc

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 03:15 AM
Douglas McClendon
 
Default Reality V/s Fantasy

On 12/01/2010 09:14 PM, Stephen John Smoogen wrote:
> On Mon, Nov 29, 2010 at 19:33, Douglas McClendon
> <dmc.centos@filteredperception.org> wrote:
>
>> so all you have in source control is srpms?
>>
>> are many of them 100% unmodified from upstream other than renaming the
>> file (if that)?
>
> Files are generally not renamed. What needs to be done is
>
> a) Look through compiled items for trademarks in images and documents.
> b) Look in source code to see where those images may be called or implanted.
> c) all corner cases not covered by a or b
>
> For a) it requires a source code change as a patch in the source RPM
> as the trademark would still be distributed for b) it requires a patch
> to say from
>
> a href="redhat.png" -> a href="centos.png"
>
> c) usually comes up as requiring a request to Karanbir of whether this
> covers a problem or not.
>
> To get an idea of what is changed in a release look at all the
> .src.rpms in say CentOS-5 with .centos.src.rpm in them.


ahh. I didn't see your message when crafting my response. Just now I
looked back at the c5 srpm list and noticed that the example I chose was
actually surrounded by examples absent the .centos suffix.

That clears things up a lot I think. So the ones without the .centos
suffix are entirely unchanged from upstream. Got it.

-dmc
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 03:57 AM
JohnS
 
Default Reality V/s Fantasy

On Wed, 2010-12-01 at 22:02 -0600, Douglas McClendon wrote:

> Where/how would one submit a candidate package? And continuing what I
> said above, it seems it would be better to submit some kind of
> standardized delta instead of a package. Realize I do know how noob
> those questions sound. And how passive-agressive that sounds. I guess
> what is missing is the wiki walkthrough description of how
> brandstripping one example package goes. And you've mentioned I think
> why you don't want to invest time in such a tutorial, though I suspect
> you've wasted more time discussing it with me already

You would file a bug report against that package here [1] under the
CentOS 6 Section. You really do not need to upload the source rpm. All
you need to do is file the report with what needs changing and where at
or along with the needed patch. If the patch needs to be done in
specific order say so. Maybe the spec file when also providing patches.

There are some sources I have looked at that really only Karanbir would
know what is need because they deal with internal centos
infrastructure.

John

[1] http://bugs.centos.org/my_view_page.php


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 04:11 AM
raj kannan
 
Default Reality V/s Fantasy

help me
Zimbra install On CentOS DNS ALSO


On Thu, Dec 2, 2010 at 10:27 AM, JohnS <jses27@gmail.com> wrote:



On Wed, 2010-12-01 at 22:02 -0600, Douglas McClendon wrote:



> Where/how would one submit a candidate package? *And continuing what I

> said above, it seems it would be better to submit some kind of

> standardized delta instead of a package. *Realize I do know how noob

> those questions sound. *And how passive-agressive that sounds. *I guess

> what is missing is the wiki walkthrough description of how

> brandstripping one example package goes. *And you've mentioned I think

> why you don't want to invest time in such a tutorial, though I suspect

> you've wasted more time discussing it with me already



You would file a bug report against that package here [1] under the

CentOS 6 Section. *You really do not need to upload the source rpm. *All

you need to do is file the report with what needs changing and where at

or along with the needed patch. *If the patch needs to be done in

specific order say so. *Maybe the spec file when also providing patches.



There are some sources I have looked at that really only Karanbir would

know what is need because they deal with internal centos

infrastructure.



John



[1] http://bugs.centos.org/my_view_page.php





_______________________________________________

CentOS-devel mailing list

CentOS-devel@centos.org

http://lists.centos.org/mailman/listinfo/centos-devel



--
Yours Sincerely
G.Raj kannan
System Administrator

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 07:27 AM
Karanbir Singh
 
Default Reality V/s Fantasy

Hi,

On 12/02/2010 05:11 AM, raj kannan wrote:
> Zimbra install On CentOS DNS ALSO

Please take your question to a more relevant forum. Perhaps the CentOS
users list, or even the zimbra lists.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 08:31 AM
Florian La Roche
 
Default Reality V/s Fantasy

Hello KB,

> One of the main things that the QA team needs to work with is
> whitelisting for release, the branding stuff. That intself means the qa
> team needs to stay small, non public access to early code builds. Also

Red Hat distributes the source without restrictions and e.g. kernel.org
is mirroring it out on all its mirror systems, so there is no requirement
to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.

I agree that binaries should maybe be kept until the branding and major
patching items are resolved, but clearly all this is a chicken-egg situation
on how to grow the participation for CentOS, right?

regards,

Florian La Roche

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 08:54 PM
Ralph Angenendt
 
Default Reality V/s Fantasy

Am 02.12.10 10:31, schrieb Florian La Roche:
> Hello KB,
>
>> One of the main things that the QA team needs to work with is
>> whitelisting for release, the branding stuff. That intself means the qa
>> team needs to stay small, non public access to early code builds. Also
>
> Red Hat distributes the source without restrictions and e.g. kernel.org
> is mirroring it out on all its mirror systems, so there is no requirement
> to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.

Hmmm. They are redistributing RH code. We try to do that as a different
project. So yes, you might be right, but I'd really like to not step
onto someone's toes inadvertently

Regards,

Ralph
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 08:56 PM
Ralph Angenendt
 
Default Reality V/s Fantasy

Am 02.12.10 05:15, schrieb Douglas McClendon:
> That clears things up a lot I think. So the ones without the .centos
> suffix are entirely unchanged from upstream. Got it.

Exactly. Problem is, that those can have changed with 6

But they are good as examples.

Ralph
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-03-2010, 02:24 PM
Andreas Rogge
 
Default Reality V/s Fantasy

Am 02.12.2010 22:54, schrieb Ralph Angenendt:
> Am 02.12.10 10:31, schrieb Florian La Roche:
>> Hello KB,
>>
>>> One of the main things that the QA team needs to work with is
>>> whitelisting for release, the branding stuff. That intself means the qa
>>> team needs to stay small, non public access to early code builds. Also
>>
>> Red Hat distributes the source without restrictions and e.g. kernel.org
>> is mirroring it out on all its mirror systems, so there is no requirement
>> to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
>
> Hmmm. They are redistributing RH code. We try to do that as a different
> project. So yes, you might be right, but I'd really like to not step
> onto someone's toes inadvertently

We don't need to redistribute the original files. We could make up a way
to have "patches" for SRPMs.
What you do when changing an SRPM is usually the following:
0. download the SRPM
1. extract the SRPM
2. change the SPEC
3. change/add/remove patches and other Sources
4. extract the included tarballs if they need to be changed
5. apply changes to the tarball content
6. repackage the tarballs
7. repackage the SRPM

Afaict this is all scriptable.
0. wget http://whatever.url/the/file/is/located/at.src.rpm
1. rpm -i whatever.src.rpm
2. cd SPEC && patch < spec-changes.patch; cd ..
3. cd SOURCES && patch < source-changes.patch; tar xf sources.tar; cd ..
4. gzip -cd whatever-1.2.3.tgz | tar xCf /tmp -
5. cd /tmp/whatever-1.2.3 && patch < tarball.patch; tar xf tarball.tar
6. cd /tmp tar cf - whatever-1.2.3 | gzip -c9 > whatever-1.2.3.tgz
7. rpmbuild --nodeps -bs whatever.spec

I'll admit that it isn't that simple, but we could have a system to keep
"SRPM patches" around and as these won't contain RH trademarked stuff it
won't hurt.
The to-be-patched SRPMs can be fetched by anyone from the original
source which is also ok.
As you might have noticed I'm suggesting to unpack tarballs into
existing directories. This is to overwrite and replace existing and
"offending" RH stuff. Files that should be removed can simply be
overwritten with 0-byte files (I guess nobody can sue us for a filename
in a tarball)

If something like this is appreciated I could write example-scripts to
do the work.

btw. please CC responses to me (I don't want to take this off-list, I'm
just not reading regularly enough to catch responses in time otherwise).

Regards,
Andreas

--
Solvention Ltd. & Co. KG
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info@solvention.de
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-03-2010, 02:38 PM
Jeff Johnson
 
Default Reality V/s Fantasy

On Dec 3, 2010, at 10:24 AM, Andreas Rogge wrote:


Hi Andreas!

> Am 02.12.2010 22:54, schrieb Ralph Angenendt:
>> Am 02.12.10 10:31, schrieb Florian La Roche:
>>> Hello KB,
>>>
>>>> One of the main things that the QA team needs to work with is
>>>> whitelisting for release, the branding stuff. That intself means the qa
>>>> team needs to stay small, non public access to early code builds. Also
>>>
>>> Red Hat distributes the source without restrictions and e.g. kernel.org
>>> is mirroring it out on all its mirror systems, so there is no requirement
>>> to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
>>
>> Hmmm. They are redistributing RH code. We try to do that as a different
>> project. So yes, you might be right, but I'd really like to not step
>> onto someone's toes inadvertently
>
> We don't need to redistribute the original files. We could make up a way
> to have "patches" for SRPMs.
> What you do when changing an SRPM is usually the following:
> 0. download the SRPM
> 1. extract the SRPM
> 2. change the SPEC
> 3. change/add/remove patches and other Sources
> 4. extract the included tarballs if they need to be changed
> 5. apply changes to the tarball content
> 6. repackage the tarballs
> 7. repackage the SRPM
>

While one can easily imagine the necessary procedure to "patch"
build recipes, its actually a quite painful process to maintain
in the "real world".

(aside)
Applying meta-patches has been attempted with WindRiver Linux,
rather a disaster (imho, there are other benefits to WRL, just
not the meta-patching of build recipes). All JMHO, YMMV.

> Afaict this is all scriptable.
> 0. wget http://whatever.url/the/file/is/located/at.src.rpm
> 1. rpm -i whatever.src.rpm
> 2. cd SPEC && patch < spec-changes.patch; cd ..
> 3. cd SOURCES && patch < source-changes.patch; tar xf sources.tar; cd ..
> 4. gzip -cd whatever-1.2.3.tgz | tar xCf /tmp -
> 5. cd /tmp/whatever-1.2.3 && patch < tarball.patch; tar xf tarball.tar
> 6. cd /tmp tar cf - whatever-1.2.3 | gzip -c9 > whatever-1.2.3.tgz
> 7. rpmbuild --nodeps -bs whatever.spec
>

Its not the scriptable, but rather the process framework to
apply the meta-patch to the build recipe that is the torquemada.

> I'll admit that it isn't that simple, but we could have a system to keep
> "SRPM patches" around and as these won't contain RH trademarked stuff it
> won't hurt.
> The to-be-patched SRPMs can be fetched by anyone from the original
> source which is also ok.
> As you might have noticed I'm suggesting to unpack tarballs into
> existing directories. This is to overwrite and replace existing and
> "offending" RH stuff. Files that should be removed can simply be
> overwritten with 0-byte files (I guess nobody can sue us for a filename
> in a tarball)
>

There are hints here to what tends to called "exploded SRPM's" in
my vocabulary, basically don't bother with all the rituals of
Sources + Patches + Recipe == Reproducible builds
from last century still in use with RPM, but just build straight
from a VCS like git/svn.

One immediate benefit with "exploded SRPM's" is that you can start
to use grep to find what needs changing, and a VCS to track patches
(rather than re-stacking patchsets and other tedious chores when
something changes).

All of "exploded SRPM's" is quite doable and KISSier. But you likely
are stuck with whatever @redhat chooses to do. Oh well ...

> If something like this is appreciated I could write example-scripts to
> do the work.
>

You might want to look at WRL: they essentially have a *BSD ish "make world"
framework on top of traditional rpmbuild invocations. The design (because
it refactors per-package goop into a per-buildsys framework) is perfectly
sane even if the reults (imho) are rather awkward for "package monkeys".

> btw. please CC responses to me (I don't want to take this off-list, I'm
> just not reading regularly enough to catch responses in time otherwise).
>

CC done

hth

73 de Jeff

> Regards,
> Andreas
>
> --
> Solvention Ltd. & Co. KG
> Egermannstr. 6-8
> 53359 Rheinbach
>
> Tel: +49 2226 158179-0
> Fax: +49 2226 158179-9
>
> http://www.solvention.de
> mailto:info@solvention.de
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel@centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 09:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org