[opensuse-factory] drpmsync.opensuse.org:8888/Factory ?
Hello is this Server not more running ? Or have it change ? -- mit freundlichen Grüßen / best Regards / avec mes meilleures salutation, Günther J. Niederwimmer --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Thu, Jun 22, 2006 at 12:18:40PM +0200, Günther J. Niederwimmer wrote:
Hello
is this Server not more running ?
This service is broken for about two weeks now. There seems to be quite low interest in this service anyway from the SUSE side because even my provided solution on https://bugzilla.novell.com/show_bug.cgi?id=183793 is pending with no action now for 10 days. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Thu, Jun 22, 2006 at 01:43:26PM +0200, Robert Schiele wrote:
Hey people, what is going on here? Is this your way to tell me (and other people): Don't use SUSE Linux if you want a system with current packages! Or do you want to tell me: If you want to contribute something then please go to a different vendor! We don't want solutions not invented in-house! Slowly I am feeling more and more pissed off by only getting information after polling for it with much effort each time and arguing down solutions that are provided or just delaying them for an infinite time when no arguments seem to be left over. If you don't like a solution someone provides then please argue resonable(!) what is wrong with it or provide the minimal required assistance to implement it if implementation cannot be completed by him because of the proprietary infrastructure Novell is using. If we can't agree on a minimal reasonable basis to work together it is definitely best if I follow the two suggestions made above because putting work into something that behaves continuously like a black hole seems somehow like completely wasting time. And please don't answer this mail with "Stay tuned!" or "We are working on it!" or similar rubbish. Arguing like "We have other problems anyway." does also make no sense because there is no reason not to solve problems where a solution is available even if you have othe problems left. And don't tell me that it is so difficult to convince the management to do something because it does also happen for problems where management for sure does not care about at all. In the special case mentioned above you have made the drpmsync service unusable for weeks now without initially telling anyone about the reasons. While I was trying to help finding a solution I had to poll continuously for more information about the problem. And when I finally provided a solution that is appropriate in my opinion then nothing happened any more. Behaving like this is exactly the way you manage to piss off people trying to contribute something but actually it is much easier to do so if you just tell them to go away. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
Good morning Robert, On Tuesday 27 June 2006 14:47, Robert Schiele wrote:
Robert, as we discussed it before via IM, you know that we know about that problem and mls has atm also other high priority work. I do understand that it is not satisfying for you, when we tell you that this problem has not on the highest priority at us atm. But it is the most honest answer I was able to give you. It is also not that easy only to apply a patch, Michael wants to debug what actually wents wrong and needs to review the code (his and yours) before he is able to solve it. The reason why it has not the highest priority is that we are at the end phase of SLES 10 and that the drpmsync service has only a small number of users. So I hope this is reasonable. Michael does not read this list btw, so you will not get an answer from him here. Please contact him directly to get feedback, but he had no time to look into this issue yet. Btw, the client limit has been removed again to debug this. Stricter ulimits are set this time. And the configuration change (no_deltacombine), suggested by you is also still active. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Wed, Jun 28, 2006 at 11:24:17AM +0200, Adrian Schroeter wrote:
You are mixing up things now. What might actually be required to be done is reviewing the code I attached in the sense that it does not do any harm. This should be a very fast process because someone with basic perl knowledge can easily see that the code is a) almost completely copied from the known drpmsync code with just code removed that is not needed for this purpose and one simple loop added and b) does not open any file for writing anyway or call any other critical system function and thus can not do any harm even if a fatal bug was included. Debugging what went wrong in the drpmsync server implementation is a competely different thing. Or do you want to allow different ways of doing something only if your current way has ultimately proven to be the wrong way? My way of doing things would only add one extra file of about 3MB to the factory distribution without hurting the current drpmsync server or other infrastructure in any way thus there is no reason to mix these things up.
But this process will only consume much time if you try to solve all related problems at one point in time before doing anything else. If you only did look at the code provided by me in the aspect that it does not do any harm to your internal infrastructure and dumped its output to a file within the repository then this would not take much time and a solution was available that allowed other people (like me) could continue their work.
Michael does not read this list btw, so you will not get an answer from him here. Please contact him directly to get feedback, but he had no time to look
Ok, adding him to CC of this mail.
into this issue yet.
I hope he can see the difference between running my code snippet in the repository and fixing the problem in the server and not consider this as one issue that must be solved together or not at all.
Ok, then one can at least sync again now. But I'd still like to continue development of an alternative way of doing things because I believe that this is the better way of doing it even when the current problem in the drpmsync server is fixed. You might have a different view here but if you even don't give me a chance to implement the idea and prove my point of view then I don't see what I should do here. If you provided the file created from my script, we had a drpmsync client that does not need a drpmsync server at all thus nullifying all problems that exist because no mirror admin wants to provide a drpmsync server. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
participants (3)
-
Adrian Schroeter
-
Günther J. Niederwimmer
-
Robert Schiele