Quoting Cristian Rodríguez :

Sad to hear this non-sensical, redundant rules are trying to be enforced without any discussion.

This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history.

OBS history is a nice 'gadget', but mostly useless once it 'leaves' OBS (published repo, users install). Heck, it's even useless when SR'ing a package to any other project. the 'Update' changes are not a new request (and packages have been constantly rejected for this reason throughout the last 6 years I participate); with VERY few exceptions (some automagically updated packages, like the timezone database). Dominqiue -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 29 Aug 2012 17:52, Cristian Rodríguez wrote:

On 29/08/12 08:42, Dominique Leuenberger a.k.a DimStar wrote:

...

Dear Factory contributors and packagers,

As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be.

Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches

Sad to hear this non-sensical, redundant rules are trying to be enforced without any discussion.

This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history.

Increasingly frustrated, Cristian.

Think of the following: A package does an upstream update (say to 2.4.5). Now the package.chances gets some new lines: ===== 2012-08-28 update to version 2.4.5 * this obsoletes OSS patch1 and patch3 * this obsoletes SLE patch4 * generic (non-distro) patches [2,5,7] are obsolete * gcc 4.5 and clang 3.1 are now fully supported. * NEW patch8 b/c of off-by-one error in main.c ===== Ask yourself: is this info in: * NEWS (from upstream) - NO * Changelog (also upstream) - NO * package.spec - Not reliable and not visible from outside And best of all you can get this info via rpm on a compiled package. Those comments in the spec-file? NO chance. Yes, care and nurturing of the .changes file is work. But it is not for naught. I'm not trying to open the door by running headfirst in it. I agree that info that is in NEWS and Changelog should at most be referenced, not repeated. -- Yamaban.

El 29/08/12 12:37, Wolfgang Rosenauer escribió:

And just one addition IMHO: I _really_ want to see the package changelog before I install or update a package. This is still not possible w/o downloading and using rpm manually.

AFAIK work was done to allow zypper to display the changelog , dunno if it the implementation is ready though. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 08/29/2012 06:30 PM, Yamaban wrote:

On Wed, 29 Aug 2012 17:52, Cristian Rodríguez wrote:

Now the package.chances gets some new lines: ===== 2012-08-28 update to version 2.4.5 * this obsoletes OSS patch1 and patch3 * this obsoletes SLE patch4 * generic (non-distro) patches [2,5,7] are obsolete * gcc 4.5 and clang 3.1 are now fully supported. * NEW patch8 b/c of off-by-one error in main.c =====

Ask yourself: is this info in: * NEWS (from upstream) - NO * Changelog (also upstream) - NO * package.spec - Not reliable and not visible from outside

Or ask: this is Joe TheEndUser, just a normal average enduser, really cares or knows about the OSS patch1 and patch3 or SLE patch4 These should be in the SR request or better in the checkin phase where it makes sense to the maintainer/reviewer to have such info at hand I hope Andreas Jaeger is following this thread as this is exactly what I mean with the decision process I asked couple of days ago. First someone comes and says hey this is the decision and then people start discussing the cons and pros of the decision, much like Stuttgart 21 if you know what I mean. Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 2012-08-29 at 19:41 +0200, Guido Berhoerster wrote:

Making patch tags mandatory would be again very useful since they are easily machine-parseable and could be read and displayed in OBS in order to get a quick overview on the purpose and status of all patches of a particular package. Right now I'm using my own script to generate a HTML patch report for all of my packages. There are way too many packages which have obscure foo.dif patches without any explanation whatsoever neither inline, in the spec or changelog. This makes packages practically only maintainable by the person who created them.

I do agree as well on the PATCH- Tag line (the 'forces patchers to report them upstream' is a very good reason), but also know that there is a lot of resistance against this one (there were a lot of discussions around them). But, actually, it IS already specified as mandatory on the Packaging Guide Lines, so the review team might actually be instructed to take this one serious as well.. The goal of all those attempts is, as you correctly state yourself: have the packages easy (well, easier) transferable and any other willing contributor be able to step up without a too high learning curve (see for example Xorg packages (Stefan, no intention to question your work! It IS great): since it was split in smaller chunks of '1-tarball = 1 package' I have seen several more contributors to those packages; A package that was just scary to be touched before, except the maintainer. Somehow I hope that this also helps Stefan to focus more on 'interesting' parts than running after package updates (which are often for X.* packages after all). SO, yes, for '*old*' packagers, this might be a burden which does impose change for all of us, but ALWAYS think about new contributors. Anything undocumented is likely something 'new contributors' have no chance of picking up in reasonable time, and as a consequence they will not pick it up. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia środa, 29 sierpnia 2012 14:43:14 Cristian Rodríguez pisze:

Sending patches to upstream is a fine idea in theory, but unless you have the time and patience to register in a dozen of trackers, mailing lists and to provide a patch that will work on at least Linux, Windows, BSD, MAC OS, different kernel or library versions this only results in a burden that I personally do not want or care. I want openSUSE be better and working, that 's all I care about.

The openSUSE project cares about upstream. It is official. You are not going to make the distro better by detaching from the principles of the project. It may work that way for some time but ultimately it will backfire. IMHO, Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 2012-08-29 at 15:01 -0400, Cristian Rodríguez wrote:

Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't)

This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-)

