Glenn,

You seem to have done the work. Why not just submit your package to the development repo?

Ie. The normal approach to updating a package you don't maintain is:

Branch a copy of development project to home project.

Update/test in home project.

Submit updated package back to development project .

Greg

Hello, Steps done: 1. Branched package system:packagemanager / smart 2. Added in newer package updates , amended spec file - smart (Project home:doiggl:branches:system:packagemanager) Question: How do I submit updated package back to development project ? system:packagemanager / smart Thanks Glenn Options on the page I see are: Branch package Submit package Edit description Delete package -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Mon, Sep 23, 2013 at 6:35 PM, wrote:

...

Glenn,

You seem to have done the work. Why not just submit your package to the development repo?

Ie. The normal approach to updating a package you don't maintain is:

Branch a copy of development project to home project.

Update/test in home project.

Submit updated package back to development project .

Greg

Hello, Steps done: 1. Branched package system:packagemanager / smart 2. Added in newer package updates , amended spec file - smart (Project home:doiggl:branches:system:packagemanager)

Question: How do I submit updated package back to development project ? system:packagemanager / smart Thanks Glenn

Options on the page I see are: Branch package Submit package Edit description Delete package

From the GUI:

In the upper right corner you should see "could have a link diff". I typically click that and review all of my changes. If they all look good at the bottom of the page full diffs is a submit button. In your case your changes file is a little weak: =============== ------------------------------------------------------------------- Wed Sep 10 14:22:37 CEST 2012 - update to version 1.4.1 - add smart-245344-takes_long_computing_upgrades.patch =============== First, has it really been a year since you did the update? Second, you should have your e-mail address after the date. Look at the other change entries to see the syntax Third - It is preferred if you have sub-bullets under update to v1.4.1 that say what the changes are. I typically get that from the upstream changes file. It can be just a couple bullets up to 20 or so (that is a personal max, not a opensuse policy max) See this changes entry as an example: === ------------------------------------------------------------------- Wed Sep 10 14:22:37 CEST 2008 - cthiel@suse.de - update to version 1.1 * The curl-based fetcher backend was handling 404 errors improperly. * Handling of signed up apt-deb channels has been improved so that a behavior similar to that of APT may be obtained. - removed smart-order-test-packages.patch and smart--cast-test-sizes.patch, both included upstream === Then just so you know, some maintainers will require you to document the new patch with a one line comment. Given the existing 3 patches aren't documented the maintainer may let it slide. http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

First, your emails are dated wrong by 2 days. Maybe your clock is wrong? More below: On Mon, Sep 23, 2013 at 8:13 PM, wrote:

...

On Mon, Sep 23, 2013 at 6:35 PM, wrote:

...

...

Glenn,

You seem to have done the work. Why not just submit your package to

On Wed, 25 Sep 2013 11:50:59 -0400, Greg Freemyer wrote: the

...

...

...

development repo?

Ie. The normal approach to updating a package you don't maintain is:

Branch a copy of development project to home project.

Update/test in home project.

Submit updated package back to development project .

Greg

Hello, Steps done: 1. Branched package system:packagemanager / smart 2. Added in newer package updates , amended spec file - smart (Project home:doiggl:branches:system:packagemanager)

Question: How do I submit updated package back to development project ? system:packagemanager / smart Thanks Glenn

Options on the page I see are: Branch package Submit package Edit description Delete package

From the GUI:

In the upper right corner you should see "could have a link diff".

I typically click that and review all of my changes. If they all look good at the bottom of the page full diffs is a submit button.

In your case your changes file is a little weak:

=============== ------------------------------------------------------------------- Wed Sep 10 14:22:37 CEST 2012

- update to version 1.4.1 - add smart-245344-takes_long_computing_upgrades.patch ===============

First, has it really been a year since you did the update?

Second, you should have your e-mail address after the date. Look at the other change entries to see the syntax

Third - It is preferred if you have sub-bullets under update to v1.4.1 that say what the changes are. I typically get that from the upstream changes file. It can be just a couple bullets up to 20 or so (that is a personal max, not a opensuse policy max)

See this changes entry as an example: === ------------------------------------------------------------------- Wed Sep 10 14:22:37 CEST 2008 - cthiel@suse.de

- update to version 1.1 * The curl-based fetcher backend was handling 404 errors improperly. * Handling of signed up apt-deb channels has been improved so that a behavior similar to that of APT may be obtained. - removed smart-order-test-packages.patch and smart--cast-test-sizes.patch, both included upstream ===

Then just so you know, some maintainers will require you to document the new patch with a one line comment. Given the existing 3 patches aren't documented the maintainer may let it slide.

http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines

Greg

Hello, A list of changes can be found at https://launchpad.net/smart/+milestone/1.4.1 Someone else built the package.

Question: Can a link to the listed changes, be put in the changes file ? --Glenn

The entire changelog from that site is: * exclude noarch packages from color comparisons [#697895] * add a preferences menu option, to edit config [#533786] * add a config option to commit in stepped mode [#245660] * support a ssh: apt alias for the scp: scheme [#841661] * handle Landscape's "no-proxy" config setting [#827999] * add arrow key history completion, for search [#389126] * fix missing stock icons from /opt/gtk * select toolbar style, icons or names & icons [#604379] * select starting tab, general or description [#604378] * allow selecting text size, of the content tab [#388689] * add rpm-collapse-libc-requires needed for yum [#845525] * record installed package origins (in pkgconf) [#687713] * show from which channel a package is selected [#245654] * don't include packages already downloaded in size [#370840] * refactor archscore and archcolor into helper functions * add a dpkg status progress callback to the deb backend [#528328] * add armel (=arm-linux-gnueabi) arch detection, for deb [#351823] * fix test breakage with newer dpkg * system_provides for deb and fink-virtual-pkgs addition [#244962] * make file locking (PathLocks) work on solaris platform [#345326] * add support for distepoch to rpm versions (EVR -> EVRD) [#777118] * cope with unknown filesize in view * avoid KeyError exceptions on mandriva * rpm: don't include @arch in vercmp string It's a little long, but you could just drop all of the above in to the *.changes file. Make sure you put it directly below "update to v1.4.1" and indent it to show it's part of the upstream update and not part of your changes to the specfile. Personally, I would remove items from the above that discuss internal code changes. (ie. remove " refactor archscore and archcolor into helper functions". In general internal changes are not relevant to packagers or users.) Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org