Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-16 Thread AL13N 
Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu:
 On Tuesday 15. January 2013 11.43, Colin Guthrie wrote:
  Sounds like one of your media couldn't be updated or something. Not
  directly related to urpmi-proxy per-se but it could certainly confuse
  the issue :)
 
 Just for good measure, I ran «urpmi.upfdate -a» just now, and the count
 didnt change. No media where unable to update, and I only have one repo
 configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors)

just mentioning, that the disadvantage to urpmi-proxy, is that it hides 
connection errors to repositories, since it will use cache if it fails. you 
can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets you 
cache after it failed)

lately, i've been testing with 2 repositories and changing the timeout value 
to very low values (5s)

as first repos, i choose one that is fast, and as second repos, i use what is 
always up2date. considering MD5SUM would be asked for both repositories (it's 
a specially configured file for that), it would get you always up2date results, 
since the first would fail to have the file and the second one would be asked 
for it.

for me, this gave alot better results especially for cauldron during the mass 
rebuild...

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-16 Thread Colin Guthrie 
'Twas brillig, and AL13N at 16/01/13 20:22 did gyre and gimble:
 Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu:
 On Tuesday 15. January 2013 11.43, Colin Guthrie wrote:
 Sounds like one of your media couldn't be updated or something. Not
 directly related to urpmi-proxy per-se but it could certainly confuse
 the issue :)

 Just for good measure, I ran «urpmi.upfdate -a» just now, and the count
 didnt change. No media where unable to update, and I only have one repo
 configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors)
 
 just mentioning, that the disadvantage to urpmi-proxy, is that it hides 
 connection errors to repositories, since it will use cache if it fails. you 
 can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets 
 you 
 cache after it failed)
 
 lately, i've been testing with 2 repositories and changing the timeout value 
 to very low values (5s)
 
 as first repos, i choose one that is fast, and as second repos, i use what is 
 always up2date. considering MD5SUM would be asked for both repositories (it's 
 a specially configured file for that), it would get you always up2date 
 results, 
 since the first would fail to have the file and the second one would be asked 
 for it.
 
 for me, this gave alot better results especially for cauldron during the mass 
 rebuild...

Interesting idea. Never thought about using two mirrors in the config.

I fought with urpmi-proxy today for a while. No matter what I tried,
when downloading a synthesis via the proxy it always ended up too small
and with md5sum failures. Requesting the same file direct from the
mirrors worked every time. I noticed that the file never ended up in the
cache tree, just in the tmp dir. Time wasn't on my side, so I didn't
debug further... one to fight another day.

(this is with urpmi-proxy-0.3.2-1.mga2 on mga2 FWIW)


Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-16 Thread Johnny A. Solbu 
On Wednesday 16. January 2013 21.22, AL13N wrote:
 you can look at the logfile if it mentions HIT_AFTER_FAIL 
 (which means it gets you cache after it failed)

# grep -i HIT_AFTER_FAIL /var/log/urpmi-proxy.log |wc -l
0

So that's not the issue. :-)=