Having patches in openSUSE is nothing bad / wrong (hint: Factory has > 10'000 at the moment!) but, as you state yourself: we do not have an army of coders: Who does take care of those 10'000 patches? Patches add an additional complexity to a package; besides the 'casual' contributor that is perfectly able to upgrade a package with a new tarball from upstream (with whom we try to have good relationships, as a project!), having all those patches requires every packager to be a crack in coding. Needless to say: excluding the casual contributors is WRONG! It makes our 'army' even smaller. We can't afford that. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 2012-08-29 at 15:14 -0400, Cristian Rodríguez wrote:

I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people.

I hope we are not measuring complexity or anything important by the number of patches are we ?

Of course it's not a 'measurement', it's more of an indication that we have 10'000 files which need maintainership by openSUSE. Actually, I found that talking to upstream gives you a LOT! Even patches that we carried for > 4 years in packages are just merged in upstream git bases after a few mails; the best? I (or anybody else touching this package) will NEVER ever have to rebase the patch again, having the optional chance for an error (yes, quilt is cool... but not magic). The openSUSE Project wants to be a good downstream and have relations with our upstreams (as much as we want to maintain a healthy with 'our downstreams', like SLEx for example). Passing patches around IS one of the strength of open source.. why should we kick it with feet and not care? Because it costs us 'five minutes now and saves us 30 in two years' ? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Aug 29, 2012 at 03:14:19PM -0400, Cristian Rodríguez wrote:

El 29/08/12 15:06, Dimstar / Dominique Leuenberger escribió:

...

On Wed, 2012-08-29 at 15:01 -0400, Cristian Rodríguez wrote:

...

Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't)

This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-)

Having patches in openSUSE is nothing bad / wrong (hint: Factory has > 10'000 at the moment!) but, as you state yourself: we do not have an army of coders: Who does take care of those 10'000 patches?

I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people.

I hope we are not measuring complexity or anything important by the number of patches are we ?

Are you actually sending your own patches upstream? The O_CLOEXEC ones at least are quite intrusive. Just wondering. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 29 August 2012 22:55, Cristian Rodríguez wrote:

El mié 29 ago 2012 16:23:50 CLT, Marcus Meissner escribió:

...

Are you actually sending your own patches upstream? The O_CLOEXEC ones at least are quite intrusive.

Just wondering.

Ciao, Marcus

To linux-only projects, directly, however to multi-os projects most are not, I dont have time to write the ugly and likely moire buggy wrappers that some projects use, in which O_CLOEXEC is tested at compile time and at runtime.

If you think there is a bug let me to know I will fix them.

Just to be sure. You didn't send them to libpcap and/or sox, true? Otherwise, do you have any link to a bugtracker so I can see upstream's feedback? Both are outdated in Factory and the patch doesn't apply cleanly any more to the latest releases (which are 3 and 7 months old). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Aug 29, 2012 at 05:50:12PM +0100, Cristian Morales Vega wrote:

On 29 August 2012 13:42, Dominique Leuenberger a.k.a DimStar wrote:

...

The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed)

More important than the .changes content IMHO is the "# PATCH-*" line. It forces people to report bugs upstream, and the reference to the bug report is priceless.

I don't see how you can *force* people to do something with this. It just means that the work done in the devel packages will stay there and not go into Factory. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting pgajdos@suse.cz:

On Thu, Aug 30, 2012 at 12:05:43PM +0200, Michael Schroeder wrote:

...

I don't see how you can *force* people to do something with this. It just means that the work done in the devel packages will stay there and not go into Factory.

Right. I will not resubmit packages declined for missing patch tag.

That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach? More correct would actually be that YOU as prj devel reviewer decline it BEFORE submitting to Factory.. openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult.. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Alin M Elena [2012-08-30 12:57]:

...

That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach?

More correct would actually be that YOU as prj devel reviewer decline it BEFORE submitting to Factory..

openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult.. let us start from saying I find the rules a on changes a little bit annoying, as they tend to duplicate what is already available and easy to be found by any curious user but that is just a simple annoyance for me...

quite few people react against this enforcement as it seems imposed in a very unilateral way, rather than discussed, and I agree with them...

I am not an adept of democracy or mobocracy but I hate dictates in equal measure...

We shall have a mature discussion on the process before trying to dictate a solution... The main problem we have with packaging is getting things accepted in devel projects and then pushed to factory... Why is that... if it is because of missing changes or tags for patches let us do become pedantic about the form of .spec files... but I am afraid that other are the reasons that the distro tends to be in a state with out of date packages...

In a several cases I'd like to have updated outdated packages but the number of non-upstreamed patches without any description would have meant the I'd possibly spend hours getting familiar with the code base and patches before I could rebase them. The "packaging bureaucracy" is a non-argument, the actual form of patch metatdata (whether inline or tags) is not that important either but adding a one-line description about the purpose of a patch and sending it upstream is not that much work. Not doing it hurts the project more than in the long run than the short term gain of saving a few minutes of a contributor. And that's also the reason why this is a policy for other distributions e.g. Debian [1] or Fedora [2]. 1. http://dep.debian.net/deps/dep3/ 2. http://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_a... -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Aug 30, 2012 at 7:27 AM, Dominique Leuenberger a.k.a DimStar wrote:

openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult..

