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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 12-07-2008, 11:25 AM
Fedora Extras repoclosure
 
Default Broken dependencies in EPEL - 2008-12-07

================================================== ====================
The results in this summary consider Test Updates!
================================================== ====================

Summary of broken packages (by owner):

gilboa AT fedoraproject.org
cgdb - 0.6.4-2.el5.ppc

jjohnstn AT fedoraproject.org
eclipse-cdt - 1:3.1.2-8.el5.ppc

konradm AT fedoraproject.org
hellanzb - 0.13-5.el5.noarch

lkundrak AT fedoraproject.org
thunderbird-lightning - 0.8-3.el5.2.ppc

mdomsch AT fedoraproject.org
dkms - 2.0.19.1-1.el5.noarch

mmahut AT fedoraproject.org
grc - 0.70-3.el5.noarch

msuchy AT fedoraproject.org
perl-Satcon - 1.9-1.el5.noarch

pertusus AT fedoraproject.org
ooo2txt - 0.0.6-3.el5.noarch

salimma AT fedoraproject.org
emacs-gambit - 4.2.8-6.el5.i386
emacs-gambit - 4.2.8-6.el5.ppc
emacs-gambit - 4.2.8-6.el5.x86_64
emacs-vala - 0.3.4-2.el5.i386
emacs-vala - 0.3.4-2.el5.ppc
emacs-vala - 0.3.4-2.el5.x86_64

sindrepb AT fedoraproject.org
perl-libwhisker2 - 2.4-3.el5.noarch

spot AT fedoraproject.org
tcl-tcludp - 1.0.8-1.el5.i386
tcl-tcludp - 1.0.8-1.el5.ppc
tcl-tcludp - 1.0.8-1.el5.x86_64
tcl-tclvfs - 20080503-1.el5.i386
tcl-tclvfs - 20080503-1.el5.ppc
tcl-tclvfs - 20080503-1.el5.x86_64
tcl-tktreectrl - 2.2.8-1.el5.1.i386
tcl-tktreectrl - 2.2.8-1.el5.1.ppc
tcl-tktreectrl - 2.2.8-1.el5.1.x86_64

steve AT fedoraproject.org
amavisd-new - 2.4.5-1.el5.noarch
cpanspec - 1.77-1.el5.noarch

thias AT fedoraproject.org
gnome-applet-sshmenu - 3.15-5.el5.noarch
python-Coherence - 0.2.1-3.el5.noarch
sshmenu - 3.15-5.el5.noarch

tmraz AT fedoraproject.org
vpnc - 0.4.0-2.el5.ppc

trasher AT fedoraproject.org
BackupPC - 3.1.0-2.el5.noarch


================================================== ====================
Broken packages in fedora-epel-5-ppc:

BackupPC-3.1.0-2.el5.noarch requires perl(Archive::Zip)
amavisd-new-2.4.5-1.el5.noarch requires perl(Archive::Zip)
cgdb-0.6.4-2.el5.ppc requires gdb
cpanspec-1.77-1.el5.noarch requires perl(Archive::Zip)
dkms-2.0.19.1-1.el5.noarch requires kernel-devel
eclipse-cdt-1:3.1.2-8.el5.ppc requires gdb
ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip)
thunderbird-lightning-0.8-3.el5.2.ppc requires thunderbird
vpnc-0.4.0-2.el5.ppc requires kernel >= 0:2.4
vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-i386-server-productivity-4. Please verify its path and try again
vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-x86_64-server-productivity-4. Please verify its path and try again
vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-ppc-server-productivity-4. Please verify its path and try again


================================================== ====================
Broken packages in fedora-epel-testing-5-i386:

