From djuran at redhat.com Sun Dec 6 15:27:11 2009 From: djuran at redhat.com (David Juran) Date: Sun, 6 Dec 2009 10:27:11 -0500 (EST) Subject: Can I avoid the ppc builder? In-Reply-To: <1641320298.1223261260112956350.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <2002296955.1223281260113231291.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Hello. Is there a way I can keep my builds away from the ppc builders? I'm trying to push an update to my noarch (java) package (http://koji.fedoraproject.org/koji/taskinfo?taskID=1847061) but it seems to end up on a ppc64 builder and fail miserably )-: Now I promise I will try to dig in to the root cause of the build failure but since ppc no longer is a primary architecture, the failed build on PPC shouldn't hold up the release on the primary architectures. -- David Juran Sr. Consultant Red Hat +358-504-146348 From jkeating at redhat.com Sun Dec 6 15:57:25 2009 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 06 Dec 2009 07:57:25 -0800 Subject: Can I avoid the ppc builder? In-Reply-To: <2002296955.1223281260113231291.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <2002296955.1223281260113231291.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <1260115045.6049.1.camel@localhost.localdomain> On Sun, 2009-12-06 at 10:27 -0500, David Juran wrote: > Hello. > > Is there a way I can keep my builds away from the ppc builders? I'm trying to push an update to my noarch (java) package (http://koji.fedoraproject.org/koji/taskinfo?taskID=1847061) but it seems to end up on a ppc64 builder and fail miserably )-: > Now I promise I will try to dig in to the root cause of the build failure but since ppc no longer is a primary architecture, the failed build on PPC shouldn't hold up the release on the primary architectures. > Not really, that is a bit of a problem. -- 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: 198 bytes Desc: This is a digitally signed message part URL: From djuran at redhat.com Sun Dec 6 16:19:22 2009 From: djuran at redhat.com (David Juran) Date: Sun, 6 Dec 2009 11:19:22 -0500 (EST) Subject: Can I avoid the ppc builder? In-Reply-To: <1260115045.6049.1.camel@localhost.localdomain> Message-ID: <1119784957.1224831260116362326.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> ----- "Jesse Keating" wrote: > On Sun, 2009-12-06 at 10:27 -0500, David Juran wrote: > > Hello. > > > > Is there a way I can keep my builds away from the ppc builders? I'm > trying to push an update to my noarch (java) package > (http://koji.fedoraproject.org/koji/taskinfo?taskID=1847061) but it > seems to end up on a ppc64 builder and fail miserably )-: > > Now I promise I will try to dig in to the root cause of the build > failure but since ppc no longer is a primary architecture, the failed > build on PPC shouldn't hold up the release on the primary > architectures. > > > > Not really, that is a bit of a problem. Doing some bugzilla searching, I think I'm running into https://bugzilla.redhat.com/show_bug.cgi?id=537536 I'll try to get hold of Andrew tomorrow to see if he can push the correction to stable. -- David Juran Sr. Consultant Red Hat +358-504-146348 From jwboyer at gmail.com Sun Dec 6 17:42:49 2009 From: jwboyer at gmail.com (Josh Boyer) Date: Sun, 6 Dec 2009 12:42:49 -0500 Subject: Can I avoid the ppc builder? In-Reply-To: <2002296955.1223281260113231291.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> References: <1641320298.1223261260112956350.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <2002296955.1223281260113231291.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> Message-ID: <20091206174249.GA7691@hansolo.jdub.homelinux.org> On Sun, Dec 06, 2009 at 10:27:11AM -0500, David Juran wrote: >Hello. > >Is there a way I can keep my builds away from the ppc builders? I'm trying to push an update to my noarch (java) package (http://koji.fedoraproject.org/koji/taskinfo?taskID=1847061) but it seems to end up on a ppc64 builder and fail miserably )-: > Now I promise I will try to dig in to the root cause of the build failure but since ppc no longer is a primary architecture, the failed build on PPC shouldn't hold up the release on the primary architectures. PPC/PPC64 are still Primary architectures for Fedora 10 - 12. josh From peng.chen22 at gmail.com Tue Dec 8 01:57:43 2009 From: peng.chen22 at gmail.com (peng chen) Date: Tue, 8 Dec 2009 09:57:43 +0800 Subject: When and how the mock removes the build directories under the "/var/lib/mock" in koji building hosts Message-ID: <7e200e7f0912071757o6addce75sc3a5ab3aa5b0fa9a@mail.gmail.com> Hello, fedora-buildsys-list: Recently, one of my building hosts's mock directory usually be filled with build directories, I wonder why the build directories of finishing building task not to be removed immediately for make room for the coming task , yet they don't stay here untill some time elapses. So, When and how the mock removes the build directories under the "/var/lib/mock" in koji building hosts? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lijian.gnu at gmail.com Wed Dec 9 01:25:29 2009 From: lijian.gnu at gmail.com (Jian Lee) Date: Wed, 9 Dec 2009 09:25:29 +0800 Subject: When and how the mock removes the build directories under the "/var/lib/mock" in koji building hosts In-Reply-To: <7e200e7f0912071757o6addce75sc3a5ab3aa5b0fa9a@mail.gmail.com> References: <7e200e7f0912071757o6addce75sc3a5ab3aa5b0fa9a@mail.gmail.com> Message-ID: <200912090925.30438.lijian.gnu@gmail.com> hi, maybe you can search "koji remove dir" in google. this is a solved question which asked by me before. give you a url that i search just now : http://osdir.com/ml/fedora-buildsys-list/2009-06/msg00034.html Thanks, Tuesday 08 December 200909:57:43peng chen ??? Hello, fedora-buildsys-list: Recently, one of my building hosts's mock directory usually be filled with build directories, I wonder why the build directories of finishing building task not to be removed immediately for make room for the coming task , yet they don't stay here untill some time elapses. So, When and how the mock removes the build directories under the "/var/lib/mock" in koji building hosts? Thanks! ---- Jian Lee [ http://jianlee.ylinux.org ] From mikem at redhat.com Wed Dec 9 02:23:09 2009 From: mikem at redhat.com (Mike McLean) Date: Tue, 08 Dec 2009 21:23:09 -0500 Subject: When and how the mock removes the build directories under the "/var/lib/mock" in koji building hosts In-Reply-To: <7e200e7f0912071757o6addce75sc3a5ab3aa5b0fa9a@mail.gmail.com> References: <7e200e7f0912071757o6addce75sc3a5ab3aa5b0fa9a@mail.gmail.com> Message-ID: <4B1F0A0D.3070705@redhat.com> On 12/07/2009 08:57 PM, peng chen wrote: > Hello, fedora-buildsys-list: > Recently, one of my building hosts's mock directory usually be filled with > build directories, I wonder why the build directories of finishing building > task not to be removed immediately for make room for the coming task , yet > they don't stay here untill some time elapses. So, When and how the mock > removes the build directories under the "/var/lib/mock" in koji building > hosts? > Thanks! Jian's link is a bit confusing. There is a clearer explanation here: https://www.redhat.com/archives/fedora-buildsys-list/2009-June/msg00003.html From lijian.gnu at gmail.com Wed Dec 9 05:42:16 2009 From: lijian.gnu at gmail.com (Jian Lee) Date: Wed, 9 Dec 2009 13:42:16 +0800 Subject: When and how the mock removes the build directories under the "/var/lib/mock" in koji building hosts In-Reply-To: <4B1F0A0D.3070705@redhat.com> References: <7e200e7f0912071757o6addce75sc3a5ab3aa5b0fa9a@mail.gmail.com> <4B1F0A0D.3070705@redhat.com> Message-ID: <200912091342.18042.lijian.gnu@gmail.com> Thanks for mike's correct! Wednesday 09 December 200910:23:09Mike McLean ??? On 12/07/2009 08:57 PM, peng chen wrote: > Hello, fedora-buildsys-list: > Recently, one of my building hosts's mock directory usually be filled with > build directories, I wonder why the build directories of finishing building > task not to be removed immediately for make room for the coming task , yet > they don't stay here untill some time elapses. So, When and how the mock > removes the build directories under the "/var/lib/mock" in koji building > hosts? > Thanks! Jian's link is a bit confusing. There is a clearer explanation here: https://www.redhat.com/archives/fedora-buildsys-list/2009- June/msg00003.html -- Fedora-buildsys-list mailing list Fedora-buildsys-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list ---- Jian Lee [ http://jianlee.ylinux.org ] From ctria at grid.auth.gr Mon Dec 14 19:03:49 2009 From: ctria at grid.auth.gr (Christos Triantafyllidis) Date: Mon, 14 Dec 2009 21:03:49 +0200 Subject: X509 login patches Message-ID: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> Hi all and welcome me to the list :), i'm using koji since a few week and i needed X509 authentication. Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the "username" of the user there are cases (like in our PKI) where CN is just "Christos Triantafyllidis" and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have "EnvVarForUserName = SSL_CLIENT_S_DN" which uses the whole DN as username. b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution. I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them. Best regards, Christos Triantafyllidis [1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3330 bytes Desc: not available URL: From steve.traylen at cern.ch Mon Dec 14 19:32:50 2009 From: steve.traylen at cern.ch (Steve Traylen) Date: Mon, 14 Dec 2009 20:32:50 +0100 Subject: X509 login patches In-Reply-To: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> Message-ID: On Mon, Dec 14, 2009 at 8:03 PM, Christos Triantafyllidis wrote: > Hi all and welcome me to the list :), > > ? ?i'm using koji since a few week and i needed X509 authentication. > Unfortunately current support for x509 was limited to: > a) Use of the CN part only from the subject DN as the username > ?Although traditionally CN can be the "username" of the user there are cases > (like in our PKI) where CN is just "Christos Triantafyllidis" and of course > many users can have the same name but different DNs. To avoid this but also > keep the backwards compatibility i have introduced a new variable to be > exported by both apache config (for git-web) and hub.conf (for the rest of > the tools) called EnvVarForUserName which defines which variable to use as > Username. For my case i have "EnvVarForUserName = SSL_CLIENT_S_DN" which > uses the whole DN as username. What did you do about the email address? It normally uses CN at configured.org I should look at the patch of course. Steve > > b) Keep asking the user to provide their pass-phrase many times for the the > same operation > ?This leads (IMHO) many users to use password-less certificates. > Unfortunately this is not acceptable according to our PKI policy so i added > a callback to cache the passphrase within each koji execution. > > ?I have created some patches to both this limitations and i have uploaded > the to my git repository[1]. Feel free to use/clone them. > > Best regards, > Christos Triantafyllidis > > [1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -- Steve Traylen From mikeb at redhat.com Mon Dec 14 19:42:11 2009 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 14 Dec 2009 14:42:11 -0500 Subject: X509 login patches In-Reply-To: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> Message-ID: <4B269513.9030209@redhat.com> On 12/14/2009 02:03 PM, Christos Triantafyllidis wrote: > Hi all and welcome me to the list :), Welcome, and thanks for the patches! Comments in-line. > i'm using koji since a few week and i needed X509 authentication. > Unfortunately current support for x509 was limited to: > a) Use of the CN part only from the subject DN as the username > Although traditionally CN can be the "username" of the user there are > cases (like in our PKI) where CN is just "Christos Triantafyllidis" and > of course many users can have the same name but different DNs. To avoid > this but also keep the backwards compatibility i have introduced a new > variable to be exported by both apache config (for git-web) and hub.conf > (for the rest of the tools) called EnvVarForUserName which defines which > variable to use as Username. For my case i have "EnvVarForUserName = > SSL_CLIENT_S_DN" which uses the whole DN as username. koji-hub already supports a DNUsernameComponent option. Rather than introduce a new config option, I think I'd rather see "DNUsernameComponent=DN" special-cased to mean "use the whole DN". I don't see any env. vars other than DN that would be useful for authentication. > b) Keep asking the user to provide their pass-phrase many times for the > the same operation > This leads (IMHO) many users to use password-less certificates. > Unfortunately this is not acceptable according to our PKI policy so i > added a callback to cache the passphrase within each koji execution. This looks very interesting, thanks. I'll see about testing it locally and merging it. I wonder if this could be extended to integrate with gnome-keyring (or similar) to provide once-per-session login for SSL certificates. I'll look into this. > I have created some patches to both this limitations and i have > uploaded the to my git repository[1]. Feel free to use/clone them. > > Best regards, > Christos Triantafyllidis > > [1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git > > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From ctria at grid.auth.gr Mon Dec 14 19:43:05 2009 From: ctria at grid.auth.gr (Christos Triantafyllidis) Date: Mon, 14 Dec 2009 21:43:05 +0200 Subject: X509 login patches In-Reply-To: References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> Message-ID: <8CA30082-46AA-47B1-B4BB-941B95BB0D55@grid.auth.gr> On 14 ??? 2009, at 9:32 ?.?., Steve Traylen wrote: > > What did you do about the email address? It normally uses CN at configured.org > Well it normally uses username at domain where in my case it already invalid. I'm planning to extend the users table to include also email. So now it is DN at domain. > I should look at the patch of course. > Steve Christos From ctria at grid.auth.gr Mon Dec 14 20:52:04 2009 From: ctria at grid.auth.gr (Christos Triantafyllidis) Date: Mon, 14 Dec 2009 22:52:04 +0200 Subject: X509 login patches In-Reply-To: <4B269513.9030209@redhat.com> References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> <4B269513.9030209@redhat.com> Message-ID: Hi Mike, first of all i need to clarify that i'm not koji expert (as i said i'm using it only a few weeks). On Dec 14, 2009, at 9:42 PM, Mike Bonnet wrote: > > koji-hub already supports a DNUsernameComponent option. Rather than > introduce a new config option, I think I'd rather see > "DNUsernameComponent=DN" special-cased to mean "use the whole DN". I > don't see any env. vars other than DN that would be useful for > authentication. Hm that sounds like a cleaner approach! Thanks. I'm going to implemented probably later today... One special case that i can think is if one would like to use the issuer's DN or any part of it but this is not the case for me so i can skip it. One case that (i think) is not covered even from my approach though is the usage of an X509 extension of the certificate (i.e. the SubjectAlternativeNames) but for now i can live without them. Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3330 bytes Desc: not available URL: From ctria at grid.auth.gr Tue Dec 15 00:25:22 2009 From: ctria at grid.auth.gr (Christos Triantafyllidis) Date: Tue, 15 Dec 2009 02:25:22 +0200 Subject: X509 login patches In-Reply-To: References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> <4B269513.9030209@redhat.com> Message-ID: <7ADA1CFA-185C-47EA-A4B9-294E92450ADF@grid.auth.gr> Hi again, On Dec 14, 2009, at 10:52 PM, Christos Triantafyllidis wrote: > Hi Mike, > > first of all i need to clarify that i'm not koji expert (as i > said i'm using it only a few weeks). > > On Dec 14, 2009, at 9:42 PM, Mike Bonnet wrote: >> >> koji-hub already supports a DNUsernameComponent option. Rather than >> introduce a new config option, I think I'd rather see >> "DNUsernameComponent=DN" special-cased to mean "use the whole DN". I >> don't see any env. vars other than DN that would be useful for >> authentication. > > Hm that sounds like a cleaner approach! Thanks. I'm going to > implemented probably later today... DONE! Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3330 bytes Desc: not available URL: From Juha.Tuomala at iki.fi Tue Dec 15 12:52:28 2009 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Tue, 15 Dec 2009 14:52:28 +0200 (EET) Subject: X509 login patches In-Reply-To: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> Message-ID: On Mon, 14 Dec 2009, Christos Triantafyllidis wrote: > i'm using koji since a few week and i needed X509 authentication. This is interesting. Any idea, would client side pkcs11.so module sertificates work out of the box then? In my understading, the part how the certificate gets into http connection, is transparent to server. In many european countries, there are goverment PKI cards that kind of establishes potential, authenticatable userbase automatically. I use the id-card in browser quite a bit and especially the SSL client-cert works very well. That would be interesting to try koji with those id-card certificates. Tuju -- Ajatteleva ihminen tarvitsee unta. From ctria at grid.auth.gr Tue Dec 15 13:26:01 2009 From: ctria at grid.auth.gr (Christos Triantafyllidis) Date: Tue, 15 Dec 2009 15:26:01 +0200 Subject: X509 login patches In-Reply-To: References: <8B5C2486-E855-431B-A402-4F2B58EFC95B@grid.auth.gr> Message-ID: Hi Tuju, no this patch doesn't cover this case. I guess this won't be that difficult to be implemented if it is supported by pyOpenSSL the SSL part is done there. Unfortunately my country doesn't use any PKI card but i'm also interested in using my eToken for this. Regards, Christos On Dec 15, 2009, at 2:52 PM, Juha Tuomala wrote: > > > > On Mon, 14 Dec 2009, Christos Triantafyllidis wrote: >> i'm using koji since a few week and i needed X509 authentication. > > This is interesting. Any idea, would client side pkcs11.so module > sertificates work out of the box then? In my understading, the > part how the certificate gets into http connection, is transparent > to server. > > In many european countries, there are goverment PKI cards that kind > of establishes potential, authenticatable userbase automatically. > > I use the id-card in browser quite a bit and especially the SSL > client-cert works very well. > > That would be interesting to try koji with those id-card certificates. > > > Tuju > > -- > Ajatteleva ihminen tarvitsee unta. > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3330 bytes Desc: not available URL: From sergio at sergiomb.no-ip.org Thu Dec 17 08:26:46 2009 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Thu, 17 Dec 2009 08:26:46 +0000 Subject: add web browser text based on rescue from boot.iso Message-ID: <1261038406.16680.14.camel@segulix> Hi, using boot.iso from releases/12/Fedora/x86_64/os/images/ I can do a usb boot disc and run the rescue mode, easily, with command livecd-iso-to-disk boot.iso /dev/sdc And install.img is write on /images. I also could update install.img using method wrote in : http://www.fedoraproject.org/wiki/Anaconda/Updates#How_to_Create_an_Anaconda_Updates_Image but I don't know how or where with /usr/lib/anaconda-runtime/buildinstall and/or pungi -B , can customize my install.img. For example I'd like add lynx (to install.img), how I can do that ? Other question rescue mode don't have any web browser text based ? Thanks in advance, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3159 bytes Desc: not available URL: From wacker at octothorp.org Wed Dec 30 07:05:56 2009 From: wacker at octothorp.org (William F. Acker WB2FLW +1 303 722 7209) Date: Wed, 30 Dec 2009 00:05:56 -0700 (MST) Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? Message-ID: Hi all, I've always noticed that when a package is updated, sometimes the i686 version isn't put into the x86_64 repo for updates. As a workaround, I add the packages to the exclude list in the fedora repo so I don't get x86_64 versions that are newer than the left behind i686 versions. This means that my disks will have less i686 stuff than was released originally by The Fedora Project. I could just carry the updated packages in a local repo, thereby preserving the original package list. Does anyone know which is the best approach? TIA. -- Bill in Denver From jcm at redhat.com Thu Dec 31 09:30:32 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 31 Dec 2009 09:30:32 +0000 Subject: How to handel spinning when i686 versions of packages don't make it into the updates repo? In-Reply-To: References: Message-ID: <1262251832.602.0.camel@tonnant> On Wed, 2009-12-30 at 00:05 -0700, William F. Acker WB2FLW +1 303 722 7209 wrote: > I've always noticed that when a package is updated, sometimes the > i686 version isn't put into the x86_64 repo for updates. Can you clarify what you're asking here? It sounds like you're saying you expect the x86_64 repo to contain i686 packages? Jon.