Now now... is this mini-flamewar really necessary? A patch tag isn't "extremely difficult", especially since I've been asked to produce them in the past, and it takes the whole 5 minutes each one in this thread has wasted discussing it. Although I agree reporting things upstream is good, the guidelines do not force you to. I quote: """ If there are related bugs in Novell or other bugzillas, please add them, it will help us to get more accurate information. If there are two or more available then it's preferable to list both (or more). """ And I've seen patch tags without bug numbers accepted. So... if adding a comment line summarizing why you need the patch is "extremely difficult", someone's being picky. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Aug 30, 2012 at 8:53 AM, Dominique Leuenberger a.k.a DimStar wrote:

...

...

openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult..

Now now... is this mini-flamewar really necessary?

A patch tag isn't "extremely difficult", especially since I've been asked to produce them in the past, and it takes the whole 5 minutes each one in this thread has wasted discussing it.

Now you take me out of context :) I don't consider ADDING the line a difficulty (at all!), but actually a help for new contributors, when they look in a package and want to do work (like a simple update).

Not having the package properly documented is the 'extremely difficult' burden.

Lol, of course, you being the OP and all ;-) But the entire thread is saying the opposite! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Philipp Thomas :

* Claudio Freire (klaussfreire@gmail.com) [20120830 13:34]:

...

And I've seen patch tags without bug numbers accepted.

At least for those someone fluent in python should write a test for rpmlint.

As currently the Patch tag line is a 'encouragement' but not strictly enforced by all devel projects (and Factory for the matter), rpmlint will bite back badly here or you'll just end up with accepted warnings. Also, rpmlint can't really see if the patch is NEW (and as such should fall under the new guideline of patching, which is nor enforced yet), or not. Raising warnings (or even errors) on all 'wrongly annotated' patches will give you a warning on > 11'000 patches currently (of which only a small fraction has a tag line at all!) Also, the patch tagging / annotation has seen a lot of discussion in earlier threads. I know of currently three ways that are actively being used (with their pros and cons): - No tagging at all - 1 - Line tagging in the .spec file, next to the Patch<n>: entry - Full annotation in the .patch / .diff file. Projects that use the 1-line tagging do not exclude to have full annotation in the .patch file neither of course (often the case with patches extracted from a VCS / git). I personally prefer the 1-line tags (on any update of a package, I usually skim through the .spec anyway), but am fine with full descriptive .patch files (seen some 'rebase' work loosing the info though: so more care needs to be taken there). Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

2012/9/1 Křištof Želechovski :

Dnia piątek, 31 sierpnia 2012 13:55:06 Dominique Leuenberger a.k.a DimStar pisze:

...

Also, the patch tagging / annotation has seen a lot of discussion in earlier threads. I know of currently three ways that are actively being used (with their pros and cons): - No tagging at all - 1 - Line tagging in the .spec file, next to the Patch<n>: entry

That should be encouraged by the Web editor before it is imposed as a requirement.

The web editor is a pile of junk and should become un-available; It's not the first time I see people using the web editor to make packages, and this raises one question... Do the vast majority of those people actually test the packages ? :) I've actually found packagers with no openSUSE system installed maintaining packages on OBS...

...

- Full annotation in the .patch / .diff file.

I do not know how to do it with Kompare but you can make a source file comment instead.

Packaging has nothing to do with KDE specific software; Not everyone uses KDE... in most cases patches should be properly formed through git or svndiff... the sad truth is that no one gives a damn... Comenting the patches on the spec is actually nice and should be how it should work for everyone else; I wonder if professionals do question the rules or if they just follow them (imagine that your software is actually under quality management process that demands absurd things). So all this communism stuff, is really not wanted by many of us. Packaging is about DISCIPLINE, if people can't obbey to it we have chaos, anarchy and turmoil... We have our release team pounded with extra work, we break our workflow and everyone suffers from it.

From my perspective openSUSE should demand superior quality packaging from everyone, specially from the 'professionals' and not support the easy way out. But let me guess... we don't give a damn about quality ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting Claudio Freire :

And I've seen patch tags without bug numbers accepted.

This can be well accepted, in those situations: - The patch came from an upstream VCS; not all commits are done based on bugs; but this should be mentioned in the comment, something along the lines 'taken from upstream git' - The patch adjusts 'default settings': would be nice to have a feature / bug for tracking, but in reality they are often not arriving like this (think adding default RSS feeds to a news reader) - Upstream is dead; Note: up to now, patch tagging is not enforced in Factory (by the factory review team). There are various devel projects which do require it though. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Quoting pgajdos@suse.cz:

I hope you want to aply this rule only for newly created patches, not existing ones.

Yes, of course! I'd not ask anybody to go and find ANY rational behind the 11'000 patches in openSUSE Factory. Please don't waste your time on trying to figure out what some of the patches do. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, 30 Aug 2012 12:37:20 -0400 Cristian Rodríguez wrote:

Im considering option 2 , because option 1 seems like talking to the brick wall.