emacs-gambit-4.2.8-6.el5.i386 requires emacs(bin) >= 0:21.4
emacs-vala-0.3.4-2.el5.i386 requires emacs(bin) >= 0:21.4
gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2)
gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2)
grc-0.70-3.el5.noarch requires gnuradio
hellanzb-0.13-5.el5.noarch requires python-twisted
hellanzb-0.13-5.el5.noarch requires par2cmdline
perl-Satcon-1.9-1.el5.noarch requires perl(RPM::Specfile)
perl-libwhisker2-2.4-3.el5.noarch requires perl(MD5)
python-Coherence-0.2.1-3.el5.noarch requires python-nevow
sshmenu-3.15-5.el5.noarch requires ruby(gtk2)
tcl-tcludp-1.0.8-1.el5.i386 requires tcl = 0:8.4
tcl-tclvfs-20080503-1.el5.i386 requires tcl = 0:8.4
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires tcl(abi) = 0:8.4
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Reading in repository metadata - please wait....
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Checking Dependencies
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Repos looked at: 6
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-5-x86_64
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-x86_64-server-productivity-5
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64-vt
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires buildsys-5-x86_64
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-testing-5-x86_64
tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Num Packages in Repos: 6521


================================================== ====================
Broken packages in fedora-epel-testing-5-ppc:

emacs-gambit-4.2.8-6.el5.ppc requires emacs(bin) >= 0:21.4
emacs-vala-0.3.4-2.el5.ppc requires emacs(bin) >= 0:21.4
gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2)
gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2)
grc-0.70-3.el5.noarch requires gnuradio
hellanzb-0.13-5.el5.noarch requires python-twisted
hellanzb-0.13-5.el5.noarch requires par2cmdline
perl-Satcon-1.9-1.el5.noarch requires perl(RPM::Specfile)
perl-libwhisker2-2.4-3.el5.noarch requires perl(MD5)
python-Coherence-0.2.1-3.el5.noarch requires python-nevow
sshmenu-3.15-5.el5.noarch requires ruby(gtk2)
tcl-tcludp-1.0.8-1.el5.ppc requires tcl = 0:8.4
tcl-tclvfs-20080503-1.el5.ppc requires tcl = 0:8.4
tcl-tktreectrl-2.2.8-1.el5.1.ppc requires tcl(abi) = 0:8.4


================================================== ====================
Broken packages in fedora-epel-testing-5-x86_64:

emacs-gambit-4.2.8-6.el5.x86_64 requires emacs(bin) >= 0:21.4
emacs-vala-0.3.4-2.el5.x86_64 requires emacs(bin) >= 0:21.4
gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(panelapplet2)
gnome-applet-sshmenu-3.15-5.el5.noarch requires ruby(gconf2)
grc-0.70-3.el5.noarch requires gnuradio
hellanzb-0.13-5.el5.noarch requires python-twisted
hellanzb-0.13-5.el5.noarch requires par2cmdline
perl-Satcon-1.9-1.el5.noarch requires perl(RPM::Specfile)
perl-libwhisker2-2.4-3.el5.noarch requires perl(MD5)
python-Coherence-0.2.1-3.el5.noarch requires python-nevow
sshmenu-3.15-5.el5.noarch requires ruby(gtk2)
tcl-tcludp-1.0.8-1.el5.x86_64 requires tcl = 0:8.4
tcl-tclvfs-20080503-1.el5.x86_64 requires tcl = 0:8.4
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires tcl(abi) = 0:8.4
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Reading in repository metadata - please wait....
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Checking Dependencies
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Repos looked at: 6
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-5-ppc
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-ppc-server-productivity-5
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires fedora-epel-5-ppc
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-5-ppc-vt
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires fedora-epel-testing-5-ppc
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires buildsys-5-ppc
tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Num Packages in Repos: 4801

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-08-2008, 02:27 PM
Michael Schwendt
 
Default Broken dependencies in EPEL - 2008-12-07

On Sun, 07 Dec 2008 12:25:02 -0000, Fedora wrote:

> vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
> vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-i386-server-productivity-4. Please verify its path and try again
> vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
> vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-x86_64-server-productivity-4. Please verify its path and try again
> vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
> vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-ppc-server-productivity-4. Please verify its path and try again
>

> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Reading in repository metadata - please wait....
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Checking Dependencies
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Repos looked at: 6
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-5-x86_64
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-x86_64-server-productivity-5
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64-vt
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires buildsys-5-x86_64
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-testing-5-x86_64
> tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Num Packages in Repos: 6521


> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Checking Dependencies
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Repos looked at: 6
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-5-ppc
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-ppc-server-productivity-5
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires fedora-epel-5-ppc
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-5-ppc-vt
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires fedora-epel-testing-5-ppc
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires buildsys-5-ppc
> tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Num Packages in Repos: 4801

