On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:

- new "search" command

Stupid question: would a patch seem useful to add an option, which prints out URLs to the project directories on the download server?? Like this: poeml@batavia510 ~ % osc search --repos-baseurl quilt No matches found for 'quilt' in projects #################################################################### matches for 'quilt' in packages: # Package # Project # URL stgit devel:tools:scm http://download.opensuse.org/repositories/devel:/tools:/scm/ stgit openSUSE:Factory http://download.opensuse.org/repositories/openSUSE:/Factory/ quilt openSUSE:Factory http://download.opensuse.org/repositories/openSUSE:/Factory/ quilt home:fseidel http://download.opensuse.org/repositories/home:/fseidel/ stgit home:tiwai http://download.opensuse.org/repositories/home:/tiwai/ quilt Ports:DebianBased http://download.opensuse.org/repositories/Ports:/DebianBased/ quilt devel:tools:scm http://download.opensuse.org/repositories/devel:/tools:/scm/ quilt Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ gquilt Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ guilt Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ stgit Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ quilt-el Ports:DebianBased:Auto http://download.opensuse.org/repositories/Ports:/DebianBased:/Auto/ Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Thu, Jul 26, 2007 at 05:50:21PM +0200, Bernhard Walle wrote:

* Dr. Peter Poeml [2007-07-26 17:42]:

...

On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:

...

- new "search" command

Stupid question: would a patch seem useful to add an option, which prints out URLs to the project directories on the download server?? Like this:

I'd like some functionality that also prints the full RPM URL. Like when I specify openSUSE_10.2 and x86_64 then I'd get all URLs that can be used to install the package. ;)

I had you in mind with that ;) but for a full binary list, I think it would be better to add a specific binarysearch command which could be used to search for binaries (only in certain repositories, maybe). FYI, the api provides functions for listing binaries, and to download them. It is just a matter of defining a useful user interface this! Moreover, I think it would be good to have some kind of "repo mirroring" script which syncs a repository to the local filesystem. It would be very useful for developers who want to test stuff locally before publishing to the users. Thinking of reposync (part of yum-utils) -- which needs to be changed to work with remote buildservice repositories (instead of yum sources configured in the system, which is what reposync requires). Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Thu, Jul 26, 2007 at 07:23:44PM +0200, Adrian Schröter wrote:

...

would be better to add a specific binarysearch command which could be used to search for binaries (only in certain repositories, maybe).

or based on certain repos like only on openSUSE:10.1 or only on KDE:KDE4/openSUSE_Factory . This is something what Andreas is implementing in the end user web interface ...

Great! A projected osc command could, by the way, also guess the installed distro of the system it runs in, and find just the appropriate binaries...

...

FYI, the api provides functions for listing binaries, and to download them. It is just a matter of defining a useful user interface this!

Moreover, I think it would be good to have some kind of "repo mirroring" script which syncs a repository to the local filesystem. It would be very useful for developers who want to test stuff locally before publishing to the users.

yes ! you read my mind :)

No, you mine ;)

...

Thinking of reposync (part of yum-utils) -- which needs to be changed to work with remote buildservice repositories (instead of yum sources configured in the system, which is what reposync requires).

Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Aug 9, 2007, at 1:38 PM, Dr. Peter Poeml wrote:

Hi,

I recently implemented a different commit method in osc, when I added the -m/-F option:

On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:

...

- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.

Did anyone test this?

works great here

(Either by setting "do_commits = 1" in .oscrc, or by using commit -m)

commit -m

I would like to make this the default behaviour, but I'm hesitant as long as I fear that I'm the only one testing this.

nope - just hadn't needed to update the package for a while. one question... how will updates made via the web interface be handled? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On 8/13/07, Andrew Beekhof wrote:

On Aug 9, 2007, at 1:38 PM, Dr. Peter Poeml wrote:

...

Hi,

I recently implemented a different commit method in osc, when I added the -m/-F option:

On Mon, Jul 16, 2007 at 07:47:32PM +0200, Dr. Peter Poeml wrote:

...

- commit: - commit: implemented -m and -F option for the commit message. NOTE: if -m is used, osc uses a different mode of uploading files and commit them, namely the way which is currently documented in the api. So far, osc was uploading each file separately through the old backward compatible way. This way of committing can also be forced with do_commits = 1 in .oscrc.

Did anyone test this?

...

(Either by setting "do_commits = 1" in .oscrc, or by using commit -m)

I've set "do_commits = 1" in .oscrc, everything works great, i haven't noticed any difference from without that line, should there be any? Cheers -J --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:

...

I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?

works great here

Cool, thanks! I'll make it the default later today.

one question... how will updates made via the web interface be handled?

Not sure what you mean with "updates made via the web interface", could you explain please? Do you mean, with regard to committing / commit message? Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Tue, Aug 14, 2007 at 10:37:41AM +0200, Dr. Peter Poeml wrote:

On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:

...

...

I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?

works great here

Cool, thanks!

I'll make it the default later today.