-- 
Johnny A. Solbu
PGP key ID: 0xFA687324


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-16 Thread AL13N 
Op woensdag 16 januari 2013 21:22:22 schreef Colin Guthrie:
 'Twas brillig, and AL13N at 16/01/13 20:22 did gyre and gimble:
  Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu:
  On Tuesday 15. January 2013 11.43, Colin Guthrie wrote:
  Sounds like one of your media couldn't be updated or something. Not
  directly related to urpmi-proxy per-se but it could certainly confuse
  the issue :)
  
  Just for good measure, I ran «urpmi.upfdate -a» just now, and the count
  didnt change. No media where unable to update, and I only have one repo
  configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors)
  
  just mentioning, that the disadvantage to urpmi-proxy, is that it hides
  connection errors to repositories, since it will use cache if it fails.
  you
  can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets
  you cache after it failed)
  
  lately, i've been testing with 2 repositories and changing the timeout
  value to very low values (5s)
  
  as first repos, i choose one that is fast, and as second repos, i use what
  is always up2date. considering MD5SUM would be asked for both
  repositories (it's a specially configured file for that), it would get
  you always up2date results, since the first would fail to have the file
  and the second one would be asked for it.
  
  for me, this gave alot better results especially for cauldron during the
  mass rebuild...
 
 Interesting idea. Never thought about using two mirrors in the config.
 
 I fought with urpmi-proxy today for a while. No matter what I tried,
 when downloading a synthesis via the proxy it always ended up too small
 and with md5sum failures. Requesting the same file direct from the
 mirrors worked every time. I noticed that the file never ended up in the
 cache tree, just in the tmp dir. Time wasn't on my side, so I didn't
 debug further... one to fight another day.
 
 (this is with urpmi-proxy-0.3.2-1.mga2 on mga2 FWIW)
 
 
 Col

so, either a partial file, or out of disk space? better make sure the cache 
tree is the same partition as the tmp dir it uses.

in any case, using multiple mirrors isn't supported...

(yet)

i'm just trying them out this way.

i had alot of troubles with cauldron due to mismatches with MD5SUM and the 
synthesis files, because the MD5SUM doesn't match the synthesis files

but, sometimes, i do have some oddness in files (i think maybe i need better 
error-checking) like if you get a partial result, it doesn't get removed from 
cache. so if it does fail, i delete the file from the cache tree for now.

don't forget to do that in all your cascading urpmi-proxy's...

i actually have tested 3 cascading urpmi-proxy's.

in normal usage, i have an urpmi-proxy at my local lan. one at my desktop 
itself, and then once i tested urpmi-proxy in a VM on my desktop.

the one on my desktop has an extra repository (and changes which ones are 
default), and the one on the server has now 2 sources (http mirrors), with 
very small timeouts (i may have used 3 or 5 seconds)

since i have an urpmi-proxy at work, my work-laptop had always 2 sources which 
i uncommented constantly, but perhaps i should actually set them both, with 
very small timeouts... maybe with a 3rd slow one?

/me continues to ponder

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-16 Thread AL13N 
Op woensdag 16 januari 2013 22:33:10 schreef Johnny A. Solbu:
 On Wednesday 16. January 2013 21.22, AL13N wrote:
  you can look at the logfile if it mentions HIT_AFTER_FAIL
  (which means it gets you cache after it failed)
 
 # grep -i HIT_AFTER_FAIL /var/log/urpmi-proxy.log |wc -l
 0
 
 So that's not the issue. :-)=

then it looks like you're up2date after all...

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-16 Thread zezinho 

Em 16-01-2013 23:06, AL13N escreveu:

Op woensdag 16 januari 2013 21:22:22 schreef Colin Guthrie:

I fought with urpmi-proxy today for a while. No matter what I tried,
when downloading a synthesis via the proxy it always ended up too small
and with md5sum failures. Requesting the same file direct from the
mirrors worked every time. I noticed that the file never ended up in the
cache tree, just in the tmp dir. Time wasn't on my side, so I didn't
debug further... one to fight another day.

(this is with urpmi-proxy-0.3.2-1.mga2 on mga2 FWIW)


Col


so, either a partial file, or out of disk space? better make sure the cache
tree is the same partition as the tmp dir it uses.



I experienced something like this when I tried to have urpmi-proxy cache 
and temp dirs in different partitions. Putting them in the same one 
fixed it.

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-15 Thread Brian Smith 
On Tuesday 15 Jan 2013 00:28:40 JA Magallón wrote:
 Hi...
 
 As the mass rebuild seems almost done, I have supposed that 
everything in
 my box not tagged ad mga3 are leftovers from previous installs, as I 
had
 not reinstalled my box since mga1. I checked this:
 
Just for comparison here is a list from mine

I had a long session of removing the --not availables last week so it is 
faily clean despite having been updated since mga1.

[root@localhost brian]# rpm -qa --nosignature --qf %{n}-%{v}-%{r}\n 
| grep mga1 | sort
dvgrab-3.5-4.mga1
giftrans-1.12.2-23.mga1
jline-0.9.94-4.mga1
kmozillahelper-0.6.3-1.mga1
lib64atlas3-x86_64-3.8.3-7.mga1
lib64opencore-amr0-0.1.2-3.mga1
mpgtx-1.3.1-7.mga1
notification-daemon-engine-nodoka-0.1.0-3.mga1
transfugdrake-1.9.4-1.mga1
[root@localhost brian]# rpm -qa --nosignature --qf %{n}-%{v}-%{r}\n 
| grep mga2 | sort
aoss-1.0.25-1.mga2
dcraw-9.12-1.mga2
hsqldb-1.8.1.3-5.mga2
jasper-1.900.1-13.mga2
lcms-1.19-6.mga2
lib64a52dec0-0.7.4-17.mga2
lib64alsa-oss0-1.0.25-1.mga2
lib64gsl0-1.15-1.mga2
lib64jasper1-1.900.1-13.mga2
lib64lcms1-1.19-6.mga2
lib64nut0-0.0.675-2.mga2
lib64nvtvsimple0-0.4.7-20.mga2
lib64vcd0-0.7.24-2.mga2
lib64wpg0.2_2-0.2.1-2.mga2
lib64xavs1-0.1.55-2.mga2
pdf2svg-0.2.1-1.mga2
postgresql-jdbc-9.0.801-1.mga2
vcdimager-0.7.24-2.mga2
x11-driver-input-1.0.0-17.mga2
xli-20061110-7.mga2
[root@localhost brian]# urpme --auto-orphans 
No orphans to remove
[root@localhost brian]# urpmq --not-available
projectlibre-1.5.1-1.noarch
[root@localhost brian]# 

Projectlibre excepted (which I have installed locally to try it out), theres 
not too many.
So it looks like the rebuild bot did a pretty good job. :-)

