From muayyad.alsadi at ojuba.org Thu Oct 2 21:53:15 2008 From: muayyad.alsadi at ojuba.org (=?UTF-8?Q?=D9=85=D8=A4=D9=8A=D8=AF_=D8=A7=D9=84=D8=B3=D8=B9=D8=AF=D9=8A?=) Date: Fri, 03 Oct 2008 00:53:15 +0300 Subject: controlling the highlighted/focused language or KB_layout Message-ID: <7626eb4ddd8bee15a0baaac4091d30b5@localhost> hi, the file that creates the language dialog is iw/language_gui.py for locale in self.instLang.available(): iter = self.listStore.append() ... later it highlight one language by default current = self.instLang.getLangNameByNick(self.instLang.getCurrent()) iter = self.listStore.get_iter_first() while iter: if self.listStore.get_value(iter, 1) == current: I used pungi and in the .ks file I set the language to ar_JO.UTF-8 but the highlighted language is still English and in /usr/share/system-config-keyboard/keyboard_gui.py if self.modelStore.get_value(iter, 0) == default it did not obey the .ks how can I fix this ? while reading anaconda code I noticed that it receives --lang who pass it to anaconda ? it seems that anaconda do not have those values hardcoded to English, so where and how this is configurable ? From wacker at octothorp.org Sat Oct 4 01:05:52 2008 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Fri, 3 Oct 2008 19:05:52 -0600 (MDT) Subject: New Anaconda for F9? Message-ID: Was this intentional? Very cool! -- Bill in Denver From muayyad.alsadi at ojuba.org Sat Oct 4 08:24:48 2008 From: muayyad.alsadi at ojuba.org (=?UTF-8?Q?=D9=85=D8=A4=D9=8A=D8=AF_=D8=A7=D9=84=D8=B3=D8=B9=D8=AF=D9=8A?=) Date: Sat, 04 Oct 2008 11:24:48 +0300 Subject: New Anaconda for F9? In-Reply-To: References: Message-ID: yes because the stock anaconda is broken and won't even build this is bad for re-spinners like me it's broken because of a change in audit-libs-devel-1.7.5-1.fc9.i386 a structure was renamed to be audit_reply talking about my self, I patched my anaconda myself by looking into the git repo On Fri, 3 Oct 2008 19:05:52 -0600 (MDT), "William F. Acker WB2FLW +1-303-722-7209" wrote: > Was this intentional? Very cool! > > > -- > Bill in Denver > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From kanarip at kanarip.com Sat Oct 4 13:42:38 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 04 Oct 2008 15:42:38 +0200 Subject: New Anaconda for F9? In-Reply-To: References: Message-ID: <48E772CE.4030406@kanarip.com> William F. Acker WB2FLW +1-303-722-7209 wrote: > Was this intentional? Very cool! > > Completely intentional. Lots of minor bugfixes, anaconda builds again on up-to-date systems, and some additional significant Fedora 9 secondary architecture fixes were applied as well. Kind regards, Jeroen van Meeuwen -kanarip From isamar at gmail.com Sat Oct 4 13:45:04 2008 From: isamar at gmail.com (Isamar Maia) Date: Sat, 4 Oct 2008 10:45:04 -0300 Subject: New Anaconda for F9? In-Reply-To: <48E772CE.4030406@kanarip.com> References: <48E772CE.4030406@kanarip.com> Message-ID: Where can I find a "stage2.img" image with this bugfixes already applied ? Isamar 2008/10/4 Jeroen van Meeuwen : > William F. Acker WB2FLW +1-303-722-7209 wrote: >> >> Was this intentional? Very cool! >> >> > > Completely intentional. Lots of minor bugfixes, anaconda builds again on > up-to-date systems, and some additional significant Fedora 9 secondary > architecture fixes were applied as well. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Isamar Maia Brazil: 55-71-9146-8575 55-71-8890-7868 ??: +81-(0)3-4550-1212 From kanarip at kanarip.com Sat Oct 4 14:56:47 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 04 Oct 2008 16:56:47 +0200 Subject: New Anaconda for F9? In-Reply-To: References: <48E772CE.4030406@kanarip.com> Message-ID: <48E7842F.5020909@kanarip.com> Isamar Maia wrote: > Where can I find a "stage2.img" image with this bugfixes already applied ? > Not on any official Fedora Project location, the install tree is not going to be rebuilt by the Fedora Project as far as existing releases is concerned. However, the Fedora Unity Project is about to release one of it's infamous Re-Spins which include a new rebuilt stage2.img as well. However, this Re-Spin will first need to pass our testing before we release it. Kind regards, Jeroen van Meeuwen -kanarip From gregswift at gmail.com Mon Oct 6 05:46:46 2008 From: gregswift at gmail.com (Greg Swift) Date: Mon, 6 Oct 2008 00:46:46 -0500 Subject: some minor modifications to wiki [Koji/ServerHowTo] Message-ID: <4e3f91d70810052246k1c39dbb2sfb9985a630900ff9@mail.gmail.com> Hi all. I started playing with Koji recently to implement a build system for our internal RPMs. While I'm decently experienced as a system admin and developer, I tend to take some things too literally or a myriad of other newbie-esque behaviors when reading through how-to guides. Thanks to a few people (such as dgilmore and mbonnect, and a few others) on #koji i've mostly bashed my way through. I decided I would try to be helpful and attempt to make some changes to the wiki to make things a tad clearer for others with the same tendencies. Anyway... to skip to the point. I made a copy of the page and made an initial set of changes. You can view the changes here: https://fedoraproject.org/wiki/Koji/ServerHowToProposed I made sure to apply an original copy before making changes so that the compare function is readily available. I did add a few TODO comments if anyone would like to comment. I think I need to add one or two more, but i'm going to step back and re-read it in a bit to try and catch anything I might have meant to do but forgot. Thanks greg From paul.schroeder at bluecoat.com Mon Oct 6 17:23:20 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 06 Oct 2008 12:23:20 -0500 Subject: some minor modifications to wiki [Koji/ServerHowTo] In-Reply-To: <4e3f91d70810052246k1c39dbb2sfb9985a630900ff9@mail.gmail.com> References: <4e3f91d70810052246k1c39dbb2sfb9985a630900ff9@mail.gmail.com> Message-ID: <48EA4988.3040309@bluecoat.com> Greg Swift wrote: > Hi all. I started playing with Koji recently to implement a build > system for our internal RPMs. While I'm decently experienced as a > system admin and developer, I tend to take some things too literally > or a myriad of other newbie-esque behaviors when reading through > how-to guides. Thanks to a few people (such as dgilmore and mbonnect, > and a few others) on #koji i've mostly bashed my way through. I > decided I would try to be helpful and attempt to make some changes to > the wiki to make things a tad clearer for others with the same > tendencies. > > Anyway... to skip to the point. I made a copy of the page and made an > initial set of changes. You can view the changes here: > https://fedoraproject.org/wiki/Koji/ServerHowToProposed Speaking to that, I created a trac ticket with a shell script for setting up koji SSL keys: https://hosted.fedoraproject.org/koji/ticket/112 This script, or something like it, would make Koji setup a little more straightforward. Cheers...Paul... -- --- Paul B Schroeder Blue Coat Systems, Inc. From mikem at redhat.com Mon Oct 6 19:14:10 2008 From: mikem at redhat.com (Mike McLean) Date: Mon, 06 Oct 2008 15:14:10 -0400 Subject: Supporting EPEL Builds in Koji In-Reply-To: <1218663337.16585.63.camel@maunalani.home> References: <1215705751.30991.7.camel@burren.bos.redhat.com> <487F8762.6090007@redhat.com> <1216334914.16888.82.camel@burren.bos.redhat.com> <4880B8F4.9040701@redhat.com> <1218663337.16585.63.camel@maunalani.home> Message-ID: <48EA6382.2070000@redhat.com> Mike Bonnet wrote: > On Fri, 2008-07-18 at 11:38 -0400, Mike McLean wrote: >> Mike Bonnet wrote: >>> On Thu, 2008-07-17 at 13:54 -0400, Mike McLean wrote: >>>> If the remote_repo_url data is going to be inherited (and I tend to >>>> think it should be), then I think it should be in a separate table. ... >>> I don't have any problem with this, though it does mean we'll need to >>> duplicate quite a bit of the inheritance-walking code, ... >> Walking inheritance is just a matter of determining the inheritance >> order and scanning data on the parent tags in sequence. ... > Sorry, I was referring to walking tag_inheritance. I'd rather have one > place that walks the inheritance hierarchy and aggregates data from it, > than two places that are doing almost the same thing. We're talking about inherently different data. External repos to be merged in are quite different from builds in the system. > Each tag has a set of builds associated with it. We walk the > inheritance hierarchy, aggregating the builds from each tag in the > hierarchy into a flat list, and then pass that list to createrepo. We > would do essentially the same thing for external repos. When walking > the hierarchy, if a tag has an external repo associated with it, we > would append that repo url to a flat list, and pass that list to > mergerepo. In both cases we're working with collections of packages > that are associated with a tag, just in different formats. Sure, we can do this with one call to readFullInheritance, and traverse both the build table and external repo table from the given order. > In discussing this with Jesse, I think we want external repos to be > inherited. This is probably the easiest way to deal with having > multiple external repos getting pulled in to a single buildroot, which > is essential for Fedora (think F9 GA and F9 Updates). > > The idea was that, by convention, we would have external-repo-only tags, > with only a single external repo associated with it and no > packages/builds associated. These external-repo-only tags could then be > inserted into the build hierarchy where appropriate. An ordered list of > external repos could then be constructed by performing the current > depth-first search of the inheritance hierarchy. The ordered list would > then be passed to mergerepo, which would ensure that packages in repos > earlier in the list supersede packages (by srpm name) in repos later in > the list. This would preserve the "first-match-wins" inheritance policy > that Koji currently implements, and that admins expect. For example: > > dist-custom-build > ??dist-custom > ??dist-f9-updates-external > ??dist-f9-ga-external > > would result mergerepo creating a single repo that would only contain > packages from dist-f9-ga-external if they did not exist in the > Koji-generated repo (dist-custom-build + dist-custom), > dist-f9-updates-external, or the blacklist of blocked packages. This is > consistent with how Koji package inheritance currently works, and I > think is the most intuitive approach. It is similar, but different in potentially confusing ways. External repos do not have build structure, so we can't really have the same sort of inheritance behavior with a combination of external repo tags and normal tags. We order the external repos in inheritance order, but ultimately those repos are merged with the internal one in a way that does not honor inheritance in the way that the admin might expect. Using tags to represent external repos fails intuition because external repos are very much not like tags. When we get to supporting external koji systems, we can do something like this, but for external repos the "bolted-on" nature needs to be clear. This is why I'd prefer to have the data a little more removed. >> I see all that, and I'm almost convinced. The flipside is that by >> default all the code will treat these external rpms the same as the >> local ones, which will not be correct for a number of cases. > > Personally I'd prefer adding a few special cases to the existing code, > rather than maintain a whole heap of almost-but-not-quite-the-same code > to manage external rpms. I think that conceptually they're alike enough > that the number of special cases will be minimal. I think I'm ok with using the rpminfo table. > I think that synthesizing builds for that sake of maintaining the > not-null constraint is more pain than it's worth, and would make > enforcing our nvr-uniqueness constraints (which we definitely want to do > for local builds) more difficult. Having locally-built rpms always > associated with a build, and external rpms not, makes sense to me. Ok, agreed. >> Also, I'm thinking we need to have some sort of rpm_origin table so that >> all these references can be managed cleanly. > > That sounds reasonable to me. Note that we may end up with a lot of > rows in this table, since we're allowing variable substitution in the > external_repo_url (tag name and arch). But I don't see that as a > problem. I'm thinking the only substitution we should support is arch. Anything else sort of constitutes a different repo. If we use an origin table like this we can abstract out the arch. Something like: create table external_repo ( id SERIAL PRIMARY KEY, name TEXT ); create table external_repo_config ( external_repo_id INTEGER NOT NULL REFERENCES external_repo (id), url TEXT NOT NULL, -- plus versioning fields -- ... ); This way if upstream repo changes url scheme or moves to a different host, you can keep some notion of connectedness. External rpms would simply reference external_repo_id. >> In the same vein, what happens when an external repo has an nvra+sigmd5 >> matching a /local/ rpm? Maybe it doesn't matter, though I guess >> technically we want to record the origin properly when it gets into a >> buildroot via external repo vs internal tag. > > Right, we would record the origin as the remote repo it came from (by > parsing the merged repodata and looking at the baseurl). So where do we draw the line between code that we add to koji and code that we add to createrepo (or some external merge-repo tool)? >>> However, we will already be parsing the remote repodata, which contains >>> information like the srpm name for each rpm, so we could do something >>> more sophisticated here. >> -snipsnip- >> ... >>> The repomerge tool seems like it solves the problem better, and would be >>> more useful in general. >> If we're going to have our fingers in the repodata, we'll probably want >> to have them in the merge too. Perhaps we can get createrepo and/or this >> repomerge tool usefully libified? > > I was thinking we would probably just call out to the tool the way we do > for createrepo, but I'm certainly not against using an API. I'm a > little concerned about memory usage when doing the create/mergerepo > in-process, since we know python and mod_python have garbage-collection > issues, but that may be a "cross the bridge when we come to it" problem. > Seth, is it feasible to provide an API to mergerepo that we could use > directly? I don't think I even saw a reply from Seth on this. Where does the mergerepo code stand now? From martin.langhoff at gmail.com Mon Oct 13 02:43:13 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 13 Oct 2008 15:43:13 +1300 Subject: revisor - strange regression with comps-cleanup misplaced... Message-ID: <46a038f90810121943l32b65462q63d20d9210e2a94a@mail.gmail.com> After 2 weeks of not building the XS build, I built it again today. It didn't want to build. Running with --debug 10 the output ends with... Running command: /usr/bin/xsltproc --novalid -o /var/tmp/revisor-pungi/0.5/xs-f9-i386/comps.xml /usr/share/revisor/comps/comps-cleanup.xsl /var/tmp/revisor-pungi/0.5/xs-f9-i386/comps.xml Extra information: /var/tmp/revisor-rundir False None Got an error from /usr/bin/xsltproc (return code 4) xsltproc's manpage says that 4 means trouble parsing the stylesheet. I tried to look at/usr/share/revisor/comps/comps-cleanup.xsl and it wasn't there. It was a directory higher. this fixed the problem: sudo ln -s /usr/share/revisor/comps-cleanup.xsl /usr/share/revisor/comps/comps-cleanup.xsl versions: $ rpm -qa revisor* revisor-gui-2.1.1-7.fc9.noarch revisor-comps-2.1.1-7.fc9.noarch revisor-cli-2.1.1-7.fc9.noarch revisor-2.1.1-7.fc9.noarch cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Mon Oct 13 03:24:01 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 13 Oct 2008 16:24:01 +1300 Subject: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 Message-ID: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> Right now, revisor can build a pristine F9 installer CD but cannot build a F9 + updates installer CD. The problem appears by merely enabling the additional repo in the stock F9 config files that ship with Revisor. It has also been reported elsewhere: https://fedorahosted.org/genome/ticket/28 The error is Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 even though the updates.newkey repo clearly has the full set of glibc-* packages at 2.8-8 The OLPC XS installer CD will be installed in many servers that are disconnected or have a horrible internet connection. Additionally, we *need* some of the updates from the updates.newkey repo. So I really need this to work. It looks like a bug to me, but I'm unsure if it's in revisor, anaconda, yum... Is there any workaround I can use? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From skvidal at fedoraproject.org Mon Oct 13 15:23:32 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 13 Oct 2008 11:23:32 -0400 Subject: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> Message-ID: <1223911412.16857.8.camel@rosebud> On Mon, 2008-10-13 at 16:24 +1300, Martin Langhoff wrote: > Right now, revisor can build a pristine F9 installer CD but cannot > build a F9 + updates installer CD. > > The problem appears by merely enabling the additional repo in the > stock F9 config files that ship with Revisor. It has also been > reported elsewhere: https://fedorahosted.org/genome/ticket/28 > > The error is > Missing Dependency: glibc-common = 2.8-3 is needed by package > glibc-2.8-3.i386 Is there any other debug information available? _something_ is pulling in glibc-2.8-3 instead of 2.8-8. That's what's horking the issue with 2.8-3, most likely. But without more debugging info I'm hard pressed to tell you what's happening. -sv From martin.langhoff at gmail.com Mon Oct 13 22:10:00 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 11:10:00 +1300 Subject: [Server-devel] Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: <1223911412.16857.8.camel@rosebud> References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <1223911412.16857.8.camel@rosebud> Message-ID: <46a038f90810131510w41d895e4hccac642a2d6373d5@mail.gmail.com> On Tue, Oct 14, 2008 at 4:23 AM, seth vidal wrote: >> The error is >> Missing Dependency: glibc-common = 2.8-3 is needed by package >> glibc-2.8-3.i386 > > Is there any other debug information available? > > _something_ is pulling in glibc-2.8-3 instead of 2.8-8. That's what's > horking the issue with 2.8-3, most likely. > > But without more debugging info I'm hard pressed to tell you what's > happening. Can't get revisor to give me a separate yum log at the moment, but I managed to get yum into high-debug mode. So the messages are mixed between revisor and yum, but it seems to make sense: http://dev.laptop.org/~martin/revisoryum.log.bz2 It definitely sees 2.8-8, and I can't spot anything that calls glibc-2.8-3 *except* that there's a mention of it being included "from Groups" -- Including glibc >From Groups: Adding glibc-0:2.8-8.i686 to transaction >From Groups: Adding glibc-0:2.8-8.i386 to transaction >From Groups: Adding glibc-0:2.8-3.i386 to transaction >From Groups: Adding glibc-0:2.8-3.i686 to transaction and later 2.8-3 wants the matching glibc-common, which *is* in the repo. However, yum doesn't like it and it doesn't settle for the 2.8-8 set. Do the logs make sense to you? Also -- I did add glibc and glibc-common explicitly to the kickstart file, but it didn't make a difference. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From csieh at fnal.gov Mon Oct 13 22:34:15 2008 From: csieh at fnal.gov (Connie Sieh) Date: Mon, 13 Oct 2008 17:34:15 -0500 (CDT) Subject: [Server-devel] Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: <46a038f90810131510w41d895e4hccac642a2d6373d5@mail.gmail.com> References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <1223911412.16857.8.camel@rosebud> <46a038f90810131510w41d895e4hccac642a2d6373d5@mail.gmail.com> Message-ID: On Tue, 14 Oct 2008, Martin Langhoff wrote: > On Tue, Oct 14, 2008 at 4:23 AM, seth vidal wrote: >>> The error is >>> Missing Dependency: glibc-common = 2.8-3 is needed by package >>> glibc-2.8-3.i386 >> >> Is there any other debug information available? >> >> _something_ is pulling in glibc-2.8-3 instead of 2.8-8. That's what's >> horking the issue with 2.8-3, most likely. >> >> But without more debugging info I'm hard pressed to tell you what's >> happening. > > Can't get revisor to give me a separate yum log at the moment, but I > managed to get yum into high-debug mode. So the messages are mixed > between revisor and yum, but it seems to make sense: > > http://dev.laptop.org/~martin/revisoryum.log.bz2 > > It definitely sees 2.8-8, and I can't spot anything that calls > glibc-2.8-3 *except* that there's a mention of it being included "from > Groups" -- > > Including glibc >> From Groups: Adding glibc-0:2.8-8.i686 to transaction >> From Groups: Adding glibc-0:2.8-8.i386 to transaction >> From Groups: Adding glibc-0:2.8-3.i386 to transaction >> From Groups: Adding glibc-0:2.8-3.i686 to transaction > > and later 2.8-3 wants the matching glibc-common, which *is* in the > repo. However, yum doesn't like it and it doesn't settle for the 2.8-8 > set. > > Do the logs make sense to you? > > Also -- I did add glibc and glibc-common explicitly to the kickstart > file, but it didn't make a difference. I excluded glibc* from the "Everything" repository in the revisor-f9-i386.conf file just to get past this error. -Connie Sieh From martin.langhoff at gmail.com Mon Oct 13 22:39:01 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 11:39:01 +1300 Subject: [Server-devel] Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <1223911412.16857.8.camel@rosebud> <46a038f90810131510w41d895e4hccac642a2d6373d5@mail.gmail.com> Message-ID: <46a038f90810131539l6205bf86h1ae86f93e7823828@mail.gmail.com> On Tue, Oct 14, 2008 at 11:34 AM, Connie Sieh wrote: > I excluded glibc* from the "Everything" repository in the > revisor-f9-i386.conf file just to get past this error. How do you do that? m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From csieh at fnal.gov Mon Oct 13 22:45:04 2008 From: csieh at fnal.gov (Connie Sieh) Date: Mon, 13 Oct 2008 17:45:04 -0500 (CDT) Subject: [Server-devel] Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: <46a038f90810131539l6205bf86h1ae86f93e7823828@mail.gmail.com> References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <1223911412.16857.8.camel@rosebud> <46a038f90810131510w41d895e4hccac642a2d6373d5@mail.gmail.com> <46a038f90810131539l6205bf86h1ae86f93e7823828@mail.gmail.com> Message-ID: On Tue, 14 Oct 2008, Martin Langhoff wrote: > On Tue, Oct 14, 2008 at 11:34 AM, Connie Sieh wrote: >> I excluded glibc* from the "Everything" repository in the >> revisor-f9-i386.conf file just to get past this error. > > How do you do that? Add excludes=glibc* to /etc/revisor/conf.d/revisor-f9-i386.conf in the [fedora] section. (substitute x86_64 as needed) -Connie Sieh > > > > > m > From martin.langhoff at gmail.com Mon Oct 13 23:05:44 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 12:05:44 +1300 Subject: [Server-devel] Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <1223911412.16857.8.camel@rosebud> <46a038f90810131510w41d895e4hccac642a2d6373d5@mail.gmail.com> <46a038f90810131539l6205bf86h1ae86f93e7823828@mail.gmail.com> Message-ID: <46a038f90810131605h4d7f2549kb44859fd8394c010@mail.gmail.com> On Tue, Oct 14, 2008 at 11:45 AM, Connie Sieh wrote: > Add > > excludes=glibc* > > to /etc/revisor/conf.d/revisor-f9-i386.conf in the [fedora] section. > (substitute x86_64 as needed) thanks - I found the excludes in the manpage as well - that definitely fixed it. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From mikem at redhat.com Tue Oct 14 02:21:14 2008 From: mikem at redhat.com (Mike McLean) Date: Mon, 13 Oct 2008 22:21:14 -0400 Subject: mock and sgid basedir Message-ID: <48F4021A.4090706@redhat.com> It seems that mock currently requires /var/lib/mock to be sgid mock, at least when run by mortal users. I know that older (perhaps much older) versions of mock did not require this. I have previously seen problems where the sgid bit on directories could propagate into built packages. However, a casual attempt to recreate this fails. Perhaps there has been a fix in rpm for this. Does anyone know for sure? From martin.langhoff at gmail.com Tue Oct 14 02:23:47 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 15:23:47 +1300 Subject: Tying yum to a package "stream"? Message-ID: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> OLPC's XS ships a number of patched packages. The packages are normally built with a different "stream" or "flavour" (they don't say "f9" but "xs05") and sit in a special repository. Is there a good way to ensure revisor/yum prefers the packages from the xs stream or repo over the standard F9 release or update packages, even if the f9 package is newer? (In the APT/Debian world the closest parallel would be setting apt preferences to have biased priorities -- aka Pin -- on a label or a component.) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Tue Oct 14 02:57:07 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 15:57:07 +1300 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <1223951241.16857.93.camel@rosebud> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> Message-ID: <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> On Tue, Oct 14, 2008 at 3:27 PM, seth vidal wrote: > you can use yum's priorities plugin to achieve similar results. It's a bit simpler than apt but I can sure work with this. Thanks! > Just as in the apt-world configuring priorities/pinning for > longterm/widespread use is a frelling nightmare. :-) -- well stated. If people mess with the repo configs we provide, install random rpms or play their Heavy Metal Rock records backwards, they void their warranty. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From skvidal at fedoraproject.org Tue Oct 14 02:27:21 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 13 Oct 2008 22:27:21 -0400 Subject: Tying yum to a package "stream"? In-Reply-To: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> Message-ID: <1223951241.16857.93.camel@rosebud> On Tue, 2008-10-14 at 15:23 +1300, Martin Langhoff wrote: > OLPC's XS ships a number of patched packages. The packages are > normally built with a different "stream" or "flavour" (they don't say > "f9" but "xs05") and sit in a special repository. > > Is there a good way to ensure revisor/yum prefers the packages from > the xs stream or repo over the standard F9 release or update packages, > even if the f9 package is newer? > > (In the APT/Debian world the closest parallel would be setting apt > preferences to have biased priorities -- aka Pin -- on a label or a > component.) you can use yum's priorities plugin to achieve similar results. Just as in the apt-world configuring priorities/pinning for longterm/widespread use is a frelling nightmare. -sv From james at fedoraproject.org Tue Oct 14 03:24:50 2008 From: james at fedoraproject.org (James Antill) Date: Mon, 13 Oct 2008 23:24:50 -0400 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> Message-ID: <1223954690.16958.14.camel@code.and.org> On Tue, 2008-10-14 at 15:57 +1300, Martin Langhoff wrote: > On Tue, Oct 14, 2008 at 3:27 PM, seth vidal wrote: > > you can use yum's priorities plugin to achieve similar results. > > It's a bit simpler than apt but I can sure work with this. Thanks! > > > Just as in the apt-world configuring priorities/pinning for > > longterm/widespread use is a frelling nightmare. > > :-) -- well stated. > > If people mess with the repo configs we provide, install random rpms > or play their Heavy Metal Rock records backwards, they void their > warranty. To expand on what Seth is saying, if you are doing this on your local developer workstation etc. ... feel free to do whatever you want to override the normal behaviour from the repos. (that's what the features are there for). But if you are going to ship a repo to end users which requires/uses the yum-priority plugin (or excludes, or whatever), then the simple advise I would give you is: _don't_. Instead clone the Fedora repo. removing the packages you want to "override", or even better get your changes into Fedora. -- James Antill Fedora From martin.langhoff at gmail.com Tue Oct 14 03:48:44 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 16:48:44 +1300 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <1223954690.16958.14.camel@code.and.org> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> Message-ID: <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> On Tue, Oct 14, 2008 at 4:24 PM, James Antill wrote: > But if you are going to ship a repo to end users which requires/uses > the yum-priority plugin (or excludes, or whatever), I am shipping a heavily "preconfigured" spin, the OLPC School Server. It points to the standard F9 repos, plus OLPCXS repos. So far we override... 1 package: ejabberd. > then the simple > advise I would give you is: _don't_. Can you tell me a bit more about why? (I definitely respect your technical advise, I'm trying to get more depth of info / experience on this...) As it's a single package and this could expand to a couple more packages but no more, one alternative is to take that single package and rename it ejabberd-xs and set it to provide:ejabberd, conflicts:ejabberd. I am already down that path with Moodle ("moodle-xs"), which I plan to maintain as a long-term heavily customised package. > Instead clone the Fedora repo. removing the packages you want to > "override" Quite a bit of work if I also want to give them access to sec updates in a timely fashion :-) and my "conflict" with Fedora packages is tiny. > ... or even better get your changes into Fedora. In some cases Fedora won't want them as they are strictly local customisations -- such is the case of ejabberd and moodle. In others Fedorans are looking into integrating changes in their own timeframes (and I have my own release schedules to work for :-/ ). It's a classic upstream/downstream game... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From james at fedoraproject.org Tue Oct 14 04:39:12 2008 From: james at fedoraproject.org (James Antill) Date: Tue, 14 Oct 2008 00:39:12 -0400 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> Message-ID: <1223959152.16958.43.camel@code.and.org> On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote: > On Tue, Oct 14, 2008 at 4:24 PM, James Antill wrote: > > But if you are going to ship a repo to end users which requires/uses > > the yum-priority plugin (or excludes, or whatever), > > I am shipping a heavily "preconfigured" spin, the OLPC School Server. > It points to the standard F9 repos, plus OLPCXS repos. So far we > override... 1 package: ejabberd. Ok, that's kind of the worst case atm. ... I had assumed you'd be doing this to a lot more. > > then the simple > > advise I would give you is: _don't_. > > Can you tell me a bit more about why? (I definitely respect your > technical advise, I'm trying to get more depth of info / experience on > this...) There are two basic problems: 1. It's a lot less efficient to push the depsolving/repoclosure down to each client, instead of solving it once on the server. So from that point of view yum-priorities/etc. are _always_ going to give a worse experience, even if we have all the data, make the depsolver a full SAT solver while keeping it fast. 2. Fedora doesn't provide all of the data to make the above possible anyway, so for instance F-9 might have foo-1.0-1 and then updates for F-9 might release foo-1.0-2, foo-1.1-1, foo-1.2-1 ... by that point _only_ foo-1.0-1 and foo-1.2-1 will be available (one pkg/version from each repo.). This means that if your repo. has bar-xo-1.0 requires "= foo-1.1" ... all the old xo repos. now become broken you have to rush out a fixed bar-xo and wait. You would still have "problems" if you did everything server side, but you'd actually be able to run repoclose/etc. and see the problem before it hit the clients ... and just not update your cloned repo. until you fixed it, with yum-priorities the first you'll see it is when all the clients don't work anymore. > As it's a single package and this could expand to a couple more > packages but no more, one alternative is to take that single package > and rename it ejabberd-xs and set it to provide:ejabberd, > conflicts:ejabberd. This is a lot better, in that it totally solves #1 above. #2 still applies (cross repo. deps. are the suck) although due to the rename it'll be to a lesser extent than trying to override packages with higher NEVRA. Of course how much the cross repo. deps. problem hits you depends a lot on the package, ejabberd doesn't look like it requires anything that might be upgraded in a bad way ... and has no deps. on itself. So there is a certain amount of "try it, it'll probably work fine". > I am already down that path with Moodle ("moodle-xs"), which I plan to > maintain as a long-term heavily customised package. > > > Instead clone the Fedora repo. removing the packages you want to > > "override" > > Quite a bit of work if I also want to give them access to sec updates > in a timely fashion :-) and my "conflict" with Fedora packages is > tiny. Yeh, I completely agree this is harder to do than it should be right now ... as an end game it'd be nice if there was a way so you could just publish a repo. which was "Fedora - " but all/most of the package hosting was done via. the Fedora mirrors etc. > > ... or even better get your changes into Fedora. > > In some cases Fedora won't want them as they are strictly local > customisations -- such is the case of ejabberd and moodle. In others > Fedorans are looking into integrating changes in their own timeframes > (and I have my own release schedules to work for :-/ ). Is there any way you could make the changes be basically bolt on config. changes? so you have a ejabberd-config-xo or whatever? I'm guessing you already looked at that, but I thought I'd ask... > It's a classic upstream/downstream game... Yeh, but think of it like Fedora vs. our upstream ... we copy all the .tar.gz files locally, because we need to be isolated from changes on their side. Ideally you'd do something similar to be isolated from changes on our side, not being able to do that starts you on the road to a bad place ... and yum-priorities is at the heart of the bad place :). -- James Antill Fedora From martin.langhoff at gmail.com Tue Oct 14 05:06:17 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 18:06:17 +1300 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <1223959152.16958.43.camel@code.and.org> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> <1223959152.16958.43.camel@code.and.org> Message-ID: <46a038f90810132206hfdc5fdbmc4ef6818b2c810c6@mail.gmail.com> Thanks a lot for your notes. *Extremely* useful. A few comments below, On Tue, Oct 14, 2008 at 5:39 PM, James Antill wrote: > On Tue, 2008-10-14 at 16:48 +1300, Martin Langhoff wrote: >> I am shipping a heavily "preconfigured" spin, the OLPC School Server. >> It points to the standard F9 repos, plus OLPCXS repos. So far we >> override... 1 package: ejabberd. > > Ok, that's kind of the worst case atm. ... I had assumed you'd be doing > this to a lot more. Yes - it is the worst case, and I don't expect to see this grow significantly. > There are two basic problems: > > 1. It's a lot less efficient to push the depsolving/repoclosure down to > each client, instead of solving it once on the server. So from that > point of view yum-priorities/etc. are _always_ going to give a worse > experience, even if we have all the data, make the depsolver a full SAT > solver while keeping it fast. I did notice yum got a ton slower during the build once I added priorities. > 2. Fedora doesn't provide all of the data to make the above possible > anyway, so for instance F-9 might have foo-1.0-1 and then updates for > F-9 might release foo-1.0-2, foo-1.1-1, foo-1.2-1 ... by that point > _only_ foo-1.0-1 and foo-1.2-1 will be available (one pkg/version from > each repo.). > This means that if your repo. has bar-xo-1.0 requires "= foo-1.1" ... > all the old xo repos. now become broken you have to rush out a fixed > bar-xo and wait. You would still have "problems" if you did everything > server side, but you'd actually be able to run repoclose/etc. and see > the problem before it hit the clients ... and just not update your > cloned repo. until you fixed it, with yum-priorities the first you'll > see it is when all the clients don't work anymore. Good point -- though with every custom package in the XS build I have ample room to shoot myself in the foot with tight dependencies... with or without priorities. True, getting fancy with tight interdeps hjandled "transparently" via yum-priorities leads me in the wrong direction... >> As it's a single package and this could expand to a couple more >> packages but no more, one alternative is to take that single package >> and rename it ejabberd-xs and set it to provide:ejabberd, >> conflicts:ejabberd. > > This is a lot better, in that it totally solves #1 above. #2 still > applies (cross repo. deps. are the suck) although due to the rename > it'll be to a lesser extent than trying to override packages with higher > NEVRA. Right - so we'll move to that model then and drop priorities. the packages will look a tad funny, but it's ok. We currently don't have any tight or tricky dependency, though our repo is of course referring to stuff in fedora and fedora-updates-newkey. Depending on php, httpd and python is not something I stress about -- if fedora breaks any of them significantly, I won't be alone in my anger... :-) > Is there any way you could make the changes be basically bolt on > config. changes? so you have a ejabberd-config-xo or whatever? I'm > guessing you already looked at that, but I thought I'd ask... Where we can, we do -- currently in a xs-config package that rolls together lots of config overrides -- we'll break that down in due course. For ejabberd we have custom patches... >> It's a classic upstream/downstream game... > > Yeh, but think of it like Fedora vs. our upstream ... we copy all > the .tar.gz files locally, because we need to be isolated from changes > on their side. Ideally you'd do something similar to be isolated from > changes on our side, not being able to do that starts you on the road to > a bad place ... and yum-priorities is at the heart of the bad place :). There are two ways to look at that. You keep complete control over the deliverable, which is definitely saner but requires a ton more development resources. In the case of the XS, we are still in heavy develoment mode (though I do cut releases, they are not a finished product). A lot is in motion and with a tiny team. Just keeping abreast of "what fedora updates to accept" in any useful way would swamp us. So at this stage I can't hope to keep such complete control :-/ once things stabilise at our end, I will review my options. thanks again! martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From mikem at redhat.com Tue Oct 14 05:16:46 2008 From: mikem at redhat.com (Mike McLean) Date: Tue, 14 Oct 2008 01:16:46 -0400 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> Message-ID: <48F42B3E.3040509@redhat.com> Martin Langhoff wrote: > As it's a single package and this could expand to a couple more > packages but no more, one alternative is to take that single package > and rename it ejabberd-xs and set it to provide:ejabberd, > conflicts:ejabberd. If you go this route, I think what you want is obsoletes. Obsoletes says "this packages replaces this one." Conflicts says "this package cannot be installed at the same time as this other one." One mechanism gives the tools instruction on how to handle things, the other is more of an assertion that mostly just causes the end user pain when it comes up. Building conflicts into your repositories is generally not very friendly. Sometimes it may make sense, but I'm not sure it makes sense here. > I am already down that path with Moodle ("moodle-xs"), which I plan to > maintain as a long-term heavily customised package. > >> Instead clone the Fedora repo. removing the packages you want to >> "override" > > Quite a bit of work if I also want to give them access to sec updates > in a timely fashion :-) and my "conflict" with Fedora packages is > tiny. I think you could come up with a reasonably fast sync script if you wanted to go this way. From martin.langhoff at gmail.com Tue Oct 14 05:49:49 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 14 Oct 2008 18:49:49 +1300 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <48F42B3E.3040509@redhat.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> <48F42B3E.3040509@redhat.com> Message-ID: <46a038f90810132249v2ca8338cq3bbe75156db6231@mail.gmail.com> On Tue, Oct 14, 2008 at 6:16 PM, Mike McLean wrote: > If you go this route, I think what you want is obsoletes. Obsoletes says > "this packages replaces this one." Conflicts says "this package cannot be > installed at the same time as this other one." Does 'obsoletes' also mean "this package cannot be installed at the same time as this other one."? Because things *will* go wrong if someone installs moodle and moodle-xs :-/ >>> Instead clone the Fedora repo. removing the packages you want to >>> "override" >> >> Quite a bit of work if I also want to give them access to sec updates >> in a timely fashion :-) and my "conflict" with Fedora packages is >> tiny. > > I think you could come up with a reasonably fast sync script if you wanted > to go this way. Sure - rsync to da rescue! :-) - but then there is no review and testing, and we're back to the same situation as with pointing users directly to the Fedora repos. Field installs may break if an update comes through untested/unreviewed. It makes sense to freeze our repo and selectively update it with reviewed&tested updates from fedora... if you have the focus on stability and the manpower to do it. Neither is true right now for me. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Tue Oct 14 11:44:37 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 14 Oct 2008 13:44:37 +0200 Subject: revisor - strange regression with comps-cleanup misplaced... In-Reply-To: <46a038f90810121943l32b65462q63d20d9210e2a94a@mail.gmail.com> References: <46a038f90810121943l32b65462q63d20d9210e2a94a@mail.gmail.com> Message-ID: <48F48625.100@kanarip.com> Martin Langhoff wrote: > After 2 weeks of not building the XS build, I built it again today. It > didn't want to build. Running with --debug 10 the output ends with... > > Running command: /usr/bin/xsltproc --novalid -o > /var/tmp/revisor-pungi/0.5/xs-f9-i386/comps.xml > /usr/share/revisor/comps/comps-cleanup.xsl > /var/tmp/revisor-pungi/0.5/xs-f9-i386/comps.xml > Extra information: /var/tmp/revisor-rundir False None > Got an error from /usr/bin/xsltproc (return code 4) > > xsltproc's manpage says that 4 means trouble parsing the stylesheet. I > tried to look at/usr/share/revisor/comps/comps-cleanup.xsl and it > wasn't there. It was a directory higher. > > this fixed the problem: > sudo ln -s /usr/share/revisor/comps-cleanup.xsl > /usr/share/revisor/comps/comps-cleanup.xsl > Fixed in GIT, thanks. Kind regards, Jeroen van Meeuwen -kanarip From skvidal at fedoraproject.org Tue Oct 14 11:52:09 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 14 Oct 2008 07:52:09 -0400 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <46a038f90810132249v2ca8338cq3bbe75156db6231@mail.gmail.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> <48F42B3E.3040509@redhat.com> <46a038f90810132249v2ca8338cq3bbe75156db6231@mail.gmail.com> Message-ID: <1223985129.16857.99.camel@rosebud> On Tue, 2008-10-14 at 18:49 +1300, Martin Langhoff wrote: > On Tue, Oct 14, 2008 at 6:16 PM, Mike McLean wrote: > > If you go this route, I think what you want is obsoletes. Obsoletes says > > "this packages replaces this one." Conflicts says "this package cannot be > > installed at the same time as this other one." > > Does 'obsoletes' also mean "this package cannot be installed at the > same time as this other one."? Because things *will* go wrong if > someone installs moodle and moodle-xs :-/ You can obsolete and conflict Obsoletes: pkgname=ver.rel Conflicts: pkgname=ver.rel -sv From kanarip at kanarip.com Tue Oct 14 12:11:56 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 14 Oct 2008 14:11:56 +0200 Subject: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> Message-ID: <48F48C8C.3000900@kanarip.com> Martin Langhoff wrote: > Right now, revisor can build a pristine F9 installer CD but cannot > build a F9 + updates installer CD. > > The problem appears by merely enabling the additional repo in the > stock F9 config files that ship with Revisor. It has also been > reported elsewhere: https://fedorahosted.org/genome/ticket/28 > > The error is > Missing Dependency: glibc-common = 2.8-3 is needed by package > glibc-2.8-3.i386 > > even though the updates.newkey repo clearly has the full set of > glibc-* packages at 2.8-8 > Fedora Unity has just released a Re-Spin of Fedora 9 + updates, and we have not seen this problem. Nevertheless I dug through the code and found a little discrepancy, now having resolved the issue (in GIT). Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Tue Oct 14 14:55:54 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Oct 2008 10:55:54 -0400 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <46a038f90810132249v2ca8338cq3bbe75156db6231@mail.gmail.com> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> <48F42B3E.3040509@redhat.com> <46a038f90810132249v2ca8338cq3bbe75156db6231@mail.gmail.com> Message-ID: <1223996154.12340.27.camel@aglarond.local> On Tue, 2008-10-14 at 18:49 +1300, Martin Langhoff wrote: > It makes sense to freeze our repo and selectively update it with > reviewed&tested updates from fedora... if you have the focus on > stability and the manpower to do it. Neither is true right now for me. Adding another time gap for release of updates is also problematic for any security updates which could already be time sensitive. Jeremy From csieh at fnal.gov Tue Oct 14 15:22:28 2008 From: csieh at fnal.gov (Connie Sieh) Date: Tue, 14 Oct 2008 10:22:28 -0500 (CDT) Subject: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: <48F48C8C.3000900@kanarip.com> References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <48F48C8C.3000900@kanarip.com> Message-ID: On Tue, 14 Oct 2008, Jeroen van Meeuwen wrote: > Martin Langhoff wrote: >> Right now, revisor can build a pristine F9 installer CD but cannot >> build a F9 + updates installer CD. >> >> The problem appears by merely enabling the additional repo in the >> stock F9 config files that ship with Revisor. It has also been >> reported elsewhere: https://fedorahosted.org/genome/ticket/28 >> >> The error is >> Missing Dependency: glibc-common = 2.8-3 is needed by package >> glibc-2.8-3.i386 >> >> even though the updates.newkey repo clearly has the full set of >> glibc-* packages at 2.8-8 >> > > Fedora Unity has just released a Re-Spin of Fedora 9 + updates, and we have > not seen this problem. I installed this respin and then tried to rebuild fedora 9 + updates on this respin and got this glibc error. > > Nevertheless I dug through the code and found a little discrepancy, now > having resolved the issue (in GIT). > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -Connie Sieh http://www.scientificlinux.org From kanarip at kanarip.com Tue Oct 14 15:56:40 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 14 Oct 2008 17:56:40 +0200 Subject: Revisor / yum odd error with f9 updates.newkey repo: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 In-Reply-To: References: <46a038f90810122024p55bfa284s19580c5437c9eddd@mail.gmail.com> <48F48C8C.3000900@kanarip.com> Message-ID: <48F4C138.8080403@kanarip.com> Connie Sieh wrote: > On Tue, 14 Oct 2008, Jeroen van Meeuwen wrote: > >> Martin Langhoff wrote: >>> Right now, revisor can build a pristine F9 installer CD but cannot >>> build a F9 + updates installer CD. >>> >>> The problem appears by merely enabling the additional repo in the >>> stock F9 config files that ship with Revisor. It has also been >>> reported elsewhere: https://fedorahosted.org/genome/ticket/28 >>> >>> The error is >>> Missing Dependency: glibc-common = 2.8-3 is needed by package >>> glibc-2.8-3.i386 >>> >>> even though the updates.newkey repo clearly has the full set of >>> glibc-* packages at 2.8-8 >>> >> >> Fedora Unity has just released a Re-Spin of Fedora 9 + updates, and we >> have not seen this problem. > > I installed this respin and then tried to rebuild fedora 9 + updates on > this respin and got this glibc error. > Like I said there was an error in selecting packages that I fixed in Revisor. FWIW, also, this should be a warning, not an error and it should definitely not be fatal. I tend to let Revisor exit out if something is serious enough or fatal for the compose. Kind regards, Jeroen van Meeuwen -kanarip From martin.langhoff at gmail.com Tue Oct 14 19:54:08 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 15 Oct 2008 08:54:08 +1300 Subject: [Server-devel] Tying yum to a package "stream"? In-Reply-To: <1223985129.16857.99.camel@rosebud> References: <46a038f90810131923l6698cb3fkbb95e4a62013919a@mail.gmail.com> <1223951241.16857.93.camel@rosebud> <46a038f90810131957o1e1c2d2fv947affef9c16b606@mail.gmail.com> <1223954690.16958.14.camel@code.and.org> <46a038f90810132048n7ab62849i9117125b28372dea@mail.gmail.com> <48F42B3E.3040509@redhat.com> <46a038f90810132249v2ca8338cq3bbe75156db6231@mail.gmail.com> <1223985129.16857.99.camel@rosebud> Message-ID: <46a038f90810141254w288252a0r43d43db3b191aca6@mail.gmail.com> On Wed, Oct 15, 2008 at 12:52 AM, seth vidal wrote: > You can obsolete and conflict > > Obsoletes: pkgname=ver.rel > Conflicts: pkgname=ver.rel Great -- thanks! I'll do exactly this. m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From mikem at redhat.com Tue Oct 14 20:10:56 2008 From: mikem at redhat.com (Mike McLean) Date: Tue, 14 Oct 2008 16:10:56 -0400 Subject: [PATCH] internal setarch support for s390/s390x Message-ID: <48F4FCD0.2030409@redhat.com> Signed-off-by: Mike McLean --- py/mock/util.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 72aea36551cef7d5417d51f918c1697d835c7398.diff Type: text/x-patch Size: 410 bytes Desc: not available URL: From jkeating at redhat.com Tue Oct 14 20:31:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 14 Oct 2008 13:31:13 -0700 Subject: [PATCH] internal setarch support for s390/s390x In-Reply-To: <48F4FCD0.2030409@redhat.com> References: <48F4FCD0.2030409@redhat.com> Message-ID: <1224016273.4122.20.camel@luminos.localdomain> On Tue, 2008-10-14 at 16:10 -0400, Mike McLean wrote: > [PATCH] internal setarch support for s390/s390x Applied. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Thu Oct 16 02:19:19 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 15 Oct 2008 21:19:19 -0500 Subject: [PATCH] pungi handling of sparc Message-ID: <200810152119.23691.dennis@ausil.us> the attached patch makes the calls to anaconda include all sparc 32 bit arches when building a sparc tree. Without change the treearch to sparcv9v we would get the small handful of sparc packages and noarch. all the sparcv9 and sparcv9v woule be excluded. this patch is against master. there is one for F-9 in fedora cvs Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-handling-so-sparc-arch-gets-handled-correctly-w.patch Type: text/x-patch Size: 2893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From paul.schroeder at bluecoat.com Thu Oct 16 19:08:52 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Thu, 16 Oct 2008 14:08:52 -0500 Subject: [PATCH] new pungi command line options Message-ID: <48F79144.3050503@bluecoat.com> In my kickstart config, the %include files are all generated in %pre and don't exist at compose time, thus "--ignore-missing-includes". And I have no repo lines defined in my ks.cfg either, so the --repo-* options allow you to specify or add repo info from the command line. --repo-baseurl=REPO BASEURL repository name and base URL to use --repo-mirrorlist=REPO MIRRORLIST repository name and mirrorlist URL to use --ignore-missing-includes ignore missing %include files in the kickstart config So you can do something like this: pungi --name=fedora --ver=10 --flavor=beta --nodebuginfo --nosplitmedia --nosource -c ks.cfg --ignore-missing-includes --repo-mirrorlist=rawhide "http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=x86_64" Cheers...Paul... diff --git a/src/bin/pungi.py b/src/bin/pungi.py index fbec6fd..703fc0a 100755 --- a/src/bin/pungi.py +++ b/src/bin/pungi.py @@ -43,7 +43,7 @@ def main(): pass # Set up the kickstart parser and pass in the kickstart file we were handed - ksparser = pykickstart.parser.KickstartParser(pykickstart.version.makeVersion()) + ksparser = pykickstart.parser.KickstartParser(pykickstart.version.makeVersion(), missingIncludeIsFatal=opts.ignore_missing_includes) ksparser.readKickstart(opts.config) if opts.sourceisos: @@ -78,6 +78,15 @@ def main(): if opts.nodebuginfo: config.set('default', 'debuginfo', "False") + if opts.repo_baseurl: + for repo in opts.repo_baseurl: + rd = ksparser.handler.RepoData(name=repo[0], baseurl=repo[1]) + ksparser.handler.repo.add(rd) + if opts.repo_mirrorlist: + for repo in opts.repo_mirrorlist: + rd = ksparser.handler.RepoData(name=repo[0], mirrorlist=repo[1]) + ksparser.handler.repo.add(rd) + # Actually do work. mypungi = pypungi.Pungi(config, ksparser) @@ -166,6 +175,12 @@ if __name__ == '__main__': parser.add_option("-c", "--config", dest="config", help='Path to kickstart config file') + parser.add_option("--repo-baseurl", action="append", dest="repo_baseurl", type="string", nargs=2, + metavar="REPO BASEURL", help='repository name and base URL to use') + parser.add_option("--repo-mirrorlist", action="append", dest="repo_mirrorlist", type="string", nargs=2, + metavar="REPO MIRRORLIST", help='repository name and mirrorlist URL to use') + parser.add_option("--ignore-missing-includes", action="store_false", default=True, dest="ignore_missing_includes", + help="ignore missing %include files in the kickstart config") parser.add_option("--all-stages", action="store_true", default=True, dest="do_all", help="Enable ALL stages") parser.add_option("-G", action="store_true", default=False, dest="do_gather", From jkeating at redhat.com Thu Oct 16 19:15:05 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 16 Oct 2008 12:15:05 -0700 Subject: [PATCH] new pungi command line options In-Reply-To: <48F79144.3050503@bluecoat.com> References: <48F79144.3050503@bluecoat.com> Message-ID: <1224184506.4122.97.camel@luminos.localdomain> On Thu, 2008-10-16 at 14:08 -0500, Paul B Schroeder wrote: > In my kickstart config, the %include files are all generated in %pre > and don't exist at compose time, thus "--ignore-missing-includes". > And I have no repo lines defined in my ks.cfg either, so the --repo-* > options allow you to specify or add repo info from the command line. > > --repo-baseurl=REPO BASEURL > repository name and base URL to use > --repo-mirrorlist=REPO MIRRORLIST > repository name and mirrorlist URL to use > --ignore-missing-includes > ignore missing %include files in the kickstart > config Rather than throw more command line options at the problems, I wonder if it would make more sense to make the kickstart parsing gracefully handle and warn about missing includes. I also really don't like doing repo declaration via the command line arguments, but I'll think on this one a bit more. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Thu Oct 16 19:30:12 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Oct 2008 15:30:12 -0400 Subject: [PATCH] new pungi command line options In-Reply-To: <1224184506.4122.97.camel@luminos.localdomain> References: <48F79144.3050503@bluecoat.com> <1224184506.4122.97.camel@luminos.localdomain> Message-ID: <1224185412.370.27.camel@aglarond.local> On Thu, 2008-10-16 at 12:15 -0700, Jesse Keating wrote: > On Thu, 2008-10-16 at 14:08 -0500, Paul B Schroeder wrote: > > In my kickstart config, the %include files are all generated in %pre > > and don't exist at compose time, thus "--ignore-missing-includes". > > And I have no repo lines defined in my ks.cfg either, so the --repo-* > > options allow you to specify or add repo info from the command line. > > > > --repo-baseurl=REPO BASEURL > > repository name and base URL to use > > --repo-mirrorlist=REPO MIRRORLIST > > repository name and mirrorlist URL to use > > --ignore-missing-includes > > ignore missing %include files in the kickstart > > config > > Rather than throw more command line options at the problems, I wonder if > it would make more sense to make the kickstart parsing gracefully handle > and warn about missing includes. Yeah, I would think this should just work. I know it's something that's been used to good effect within anaconda in the past. > I also really don't like doing repo > declaration via the command line arguments, but I'll think on this one a > bit more. I definitely don't like this -- the idea of using a kickstart config for pungi, livecd-creator, etc is that the config file can be enough to reliably recreate a set of images. Passing the repos on the command line makes this entirely not the case. Jeremy From paul.schroeder at bluecoat.com Thu Oct 16 19:32:55 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Thu, 16 Oct 2008 14:32:55 -0500 Subject: [PATCH] new pungi command line options In-Reply-To: <1224184506.4122.97.camel@luminos.localdomain> References: <48F79144.3050503@bluecoat.com> <1224184506.4122.97.camel@luminos.localdomain> Message-ID: <48F796E7.306@bluecoat.com> Jesse Keating wrote: > On Thu, 2008-10-16 at 14:08 -0500, Paul B Schroeder wrote: >> In my kickstart config, the %include files are all generated in %pre >> and don't exist at compose time, thus "--ignore-missing-includes". >> And I have no repo lines defined in my ks.cfg either, so the --repo-* >> options allow you to specify or add repo info from the command line. >> >> --repo-baseurl=REPO BASEURL >> repository name and base URL to use >> --repo-mirrorlist=REPO MIRRORLIST >> repository name and mirrorlist URL to use >> --ignore-missing-includes >> ignore missing %include files in the kickstart >> config > > Rather than throw more command line options at the problems, I wonder if > it would make more sense to make the kickstart parsing gracefully handle > and warn about missing includes. A warning may be better. It certainly would be better than what it does now.. i.e. errors out and fails > I also really don't like doing repo > declaration via the command line arguments, but I'll think on this one a > bit more. Well, maybe I can make a case. ;) Without it, it becomes necessary to copy your kickstart config to a new file that only adds the repo lines. And then if you want to compose from another repo, you'll need yet another kickstart config with yet another repo line is needed. It would be nicer to be able to maintain just one kickstart config. Being able to simply define the repo on the command line allows that. Also, I've been doing composes out of /mnt/koji and this really helps when I want to compose agaist the latest generated repo. e.g. --repo-baseurl=f10beta "file:///mnt/koji/repos/dist-f10-beta/15/x86_64" -- --- Paul B Schroeder Blue Coat Systems, Inc. From paul.schroeder at bluecoat.com Thu Oct 16 19:39:28 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Thu, 16 Oct 2008 14:39:28 -0500 Subject: [PATCH] new pungi command line options In-Reply-To: <1224185412.370.27.camel@aglarond.local> References: <48F79144.3050503@bluecoat.com> <1224184506.4122.97.camel@luminos.localdomain> <1224185412.370.27.camel@aglarond.local> Message-ID: <48F79870.7060709@bluecoat.com> Jeremy Katz wrote: > On Thu, 2008-10-16 at 12:15 -0700, Jesse Keating wrote: >> On Thu, 2008-10-16 at 14:08 -0500, Paul B Schroeder wrote: >>> In my kickstart config, the %include files are all generated in %pre >>> and don't exist at compose time, thus "--ignore-missing-includes". >>> And I have no repo lines defined in my ks.cfg either, so the --repo-* >>> options allow you to specify or add repo info from the command line. >>> >>> --repo-baseurl=REPO BASEURL >>> repository name and base URL to use >>> --repo-mirrorlist=REPO MIRRORLIST >>> repository name and mirrorlist URL to use >>> --ignore-missing-includes >>> ignore missing %include files in the kickstart >>> config >> Rather than throw more command line options at the problems, I wonder if >> it would make more sense to make the kickstart parsing gracefully handle >> and warn about missing includes. > > Yeah, I would think this should just work. I know it's something that's > been used to good effect within anaconda in the past. > >> I also really don't like doing repo >> declaration via the command line arguments, but I'll think on this one a >> bit more. > > I definitely don't like this -- the idea of using a kickstart config for > pungi, livecd-creator, etc is that the config file can be enough to > reliably recreate a set of images. Passing the repos on the command > line makes this entirely not the case. But this doesn't preclude one from reliably recreating images. It simply allow you to add repos. -- --- Paul B Schroeder Blue Coat Systems, Inc. From katzj at redhat.com Thu Oct 16 19:48:52 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Oct 2008 15:48:52 -0400 Subject: [PATCH] new pungi command line options In-Reply-To: <48F79870.7060709@bluecoat.com> References: <48F79144.3050503@bluecoat.com> <1224184506.4122.97.camel@luminos.localdomain> <1224185412.370.27.camel@aglarond.local> <48F79870.7060709@bluecoat.com> Message-ID: <1224186532.370.29.camel@aglarond.local> On Thu, 2008-10-16 at 14:39 -0500, Paul B Schroeder wrote: > Jeremy Katz wrote: > > On Thu, 2008-10-16 at 12:15 -0700, Jesse Keating wrote: > >> On Thu, 2008-10-16 at 14:08 -0500, Paul B Schroeder wrote: > >> I also really don't like doing repo > >> declaration via the command line arguments, but I'll think on this one a > >> bit more. > > > > I definitely don't like this -- the idea of using a kickstart config for > > pungi, livecd-creator, etc is that the config file can be enough to > > reliably recreate a set of images. Passing the repos on the command > > line makes this entirely not the case. > But this doesn't preclude one from reliably recreating images. It > simply allow you to add repos. It doesn't preclude it, but it means that you have to give both a config file and the set of command line parameters you passed. It's the same argument as why you want to encode things in spec files rather than passing everything to rpmbuild with --define. Jeremy From skvidal at fedoraproject.org Fri Oct 17 20:20:21 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 17 Oct 2008 20:20:21 +0000 Subject: Supporting EPEL Builds in Koji In-Reply-To: <48EA6382.2070000@redhat.com> References: <1215705751.30991.7.camel@burren.bos.redhat.com> <487F8762.6090007@redhat.com> <1216334914.16888.82.camel@burren.bos.redhat.com> <4880B8F4.9040701@redhat.com> <1218663337.16585.63.camel@maunalani.home> <48EA6382.2070000@redhat.com> Message-ID: <1224274821.21581.100.camel@rosebud> On Mon, 2008-10-06 at 15:14 -0400, Mike McLean wrote: > > would result mergerepo creating a single repo that would only contain > > packages from dist-f9-ga-external if they did not exist in the > > Koji-generated repo (dist-custom-build + dist-custom), > > dist-f9-updates-external, or the blacklist of blocked packages. This is > > consistent with how Koji package inheritance currently works, and I > > think is the most intuitive approach. > > It is similar, but different in potentially confusing ways. External > repos do not have build structure, so we can't really have the same sort > of inheritance behavior with a combination of external repo tags and > normal tags. > I don't think I even saw a reply from Seth on this. Where does the > mergerepo code stand now? mergerepo has been checked into createrepo and should do what you want, now. it requires HEAD of createrepo and as soon as I make a new release yum 3.2.19-6 or 3.2.20 of yum. -sv From paul.schroeder at bluecoat.com Fri Oct 17 23:21:42 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Fri, 17 Oct 2008 18:21:42 -0500 Subject: automated signing of rpms in koji Message-ID: <48F91E06.4050201@bluecoat.com> Hello.. Looking for a bit of help.. I'm not quite sure how to do the above and don't see any real doco on doing so either. Basically, how do I get my packages to be signed with each build with my GPG key in koji? I see "import-sig" and "write-signed-rpm", but am not 100% certain how they work. And am not sure that they provide a way for my rpm builds to be signed automatically. Thanks in advance for any help.. Cheers...Paul... -- --- Paul B Schroeder Blue Coat Systems, Inc. From jkeating at redhat.com Fri Oct 17 23:25:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Oct 2008 16:25:37 -0700 Subject: automated signing of rpms in koji In-Reply-To: <48F91E06.4050201@bluecoat.com> References: <48F91E06.4050201@bluecoat.com> Message-ID: <1224285937.4142.45.camel@luminos.localdomain> On Fri, 2008-10-17 at 18:21 -0500, Paul B Schroeder wrote: > > Looking for a bit of help.. I'm not quite sure how to do the above and > don't see any real doco on doing so either. Basically, how do I get my > packages to be signed with each build with my GPG key in koji? > > I see "import-sig" and "write-signed-rpm", but am not 100% certain how > they work. And am not sure that they provide a way for my rpm builds to > be signed automatically. There is no way to do this within Koji itself. You'd have to do it using some other software that interacts with the API calls you mentioned. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dledford at redhat.com Mon Oct 20 13:36:12 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 20 Oct 2008 09:36:12 -0400 Subject: Koji probes Message-ID: <1224509772.4843.284.camel@firewall.xsintricity.com> I've been seeing stuff like this in my web server logs: A total of 3 sites probed the server 66.249.71.77 66.249.71.78 66.249.71.79 A total of 6 possible successful probes were detected (the following URLs contain strings that match one or more of a listing of strings that indicate a possible exploit): /koji/fileinfo?rpmID=866&filename=/usr/kerberos/bin/kpasswd HTTP Response 200 /koji/fileinfo?rpmID=1356&filename=/usr/bin/ldappasswd HTTP Response 200 /koji/fileinfo?rpmID=1954&filename=/usr/bin/vncpasswd HTTP Response 200 /koji/fileinfo?rpmID=3570&filename=/usr/bin/vncpasswd HTTP Response 200 /koji/fileinfo?rpmID=3107&filename=/usr/bin/ldappasswd HTTP Response 200 /koji/fileinfo?rpmID=2686&filename=/usr/kerberos/bin/kpasswd HTTP Response 200 So, I guess it's nice to know that koji is important enough that people are writing probes to try and ferret out information, but on the other hand, people are writing probes for it to try and ferret out information... -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From andreas at bawue.net Mon Oct 20 13:44:23 2008 From: andreas at bawue.net (Andreas Thienemann) Date: Mon, 20 Oct 2008 15:44:23 +0200 (CEST) Subject: Koji probes In-Reply-To: <1224509772.4843.284.camel@firewall.xsintricity.com> References: <1224509772.4843.284.camel@firewall.xsintricity.com> Message-ID: On Mon, 20 Oct 2008, Doug Ledford wrote: > So, I guess it's nice to know that koji is important enough that people > are writing probes to try and ferret out information, but on the other > hand, people are writing probes for it to try and ferret out > information... This looks more like automated probing for everything with the word passwd in it... Seen these for years at other systems, not much to worry about. regards, andreas From oliver at linux-kernel.at Mon Oct 20 13:55:37 2008 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 20 Oct 2008 15:55:37 +0200 Subject: Koji probes In-Reply-To: References: <1224509772.4843.284.camel@firewall.xsintricity.com> Message-ID: <48FC8DD9.4060007@linux-kernel.at> Andreas Thienemann wrote: > On Mon, 20 Oct 2008, Doug Ledford wrote: > >> So, I guess it's nice to know that koji is important enough that people >> are writing probes to try and ferret out information, but on the other >> hand, people are writing probes for it to try and ferret out >> information... > > This looks more like automated probing for everything with the word passwd > in it... > > Seen these for years at other systems, not much to worry about. Copy that. I've seen the same on various webservers here.... -of From mikem at redhat.com Mon Oct 20 16:13:23 2008 From: mikem at redhat.com (Mike McLean) Date: Mon, 20 Oct 2008 12:13:23 -0400 Subject: Koji probes In-Reply-To: <1224509772.4843.284.camel@firewall.xsintricity.com> References: <1224509772.4843.284.camel@firewall.xsintricity.com> Message-ID: <48FCAE23.7060500@redhat.com> Doug Ledford wrote: > A total of 3 sites probed the server > 66.249.71.77 > 66.249.71.78 > 66.249.71.79 These reverse map to googlebot.com. > A total of 6 possible successful probes were detected (the following URLs > contain strings that match one or more of a listing of strings that > indicate a possible exploit): > > /koji/fileinfo?rpmID=866&filename=/usr/kerberos/bin/kpasswd HTTP Response 200 > /koji/fileinfo?rpmID=1356&filename=/usr/bin/ldappasswd HTTP Response 200 > /koji/fileinfo?rpmID=1954&filename=/usr/bin/vncpasswd HTTP Response 200 > /koji/fileinfo?rpmID=3570&filename=/usr/bin/vncpasswd HTTP Response 200 > /koji/fileinfo?rpmID=3107&filename=/usr/bin/ldappasswd HTTP Response 200 > /koji/fileinfo?rpmID=2686&filename=/usr/kerberos/bin/kpasswd HTTP Response 200 These links are all reachable via the web ui, any crawler might will hit them. I suggest adding a robots.txt to keep crawlers out. From bruno at wolff.to Mon Oct 20 16:36:04 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 20 Oct 2008 11:36:04 -0500 Subject: Koji probes In-Reply-To: <48FCAE23.7060500@redhat.com> References: <1224509772.4843.284.camel@firewall.xsintricity.com> <48FCAE23.7060500@redhat.com> Message-ID: <20081020163604.GA7376@wolff.to> On Mon, Oct 20, 2008 at 12:13:23 -0400, Mike McLean wrote: > > These links are all reachable via the web ui, any crawler might will hit > them. I suggest adding a robots.txt to keep crawlers out. Or meta tags directed at robots. Doing things that way has some advantages over robots.txt. From paul.schroeder at bluecoat.com Wed Oct 22 19:41:48 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Wed, 22 Oct 2008 14:41:48 -0500 Subject: Yum Static Repos In-Reply-To: <4898D561.9020702@redhat.com> References: <4898D1C7.5020507@jla.rutgers.edu> <4898D561.9020702@redhat.com> Message-ID: <48FF81FC.6070001@bluecoat.com> Mike McLean wrote: > So, this term 'static-repo' is unfortunate. What folks really mean is > 'slowly changing repo at a convenient location.' One way to get such a > thing is to make a cronjob that periodically copies the current active > repo for a tag to a fixed location. Just saw this old post. Coincidentally, I recently patched my kojid (patch below) to create a symlink to the "latest" repo. Unless I'm missing something that's fundamentally wrong with this, it seems easier/better. So I can now always get to the latest repo via /mnt/koji/repos/repo_tag/latest. Add this to kojiweb.conf: Alias /repos/ "/mnt/koji/repos/" Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all And the "latest" can be had via http://koji.foo.com/repos/repo_tag/latest. Be sure to also add this to kojiweb.conf so that your packages can be found: Alias /packages/ "/mnt/koji/packages/" Options Indexes MultiViews FollowSymLinks AllowOverride None Order allow,deny Allow from all Cheers...Paul... diff --git a/builder/kojid b/builder/kojid index 8b566a3..aab0f0b 100755 --- a/builder/kojid +++ b/builder/kojid @@ -2223,6 +2223,7 @@ class CreaterepoTask(BaseTaskHandler): raise koji.GenericError, "Repo %(id)s not in INIT state (got %(state)s)" % rinfo pathinfo = koji.PathInfo(options.topdir) toprepodir = pathinfo.repo(repo_id, rinfo['tag_name']) + latestrepolink = pathinfo.repo('latest', rinfo['tag_name']) repodir = "%s/%s" % (toprepodir, arch) groupdata = os.path.join(toprepodir, 'groups', 'comps.xml') if not os.path.isdir(repodir): @@ -2266,6 +2267,10 @@ class CreaterepoTask(BaseTaskHandler): files.append(f) session.uploadWrapper("%s/%s" % (datadir, f), uploadpath, f) + if os.path.lexists(latestrepolink): + os.unlink(latestrepolink) + os.symlink(toprepodir, latestrepolink) + return [uploadpath, files] class WaitrepoTask(BaseTaskHandler): From mikem at redhat.com Wed Oct 22 21:24:31 2008 From: mikem at redhat.com (Mike McLean) Date: Wed, 22 Oct 2008 17:24:31 -0400 Subject: Yum Static Repos In-Reply-To: <48FF81FC.6070001@bluecoat.com> References: <4898D1C7.5020507@jla.rutgers.edu> <4898D561.9020702@redhat.com> <48FF81FC.6070001@bluecoat.com> Message-ID: <48FF9A0F.8000904@redhat.com> Paul B Schroeder wrote: > Mike McLean wrote: >> So, this term 'static-repo' is unfortunate. What folks really mean is >> 'slowly changing repo at a convenient location.' One way to get such a >> thing is to make a cronjob that periodically copies the current active >> repo for a tag to a fixed location. > Just saw this old post. Coincidentally, I recently patched my kojid > (patch below) > to create a symlink to the "latest" repo. Unless I'm missing something > that's > fundamentally wrong with this, it seems easier/better. This shouldn't be done in kojid. Koji does not require the builders to have write access to the filesystem, but your patch assumes it. My only worry is that the sometime rapid rate of repo regeneration might cause a problem for yum when the link changes at the wrong time. I guess it is probably ok though. This should probably be handled in HostExports.repoDone on the hub. I've made a patch for that. Will test and push later. Hmm, I should probably also make this configurable, since some admins might already have their own mechanism for creating such links (e.g. a cronjob). > So I can now always get to the latest repo via > /mnt/koji/repos/repo_tag/latest. Add this to kojiweb.conf: > Alias /repos/ "/mnt/koji/repos/" > > Options Indexes MultiViews FollowSymLinks > AllowOverride None > Order allow,deny > Allow from all > Is multiviews needed? I don't see how it will help anything with the content that Koji generates here. > And the "latest" can be had via http://koji.foo.com/repos/repo_tag/latest. > Be sure to also add this to kojiweb.conf so that your packages can be > found: > Alias /packages/ "/mnt/koji/packages/" > > Options Indexes MultiViews FollowSymLinks > AllowOverride None > Order allow,deny > Allow from all > I don't see why FollowSymLinks is required for /mnt/koji/packages/ From paul.schroeder at bluecoat.com Wed Oct 22 21:37:36 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Wed, 22 Oct 2008 16:37:36 -0500 Subject: Yum Static Repos In-Reply-To: <48FF9A0F.8000904@redhat.com> References: <4898D1C7.5020507@jla.rutgers.edu> <4898D561.9020702@redhat.com> <48FF81FC.6070001@bluecoat.com> <48FF9A0F.8000904@redhat.com> Message-ID: <48FF9D20.7090401@bluecoat.com> Mike McLean wrote: > Paul B Schroeder wrote: >> Mike McLean wrote: >>> So, this term 'static-repo' is unfortunate. What folks really mean is >>> 'slowly changing repo at a convenient location.' One way to get such >>> a thing is to make a cronjob that periodically copies the current >>> active repo for a tag to a fixed location. >> Just saw this old post. Coincidentally, I recently patched my kojid >> (patch below) >> to create a symlink to the "latest" repo. Unless I'm missing >> something that's >> fundamentally wrong with this, it seems easier/better. > > This shouldn't be done in kojid. Koji does not require the builders to > have write access to the filesystem, but your patch assumes it. Gotcha.. > My only worry is that the sometime rapid rate of repo regeneration might > cause a problem for yum when the link changes at the wrong time. I guess > it is probably ok though. I had thought about that actually, but then thought it may not be very likely to cause an issue. It's definitely not an issue for me as my repos aren't getting regenerated all to often (and I'm the only one really using them). > This should probably be handled in HostExports.repoDone on the hub. I've > made a patch for that. Will test and push later. Cool.. Thanks.. > Hmm, I should probably also make this configurable, since some admins > might already have their own mechanism for creating such links (e.g. a > cronjob). > >> So I can now always get to the latest repo via >> /mnt/koji/repos/repo_tag/latest. Add this to kojiweb.conf: >> Alias /repos/ "/mnt/koji/repos/" >> >> Options Indexes MultiViews FollowSymLinks >> AllowOverride None >> Order allow,deny >> Allow from all >> > > Is multiviews needed? I don't see how it will help anything with the > content that Koji generates here. > >> And the "latest" can be had via >> http://koji.foo.com/repos/repo_tag/latest. >> Be sure to also add this to kojiweb.conf so that your packages can be >> found: >> Alias /packages/ "/mnt/koji/packages/" >> >> Options Indexes MultiViews FollowSymLinks >> AllowOverride None >> Order allow,deny >> Allow from all >> > > I don't see why FollowSymLinks is required for /mnt/koji/packages/ I simply didn't look over the options I put in my kojiweb.conf too well. It may be worth having the proper config commented out in the kojiweb.conf file by default. Then when somebody installs, they can simply uncomment these and change the directory names if need be. -- --- Paul B Schroeder Blue Coat Systems, Inc.