(Can't resist :) Deja vu. Do you recall systemd and some other discussions? It is just that you are now in opposition. The idea to use some description, useful for everybody, but also to those that don't speak C, C++, Java, Python etc, is not bad idea. It will allow to have first level packagers (like first level support) , that work per script (written instructions), not understanding the code too much, and then when problems can't be solved without looking at the code, issue is escalated to you and people like you. Wouldn't that make your life more interesting? More coding, more real debugging, instead of boring repetitive tasks. Or, I don't get what you like? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sun, 2012-10-28 at 14:01 -0300, Cristian Rodríguez wrote:

On 30/08/12 06:23, pgajdos@suse.cz wrote:

...

Right. I will not resubmit packages declined for missing patch tag.

Me neither, In fact I am considering not submitting anything at all anymore.

It is very sad that politics and bureaucracy have taken over.

This new policies are absolutely ridiculous and want nothing to do with it.

Free software should not be confused with Anarchy... it's not that our packaging guidelines are really tough... and sorry to say: 'packaging is a job to be taken serious' - which comes with maintainership. It's not the thing to be done 'next to the distribution'.. it is actually the task that forms and shapes the distribution (of course, together with the tarballs, which are even more important) And just on the topic: the patch tag has, so far, NEVER been a reason for a reject in Factory (can be handled different in different devel projects... some are a bit stricter on that). And just once more, 'slowly' for everybody to read: the documentation of patches is useful for a few aspects: - Lifecycle of a patch gives clear indication for other packagers when a patch was added and removed.. so it's always clear they are conscious about them.. I've seen a lot of patches 'dropped' (by just putting a comment sign) and nobody knew why or what.. until a bug came in and then oh wonder: that patch was just commented because it did not apply.. and nobody new... great 'team work' (which, by the way, could be seen as a different word for 'community') I for myself prefer having packagers submitting their stuff that take it serious, that are aware of what they are doing and that do not just consider this a playground. Otherwise, try to submit any 'hack patches' to any serious upstream project... best, make a 200 line patch for the kernel without any 'documentation' of why for what it is... I bet it won't be applied (git format-patch does produce some documentation based on your commit log.. that does not count here... I'd really challenge you to just send a "git diff" over). Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sun, 2012-10-28 at 14:38 -0300, Cristian Rodríguez wrote:

That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks.

I know you know better than that Christian.. BUT: OBS is not really a VCS... you know, I know.. everybody knows.. let's stop claiming the opposite.

It is so absurd that complyng with this rules takes more time than actually fixing a problem.

Packaging is a task of it's own... and, considering that I can update an entire gnome stack in < 2 days (which is ~ 200 packages!) I don't think those 'rules' are that difficult to honor... in fact, they just ask you to write down what you do... I know, documentation is NOT exactly what devs like.. but without it, we're just lost. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 10/28/2012 06:41 PM, Dimstar / Dominique Leuenberger wrote:

On Sun, 2012-10-28 at 14:38 -0300, Cristian Rodríguez wrote:

...

That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks.

The OBS knows but your other fellow packagers have no clue what that patch is for if there is no patch tag.

...

I know you know better than that Christian.. BUT: OBS is not really a VCS... you know, I know.. everybody knows.. let's stop claiming the opposite.

...

It is so absurd that complyng with this rules takes more time than actually fixing a problem.

Packaging is a task of it's own... and, considering that I can update an entire gnome stack in < 2 days (which is ~ 200 packages!) I don't think those 'rules' are that difficult to honor... in fact, they just ask you to write down what you do... I know, documentation is NOT exactly what devs like.. but without it, we're just lost.

I would actually advocate that even in devel projects of packages that are part of factory. if the submitted package has patches and the patches are not neither tagged in the spec, nor have a header that briefly describes the purpose of the patch should be declined until they meet the patching guidelines. Because if I as a contributor would like to update the package either to a newer version or fixing some broken build; if there are no patch tags in the spec or no header in the patch, I am spending time to figure out what does that patch do and in newer versions why the patch fails. In my opinion following patch guidelines is not bureaucracy nor absurd but courtesy towards other contributors. Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia niedziela, 28 października 2012 14:01:04 Cristian Rodríguez pisze:

On 30/08/12 06:23, pgajdos@suse.cz wrote:

...

Right. I will not resubmit packages declined for missing patch tag.

Me neither, In fact I am considering not submitting anything at all anymore.

Submitting packages that get rejected does have sense, in that the mainainers know that the problem has been fixed and can apply the required procedures themselves. This is what happened to the Polish translation of the openSUSE license agreement: accepted with a problem, the workaround rejected but adapted by the maintainer without any further contribution on my part. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 12:27 AM, Jan Engelhardt wrote:

Patches should be required to carry a description, akin to the what (many, but not all of,) kernel-source/patches.*.tar.bz2#*/* do:

ACK. That also holds for grub2 for some time. And it should be the case for all project with more than one simple patch. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQP88EAAoJEL0lsQQGtHBJdcQP/jv35/vwvbEY5q/6NETrij6m Vy+P3OXdjtXt6SvpYww3hr3S+fq3H/bRBj7CbQynL6IEUkv79hYQq3yHjy991reI 20lX1i8ZeRpLVv06/fREW4Lay0ZuB5m6UKyV0cRVrPrPw4OXN6weyfF2KwxnA9Un gR80iGQ6urKWgRKKPdAR5QakFA19p6W05RH955lr/lKHVwQOrt3pFUaz2YqdvJ1N 0h+1pk3W010tE5NSW43N+Nbyha1XQT2ED5CZKUFvwN5IKRxJW1NjstKVvN1qKUzH Z9IZJ1hJNqe3LOpGqrKSRhwMle3XTLb2BIgsYvL2mtr+x9VCd3+BqZueP6XOhqC4 s0Y+fNomQoYr7FtxolrKSqKHhmK56OdOvo2B30M82Y37iJyX/flaPV3NevIJKv37 QRNbZOZHiMk/yHicYe7vN5G4J+V9sbZwS/WEVA4bjU5ZrvLChlSKsRYZMsM9vP9B jhhqHrSQD0iiAiXbfJ8oslmPUJ7kvBPRdBHx4Ic+HP9zOtkws9I/gh9ZQBI9QjSw 6q9szJhDYeeffsUChFRmM+992EBvfQw0iJRxoMEswVx4IFVy+opOY01SEDThdNZH LFvFvxzxMdSaERv7cgVa6leFRk4Fe4VNwhA+uTpiarhW4NUlSBf70+L0bLzJXs+u +naq9Vs9SR0dRpzDGplP =Q0IZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Aug 30, 2012 at 02:06:25PM +0200, Dominique Leuenberger a.k.a DimStar wrote:

+ Update to version 3.41: - A new get_robust_list(2) page documents the get_robust_list() and set_robust_list() system calls. - Three new pages ? mallinfo(3), malloc_info(3), and malloc_stats(3) ? document various interfaces used to monitor the state of the malloc implementation. - The madvise(2) page adds documentation of the MADV_DONTDUMP and MADV_DODUMP operations

Ok, I will use head -n 15 for it :-]. Petr

On Thu, Aug 30, 2012 at 02:19:38PM +0200, Dominique Leuenberger a.k.a DimStar wrote:

that's one option.. or really just reading the release announcements might do an even better trick: http://linux-man-pages.blogspot.nl/2012/05/man-pages-341-is-released.html

(btw: sometimes not just copy-pasting that stuff but actually reading and understanding it, can give you as a packager also hints about new / obsoleted optional BuildRequires.

Wow, good shot. Hats off, Petr

On Thu, Aug 30, 2012 at 10:37:40PM +0200, Jiri Slaby wrote:

Instead, I would prefer rpm changelog generated from osc log, where some minimal info would be required (and bug numbers requisite).

Oh god, that's like saying you want to generate the NEWS file from the git commit log.

And also the rpm proper should contain an osc rev.

It has the 'srcmd5', a rev doesn't exist for linked packages. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Aug 31, 2012 at 9:40 AM, Jiri Slaby wrote:

...

Oh god, that's like saying you want to generate the NEWS file from the git commit log.

I meant nothing less than: rpm -q --changelog kernel-desktop

That kind of thing only makes sense. This is actually a changelog.

That's not really true. That only makes sense when the git/svn/vcs log indeed contains descriptive entries. OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline, for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good. On the other hand, OBS vcs changelogs also contain SR descriptions when SRs are accepted. That would in fact make for a good changelog. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Aug 31, 2012 at 11:17 AM, Jiri Slaby wrote:

...

OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline,

Well, if somebody commits via web-ui, I doubt they change the .changes file. The discipline is needed in both separate-.changes and osc-log cases at the very same level.

There is a very neat button when editing .changes files in the web-ui, that says "add changelog template". It makes editing .changes with web-ui as easy as "osc vc". I use it when I'm "osc"ing in debian, since debian's osc doesn't support the "vc" thing. It beats "echo date -U blabla" >> blah.changes every time ;-)

...

for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good.

Mistakes happen, even in the kernel log where we cannot undo them. This is the case in any vcs maintained project. And we live with that, your argument looks to be odd in this case.

Interesting. And how do you handle that? How do you fix the changelog in those cases? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Aug 31, 2012 at 11:29 AM, Jiri Slaby wrote:

...

How do you fix the changelog in those cases?

No way. It's set in stone. We just have to live with that...

Well, maybe that works for kernel developers (ie: seasoned developers), but I don't see *all* OBS users exhibiting that amount of discipline. We could, however, do the SR comment --> .changes entry thing as an option for "request accept". On Fri, Aug 31, 2012 at 11:35 AM, Jiri Slaby wrote:

...

But the changelog's purpuse is to tell the user why he should install/update a package.

I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?

I do. I read them usually *after* I install updates, only because I have no easy way to read them before. Debian lets you read the changelog *before*, and almost everybody I know that uses debian reads it. Everybody I know that uses debian is tech savvy, so it's a biased sample, but it's still an important sample if you ask me. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Aug 31, 2012 at 3:15 PM, Jiri Slaby wrote:

...

I do. I read them usually *after* I install updates, only because I have no easy way to read them before.

Debian lets you read the changelog *before*, and almost everybody I know that uses debian reads it.

You all do not run unstable, right? And you do not maintain multiple servers with distinct OSs, do you?

I have debian unstable on my own work computer (and, granted, I rarely read changelogs in debian unstable). I have a few servers with debian stable, and I do read changelogs there. There's also some RHEL and CentOS - whenever possible, I don't manage them, but those that do do read changelogs (the hard way, because those have the same problem as openSUSE). I have openSUSE at home, and I read changelogs there. I have a few community repos on, and I do read changelogs when they have updates. Released versions of openSUSE tend to receive updates through patches, which already provides a description of the changes, and it even classifies them as recommended, security and whatnot. That's very useful, and is absent on community repos (which usually don't generate patches). There, the only thing left are the changelogs. Especially for mesa, which is quite critical. I have to go to OBS and check the changelog there so that I may know what changed before installing.

And no, I'm a debian user, run debian on several servers and definitely do not have time to read changelogs, no.