[Mageia-dev] Missign rebuilds tagged mga1

2013-01-14 Thread JA Magallón 

Hi...

As the mass rebuild seems almost done, I have supposed that everything in
my box not tagged ad mga3 are leftovers from previous installs, as I had
not reinstalled my box since mga1. I checked this:

rpm -qa --nosignature --qf %{n}-%{v}-%{r}\n | grep mga1 | sort

(I have another list for mga2 ;) )

But some packages seems to be needed, and skipped in the mass rebuild.
This is the list I get in my main box:

werewolf:~/bin# mga1
jline-0.9.94-4.mga1
lib64atlas3-x86_64-3.8.3-7.mga1
lib64iec16022_0-0.2.4-4.mga1
lib64jbig1-2.0-5.mga1
lib64jbig-devel-2.0-5.mga1
lib64mpeg2dec0-0.5.1-5.mga1
lib64opencore-amr0-0.1.2-3.mga1
net-tools-1.60-34.mga1
perl-Spreadsheet-ParseExcel-0.590.0-1.mga1
python-dateutil-1.5-2.mga1
transfugdrake-1.9.4-1.mga1

Some look pretty important:

jline - rhino - jdk7
net-tools - basesystem
transfugdrake - userdrake

... and so on.

Mirrors also seem to contain packages dated 2011. I will wait for mirrors to 
settle
and look again. If they are dead packages, should not they be killed from 
mirrors ?

TIA

--
J.A. Magallon jamagallon()ono!com\   Winter is coming...

Re: [Mageia-dev] Missign rebuilds tagged mga1

2013-01-14 Thread Pascal Terjan 
On Mon, Jan 14, 2013 at 11:28 PM, JA Magallón jamagal...@ono.com wrote:
 Hi...

 As the mass rebuild seems almost done, I have supposed that everything in
 my box not tagged ad mga3 are leftovers from previous installs, as I had
 not reinstalled my box since mga1. I checked this:

 rpm -qa --nosignature --qf %{n}-%{v}-%{r}\n | grep mga1 | sort

 (I have another list for mga2 ;) )

 But some packages seems to be needed, and skipped in the mass rebuild.

450 failed to build (list on
http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-11)
63 got rejected (no handy list available yet, visible on
http://pkgsubmit.mageia.org/?user=umeabot but only the last 48h are
displayed)

 This is the list I get in my main box:

 werewolf:~/bin# mga1
 jline-0.9.94-4.mga1
 lib64atlas3-x86_64-3.8.3-7.mga1
 lib64iec16022_0-0.2.4-4.mga1
 lib64jbig1-2.0-5.mga1
 lib64jbig-devel-2.0-5.mga1
 lib64mpeg2dec0-0.5.1-5.mga1
 lib64opencore-amr0-0.1.2-3.mga1
 net-tools-1.60-34.mga1
 perl-Spreadsheet-ParseExcel-0.590.0-1.mga1
 python-dateutil-1.5-2.mga1
 transfugdrake-1.9.4-1.mga1

 Some look pretty important:

 jline - rhino - jdk7
 net-tools - basesystem
 transfugdrake - userdrake

 ... and so on.

 Mirrors also seem to contain packages dated 2011. I will wait for mirrors to
 settle
 and look again. If they are dead packages, should not they be killed from
 mirrors ?

Many of them should be fixed, some should be killed