https://bugzilla.novell.com/show_bug.cgi?id=329691#c2 Robert Schiele changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from Robert Schiele 2007-10-01 03:40:10 MST --- But it is still out of date. For example SL-OSS-factory/drpmsync/filelist.gz says inst-source/ARCHIVES.gz has md5sum of 78cd1afb7945d922f74a6905187f4112 but it actually has 7f4337e8422d96e5662f49c945b24451. I wouldn't call that "perfect sync". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=329691#c4 Robert Schiele changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED Info Provider|rschiele@gmail.com | --- Comment #4 from Robert Schiele 2007-11-01 19:12:19 MST --- Now it is completely broken. rsync rsync.opensuse.org::opensuse-full-with-factory-drpmsync/opensuse/distribution/SL-OSS-factory/ does not even show a drpmsync subdirectory any more. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=329691#c6 --- Comment #6 from Robert Schiele 2007-11-05 07:46:06 MST --- The point is that drpmsync had a long story of being unavailable because the server was overloaded and the drpmsync client/protocol could not handle this situation gracefully I did implement and announce a drpmsync client which is completely based on rsync as a protocol and only needs the drpmsync index file as meta information (which mls added to be stored in the drpmsync directory). With that method I was able to even use mirrors that also mirrored the drpmsync directory. Now since all mirrors have stopped mirroring the drpmsync directory and no server does provide the drpmsync data via rsync any more this is no longer possible. Since it seems to be a big burden for you to keep a continuous service like that for the factory distribution I am also willing to conclude that efforts to keep testing on the latest development version of openSUSE is no longer worth the effort and use other distributions only instead but clear announcements of discontinuation of such services would make these kind of decissions more easy for people. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=329691#c8 Peter Poeml changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |rschiele@gmail.com --- Comment #8 from Peter Poeml 2007-11-05 11:19:00 MST --- There hasn't been a decision to drop anything from mirrors. It is entirely up to the mirrors to decide what they want to mirror. There has been a decision to split the drpmsync tree into its own rsync module. This was because we discovered that there was no convenient way for mirrors to *not* mirror the drpmsync tree together with Factory, and several mirrored it unwillingly. The problem with the drpmsync tree is that it encompasses an extreme amount of files, which takes the rsync server minutes for merely stat'ing it, which significantly contributed to load on the machine, and is a waste if the mirror doesn't want the tree. And it blew up the redirector database, prolonged mirror scanning, and I knew from log analysis that nearly no requests ever were received on all the stuff. This change was done maybe 2 or 3 months ago, and announced on the mirror list. If no mirror is mirroring that content, then I guess that no mirror is interested. However, there is something else to be taken into account. We are really talking about two machines here. There is stage.opensuse.org and rsync.opensuse.org. All the above applies to stage.opensuse.org, where our "official" mirrors sync from. While stage.opensuse.org has reserved bandwidth, rsync.opensuse.org is an additional *public* mirror which anyone can use, which used to run on the very same box, but throttled. When we moved rsync.opensuse.org to a separate machine one month ago, the drpmsync rsync modules were *configured* on the new machine (oversight by me), but not filled with data. I didn't *intend* to offer the drpmsync tree on that box, because it primarily serves as a mirror, and since the drpmsync tree is used by extremely few people, it doesn't contribute much to the load of the main (stage.o.o) box. As far as I know, the drpmsync tree is primarily accessed directly via the drpmsync server running on stage.o.o, and I was not aware of "special" drpmsync clients, servers, or something, running anywhere else. So if it takes one month for anyone to notice that something valuable is missing, then you (Robert) might need to face the fact that you are the only one using this service, and keep your negative vibes for yourself. If nobody else asks for it, then *you* need to ask for it. We'll happily help with providing what you need. We just need to know about it. So, if you want to mirror the tree, we'll be happy to give you access. If you know a mirror who is interested in mirroring, they just need to pick the appropriate rsync module. All info is here: http://en.opensuse.org/Mirror_Infrastructure Feel free to point it out to your favourite mirror. And I understand that you need rsync access for your special drpmsync client. For that purpose, it seems logical to host the drpmsync tree on rsync.opensuse.org, especially as it is a very capable machine. I'll start to put the drpmsync tree tree there right now. Robert, please let me know if this covers your needs. .. Recommendations about sync frequencies are appreciated. Because otherwise it'll happen quite randomly. (We could also consider pushing the drpmsync tree through from Autobuild directly to rsync.opensuse.org, to avoid additional delays and inconsistencies. But at least we have recently cleaned up on stage.opensuse.org enough to no longer have any load problem anymore. So I think that we can rsync.o.o can pull from stage.o.o, like every 4 or 6 hours maybe.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=329691#c10 Robert Schiele changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED Info Provider|rschiele@gmail.com | --- Comment #10 from Robert Schiele 2007-11-05 22:16:00 MST --- Actually, I _did_ report this bug more than a month ago. Thus if you complain that I did not make you aware of problems just check the date when this bug was opened. Obviously the problem initially reported was not as bad it got later but I didn't see a motivation to open yet another bug when even this one was just declared to be invalid in the first place though it obviously _was_ valid but just ignored then for one month. So maybe what we really see here is some big communication problem that we just don't understand each other in which case we are back at the question whether it makes sense to put effort into that issue or I should just stop using the openSUSE development versions for testing my applications on. Maybe the latter solution is just less annoying to both of us since my use pattern is just to exotic and it is not worth you consider it. But to get back to the technical level of the problem: Yes, providing the drpmsync data on any accessible server would solve the issue for me. Whether it is a long term solution depends on how reliable the access to this data is in the future. But this brings us back to the previous topic which most likely is not worth to discuss again and again. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.