Currently these people are members of the EPEL Steering Committee:

* Mike McGrath ( mmcgrath )
* Michael Stahnke ( stahnma )
* Kevin Fenzi ( nirik )
* Xavier Lamien ( SmootherFrOgZ )
* Andy Gospodarek ( Gospo )
* Jeff Sheltren ( Jeff_S )
* Karsten Wade ( quaid )
* Stephen J Smoogen ( smooge ) (Chair)

Who of these people has the necessary privileges to shut off this thing,
which is broken for many months? My reply from last week is unanswered.
Do you think it's right to spam your packagers with crap in the reports
just because you misconfigured repoclosure?

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-08-2008, 05:23 PM
Kevin Fenzi
 
Default Broken dependencies in EPEL - 2008-12-07

On Mon, 8 Dec 2008 16:27:07 +0100
mschwendt@gmail.com (Michael Schwendt) wrote:

> On Sun, 07 Dec 2008 12:25:02 -0000, Fedora wrote:
>
> > vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata
> > - please wait.... vpnc-0.4.0-2.el5.ppc requires Cannot retrieve
> > repository metadata (repomd.xml) for repository:
> > rhel-i386-server-productivity-4. Please verify its path and try
> > again vpnc-0.4.0-2.el5.ppc requires Reading in repository
> > metadata - please wait.... vpnc-0.4.0-2.el5.ppc requires Cannot
> > retrieve repository metadata (repomd.xml) for repository:
> > rhel-x86_64-server-productivity-4. Please verify its path and try
> > again vpnc-0.4.0-2.el5.ppc requires Reading in repository
> > metadata - please wait.... vpnc-0.4.0-2.el5.ppc requires Cannot
> > retrieve repository metadata (repomd.xml) for repository:
> > rhel-ppc-server-productivity-4. Please verify its path and try again
> >
>
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Reading in
> > repository metadata - please wait....
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Checking Dependencies
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Repos looked at: 6
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires
> > rhel-x86_64-server-productivity-5
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64-vt
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires buildsys-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires
> > fedora-epel-testing-5-x86_64 tcl-tktreectrl-2.2.8-1.el5.1.i386
> > requires Num Packages in Repos: 6521
>
>
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Checking
> > Dependencies tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Repos
> > looked at: 6 tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires
> > rhel-5-ppc tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires
> > rhel-ppc-server-productivity-5 tcl-tktreectrl-2.2.8-1.el5.1.x86_64
> > requires fedora-epel-5-ppc tcl-tktreectrl-2.2.8-1.el5.1.x86_64
> > requires rhel-5-ppc-vt tcl-tktreectrl-2.2.8-1.el5.1.x86_64
> > requires fedora-epel-testing-5-ppc
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires buildsys-5-ppc
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Num Packages in
> > Repos: 4801
>
> Currently these people are members of the EPEL Steering Committee:
>
> * Mike McGrath ( mmcgrath )
> * Michael Stahnke ( stahnma )
> * Kevin Fenzi ( nirik )
> * Xavier Lamien ( SmootherFrOgZ )
> * Andy Gospodarek ( Gospo )
> * Jeff Sheltren ( Jeff_S )
> * Karsten Wade ( quaid )
> * Stephen J Smoogen ( smooge ) (Chair)
>
> Who of these people has the necessary privileges to shut off this
> thing, which is broken for many months? My reply from last week is
> unanswered. Do you think it's right to spam your packagers with crap
> in the reports just because you misconfigured repoclosure?