So you install updates blindly? I'm glad you trust debian that much. It's not our case, and it's not the case of many people I know. So the use case exists and isn't trivial, nor a niche.

...

Everybody I know that uses debian is tech savvy, so it's a biased sample, but it's still an important sample if you ask me.

Ok, let me ask again. What actually it gives you?

Note that I'm not against *removing* changelogs. I only think that maintaining .changes files is tedious and does not really work.

It lets me gauge whether an update is necessary, worth the risk, or not. Updating stuff is always a risk. Minimal on stable repos, considerable on community repos. Having the changelog available lets you decide better. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am Freitag, 31. August 2012, 11:09:56 schrieb Claudio Freire:

On Fri, Aug 31, 2012 at 9:40 AM, Jiri Slaby wrote:

...

...

Oh god, that's like saying you want to generate the NEWS file from the git commit log.

I meant nothing less than: rpm -q --changelog kernel-desktop

That kind of thing only makes sense. This is actually a changelog.

That's not really true.

That only makes sense when the git/svn/vcs log indeed contains descriptive entries.

And entries would need to be classified. Some of the entries would be just for co-developers and some others for users. Not everything from the vcs source log should be shown to the user, he should get a descriptive changelog ...

OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline, for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good.

On the other hand, OBS vcs changelogs also contain SR descriptions when SRs are accepted. That would in fact make for a good changelog.

-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 04:27 PM, Michael Schroeder wrote:

On Fri, Aug 31, 2012 at 02:40:29PM +0200, Jiri Slaby wrote:

...

I meant nothing less than: rpm -q --changelog kernel-desktop

That kind of thing only makes sense. This is actually a changelog.

That makes sense if the target audience are developers.

Why do you think so? (see below)

But the changelog's purpuse is to tell the user why he should install/update a package.

I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why? Yes, they may care in case they monitor if some their issue was resolved, but that info is available elsewhere. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQMugAAoJEL0lsQQGtHBJDnYP/jRCwMIi/SRMnzTXtQfWlFAc D7Og9q2TCUnWxQbVFkdTkuslVZjwGcYYzQz3epM7payqD1YpLHPb8w0V312tLurJ Gq0YGnUtqfL4dkU+SRMjwckcVbJsssig5RzPDXH+w+y9+O3QcGfctMrjTOun8mFl 6aJCR9dsdtzvjWSfix7PMd9WgHy9LTSDAsN3hEwv+j1vyJUrkAFuAhko7ko0wZno 0xoe+tTLTzhaZbiNJ9uT08C7xGwBcpmLU3S0V/Dx9e8dyR12jM+0ZUI/lTvIkuNW aoqUl0Hcy7Qyibc8Q4zBMBzDu8VqHnlezzyaiI+wj2Cof4HZiWosO+Xf4fCRPLf1 ul2YfM7wQHtoHMgH9OSRiTCDVwIEwJ/R6XVxCtWw+slotuKIvEXxRswN8tDC0w0s XPk0qjw4d0Z3en0VchAyHehL+6p9R+osHHqFMInHjZa2XTupVxlJ4jk8gJPP/mqq TvlqsXYw9DkSubGaz6NfrCuMlrRSvYCD/8NG3Xa1AF7l31xmlJ7GQkv5bRuRMfr1 b10pd+is+yf88CCA4JiW+t5dLWUgqLIqVufHYTooL08za3CAuL1xAwO5zqVSmbRb Qq61YUdlXGDeQKGeT39CH+qVRlcIroJp6omYvHdfLhhBsFU0DpinSXlwNbUXHAhR uXcgMcv1UVDka8EK0XN6 =OM6J -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 05:03 PM, Michael Schroeder wrote:

On Fri, Aug 31, 2012 at 04:35:12PM +0200, Jiri Slaby wrote:

...

I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?

If they wouldn't care, how do you explain the requests to make yast show the changelog of packages?

That unfortunately still does not answer the second part of my question. If I demanded yast to show packagers for non-installed packages, would you tend to implement that immediately? I don't think so. Hence I asked *why* they need that and if it won't be enough what I suggested? regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQP3YAAoJEL0lsQQGtHBJtggP/iUMzNb9W/exGtnIwyAY3nZE JBotDYT5K7qhzIpTk6TUXe4w7zBDdpqUEGKLflKge3Ounngxz69vjG/L4ywp/gXH Bda5775P3T+8HZulN93a08BML6tgYiGvvKkrVK6tQSz2UCTq8IrgsNObatFmx5hU fFBCQoWY6VpqOhBrdMlx/BhtpYs0eg2PXN8sNQ5KN8dj6PXP53M6Tl9XMM4bdtzH knTwuRqGoMPTYPdk8uc7bv859hFe54La2Nr+TNe0XipiPP7sJOC4vOtdsETb/kAT dKZJzlTCmubzrkEEd/3tuGyLxFXQtsDVC16WWDOf/wNh7HhBq15iGY3sOZvbe7G/ hvINAu05PqO+81Yz9uOZOAvXzkqLy6jl6oQCRT+6xrthrUjTqESGrXHp+teJIGkO yf5SzibYaJ9SGS3iHBTmyPzz8gtSDmkfW1BMZmaq6Jz/MrK1Qyb1efy7XwB/Fa7C I8OSzN0gi1aq1uqv6hNJG3Xl6tjgESD3FmWqj0CJ34WPujFkZgS3HtjCHSUYDsE5 /eMmviJLp10ecovgYU43ErVFYMPT3IT6u1xvAZ5YAOL/XCs60Cvmh1+nflTDaAT2 CTTxGfR5JqpqNkzdyx1x+FfWV+xGP8VusZCJf7wBK9EFaXvoHvzu8DhNJDIujBNQ OcfKLhAsmsYvph4MGm6c =R1y9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jiri Slaby writes:

Michael Schroeder writes:

...

But the changelog's purpuse is to tell the user why he should install/update a package.

install: no, that's in the description (and in /usr/share/doc/packages/*/NEWS or /usr/share/doc/packages/*/README) update: yes, you will mention applied (security) patches, etc.

I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?

No, I completely agree with you. rpm changelogs are a source of info for all of us who are involved in packaging. Tracking general changes in the rpm changelog is a mis-conception.

Yes, they may care in case they monitor if some their issue was resolved, but that info is available elsewhere.

I'm not that sure, or I do not understand what you actually mean. I think referencing bug numbers is something for the rpm changelog. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, 6 Sep 2012 11:12, Michael Schroeder wrote:

On Thu, Sep 06, 2012 at 10:21:02AM +0200, Karl Eichwalder wrote:

...

Jiri Slaby writes:

...

Michael Schroeder writes:

...

...

But the changelog's purpose is to tell the user why he should install/update a package.

install: no, that's in the description (and in /usr/share/doc/packages/*/NEWS or /usr/share/doc/packages/*/README)

Oh, is that so? And how do you access that information if the package is not installed?

Now THAT is a failure of the used packaging tools (RPM), not that DEB is better, but this is a general failure of all those tools. These tools where simply NOT made with regards to such information requests. Do not blame the packagers for the tools they are forced (by management) to use. I'm open for the introduction of better tools. But this henpecking on failures of the tools? -- helpful it is _NOT_. -- Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:

I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.

Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi, On Thu, 6 Sep 2012, Karl Eichwalder wrote:

...

Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?

No, just copy it to a repo meta file.

That needs conventions. .changes is a convention. A random file whose name contains at least one capital (I have seen NEWS, README, README.md, CHANGES, ChangeLog, Readme and ReadMe in this thread alone) is not a convention, sorry. How anyone could seriously suggest that an interested person should go hunting for random files in /usr/share/doc/packages/$name/SoMeWhErE instead of using _one well defined way_ is beyond me. If it's in .changes or somewhere else doesn't matter that much, but it must be in _one defined place_ for all packages. Currently that one defined place is the rpm changelog, generated from the .changes file. Note that the current policy is nothing new. This whole bruhaha thread is coming about five years late. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, 6 Sep 2012, Michael Schroeder wrote:

On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:

...

I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.

Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?

The package description should contain enough information to tell whether the package is worth installing. The changelog is also not available without downloading the package (at least I hope so ...) Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, 6 Sep 2012, Michael Schroeder wrote:

On Thu, Sep 06, 2012 at 01:42:25PM +0200, Richard Guenther wrote:

...

On Thu, 6 Sep 2012, Michael Schroeder wrote:

...

On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:

...

I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.

Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?

The package description should contain enough information to tell whether the package is worth installing. The changelog is also not available without downloading the package (at least I hope so ...)

Wrong, the changelog is in the repodata.

I hope you are wrong ;) (yes, there is a reference to it) Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 8/31/2012 8:40 AM, Jiri Slaby wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 08/31/2012 11:43 AM, Michael Schroeder wrote:

...

On Thu, Aug 30, 2012 at 10:37:40PM +0200, Jiri Slaby wrote:

...

Instead, I would prefer rpm changelog generated from osc log, where some minimal info would be required (and bug numbers requisite).

Oh god, that's like saying you want to generate the NEWS file from the git commit log.

I meant nothing less than: rpm -q --changelog kernel-desktop

That kind of thing only makes sense. This is actually a changelog. The only valid thing in RPM changelog is information about * version update * patch removal/addition * spec file change * maybe some info of other changes

Other packagers' written stories about added/removed features are useless for the reasons mentioned earlier.

I agree that rpm changelog should only be _required_ to talk about the packaging of the software, not the software itself except those changes added by the package, ie patches and whatever the patches do. It's even a messy distraction to see stuff in rpm changelog that is about the software itself. When you say "version x.y.z", that along with the already required link to upstream source, covers all changes in the software. And if it _doesn't_, it's unreasonable to ask a packager to audit the code and supply info that upstream didn't. It's also unreasonable to ask why update if you don't have a good changelog from upstream. So either way it's basically just clutter when stuff from the packages changelog is present in the rpm changelog, and an unnecessary burden in many cases, and likely to simply be wrong or incomplete in many others if you make it a requirement. rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream. At least these days that would be the most sane for me. Maybe the changelog feature was originally added to rpm to hold essentially the softwares changelog, but I don't think that's the best use for the feature, especially not now when packagers are distinct from authors. -- bkw

regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQQLC8AAoJEL0lsQQGtHBJ8uMP/0e0tbW9ZjORZTM+ACh91n+6 cabS1wj5uJ9ZSISOUjI2sv8AfbPk7DgbJ0mt/HRBlHaMthBtQPray+ybilqR2qGI yBthkqNry27uskZD1ZP9kfDdRuMY65YW75b6zNDWmIKSYqoGtjhukuCKGXsFnWMc JRt2KfZfs1z6CeKcxRaGygRpzOQNTF6JMxPEVf61/5s6XLU70UfAtR7KI0sAo+cK inq6/zJDKWepNF+ds3R4mrIxJAMnyaI/aEe9UMQzt3eJPXZMdeHaRXkHZwzPQRA1 vlDWUQVGcOoabXMgNNSmUs+kCRDWddRQFxpaMvZRvqsF7ctxY1CsLYzEZnlr+lmT z4HQXE2NJVCYUDD8uVuFzeHtO+l9UjRTehZljK8W06uRRz0jvbmCaWf7LT0FxkBK 6FoFqpUcXho3CbsBZ96NsJylrceK1BpqqxZE7Xi6Z+E531xAvDP5obHxtg13mB6/ DRl8HYoPkZHT8DqZG8pFiJ8kyOrZi9B2sUHFGKSxZ2aXHwHFr/pE8770tL8nDGtG QxNY3BhjNC/C16tlC2AHE4YxzPv2YgAVYBbVy7hoYlDM9lFE5nl456ZmKhg4srX+ nJ37n0bLhZPtlJzQ9mZaYCGYahqUoSjTdLaZvrCFr7bUIDzFtHLI+O5hUqKgY7IL nDixySK8ndp8rHAjkgla =UmQV -----END PGP SIGNATURE-----

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sat, 1 Sep 2012 18:49:59 -0300 Claudio Freire wrote:

Practicality would then *suggest* to make rpm changelogs a little bit about the software too.

That is what is proposed by Dominique in the original post, but what Brian and few other are asking is to keep change log as a technical information. There is a lot of places where other info can be obtained and polluting log with it will not help packagers to find what has to be done for new version of software. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Michael Schroeder wrote:

On Sat, Sep 01, 2012 at 03:34:36AM -0400, Brian K. White wrote:

...

rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream.

That's because you're a developer/packager, if you'd be a user who doesn't know about packaging you would demand some info about the functional changes (plus the security changes).

For user visible docu we have the patch descriptions. Since those descriptions are compiled from the changelog entries I agree that the changelog should contain at least some notes about important function changes or new features. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

"Brian K. White" writes:

I agree that rpm changelog should only be _required_ to talk about the packaging of the software, not the software itself except those changes added by the package, ie patches and whatever the patches do. It's even a messy distraction to see stuff in rpm changelog that is about the software itself.

+1 [...]

rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream.

At least these days that would be the most sane for me. Maybe the changelog feature was originally added to rpm to hold essentially the softwares changelog, but I don't think that's the best use for the feature, especially not now when packagers are distinct from authors.

I do not even think that the rpm changelog feature was initially meant to list any software changes, but just the packaging changes. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Aug 30, 2012 at 4:38 PM, Cristian Rodríguez wrote:

"The preferred patchlevel is -p1 as it makes importing using tools like quilt more straightforward."

Really ? according to whom ? been using quilt for years with -p0 with no problems at all... the only thing that will do is adding more characters and flags to the already ugly spec files...

Regardless of that, I find -p1 patches easier to generate when working with tarballs. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 30 August 2012 20:38, Cristian Rodríguez wrote:

"The preferred patchlevel is -p1 as it makes importing using tools like quilt more straightforward."

Really ? according to whom ? been using quilt for years with -p0 with no

According to Jengelh -> http://old-en.opensuse.org/index.php?title=Packaging%2FPatches&diff=119213&oldid=119212 And it's the problem with the "the guidelines say so" argument. It's a wiki, anybody can change it without any previous discussion. Last time I read them it didn't say the -p1 was preferred and I don't remember a single line discussing it in this mailing list. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia piątek, 31 sierpnia 2012 13:31:45 Philipp Thomas pisze:

* Dominique Leuenberger a.k.a DimStar (DimStar@openSUSE.org) [20120829 14:42]:

...

A simple "Update to version x.y.z" is, as before, not accepted.

What is when there is *no* nor no usable info in the package about the changes? Perfect example are some of the packages that comprise OFED (publicly accessible in OFED:Factory). It's nearly impossible to get useful info on the changes and I will not try to scan a ChangeLog with the detailed changes and try to condense them into something usefull.

...

Most prominent is likely the mentioning of the patches life cycle,

The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.

That would require patching Kompare so that it allows adding that sort of annotation to a patch. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia sobota, 1 września 2012 17:44:52 Jiri Slaby pisze:

On 09/01/2012 12:44 PM, Křištof Želechovski wrote:

...

...

The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.

That would require patching Kompare so that it allows adding that sort of annotation to a patch.

No it would not. It should already handle patch-like patches, i.e. with header, right?

The problem is Kompare cannot *produce* patches with headers. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dnia wtorek, 11 września 2012 03:29:36 Jan Engelhardt pisze:

On Sunday 2012-09-02 13:37, Křištof Želechovski wrote:

...

...

...

...

The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.

That would require patching Kompare so that it allows adding that sort of annotation to a patch.

No it would not. It should already handle patch-like patches, i.e. with header, right?

The problem is Kompare cannot *produce* patches with headers.

Producing patchces is inherently a user task, as Kompare cannot know what the patch is for.

I think this problem is soluble, in that it should be possible to tell Kompare what the patch is for. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org