I would like to hear your opinion about something. Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional. The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does. Or if the current behaviour should remain. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Tue, 14 Aug 2007, Dr. Peter Poeml wrote:

Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.

The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.

Or if the current behaviour should remain.

I would vote for enforcement, but there are some other things related to this: a) The webinterface commits currently have no commit message: adding new files, deleting files, editing files b) Commit messages are only useful, when the RPM changelog can be built with the help of these messages somehow automatically. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, Aug 14, 2007 at 12:48:53PM +0200, Dirk Stoecker wrote:

On Tue, 14 Aug 2007, Dr. Peter Poeml wrote:

...

Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.

The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.

Or if the current behaviour should remain.

I would vote for enforcement, but there are some other things related to this:

a) The webinterface commits currently have no commit message: adding new files, deleting files, editing files

Indeed.

b) Commit messages are only useful, when the RPM changelog can be built with the help of these messages somehow automatically.

I think they should kept separate (or at least this behaviour should be made optional). I regard the commit log as something which may not be what I want to end up into the rpm changelog. I may need many iterations until I get a package to build on all targets, and I would clutter the rpm changelog with those changes. Just like the rpm changelog is usually not the same as the changelog of any upstream source code repository. For example, IMO it makes sense to the Apache webserver package that there are really three changelogs: - the upstream svn changelog (also packaged as CHANGES in the packages) - the buildservice commit log (making transparent the work of the packager) - the rpm changelog (documenting user-visible end results) Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

Dr. Peter Poeml schrieb:

[...]

Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.

The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.

Yes, it should be enforced, else it is too easy to enter no commit message which is always bad. Another question how such a message would be related to some changelog inside of the package. Maybe it is possible to have another option (Say -M) that tells osc to reuse some information from there.

Or if the current behaviour should remain.

Cheers Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Aug 14, 2007, at 12:40 PM, Dr. Peter Poeml wrote:

On Tue, Aug 14, 2007 at 10:37:41AM +0200, Dr. Peter Poeml wrote:

...

On Mon, Aug 13, 2007 at 03:26:42PM +0200, Andrew Beekhof wrote:

...

...

I recently implemented a different commit method in osc, when I added the -m/-F option: Did anyone test this?

works great here

Cool, thanks!

I'll make it the default later today.

I would like to hear your opinion about something.

Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.

The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.

I believe this is the correct approach. Project membership is rarely static and as such we really should be telling those that came after us about the changes we're making. And for personal projects, its a good habit to get into anyway :-) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Tue, Aug 14, 2007 at 12:55:30PM +0200, Herbert Graeber wrote:

Dr. Peter Poeml schrieb:

...

[...]

Now that it is possible to specify a commit message, should that be enforced by the user interface? Until now, the -m <msg> argument is optional.

The question is, whether "osc commit" should open $EDITOR if -m is not used. Just like svn does.

Yes, it should be enforced, else it is too easy to enter no commit message which is always bad.

Another question how such a message would be related to some changelog inside of the package. Maybe it is possible to have another option (Say -M) that tells osc to reuse some information from there.

osc would not be the place to implement this, as far as I can see. It would rather be the build service backend which could be configured to (principally) reuse the information from the commit log when adding to the rpm changelog. Or, it is also conceivable that osc takes the string which is specified via -m, and inserts it at the top of the .changes file and commits that. Or vice versa -- it could use the top entry of .changes as commit message. Personally, I think the latter makes most sense. What do others think? I may be a little Novell centric here. I'm not sure how widespread usage of a .changes file is, though. We might want to establish that, first... it is pretty much standard inside Novell, because the internal build system enforces this. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Thu, Aug 16, 2007 at 03:45:32PM +0200, Dirk Stoecker wrote:

Hi Peter,

...

...

Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.

You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.

Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?

Would be very helpful I think.

And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.

Regarding the webpage:

The Add-file and edit-file pages could get a box for commit messages as well as checkmarks for the Tags I introduced here :-) Leaving only deletes without message.

Did you think about this suggestion?

Think, yes, come to a conclusion, no, Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Fri, Aug 17, 2007 at 08:58:20AM +0200, Dirk Stoecker wrote:

...

...

...

...

Of course it can make total sense to derive the rpm changelog automatically from the commit log, in certain cases -- I agree on that.

You are right. Nevertheless I'm too lazy to change my RPM packages (especially as I hate the syntax). But I'm used to have -m due to svn and cvs.

Probably the solution could be a tag system like the one used in KDE. Adding e.g. "CHANGELOG:" to the commit message to have it in the RPM changelog?

No, I don't think that this is a good idea. An overkill mechanism IMO, and it'd only make sense if you work exactly in the way and order you assume here...

...

...

...

Would be very helpful I think.

And when having Tags, we could also implement "NOREBUILD" to prevent a rebuild e.g. when checking in new files and before I had the chance to edit the .spec.

Doesn't make sense to me. The basic idea does, but that should rather be an optional query argument sent to the api IMO, not a "magic" part of the changelog. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development