I had marked your previous message for reply, but just had not gotten
to it. ;(

I poked the infrastructure folks to try and make needed changes in the
script config and re-run it.

It should send out a report here shortly... if it still has any issues
you see, could you please help us configure it correctly? I would be
happy to get you the current config/cron to provide patches against.

Sorry for this being broken so long. ;(

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-08-2008, 06:03 PM
Michael Schwendt
 
Default Broken dependencies in EPEL - 2008-12-07

On Mon, 8 Dec 2008 11:23:43 -0700, Kevin wrote:

> I poked the infrastructure folks to try and make needed changes in the
> script config and re-run it.
>
> It should send out a report here shortly... if it still has any issues
> you see, could you please help us configure it correctly? I would be
> happy to get you the current config/cron to provide patches against.

It had started with a working setup (EL4 and EL5 in a single report):
https://www.redhat.com/archives/epel-devel-list/2008-April/msg00016.html

Then, sometime later, the RHEL repos have been renamed and moved around
again and again (with games like switching repo ids from upper-case to
lower-case and vice versa), and finally the shell script has been damaged
as an added bonus.

I've suggested fixes for the script before based on commit diffs I've seen
flying by on sysadmin-members list. It just needs somebody with commit
access to fix the stuff or revert to the old working version. And that
seems to be the problem, as the RHEL repos are hidden somewhere where it
needs special privileges to access them. At present, the RHEL4 URLs used
in the script are invalid. For months the report for EPEL4 has been empty
because of that. The process is overly complicated. Mike seems to feel
pissed as he doesn't like to spend time on it. And stahnma presumably
doesn't have the proper permission to fully test and commit his changes.
Right?

Rather than spending hours on irc learning about any infrastructure secrets
and getting confirmation that some stuff is being locked down,
how about posting a verified (!) list of RHEL/EPEL repository URLs?

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-08-2008, 09:21 PM
Mike McGrath
 
Default Broken dependencies in EPEL - 2008-12-07

On Mon, 8 Dec 2008, Michael Schwendt wrote:

> On Sun, 07 Dec 2008 12:25:02 -0000, Fedora wrote:
>
> > vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
> > vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-i386-server-productivity-4. Please verify its path and try again
> > vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
> > vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-x86_64-server-productivity-4. Please verify its path and try again
> > vpnc-0.4.0-2.el5.ppc requires Reading in repository metadata - please wait....
> > vpnc-0.4.0-2.el5.ppc requires Cannot retrieve repository metadata (repomd.xml) for repository: rhel-ppc-server-productivity-4. Please verify its path and try again
> >
>
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Reading in repository metadata - please wait....
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Checking Dependencies
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Repos looked at: 6
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-x86_64-server-productivity-5
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires rhel-5-x86_64-vt
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires buildsys-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires fedora-epel-testing-5-x86_64
> > tcl-tktreectrl-2.2.8-1.el5.1.i386 requires Num Packages in Repos: 6521
>
>
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Checking Dependencies
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Repos looked at: 6
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-5-ppc
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-ppc-server-productivity-5
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires fedora-epel-5-ppc
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires rhel-5-ppc-vt
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires fedora-epel-testing-5-ppc
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires buildsys-5-ppc
> > tcl-tktreectrl-2.2.8-1.el5.1.x86_64 requires Num Packages in Repos: 4801
>
> Currently these people are members of the EPEL Steering Committee:
>
> * Mike McGrath ( mmcgrath )
> * Michael Stahnke ( stahnma )
> * Kevin Fenzi ( nirik )
> * Xavier Lamien ( SmootherFrOgZ )
> * Andy Gospodarek ( Gospo )
> * Jeff Sheltren ( Jeff_S )
> * Karsten Wade ( quaid )
> * Stephen J Smoogen ( smooge ) (Chair)
>
> Who of these people has the necessary privileges to shut off this thing,
> which is broken for many months? My reply from last week is unanswered.
> Do you think it's right to spam your packagers with crap in the reports
> just because you misconfigured repoclosure?
>


The epel steering committee is just that, its not an operations group.
Second. You said "add -q" to what?

-q Mike

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-08-2008, 09:42 PM
Michael Schwendt
 
Default Broken dependencies in EPEL - 2008-12-07

On Mon, 8 Dec 2008 16:21:29 -0600 (CST), Mike wrote:

> The epel steering committee is just that, its not an operations group.

Where does the steering take place, if you ignore such issues for months?
Without opening up enough to make it possible that others can fix it.
It is as if you endorse such issues.

> Second. You said "add -q" to what?

To the rc-modified (repoclosure) options. To reduce the noise output.

That will be half of the fix. The other half is fixing the invalid URLs.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-09-2008, 04:25 PM
Mike McGrath
 
Default Broken dependencies in EPEL - 2008-12-07

On Mon, 8 Dec 2008, Michael Schwendt wrote:

> On Mon, 8 Dec 2008 11:23:43 -0700, Kevin wrote:
>
> > I poked the infrastructure folks to try and make needed changes in the
> > script config and re-run it.
> >
> > It should send out a report here shortly... if it still has any issues
> > you see, could you please help us configure it correctly? I would be
> > happy to get you the current config/cron to provide patches against.
>
> It had started with a working setup (EL4 and EL5 in a single report):
> https://www.redhat.com/archives/epel-devel-list/2008-April/msg00016.html
>
> Then, sometime later, the RHEL repos have been renamed and moved around
> again and again (with games like switching repo ids from upper-case to
> lower-case and vice versa), and finally the shell script has been damaged
> as an added bonus.
>

Actually that only seemed to have worked. IIRC, we were missing some
repos so there are false positives there.

> I've suggested fixes for the script before based on commit diffs I've seen
> flying by on sysadmin-members list. It just needs somebody with commit
> access to fix the stuff or revert to the old working version. And that
> seems to be the problem, as the RHEL repos are hidden somewhere where it
> needs special privileges to access them. At present, the RHEL4 URLs used
> in the script are invalid. For months the report for EPEL4 has been empty
> because of that. The process is overly complicated. Mike seems to feel
> pissed as he doesn't like to spend time on it. And stahnma presumably
> doesn't have the proper permission to fully test and commit his changes.
> Right?
>

Yep, just needs someone with commit access. Strange that you've never
offered to do this. As we say in the states "Talk is cheap". Bringing
loose complaints to this list is not even close to the right thing to do
and while I'd normally let it slide, I'm going to spell it out because you
should know better, you're an experienced valued contributor.

We have a ticketing system. If you want something done go there.
Second, I'm the only full time person paid to work on Infrastructure 100%
of my time. After a year of this script not working and multiple
rewrites. I've taken a calculated decision not to work on it. It sort of
works, it emails people, etc. I've got 6 months of back log to work on of
stuff that volunteers just won't do. Just like this script for some
reason, there's some stuff that people don't step up and say "I'll take
responsibility for this and see it through to conclusion"

> Rather than spending hours on irc learning about any infrastructure secrets
> and getting confirmation that some stuff is being locked down,
> how about posting a verified (!) list of RHEL/EPEL repository URLs?

And thus the problem, you've become a complainer. Think real hard about
what you're trying to accomplish. Then ask yourself how the above
attitude will actually accomplish that. You've asked for the list (not
that it will be helpful to you) so I've included it.

-Mike[main]
cachedir=/tmp/mdcache
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=fedora-release
reposdir=/dev/null
exactarch=1
obsoletes=1
retries=20

### EL5 ###

[rhel-5-i386]
name=RHEL5
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-i386-server-5/
enabled=0

[rhel-5-i386-vt]
name=RHEL5
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-i386-server-vt-5/
enabled=0

[rhel-5-x86_64]
name=RHEL 5 - x86_64
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-x86_64-server-5/
enabled=0

[rhel-5-x86_64-vt]
name=RHEL5
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-x86_64-server-vt-5/
enabled=0

[rhel-5-ppc]
name=RHEL 5 ppc
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-ppc-server-5/

[rhel-5-ppc-vt]
name=RHEL5
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-ppc-server-vt-5/
enabled=0

[fedora-epel-5-i386]
name=Fedora EPEL 5 - i386
baseurl=file:///pub/epel/5/i386/
enabled=0

[fedora-epel-testing-5-i386]
name=Fedora EPEL Test Updates 5 - i386
baseurl=file:///pub/epel/testing/5/i386/
enabled=0

[fedora-epel-5-x86_64]
name=Fedora EPEL 5 - x86_64
baseurl=file:///pub/epel/5/x86_64/
enabled=0

[fedora-epel-testing-5-x86_64]
name=Fedora EPEL Test Updates 5 - x86_64
baseurl=file:///pub/epel/testing/5/x86_64/
enabled=0

[fedora-epel-5-ppc]
name=Fedora EPEL 5 - ppc
baseurl=file:///pub/epel/5/ppc/
enabled=0

[fedora-epel-testing-5-ppc]
name=Fedora EPEL Test Updates 5 - ppc
baseurl=file:///pub/epel/testing/5/ppc/
enabled=0


### EL4 ###

[rhel-4-i386]
name=RHEL 4 - i386
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-i386-as-4/
enabled=0

[rhel-4-x86_64]
name=RHEL 4 - x86_64
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-x86_64-as-4/
enabled=0

#Redhat doesnt ship a 32 bit ppc kernel. we use the CentOS one
[kernel]
name=kernel
baseurl=http://infrastructure.fedoraproject.org/buildsys/4/ppc/

[rhel-4-ppc]
name=RHEL 4 - ppc
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-ppc-as-4/
enabled=0

[fedora-epel-4-i386]
name=Fedora EPEL 4 - i386
baseurl=file:///pub/epel/4/i386/
enabled=0

[fedora-epel-testing-4-i386]
name=Fedora EPEL Test Updates 4 - i386
baseurl=file:///pub/epel/testing/4/i386/
enabled=0
[fedora-epel-4-x86_64]
name=Fedora EPEL 4 - x86_64
baseurl=file:///pub/epel/4/x86_64/
enabled=0

[fedora-epel-testing-4-x86_64]
name=Fedora EPEL Test Updates 4 - x86_64
baseurl=file:///pub/epel/testing/4/x86_64/
enabled=0


[fedora-epel-4-ppc]
name=Fedora EPEL 4 - ppc
baseurl=file:///pub/epel/4/ppc/
enabled=0

[fedora-epel-testing-4-ppc]
name=Fedora EPEL Test Updates 4 - ppc
baseurl=file:///pub/epel/testing/4/ppc/
enabled=0


# Custom created stuff for compatability
[rhel-ppc-server-productivity-5]
name=RHEL 5 - ppc
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-ppc-server-productivity-5/
enabled=0

[rhel-x86_64-server-productivity-5]
name=RHEL 5 - x86_64
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-x86_64-server-productivity-5/
enabled=0

[rhel-i386-server-productivity-5]
name=RHEL 5 - i386
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-i386-server-productivity-5/
enabled=0

[rhel-ppc-server-productivity-4]
name=RHEL 4 - ppc
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-ppc-server-productivity-4/
enabled=0

[rhel-x86_64-server-productivity-4]
name=RHEL 4 - x86_64
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-x86_64-server-productivity-4/
enabled=0

[rhel-i386-server-productivity-4]
name=RHEL 4 - i386
baseurl=http://infrastructure.fedoraproject.org/rhel/rhel-i386-server-productivity-4/
enabled=0

[buildsys-5-x86_64]
name=buildsys 5 - x86_64
baseurl=http://infrastructure.fedoraproject.org/buildsys/5/x86_64/
enabled=0

[buildsys-5-i386]
name=buildsys 5 - i386
baseurl=http://infrastructure.fedoraproject.org/buildsys/5/i386/
enabled=0

[buildsys-5-ppc]
name=buildsys 5 - ppc
baseurl=http://infrastructure.fedoraproject.org/buildsys/5/ppc/
enabled=0

[buildsys-4-x86_64]
name=buildsys 4 - x86_64
baseurl=http://infrastructure.fedoraproject.org/buildsys/4/x86_64/
enabled=0

[buildsys-4-i386]
name=buildsys 4 - i386
baseurl=http://infrastructure.fedoraproject.org/buildsys/4/i386/
enabled=0

[buildsys-4-ppc]
name=buildsys 4 - ppc
baseurl=http://infrastructure.fedoraproject.org/buildsys/4/ppc/
enabled=0

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-09-2008, 07:52 PM
Michael Schwendt
 
Default Broken dependencies in EPEL - 2008-12-07

On Tue, 9 Dec 2008 11:25:11 -0600 (CST), Mike wrote:

> > It had started with a working setup (EL4 and EL5 in a single report):
> > https://www.redhat.com/archives/epel-devel-list/2008-April/msg00016.html
> >
> > Then, sometime later, the RHEL repos have been renamed and moved around
> > again and again (with games like switching repo ids from upper-case to
> > lower-case and vice versa), and finally the shell script has been damaged
> > as an added bonus.
> >
>
> Actually that only seemed to have worked. IIRC, we were missing some
> repos so there are false positives there.

Minor problem. Step 1) Make the RHEL repos available. Step 2) Give out
valid (albeit internal) URLs to a person who creates a repoclosure
config script. I've provided the original scripts (list archives -> Feb)
plus even several updates.

