I wonder If we a numerous enough do do so right now, but it could be an idea to go. I beleive that in the near future the Novell Programmers will be very busy working on the new distributions, as they do with 10.1 right now. one of the consequencies is that the debugging of the stable version is short. I know that security debugging is done (and I think well done), but, specially, Yats bugfixes are no more wellcome. However there are still many. many cosmetic (typos, translations), some of them worst (problems in adding inst-sources). In the same time, new SUSE Linux version are more and more hardware demanding. Using 10.0 on a 5 years computer is pretty straight forward, 10.1 is questionable, 10.2 or 3 probably not possible if all goes as it do now (5 years ago, 128Mb ram was current, 256Mb very high end). I understand why this is. But I try to keep all this nice hardware living and I'll hate to revert to debian :-((( I understand also that user using, say, SUSE 9.0 (or 10.0 two years in the future) can afford to update manually the problematics packages (kernel...) for security reason. I know some people use still 7.x versions. But nobody can fix yast alone :() why not us? Yast is a fine piece of code, but a big part is scripts, translations are texts files, openSUSE builder should ease the process. So could the community be more involved in this? As I am, I could take the french translation part and be assigned the translation fix (for example) from bugzilla. what do you think of the idea (the setup is to be discussed after if necessary) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 19, 2006 at 02:41:11PM +0200, jdd wrote:
what do you think of the idea (the setup is to be discussed after if necessary)
Say I find a spellingserror in SUSE 9.2. How do you propose that information is going to the users? It is not a security issue, so it won't be done by YOU. So what good would it be to do this? Even worse for versions that are no longer in the security period (or how to call those two years). Say I find something and the solution for a 6.4 issue. How should I reach the users? Not via YOU. Not via any SUSE or Novell channel. I understand your eagerness to keep old hardware running on SUSE. I am just afraid that it is not going to happen. SUSE is, I think, very clear in their policy. Security updates for 2 years. Sometimes major issues are also done, but by and large nothing else and especially not for unsuported versions. It would send a very confusing message to the users if you say on one hand, we only do security updates and only support for 2 years and on the other hand give them spellings corrections and updates for older version. What could be done is that you make your own website where people can point their YOU and get all the patched you made for any version you like. For existing bugs, there is Bugzilla that can be used to post solutions as well. So in general, I think it is a bad idea, sorry. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
On Wed, Apr 19, 2006 at 02:41:11PM +0200, jdd wrote:
what do you think of the idea (the setup is to be discussed after if necessary)
Say I find a spellingserror in SUSE 9.2. How do you propose that information is going to the users? It is not a security issue, so it won't be done by YOU.
YOU allows all king of updates, not only security, this is a user choice.
So what good would it be to do this?
Even worse for versions that are no longer in the security period (or how to call those two years). Say I find something and the solution for a 6.4 issue. How should I reach the users?
may be we won't go back so far :-)
Not via YOU. Not via any SUSE or Novell channel.
why not any SUSE??? and openSUSE??? why not an "update" openSUSE page?
in their policy. Security updates for 2 years.
I have problems now with 10.0, far inside the 2 years limit. and this don't seem to be fixed neither.
Sometimes major issues are also done, but by and large nothing else and especially not for unsuported versions.
It would send a very confusing message to the users if you say on one hand, we only do security updates and only support for 2 years and on the other hand give them spellings corrections and updates for older version.
no. We can update Yast (anyway, yast is the only SUSE visible products, all the rest have others maintainers).
For existing bugs, there is Bugzilla that can be used to post solutions as well.
? only patches available simply, that is pretty rare
So in general, I think it is a bad idea, sorry.
I think you are discussing methods, not ideas. Idea is: do you think community users can be part of the debugging that Novell employees can't do? if yes, then the methos will follow. emergency is for stable distribution, problem in previous ones should be very rare. may be SUSE is getting too fast, but the 10.0 if full of bugs, even annoying ones, 10.1 is quite bad on this respect as the RC1 don't works at all for some install options and this is not good. It really upset me to see typos in Yast I could correct in 10 seconds with the good interface staying there for age. may I write a wiki page saying "in this page there is a bug, but it wont be fixed"? I would like Novell programmers concentrate to bugs I can't fix (there are enough :-() jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
jdd wrote:
Idea is: do you think community users can be part of the debugging that Novell employees can't do? if yes, then the methos will follow.
I try to think of solutions. * One of the problems about _translation_ or simply _typos_ in yast is the difficulty to identify the screen involved. *could it be possible to have a screen number on a corner, or by the way a unique screen title? (with anywhere an index?) there are not so many errors, and they are not blockers, but this gives a bad feeling :-) *may be we should slowdown and have a worked stable, a working unstable and a dev one like debian. Debian is too slow, but SUSE is too fast :-) *I already tried to identify what yast module do what to look at the sources. It's really difficult. any doc? *why is Yast so bad documented? I use SUSE now for nearly 10 years an they are still options I don't know what they are for... *why is there already a sysconfig editor? is it so difficult to write standard modules to do the job? *The left column for help is a great idea. why is it so poorly used? *each yast page should have a help counterpart with comment for each name and option *but to acheive this yast should not be rewritten for each version. choose a layout and add page but don't change the old ones. even the options order change! *openup the layout team, there the community can help jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
as an example of problems. I downloaded a yast source file (fr translation) got a 10.1 was looking for a 10.0 :-( probably my fault :-( install the rpm with yast. Was unable to find the unarchived files? used rpm2cpio yas... | cpio -i to extratct them... and I found no way to download all yast sources at once :-( if that ones where easily available, one could make a search and give much more relevant bugreports :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Wed, Apr 19, 2006 at 08:48:42PM +0200, jdd wrote:
as an example of problems.
I downloaded a yast source file (fr translation)
got a 10.1 was looking for a 10.0 :-( probably my fault :-(
install the rpm with yast. Was unable to find the unarchived files?
used rpm2cpio yas... | cpio -i to extratct them...
and I found no way to download all yast sources at once :-(
if that ones where easily available, one could make a search and give much more relevant bugreports :-)
Sorry, I have no idea what your problem is here or how it is relevant to what I think you are discussing. I don't understand what you might be searching for and am getting very confused to what you want to actualy discuss. I think I am completely misunderstanding what the issue is here. First it was about spelling errors that could be solved by users, then is was about changes that should be done in Yast and now it is about making better bugreports. Very confusing to me, sorry. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
I think I am completely misunderstanding what the issue is here. First it was about spelling errors that could be solved by users, then is was about changes that should be done in Yast and now it is about making better bugreports. Very confusing to me, sorry.
It's not really that difficult, houghi. What jdd is proposing/suggesting is that not only Novell solve the problems in the SUSE distribution, but that they open it (somehow) for others to participate with bugfixes (however minor or irrelevant). Perhaps I spot a problem in an apparmor profile - I can correct it, then submit a fix/patch. After all, this is usually the way OSS project work. Right now, opensuse seems to work mostly by the community submitting reports, and Novell fixing the problems. /Per Jessen, Zürich
On Wed, Apr 19, 2006 at 09:41:30PM +0200, Per Jessen wrote:
Perhaps I spot a problem in an apparmor profile - I can correct it, then submit a fix/patch. After all, this is usually the way OSS project work. Right now, opensuse seems to work mostly by the community submitting reports, and Novell fixing the problems.
OK, and how do you see this happening? Remeber that you can sunmit a fix with bugzilla as well. Also remember that not only SUSE users are affected by changes you do. There are responsabilities. I realy like the idea. I just do not see it happening because of legal resposabilities Novell has towards their paying customers. Any change you make will have inflence in other things as well. As far as I have seen, the same is done by any OSS project. You file a bugreport (with or without patch) and then the maintainers review this report and either implement it or not. This is done at SUSE now as well with the help of Bugzilla. So I do not see any difference as with e.g. the kernel source. Practical example, you see an error in makeSUSEdvd and have a solution. What do you do? You look at the code, find the problem, write the solution and then contact the maintainer. So what in effect is being asked is that non-Novell people can become maintainers. I believe something like that will be possible with the new build server. http://build.opensuse.org/ Refering to http://lists.opensuse.org/archive/opensuse-buildservice/2006-Mar/0004.html I asume we need to wait till after 10.1 launch? houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
houghi wrote:
I think I am completely misunderstanding what the issue is here. First it was about spelling errors that could be solved by users, then is was about changes that should be done in Yast and now it is about making better bugreports. Very confusing to me, sorry.
It's not really that difficult, houghi. What jdd is proposing/suggesting is that not only Novell solve the problems in the SUSE distribution, but that they open it (somehow) for others to participate with bugfixes (however minor or irrelevant). Perhaps I spot a problem in an apparmor profile - I can correct it, then submit a fix/patch. After all, this is usually the way OSS project work. Right now, opensuse seems to work mostly by the community submitting reports, and Novell fixing the problems.
I like the idea. I think part of the soluition is the build service coming soon. I think MySQL AB with the various products is a good example. They have internal source tree's and external. Whether they are BK(Bit Keeper) or svn. I am able to download and keep all the tree's locallly. I then get a pack and post it to the internals list or to the appporiate group/list. I have signed a form giving MySQL AB joint ownership of the code for them to do with as they like sometimes they change the patches sometime they take them as is. I would like something similar for All the SUSE Distribution. I think that is what will happend with the build service. All the source will be available to the build service and we can make/post fixes there. Then SUSE/Novell are free to take those changes and do with them as they like. I would like a public tree like public CVS access to freely down load all source and submit patches. I know with the 10.1 new accounts are held up. I asked for one back in January and I am still waiting. I would like to get on and fix a few of the bugs that really bother me. I like the opensuse-commits list. It is very interesting to follow. I sometimes wish there were more details. It is a very good start. Thanks, - -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFERtNUVtBjDid73eYRAomVAJwN2GV1uIpvdfkiec71MaKBPbpWaQCfVcpU GYQDpPQIGMnbOrah+MPFg7E= =qqyg -----END PGP SIGNATURE-----
On Wed, Apr 19, 2006 at 08:23:05PM +0200, jdd wrote:
*may be we should slowdown and have a worked stable, a working unstable and a dev one like debian. Debian is too slow, but SUSE is too fast :-)
SUSE used to be a 6 month realease date. From 10.1 this is changed to an 8 month release date. <snip> What you are describing is something completely different then what you were writing about earlier. The part I snipped now is for future releases and has some valid points. It was also specific about YaST. What you described in earlier postings was about SUSE versions that were already out there and about the distro in general. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
I try to think of solutions. *may be we should slowdown and have a worked stable, a working unstable and a dev one like debian. Debian is too slow, but SUSE is too fast :-)
Yes, I think working in two teams: stable + unstable will be good. Unfortunately SUSE Linux 10.0 is poorly tested, leaving out many bugs. I'm even thinking about starting rolling Unofficial Service Packs for SUSE Linux 10.0. (why only corporates deserve fixes ? we - the community - too deserve fixes) I also believe that offline support must be available for stable releases - that is either Service Packs (like M$) or ISO releases (r1, r2 - like Debian Stable).
*I already tried to identify what yast module do what to look at the sources. It's really difficult. any doc?
*why is Yast so bad documented? I use SUSE now for nearly 10 years an they are still options I don't know what they are for...
Yast is generally very poorly documented, and there are very few tutorials about programming Yast modules (even the FOSDEM2006 tutorial is not really enough to start speaking Yast ) I think Novell should release more documentation about Yast - so then more developers will write Yast Modules and perhaps more distros will use Yast (which in turn will bring us even more modules backported from other distros).
On Wed, Apr 19, 2006 at 05:10:35PM -0200, Alexey Eremenko wrote:
Unfortunately SUSE Linux 10.0 is poorly tested, leaving out many bugs.
Well, see that future versions are better tested. ;-)
I'm even thinking about starting rolling Unofficial Service Packs for SUSE Linux 10.0. (why only corporates deserve fixes ? we - the community - too deserve fixes)
Uhm, sorry? What about YOU?
I also believe that offline support must be available for stable releases - that is either Service Packs (like M$) or ISO releases (r1, r2 - like Debian Stable).
That is possible. Download them and burn them on a CD. The reason there is no ISO has been discussed already. <snip>
more developers will write Yast Modules and perhaps more distros will use Yast (which in turn will bring us even more modules backported from other distros).
That would indeed be great, provided that they HAVE that documentation. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Wed, Apr 19, 2006 at 08:04:00PM +0200, jdd wrote:
It is not a security issue, so it won't be done by YOU.
YOU allows all king of updates, not only security, this is a user choice.
I understand that YOU could do any updates. It is the policy from SUSE to only do updates. The reason has been explained before. <snip>
I have problems now with 10.0, far inside the 2 years limit. and this don't seem to be fixed neither.
Is it a security issue? If so, it should be reported via Bugzilla, if not, it might not be importand enough to be done.
no. We can update Yast (anyway, yast is the only SUSE visible products, all the rest have others maintainers).
YOU can indeed do it. It is the policy of SUSE only to do security updates.
So in general, I think it is a bad idea, sorry.
I think you are discussing methods, not ideas.
The two are inter connected. If you have an idea, you also need the method to do the updates.
Idea is: do you think community users can be part of the debugging that Novell employees can't do? if yes, then the methos will follow.
Bugzilla is great for this. <snip>
It really upset me to see typos in Yast I could correct in 10 seconds with the good interface staying there for age.
Again, SUSE does security updates, not spellingcorrectionupdates.
may I write a wiki page saying "in this page there is a bug, but it wont be fixed"?
Sure, it is a wiki. You could make it yourself easy and just say that only security updates are done and spelling errors are not done.
I would like Novell programmers concentrate to bugs I can't fix (there are enough :-()
So again I ask you, say you have found a spellingserror, how would that get to me, a user, when you know it won't be done by YOU? houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
On Wed, Apr 19, 2006 at 08:04:00PM +0200, jdd wrote:
I have problems now with 10.0, far inside the 2 years limit. and this don't seem to be fixed neither.
Is it a security issue? If so, it should be reported via Bugzilla, if not, it might not be importand enough to be done.
I think it should be reported regardless of what type of issue it may be. But presumably jdd has already done so, since he knows that no fix is forthcoming.
The two are inter connected. If you have an idea, you also need the method to do the updates.
Eventually yes, but not both at the same time. When John F. Kennedy thought going to the Moon was a good idea, he didn't quite have the methods ready. The methods will follow if the idea is accepted. /Per Jessen, Zürich
On Wed, Apr 19, 2006 at 09:37:21PM +0200, Per Jessen wrote:
Eventually yes, but not both at the same time. When John F. Kennedy thought going to the Moon was a good idea, he didn't quite have the methods ready. The methods will follow if the idea is accepted.
Bush told that going to Mars with a manned vehicle was a good idea. That won't happen in the timeframe he promised. At the time of the JFK speech, the idea was already accepted and the method needed finetuning. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
On Wed, Apr 19, 2006 at 09:37:21PM +0200, Per Jessen wrote:
Eventually yes, but not both at the same time. When John F. Kennedy thought going to the Moon was a good idea, he didn't quite have the methods ready. The methods will follow if the idea is accepted.
Bush told that going to Mars with a manned vehicle was a good idea. That won't happen in the timeframe he promised. At the time of the JFK speech, the idea was already accepted and the method needed finetuning.
Oh yeah - about 8 years of it, wasn't it? I think what you call finetuning I prefer to call development. /Per Jessen, Zürich
On Thu, Apr 20, 2006 at 03:08:27PM +0200, Per Jessen wrote:
Bush told that going to Mars with a manned vehicle was a good idea. That won't happen in the timeframe he promised. At the time of the JFK speech, the idea was already accepted and the method needed finetuning.
Oh yeah - about 8 years of it, wasn't it? I think what you call finetuning I prefer to call development.
So let us see how much development will be done with the Bush speech and his speech about a manned-mission to mars. What I am saying is talking the talk is not enough. The one can not go without the other. I would not call it development, I would say 'further development'. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
houghi wrote:
So again I ask you, say you have found a spellingserror, how would that get to me, a user, when you know it won't be done by YOU?
why do you keep saying things you should know are wrong? YOU is _not_ only for security. Novell choosed to not bugfix other than security, for evident reason (they concentrate on 10.1), bugzilla bugreport on other subjets are prone to be rejected. others contributors understood my meaning; The yast example I gave was to show that right now it's very difficult to install yast sources locally. tgis kind of install could be a way to give not only bugreports but also bugfixes through bugzilla. I hope the new build service will be able to do part of what I aks for. Of course all this won't happen right now jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Thu, 20 Apr 2006, jdd wrote:
So again I ask you, say you have found a spellingserror, how would that get to me, a user, when you know it won't be done by YOU?
why do you keep saying things you should know are wrong? YOU is _not_ only for security. Novell choosed to not bugfix other than security, for evident reason (they concentrate on 10.1), bugzilla bugreport on other subjets are prone to be rejected.
The YaST Online Update has been used only for security and critical updates in the past -- but there is no technical reason not to use it for other/minor stuff, but we have choosen not to do this in the past. This has been discussed many times on this list, so please let's try not to get into this again now.
others contributors understood my meaning;
The yast example I gave was to show that right now it's very difficult to install yast sources locally. tgis kind of install could be a way to give not only bugreports but also bugfixes through bugzilla.
I hope the new build service will be able to do part of what I aks for.
It definately will. Regards Christoph
Christoph Thiel wrote:
The YaST Online Update has been used only for security and critical updates in the past -- but there is no technical reason not to use it for other/minor stuff, but we have choosen not to do this in the past. This has been discussed many times on this list, so please let's try not to get into this again now.
I quoted on an other mail (sorry, I have not it at hand) that anybody can see in YOU three levels of colors, with "optional" patches. right now I see "SuSE Kde extensions" (SuSE written that way :-) "This update fixes problems with buttons being swapped in QMessageBoxes when the Qt/KDE integration is enabled." this don't seems security related but this is minor; it's easy to find solutions jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Thu, 20 Apr 2006, jdd wrote:
The YaST Online Update has been used only for security and critical updates in the past -- but there is no technical reason not to use it for other/minor stuff, but we have choosen not to do this in the past. This has been discussed many times on this list, so please let's try not to get into this again now.
I quoted on an other mail (sorry, I have not it at hand) that anybody can see in YOU three levels of colors, with "optional" patches.
right now I see "SuSE Kde extensions" (SuSE written that way :-) "This update fixes problems with buttons being swapped in QMessageBoxes when the Qt/KDE integration is enabled."
this don't seems security related
but this is minor; it's easy to find solutions
Ok, I should have phrased it like this: "... we have choosen to release other/optional/minor updates as an exception only." However, with the power of the openSUSE build service, we as a community might come to the conclusion that it actually makes sense to create a repository with fixed packages that covers all those littel bugs and glitches that you find while using the distribution. But it should be obvious, that something like this needs quite an effort by the community. Regards Christoph
On Thu, Apr 20, 2006 at 09:26:56AM +0200, Christoph Thiel wrote:
On Thu, 20 Apr 2006, jdd wrote:
The YaST Online Update has been used only for security and critical updates in the past -- but there is no technical reason not to use it for other/minor stuff, but we have choosen not to do this in the past. This has been discussed many times on this list, so please let's try not to get into this again now.
I quoted on an other mail (sorry, I have not it at hand) that anybody can see in YOU three levels of colors, with "optional" patches.
right now I see "SuSE Kde extensions" (SuSE written that way :-) "This update fixes problems with buttons being swapped in QMessageBoxes when the Qt/KDE integration is enabled."
this don't seems security related
but this is minor; it's easy to find solutions
Ok, I should have phrased it like this: "... we have choosen to release other/optional/minor updates as an exception only." However, with the power of the openSUSE build service, we as a community might come to the conclusion that it actually makes sense to create a repository with fixed packages that covers all those littel bugs and glitches that you find while using the distribution. But it should be obvious, that something like this needs quite an effort by the community.
With 10.1 and on anyone can just provide an external update repository, which can be linked in. (I think.) Ciao, Marcus
Hi, On Thursday 20 April 2006 09:26, Christoph Thiel wrote:
Ok, I should have phrased it like this: "... we have choosen to release other/optional/minor updates as an exception only." However, with the power of the openSUSE build service, we as a community might come to the conclusion that it actually makes sense to create a repository with fixed packages that covers all those littel bugs and glitches that you find while using the distribution. But it should be obvious, that something like this needs quite an effort by the community.
And that was the original proposal (if I understood it correctly). What would be needed would be a clear communication towards the end user: a commitment from SUSE limited to security and major issues (todays policy) and beyond that a non-commited "community contribution". Greetings from Stuhr hartmut -- Hartmut Meyer, NTS EMEA Partner Relationship Manager SUSE LINUX GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 421 3064385 - M: +49 179 2279480 F: +49 421 3064387 - hartmut.meyer@novell.com ---------------------------------------------------- http://www.novell.com/open
Hartmut Meyer wrote:
Hi,
On Thursday 20 April 2006 09:26, Christoph Thiel wrote:
Ok, I should have phrased it like this: "... we have choosen to release other/optional/minor updates as an exception only." However, with the power of the openSUSE build service, we as a community might come to the conclusion that it actually makes sense to create a repository with fixed packages that covers all those littel bugs and glitches that you find while using the distribution. But it should be obvious, that something like this needs quite an effort by the community.
And that was the original proposal (if I understood it correctly).
partly. we must be precise, here. as of updates, there are for that purpose two categories: * usual packages updates. probably most of it is done by the package owner... suse integration should modify nothing if possible, if not the least possible thing, so the build system could build the new package right from the new sources. Better then if the package is all maintained by the build system :-). I see nothing to do in this, should be 99.9% automatic * SUSE specific stuff. We use to call it Yast, but it can be also sax2, /etc/sysconfig, SuSEconfig, SuSEfirewall2 (translating the doc?)... I think the community should concentrate mainly on the second part, SUSE Specific. Then we could have several levels of implication. * true maintainer. I don't really know how Novell/SUSE is organised, but I beg there is a team or a person assigned to a task. For example I see this: # translation of bootloader.po to # translation of bootloader.po to # translation of bootloader.po to français # translation of bootloader.po to Français # translation of bootloader.fr.po to Français # French message file for YaST2 (bootloader). # Copyright (C) SuSE GmbH, 2000. # Copyright (C) 2002 SuSE Linux AG. # Francoise Lermen <flermen@suse.de>, 2000, 2002. # Patricia Vaz <Patricia.Vaz@suse.de>, 2003,2004. # Patricia Vaz <patricia.vaz@suse.com>, 2004. # Patricia Vaz <patricia@suse.de>, 2005. # and I beg Pat is the owner of this package. May be a member of the community could be set as the maintainer, or simply set as a Pat help * organised help. Simply better document the way the community can help. Make a wiki page explaining how to download the po sources, make all these po files available from an html browser (seems very easy). Make wiki pages with yast screenshots and links to the relevant po file. Eventually provide special bugzilla access for that. Link all this to the Manual corresponding page... all this need quite a lot of work to setup, but once this done, the resulting quality should greatly improve in fact, if I correctly see, this is nothing more than a building / bugfix system for documentation/translation... As you see, I think the documentation at large is that part where the community can be the most usefull, because anybody can proofread a screen. Knowing it's also my main knowledge I may be biased, but if the community can also help elsewhere, the more the better :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Thu, Apr 20, 2006 at 01:41:04PM +0200, jdd wrote:
* true maintainer. I don't really know how Novell/SUSE is organised, but I beg there is a team or a person assigned to a task. For example I see this: <snip> and I beg Pat is the owner of this package.
May be a member of the community could be set as the maintainer, or simply set as a Pat help
Everybody is a 'Pat help'. Just use Bugzilla and add her as a contact, or mail her directly. The first will be better, I suppose. If you can't find the correct person, most likely the person at SUSE you assigned it to, will know and assign it to that person.
* organised help.
Simply better document the way the community can help.
Make that 'better documentation in general'. Although the documentation is one of the best for the users. There still needs a LOT to be done. Fact is that good documentation takes time away from development and 99% of the documentation is not read.
Make a wiki page explaining how to download the po sources,
I believe the po files are in the sources so they are available. Each package will have it's own .po files. Placing them outside of tat package might be complicating thing, although I am not sure.
make all these po files available from an html browser (seems very easy).
file:///dir/to/langage.po after unpacking the po file, I should think. Lets try it. I did a `locate *.po` and got (among others) /usr/share/gfxboot/themes/SuSE/po/nl.po, so that would become: file:///usr/share/gfxboot/themes/SuSE/po/nl.po
Make wiki pages with yast screenshots and links to the relevant po file. Eventually provide special bugzilla access for that.
I would call that a bit over the top, especially because you need to replace the screenshots after each correction to be accurate. However as it is a wiki, please go ahead. <snip>
in fact, if I correctly see, this is nothing more than a building / bugfix system for documentation/translation... <snip>
It feels as if you try to re-invent bugzilla again or that you want to become an offical SUSE maintainer. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Reading old mails... jdd, I like your idea about polishing the distribution once the product is released. As Christoph and others said, we now can offer those updates using the openSUSE Build Service. If not already done, I propose to start a "translation" Project and to add some yast2-trans packages for testing. Is "translation" ("Translation"?) a good name? What about "L10N"? "Localization"? The packages will require some adjustments to make them build smoothly outside of our internal SVN system. More precisely, building works, but for best results preparation steps are required which are usually done within the SVN. This part we will move to the developer.novell.com servers some time soon. For preliminary information, see http://en.opensuse.org/OpenSUSE_Localization_Guide All this could be better discussed on the opensuse-translation ML, to where I'll forward the translation aspect of this thread. Please subscribe to the opensuse-translation ML! jdd <jdd@dodin.org> writes:
in fact, if I correctly see, this is nothing more than a building / bugfix system for documentation/translation...
As you see, I think the documentation at large is that part where the community can be the most usefull, because anybody can proofread a screen.
Yes, the same could be done for documentation, but do not underestimate the work involved... -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH Key fingerprint = B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org
Karl Eichwalder wrote:
Reading old mails...
jdd, I like your idea about polishing the distribution once the product is released.
:-) As Christoph and others said, we now can offer those
updates using the openSUSE Build Service. If not already done, I propose to start a "translation" Project and to add some yast2-trans packages for testing. Is "translation" ("Translation"?) a good name? What about "L10N"? "Localization"?
why not? for example is going from pt to pt-br a translation? localization seems good.
The packages will require some adjustments to make them build smoothly outside of our internal SVN system. More precisely, building works, but for best results preparation steps are required which are usually done within the SVN. This part we will move to the developer.novell.com servers some time soon. For preliminary information, see http://en.opensuse.org/OpenSUSE_Localization_Guide
I wont be able do do any usefull work on this project before end of summer (I don't take vacations, but family is very demanding at this period :-); this said, using svn if probably the best way to make such small adjustement. We could have some kind of project manager (people able to manage svn) from the local voluntaries to keep the doc up to date - a wiki is definitvely not the place for that
All this could be better discussed on the opensuse-translation ML, to where I'll forward the translation aspect of this thread. Please subscribe to the opensuse-translation ML!
why not use doc? there are too many lists already. sight. (I subscribed)
jdd <jdd@dodin.org> writes:
in fact, if I correctly see, this is nothing more than a building / bugfix system for documentation/translation...
As you see, I think the documentation at large is that part where the community can be the most usefull, because anybody can proofread a screen.
Yes, the same could be done for documentation, but do not underestimate the work involved...
I don't :-) I was an editor, long time ago but as soon as some tasks can be scripted things a simpler (a little) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org
jdd wrote:
houghi wrote:
So again I ask you, say you have found a spellingserror, how would that get to me, a user, when you know it won't be done by YOU?
why do you keep saying things you should know are wrong? YOU is _not_ only for security. Novell choosed to not bugfix other than security, for evident reason (they concentrate on 10.1), bugzilla bugreport on other subjets are prone to be rejected.
others contributors understood my meaning;
The yast example I gave was to show that right now it's very difficult to install yast sources locally. tgis kind of install could be a way to give not only bugreports but also bugfixes through bugzilla.
You are mixing up two different things: 1) using YOU as a channel to provide other updates, not only security or critical ones 2) access to the sources of the packages on SUSE Linux I'd just like to mention for the 1st item that this totally voids the YOU approach in my opinion, from the perspective of a 3rd party packager. Patch RPMs aside (too complex and time-consuming to maintain), YOU is just a notification mechanism. There is no reason for it to be a separate channel for getting RPMs (well, there is one reason, read at the end ;)). I think that the concept should be refined here, if we head in the direction of having broader updates on released SUSE versions and real integration of 3rd party packagers, something that has been totally ignored in the past. The current YOU update checker should be refactored to fetch the metadata of all the "installation sources" that have been registered into YaST2 (e.g. like how ksmarttray does) and notify the end-user when new packages are available. To keep it limited to an update-only notification tool, it could only notify the end-user when an update to an already installed package is available from any of the registered installation sources. That wouldn't be all that complex to implement (and the user could choose/configure whether he wants to be notified about new packages as well or only about updates). As with 10.0's SUSE watcher, a click on the icon could trigger a specific YaST2 mode that shows a list of new packages and updates to existing packages (something similar to what YOU does). YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available". It's too complex, there should be a single icon in the YaST2 menu to do that operation in a dedicated way, since it's what almost every SUSE Linux user is doing, every single day for many of them.. well, at least those who use 3rd party repositories like mine, Packman, etc... I currently have around 400 active projects that I package, part of them are not shipped with SUSE Linux at all, and the other part are newer versions (e.g. gimp, gaim, amarok, blender, lyx, ...). And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer". "smart update && smart upgrade" is so much easier, it's what I recommend to everyone. Spend a few evenings on IRC (freenode.net, #suse) or on web forums and have a look at what end-users are asking, where they need help, and you'll notice quite quickly what operations are too tedious, too complex and would require some refinement in YaST2. I very often recommend to install smart first, as it allows to do many package management operations in a much more straightforward way, without asking the end-user to manually resolve a dozen "conflicts". As an example, the always recurring MP3 support question is answered by: - install smart (from suser-guru) - smart comes preconfigured with suser-guru and packman channels, so fortunately there's no need to add those repositories - smart install libxine1 amarok amarok-xine Doing that with YaST2 would be a much more tedious operation: - adding 2 installation sources (the GUI should really accept URLs instead of splitting into "protocol", "server", "directory on server", what a pain) - make sure they're on autorefresh - add an installation source for SUSE Linux 10.0 (as the CDs or DVD don't include all the packages) - something you don't have to do with smart either, as it comes preconfigured with that - open YaST2's "software management" screen - select "Search" - search for "libxine1" - check the box for libxine1 - search for "amarok" - ("oh, it's locked and/or red..hmm.. why is that ?" - "no idea, don't bother") - click on amarok and amarok-xine until it shows the update icon - press OK Now, to come back to YOU... The only real added value of YOU is the following additional information: - description of the update - severity (critical, security, minor, ...) That information is not available in repository metadata formats as of now (neither in YaST2, nor apt-rpm, nor rpm-md and I guess it's not possible in red/open-carpet either). That's the problem ;) An update/change description could be pulled out of the RPM %changelog, although I don't know whether that information is stored in current repository metadata formats like rpm-md. But the severity information isn't available by any means.
I hope the new build service will be able to do part of what I ask for.
Yes, partly. But if you want to submit bugfixes to e.g. YaST2, you should pull the YaST2 source code, make patches and submit them to the YaST2 maintainers (either through bugzilla or by mail).
Of course all this won't happen right now
Indeed. And I doubt it will happen any time soon. -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
On Thu, Apr 20, 2006 at 12:46:23PM +0200, Pascal Bleser wrote:
To keep it limited to an update-only notification tool, it could only notify the end-user when an update to an already installed package is available from any of the registered installation sources. That wouldn't be all that complex to implement (and the user could choose/configure whether he wants to be notified about new packages as well or only about updates).
As long as the package had the feature to or wil only update those from the original source, I would be very happy to use it. e.g. if there I have a xmms installed from SUSE and there is a newer version on Packman, I want to keep my SUSE, or the other way around. On the `smart` thing. If it is so much better then the YaST software management, why not ditch the seconds and replace it with smart? It should not be too hard to make a YaST module. Could/should be doable for 10.2 houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Hi, On Thursday, April 20, 2006 at 12:46:23, Pascal Bleser wrote: > YaST2 should also get a decent way to update existing packages. This > is currently (as of 10.0) a real pain to do, there's no obvious option. > You have to select "package categories", go to "zzz all", right click > on the right pane, "this list..." -> "update if newer version available". YaST -> System Update does exactly that... > And while y2pmsh has a "newer" command to show what updates are > available, it doesn't have a "install-newer" (or similar) command, so > you have to specify them yourself from the list shown by "newer". y2pmsh upgrade solve commit > Now, to come back to YOU... The only real added value of YOU is the > following additional information: > - description of the update > - severity (critical, security, minor, ...) - scripts - pre/post install messages > That information is not available in repository metadata formats as of > now (neither in YaST2, nor apt-rpm, nor rpm-md and I guess it's not > possible in red/open-carpet either). Its included in "our" enhanced rpm-md that we use for the update dirs. Henne -- Henne Vogelsang, Core Services "Rules change. The Game remains the same." - Omar (The Wire)
Henne Vogelsang wrote:
Its included in "our" enhanced rpm-md that we use for the update dirs.
uh :-) open source is a dreadfull system :-) users asks always questions and secrets are hard to keep :-)))) I know openSUSE is only 9 month old, it's VERY youg. We all want the best and so push the beast :-) But we know a great job is done :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
Am Thursday 20 April 2006 13:23 schrieb Henne Vogelsang:
Hi,
On Thursday, April 20, 2006 at 12:46:23, Pascal Bleser wrote:
YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available".
YaST -> System Update does exactly that...
it does even support changing repositories since 10.0.
And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".
y2pmsh upgrade solve commit
Now, to come back to YOU... The only real added value of YOU is the following additional information: - description of the update - severity (critical, security, minor, ...)
- scripts - pre/post install messages
- defined patch sets (no way to do only a partly update and to cause more trouble) In general, I do think that we should keep the default updates low as we do atm. The rational here is that a number of people do already complain about the needed bandwidth for doing the updates and that changes can also break things which may be more annoying than a missing fix. BUT we can also create a "Community SL 10.1 Maintainance" project in the build service. This one can get integrated via an additional repository in yast and the update will be possible via YaST or any other YUM compatible updater. There would the need of a number of people with direct write access to this project. Others will be able suggest further fixes via their projects for inclusion into this one. This means a group of people needs to be formed to decide what to include into that project and what not. Maybe also to create a policy about that first. Pascal, you are obviously a good candidate to form such a group ;) We can hopefully support you soon with the needed infrastructure for this task ... mls is working about source linking atm. This means one will be able to link the sources of apache from SL 10.1 into this project for example. And to add some patches which fixes the particular issue. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
On Thu, 20 Apr 2006, Pascal Bleser wrote:
You are mixing up two different things: 1) using YOU as a channel to provide other updates, not only security or critical ones 2) access to the sources of the packages on SUSE Linux
I'd just like to mention for the 1st item that this totally voids the YOU approach in my opinion, from the perspective of a 3rd party packager. Patch RPMs aside (too complex and time-consuming to maintain), YOU is just a notification mechanism. There is no reason for it to be a separate channel for getting RPMs (well, there is one reason, read at the end ;)).
I think that the concept should be refined here, if we head in the direction of having broader updates on released SUSE versions and real integration of 3rd party packagers, something that has been totally ignored in the past.
Using/accessing additional package repositories has been a feature of YaST for quite some time already -- however, creating those repos was challenging in the past, due to the lack of proper documentation for example. I think we have made significant progress in this area with 10.0 (which introduced support for repomd/yum repos) and especially with 10.1 (which may sound a bit exaggerated, considering the current state of libzypp -- but at the end of the day, it still improves the repo handling a lot ;)).
YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available". It's too complex, there should be a single icon in the YaST2 menu to do that operation in a dedicated way, since it's what almost every SUSE Linux user is doing, every single day for many of them.. well, at least those who use 3rd party repositories like mine, Packman, etc...
Offering an update repository (in repomd style + patch infos) should pretty straightforward on 10.1...
And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".
"smart update && smart upgrade" is so much easier, it's what I recommend to everyone.
Exactly -- y2pmsh is basically dead, so pushing people into the smart direction is the right thing(tm) ;)
Doing that with YaST2 would be a much more tedious operation: - adding 2 installation sources (the GUI should really accept URLs instead of splitting into "protocol", "server", "directory on server", what a pain)
+1 -- should be fixed for 10.2 ;)
- make sure they're on autorefresh
Which sould actually be the case by default, IIRC.
Now, to come back to YOU... The only real added value of YOU is the following additional information: - description of the update - severity (critical, security, minor, ...)
Have you looked at the new update trees for 10.1? They contain repomd stuff out-of-the-box + the additional information is stored in a repomd-alike way, which could be created by 3rd party packagers as well. I think it could even become a feature of the openSUSE build service to create/provide special update trees or add those kind of additional information to repos it creates. (But that's something for... later ;))
That information is not available in repository metadata formats as of now (neither in YaST2, nor apt-rpm, nor rpm-md and I guess it's not possible in red/open-carpet either).
That's the problem ;)
An update/change description could be pulled out of the RPM %changelog, although I don't know whether that information is stored in current repository metadata formats like rpm-md.
But the severity information isn't available by any means.
See above -- the stuff we did for the update trees is quite an extension to what repomd offers right now, but it should be relatively easy to add this to smart and $other_packages_manager(s). Regards Christoph
Am Thursday 20 April 2006 14:31 schrieb Christoph Thiel:
On Thu, 20 Apr 2006, Pascal Bleser wrote:
- make sure they're on autorefresh
Which sould actually be the case by default, IIRC.
except when it is disabled explicit in the repository information. -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
Christoph Thiel wrote:
On Thu, 20 Apr 2006, Pascal Bleser wrote:
You are mixing up two different things: 1) using YOU as a channel to provide other updates, not only security or critical ones 2) access to the sources of the packages on SUSE Linux
I'd just like to mention for the 1st item that this totally voids the YOU approach in my opinion, from the perspective of a 3rd party packager. Patch RPMs aside (too complex and time-consuming to maintain), YOU is just a notification mechanism. There is no reason for it to be a separate channel for getting RPMs (well, there is one reason, read at the end ;)).
I think that the concept should be refined here, if we head in the direction of having broader updates on released SUSE versions and real integration of 3rd party packagers, something that has been totally ignored in the past.
Using/accessing additional package repositories has been a feature of YaST for quite some time already -- however, creating those repos was challenging in the past, due to the lack of proper documentation for example. I think we have made significant progress in this area with 10.0
Actually I meant a little bit more than adding other repositories. Everything, up to 10.0 was only tailored for the way SUSE ships its distribution, and didn't take into account how the actual setup for many (I wouldn't say "most", I don't have numbers) users is, i.e. with additional repositories such as Packman and a few others. And, precisely, lack of documentation has been a major issue, for example - how to create a YaST2 repository (which is still a mess, compared to opencarpet or createrepo - I won't mention apt4rpm as I've always found that to be way too complex to set up as well) - how to create YOU repositories - easy "upgrade" operation in YaST2 (the "system update" thing in YaST2 always reinstalls the kernel package)
(which introduced support for repomd/yum repos) and especially with 10.1 (which may sound a bit exaggerated, considering the current state of libzypp -- but at the end of the day, it still improves the repo handling a lot ;)).
I hope so ;)
YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available". It's too complex, there should be a single icon in the YaST2 menu to do that operation in a dedicated way, since it's what almost every SUSE Linux user is doing, every single day for many of them.. well, at least those who use 3rd party repositories like mine, Packman, etc...
Offering an update repository (in repomd style + patch infos) should pretty straightforward on 10.1...
Great! Where can I find the documentation about it ? - how to generate such repositories, where does the additional data come from ? - what are the repomd extensions ? schema or DTD ? Is it backwards compatible with plain repomd ?
And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".
"smart update && smart upgrade" is so much easier, it's what I recommend to everyone.
Exactly -- y2pmsh is basically dead, so pushing people into the smart direction is the right thing(tm) ;)
y2pmsh is still well alive for 10.1 atm, unfortunately, because libzypp & friends are mostly broken in 10.1RC1 :\ (at least that's what most people report on IRC, I for myself currently use y2pmsh for my 10.1RC1 build chroots) Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?
Doing that with YaST2 would be a much more tedious operation: - adding 2 installation sources (the GUI should really accept URLs instead of splitting into "protocol", "server", "directory on server", what a pain)
+1 -- should be fixed for 10.2 ;)
Good :) I guess it should be entered in bugzilla.
- make sure they're on autorefresh Which sould actually be the case by default, IIRC.
Yes, but also setting the internet installation source for SUSE Linux (inst-source and inst-source-java) on no-autorefresh.
Now, to come back to YOU... The only real added value of YOU is the following additional information: - description of the update - severity (critical, security, minor, ...)
Have you looked at the new update trees for 10.1? They contain repomd
No.
stuff out-of-the-box + the additional information is stored in a repomd-alike way, which could be created by 3rd party packagers as well.
I sure hope so ;)
I think it could even become a feature of the openSUSE build service to create/provide special update trees or add those kind of additional information to repos it creates. (But that's something for... later ;))
Right.
That information is not available in repository metadata formats as of now (neither in YaST2, nor apt-rpm, nor rpm-md and I guess it's not possible in red/open-carpet either). That's the problem ;) An update/change description could be pulled out of the RPM %changelog, although I don't know whether that information is stored in current repository metadata formats like rpm-md. But the severity information isn't available by any means.
See above -- the stuff we did for the update trees is quite an extension to what repomd offers right now, but it should be relatively easy to add this to smart and $other_packages_manager(s).
Hm. myeah. Well, if that "repomd-suse" format is backwards compatible with plain repomd, it will work with smart and yum without any need for modifications (I suppose). If not, then support for another SUSE-specific repomd-variant must be added to smart. Mauricio ? ;) cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
On Thu, 20 Apr 2006, Pascal Bleser wrote: [...]
YaST2 should also get a decent way to update existing packages. This is currently (as of 10.0) a real pain to do, there's no obvious option. You have to select "package categories", go to "zzz all", right click on the right pane, "this list..." -> "update if newer version available". It's too complex, there should be a single icon in the YaST2 menu to do that operation in a dedicated way, since it's what almost every SUSE Linux user is doing, every single day for many of them.. well, at least those who use 3rd party repositories like mine, Packman, etc...
Offering an update repository (in repomd style + patch infos) should pretty straightforward on 10.1...
Great! Where can I find the documentation about it ? - how to generate such repositories, where does the additional data come from ? - what are the repomd extensions ? schema or DTD ?
I'm afraid to have to tell you, that there isn't much documentation on a technical level yet :( You'd have to dig into some YaST / libzypp / zmd packages, to find the answers to your questions. But as we move along, we will hopefully be able to deliver documentation on this in the future.
Is it backwards compatible with plain repomd ?
It is, as it's just an extension to what repomd offers out-of-the-box. So there are some more .xml files (one per patch) and the usual primary/filelist/other .xml files. Check out http://download.suse.com/update/10.1/repodata/ for the details.
And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".
"smart update && smart upgrade" is so much easier, it's what I recommend to everyone.
Exactly -- y2pmsh is basically dead, so pushing people into the smart direction is the right thing(tm) ;)
y2pmsh is still well alive for 10.1 atm, unfortunately, because libzypp & friends are mostly broken in 10.1RC1 :\ (at least that's what most people report on IRC, I for myself currently use y2pmsh for my 10.1RC1 build chroots)
Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?
y2pmbuild should be fully functional with the BuildRequires expansion stuff that went into build.rpm -- there is no real need to use y2pmsh, IIUC.
Doing that with YaST2 would be a much more tedious operation: - adding 2 installation sources (the GUI should really accept URLs instead of splitting into "protocol", "server", "directory on server", what a pain)
+1 -- should be fixed for 10.2 ;)
Good :) I guess it should be entered in bugzilla.
Right, if it's not there yet -- or, actually it should be added to some wiki page on openSUSE.org ;) Regards Christoph
Christoph Thiel wrote:
> On Thu, 20 Apr 2006, Pascal Bleser wrote:
>
> [...]
>
>>>> YaST2 should also get a decent way to update existing packages. This
>>>> is currently (as of 10.0) a real pain to do, there's no obvious
>>>> option. You have to select "package categories", go to "zzz all",
>>>> right click on the right pane, "this list..." -> "update if newer
>>>> version available". It's too complex, there should be a single icon
>>>> in the YaST2 menu to do that operation in a dedicated way, since
>>>> it's what almost every SUSE Linux user is doing, every single day
>>>> for many of them.. well, at least those who use 3rd party
>>>> repositories like mine, Packman, etc...
>>> Offering an update repository (in repomd style + patch infos) should
>>> pretty straightforward on 10.1...
>> Great! Where can I find the documentation about it ?
>> - how to generate such repositories, where does the additional data come
>> from ?
>> - what are the repomd extensions ? schema or DTD ?
>
> I'm afraid to have to tell you, that there isn't much documentation on a
> technical level yet :( You'd have to dig into some YaST / libzypp / zmd
> packages, to find the answers to your questions. But as we move along, we
> will hopefully be able to deliver documentation on this in the future.
Keep in mind that as long as there isn't any documentation, it's more
or less of no use outside of the SUSE team at Novell.
When you plan/implement such tasks inside the SUSE team, please
consider spending a little bit of time on some decent documentation, a
text file or a wiki page on opensuse.org is sufficient.
(AJ: hint, hint ;))
That's also an aspect of "community", keep in mind your stuff isn't
just intended to be used by a handful of people who sit on the same
floor, in the same building (near the "harddisk mortuary"
(Maxtorgraben) in Nürnberg ;)).
>> Is it backwards compatible with plain repomd ?
>
> It is, as it's just an extension to what repomd offers out-of-the-box. So
> there are some more .xml files (one per patch) and the usual
> primary/filelist/other .xml files.
Ah, ok, it's additional XML files. Great :)
> Check out http://download.suse.com/update/10.1/repodata/ for the details.
Allright.
What I can see there is
* Plain rpm-md files:
- filelists.xml.gz
- other.xml.gz
- primary.xml.gz
- repomd.xml ==> extended with
<data type="patches">
<location href="repodata/patches.xml"/>
<checksum type="sha">...</checksum>
<timestamp>1145376771</timestamp>
<open-checksum type="sha">...</open-checksum>
</data>
* Additional SUSE-specific files:
- patches.xml
<patches>
<patch id="zypp-1261">
<checksum type="sha">...</checksum>
<location href="repodata/patch-zypp-1261.xml"/>
</patch>
...
</patches>
- a lot of individual patch-*.xml files
(with a quite complex structure)
Well, everything seems pretty straightforward, except the patch-*.xml
files.
I assume you've got some tooling to generate those, as well as a
modified createrepo, right ?
How can we use those ?
- modified createrepo ? (that mentions <data type="patches">...</data>
in the generated repomd.xml, and generates the patches.xml file)
- tool to generate the patch-*.xml files ?
...
>> Which makes me think that... err... once y2pmsh will really be dead
>> (i.e. non functional), y2pmbuild must be ported to something else. To
>> smart ? Or is there some form of CLI driven package installation tool
>> with libzypp ?
>
> y2pmbuild should be fully functional with the BuildRequires expansion
> stuff that went into build.rpm -- there is no real need to use y2pmsh,
> IIUC.
Mmmmm.. not quite, as y2pmbuild uses y2pmsh to install missing
BuildRequires into the build chroots.
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@skynet.be> <guru@unixtech.be>
_\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
On Thu, 20 Apr 2006, Pascal Bleser wrote: [...]
I'm afraid to have to tell you, that there isn't much documentation on a technical level yet :( You'd have to dig into some YaST / libzypp / zmd packages, to find the answers to your questions. But as we move along, we will hopefully be able to deliver documentation on this in the future.
Keep in mind that as long as there isn't any documentation, it's more or less of no use outside of the SUSE team at Novell.
When you plan/implement such tasks inside the SUSE team, please consider spending a little bit of time on some decent documentation, a text file or a wiki page on opensuse.org is sufficient. (AJ: hint, hint ;))
Frankly, this stuff has been developed within a very short timeframe under extrem pressure, so nobody cared about documenting this yet ;(
That's also an aspect of "community", keep in mind your stuff isn't just intended to be used by a handful of people who sit on the same floor, in the same building (near the "harddisk mortuary" (Maxtorgraben) in Nürnberg
By the way, the Maxtorhof doesn't have anything todo with a well known harddisk manufacturer. It's called like this, as it is located close to the Maxtor (a city gate) and the Maxtorgraben (something like a "moat").
Is it backwards compatible with plain repomd ?
It is, as it's just an extension to what repomd offers out-of-the-box. So there are some more .xml files (one per patch) and the usual primary/filelist/other .xml files.
Ah, ok, it's additional XML files. Great :)
Check out http://download.suse.com/update/10.1/repodata/ for the details.
Allright.
What I can see there is * Plain rpm-md files: - filelists.xml.gz - other.xml.gz - primary.xml.gz - repomd.xml ==> extended with <data type="patches"> <location href="repodata/patches.xml"/> <checksum type="sha">...</checksum> <timestamp>1145376771</timestamp> <open-checksum type="sha">...</open-checksum> </data>
* Additional SUSE-specific files: - patches.xml <patches> <patch id="zypp-1261"> <checksum type="sha">...</checksum> <location href="repodata/patch-zypp-1261.xml"/> </patch> ... </patches> - a lot of individual patch-*.xml files (with a quite complex structure)
Well, everything seems pretty straightforward, except the patch-*.xml files.
Right ;)
I assume you've got some tooling to generate those, as well as a modified createrepo, right ?
We don't have a modified createrepo for this, but we have our own set of tools to generate those files. The current generation of those tools is tied very closely to our internal build system & infrastructure, so we won't be able to release it as-is. But I can assure you that we will have tools to create that metadata in the future.
How can we use those ? - modified createrepo ? (that mentions <data type="patches">...</data> in the generated repomd.xml, and generates the patches.xml file) - tool to generate the patch-*.xml files ?
Actually, it's createrepo + tool to generate patch-*.xml files. The first part is easy, the other a bit more complicated.
Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?
y2pmbuild should be fully functional with the BuildRequires expansion stuff that went into build.rpm -- there is no real need to use y2pmsh, IIUC.
Mmmmm.. not quite, as y2pmbuild uses y2pmsh to install missing BuildRequires into the build chroots.
Right, but that could be done by simple rpm calls + the BuildRequires expansion that comes with build.rpm! y2pmsh is only used to compute the dependencies, IIUC. Regards Christoph
Hi, On Thursday, April 20, 2006 at 17:14:54, Christoph Thiel wrote:
On Thu, 20 Apr 2006, Pascal Bleser wrote:
Which makes me think that... err... once y2pmsh will really be dead (i.e. non functional), y2pmbuild must be ported to something else. To smart ? Or is there some form of CLI driven package installation tool with libzypp ?
y2pmbuild should be fully functional with the BuildRequires expansion stuff that went into build.rpm -- there is no real need to use y2pmsh, IIUC.
Mmmmm.. not quite, as y2pmbuild uses y2pmsh to install missing BuildRequires into the build chroots.
Right, but that could be done by simple rpm calls + the BuildRequires expansion that comes with build.rpm! y2pmsh is only used to compute the dependencies, IIUC.
And for the repo handling. We just need uberbuild that incorporates all features of y2pmbuild, build.rpm and the build service commandline client. With the BuildRequires expansion we came a good step closer to a unified (local) build tool. The rest should be pretty straigth forward. Henne -- Henne Vogelsang, Core Services "Rules change. The Game remains the same." - Omar (The Wire)
Christoph Thiel wrote:
Frankly, this stuff has been developed within a very short timeframe under extrem pressure, so nobody cared about documenting this yet ;(
let me say that * for sure you know this situation is very dangerous for you, as any problem (sikness... ) involving the programmer make all the system unusable. and I know you know :-) * so may be we could help. I beg some of us (probably not me :-() can with quite little doc make a better document on the wiki and save you some hours... don't hesitate to ask for help... and we can hold on till 10.1 final is out :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
Hi, On Thursday, April 20, 2006 at 20:36:55, jdd wrote:
Christoph Thiel wrote:
Frankly, this stuff has been developed within a very short timeframe under extrem pressure, so nobody cared about documenting this yet ;(
let me say that
* so may be we could help. I beg some of us (probably not me :-() can with quite little doc make a better document on the wiki and save you some hours...
don't hesitate to ask for help... and we can hold on till 10.1 final is out :-)
Quote from http://en.opensuse.org/Tasks Documentation * Document the new media handling and alternatives (autofs, ivman) in the SDB. * Document libzypp/zmd/rug on the Libzypp page. Libzypp contains some information, but rug is only documented by example, there's no wiki page for rug. zen-updater, zen-remover and zen-installer seem to be undocumented. If you are doing this coordinate in bug #163279 please. Ive just added * Document the rpm-md+ format we use in the 10.1 update directory. Please ask on the factory mailinglist if you have any questions about it. Henne -- Henne Vogelsang, Core Services "Rules change. The Game remains the same." - Omar (The Wire)
Henne Vogelsang wrote:
I just fill a bug (168293) because yestaerday, searching this page, I made a search for "task" and this did _not_ give the page (many other, but not this one) :-( this page is a good beginning :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos
On Fri, 21 Apr 2006, Henne Vogelsang wrote:
Quote from
Documentation
* Document the new media handling and alternatives (autofs, ivman) in the SDB. * Document libzypp/zmd/rug on the Libzypp page. Libzypp contains some information, but rug is only documented by example, there's no wiki page for rug. zen-updater, zen-remover and zen-installer seem to be undocumented. If you are doing this coordinate in bug #163279 please.
Ive just added
* Document the rpm-md+ format we use in the 10.1 update directory. Please ask on the factory mailinglist if you have any questions about it.
Thanks -- at the moment this is still kind of a moving target ;( I'd actually want to avoid having someone reverse engineer the format now, because my hope is that we get some decent documentation on the format and its semantics, from the people that worked on this stuff. Regards Christoph
On Thu, Apr 20, 2006 at 03:57:16PM +0200, Pascal Bleser wrote:
And, precisely, lack of documentation has been a major issue, for example - how to create a YaST2 repository (which is still a mess, compared to opencarpet or createrepo - I won't mention apt4rpm as I've always found that to be way too complex to set up as well)
With 10.0 you can use createrepo for that. I know it does not make a REAL YaST repository. It makes a workable one. That
- how to create YOU repositories
As long as it is trictly devided and does not just look at the latest version. I would hate it if a Packman version would overwrite a SUSE version of software or the other way around.
- easy "upgrade" operation in YaST2
That would indeed be very welcome. At this moment I do not even try do do an upgrade as I see so many problems other people have with only slightly changed versions. I rather do a new installation and edit that then trust SUSE with doing everything correct. Many people ask for it and my advice is 1) Backup 2) Try the upgrade 3) Do a new installation. The reason so many people ask is because they want to run the latest version of whatever is available. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Thursday 20 April 2006 12:46, Pascal Bleser wrote:
[...] And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".
newer -i ... but you almost always want to use "upgrade" anyways /me still dreams of pipes cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/
Ludwig Nussel wrote:
On Thursday 20 April 2006 12:46, Pascal Bleser wrote:
[...] And while y2pmsh has a "newer" command to show what updates are available, it doesn't have a "install-newer" (or similar) command, so you have to specify them yourself from the list shown by "newer".
newer -i ... but you almost always want to use "upgrade" anyways /me still dreams of pipes
Ew, nice one. Documented somewhere ? ;) (yes, I could have checked the source code) And upgrade, well, yeah, but it always reinstalls the kernel package. cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
Hello, Am Donnerstag, 20. April 2006 15:42 schrieb Pascal Bleser:
Ludwig Nussel wrote:
On Thursday 20 April 2006 12:46, Pascal Bleser wrote: [y2mpsh stuff] newer -i ... but you almost always want to use "upgrade" anyways /me still dreams of pipes
Ew, nice one. Documented somewhere ? ;) (yes, I could have checked the source code)
;-)
And upgrade, well, yeah, but it always reinstalls the kernel package.
"system updade/upgrade (?)" YaST module downgrading the kernel was a bug in 9.3 and 10.0 and was finally fixed some time after 10.0 release - so it should work fine in 10.1 ;-) I guess this fix also fixes the y2pmsh behaviour - it uses the same codebase AFAIK. Regards, Christian Boltz -- Wieviele Leute braucht es, um Windows zu installieren? - Sieben! Einen, der sich die CD leisten kann, drei die ausdiskutieren, wie man das wohl macht, zwei Priester, die beten, dass es funktioniert und einen Psychiater, der die Nervenzusammenbrüche behandelt!!!
participants (14)
-
Adrian Schröter -
Alexey Eremenko -
Boyd Lynn Gerber -
Christian Boltz -
Christoph Thiel -
Hartmut Meyer -
Henne Vogelsang -
houghi -
jdd -
Karl Eichwalder -
Ludwig Nussel -
Marcus Meissner -
Pascal Bleser -
Per Jessen