Step 1 has been troublesome according to various messages related
to making the same repos available to the buildsys.

Step 2 has never happened. Only with your most recent reply. That is
progress (provided that the repo urls are correct). Only the knowledge of
the full list of repoids makes it possible that someone other than you can
supply a script which contains defaults.

> > I've suggested fixes for the script before based on commit diffs I've seen
> > flying by on sysadmin-members list. It just needs somebody with commit
> > access to fix the stuff or revert to the old working version. And that
> > seems to be the problem, as the RHEL repos are hidden somewhere where it
> > needs special privileges to access them. At present, the RHEL4 URLs used
> > in the script are invalid. For months the report for EPEL4 has been empty
> > because of that. The process is overly complicated. Mike seems to feel
> > pissed as he doesn't like to spend time on it. And stahnma presumably
> > doesn't have the proper permission to fully test and commit his changes.
> > Right?
> >
>
> Yep, just needs someone with commit access. Strange that you've never
> offered to do this.

Funny that I've done it for Fedora Extras, spending additional time on
fixing repoclosure to do the things our packagers wanted it to do.

Once some people at the controls started to lock down things, it became
more difficult to impossible. Nowadays we have arrived at a point, where
you want potential contributors to spend hours on IRC waiting for the few
power-hungry "leaders" to move forward and do things where the
unprivileged folk cannot help.

My access has been removed gradually. Earlier this year with the "cleanup"
of sysadmin-build, then later after the break-in with rebuilding of
machines and no documentation of what access is left.

> As we say in the states "Talk is cheap".

Then let me return "Talk is silver, silence is golden". You only flame
while I have had reason to complain. Mind you, I've tried to assist you
with fixes for the commit diffs that are posted to sysadmin members. And
I've also pointed out mistakes and the necessary fixes for the broken
rewrites mstahnma has worked on. That has been fruitless. Weeks have gone
by without progress or requests for help.

It would have taken you only a few minutes to brief me with regard to what
access I can get to roll out a fix myself.

> Bringing
> loose complaints to this list is not even close to the right thing to do
> and while I'd normally let it slide, I'm going to spell it out because you
> should know better, you're an experienced valued contributor.

Valued? I don't have that impression.

> We have a ticketing system. If you want something done go there.

Ridiculous. As if all tickets would move forward magically.

Like https://www.redhat.com/archives/fedora-infrastructure-list/2008-October/msg00054.html

Yet nobody else on the list has replied or told me what I could do to
help. I can't even access the epel/extras build machine anymore.

> After a year of this script not working and multiple
> rewrites.

The original shell script was simple. It suffered only from incomplete
repo contents (RHEL server vs. client, and virt.bits) and typos.
The questionable rewrites have not been discussed on any relevant list,
perhaps only on IRC. They've come as a surprise.

> I've taken a calculated decision not to work on it. It sort of
> works, it emails people, etc.

If you don't care about it, disable it. It mails out crap.
If EPEL has no interest in a broken deps report, discuss that in a
meeting and get rid of it. If there's interest in it, make it possible
that an arbitrary volunteer can take care of it.

> > Rather than spending hours on irc learning about any infrastructure secrets
> > and getting confirmation that some stuff is being locked down,
> > how about posting a verified (!) list of RHEL/EPEL repository URLs?
>
> And thus the problem, you've become a complainer.

Sure, to shut down one source of false positives. Enough packagers
don't believe broken deps reports. It doesn't help if there is additional
FUD and an installation that mails out crap.

Did you want to continue with these broken deps wreckage till Xmas?

> Think real hard about
> what you're trying to accomplish. Then ask yourself how the above
> attitude will actually accomplish that. You've asked for the list (not
> that it will be helpful to you) so I've included it.

It is beyond my comprehension what you try to accomplish with such an
arrogant ending of your mail. You flame me in the "put up or shut up" line
of thinking and at the same time admit that the repo urls are useless to me.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-09-2008, 08:31 PM
"Michael Stahnke"
 
Default Broken dependencies in EPEL - 2008-12-07

While I certainly can respect either point of view here, I will reply
with my take, and not throw any flames anywhere (I hope).

A while back , I tried to add some features to the shell script that
ran the repo closure of EPEL. I wanted to be able to test running it
without emailing people, and be able to break out architectures and
stuff. I don't remember why I couldn't quite do that with the old
one. Either way, I submitted a basically new script to control that.

After that, the yum repo URLs changed, we added productivity and of
course massive rebuilds of the infrastructure.

I tried to fix things when I had time, albeit not much time. I took
Michael's advice on some things when I had the chance and consolidated
6 emails back to one.

The biggest problem for me was the ability to test. The publictest
boxes couldn't send mail, and couldn't see all the repos for yum (I
think). Either way , that stuff appears to be relatively fixed now.

It's probably not worth being too upset about it. Please realize
we're donating time to this cause for the most part. I'm sorry that
not all of my patches and fixes were working/good/perfect, but alas we
live on.

I really wish I did have access to commit to this and fully test it,
but that requires a commitment I can't give much of the time, and
don't deserve. I am grateful to those who have helped, and I am sure
they will continue to do an awesome job.



stahnma

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-09-2008, 08:33 PM
Mike McGrath
 
Default Broken dependencies in EPEL - 2008-12-07

On Tue, 9 Dec 2008, Michael Schwendt wrote:

> On Tue, 9 Dec 2008 11:25:11 -0600 (CST), Mike wrote:
>
> > > It had started with a working setup (EL4 and EL5 in a single report):
> > > https://www.redhat.com/archives/epel-devel-list/2008-April/msg00016.html
> > >
> > > Then, sometime later, the RHEL repos have been renamed and moved around
> > > again and again (with games like switching repo ids from upper-case to
> > > lower-case and vice versa), and finally the shell script has been damaged
> > > as an added bonus.
> > >
> >
> > Actually that only seemed to have worked. IIRC, we were missing some
> > repos so there are false positives there.
>
> Minor problem. Step 1) Make the RHEL repos available. Step 2) Give out
> valid (albeit internal) URLs to a person who creates a repoclosure
> config script. I've provided the original scripts (list archives -> Feb)
> plus even several updates.
>
> Step 1 has been troublesome according to various messages related
> to making the same repos available to the buildsys.
>
> Step 2 has never happened. Only with your most recent reply. That is
> progress (provided that the repo urls are correct). Only the knowledge of
> the full list of repoids makes it possible that someone other than you can
> supply a script which contains defaults.
>

Sorry if I gave you the impression that a reply from you was required, it
was not.

> > I've taken a calculated decision not to work on it. It sort of
> > works, it emails people, etc.
>
> If you don't care about it, disable it. It mails out crap.
> If EPEL has no interest in a broken deps report, discuss that in a
> meeting and get rid of it. If there's interest in it, make it possible
> that an arbitrary volunteer can take care of it.
>

Whether the script runs or not is not my call. Thats a steering decision.
They've requested it to run, I've done my best to see to it that it
happens but there's only so much time in the day.

> > > Rather than spending hours on irc learning about any infrastructure secrets
> > > and getting confirmation that some stuff is being locked down,
> > > how about posting a verified (!) list of RHEL/EPEL repository URLs?
> >
> > And thus the problem, you've become a complainer.
>
> Sure, to shut down one source of false positives. Enough packagers
> don't believe broken deps reports. It doesn't help if there is additional
> FUD and an installation that mails out crap.
>

That's a complaint, which is what complainers do. I don't see any
suggestions there that would benefit the epel community or fix the script.

> Did you want to continue with these broken deps wreckage till Xmas?
>

Still not a suggestion on how to actually fix it nor an offer to help.

> > Think real hard about
> > what you're trying to accomplish. Then ask yourself how the above
> > attitude will actually accomplish that. You've asked for the list (not
> > that it will be helpful to you) so I've included it.
>
> It is beyond my comprehension what you try to accomplish with such an
> arrogant ending of your mail. You flame me in the "put up or shut up" line
> of thinking and at the same time admit that the repo urls are useless to me.
>

I'll spell it out more so you can comprehend. I was asking you to help.
I was asking you to stop by, say "Hey guys, I understand the problems with
the epel dep check script are still failing and I'd like to see how I can
help". Does that make more sense? But instead of following proper
channels, submitting tickets so they didn't get forgotten about you
complained.

-Mike

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 07:42 AM.

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