(moving this thread from smart-maintainers to opensuse-buildservice, I think its content is more relevant here ;)) Christoph Thiel wrote:
On Mon, 29 May 2006, Pascal Bleser wrote:
And Christoph because you might want to check whether you've got all of those patches in the SL10.1/Factory smart RPM (but if you do a new build, please don't have a release >= 25 that supersedes my package again ;D).
I'll check our smart package soon. Now, that we have the openSUSE Build Service up and running, we might consider working on the smart package together and share the maintainership. How about that?
I don't think so.
Well, we could, and I would base my own spec on the one in the build service (though there wouldn't be any benefit for me, rather the opposite, it would be more work).
The buildservice is not interesting to me ATM because
1) the buildservice is not advertised anywhere as a repository for packages (as opposed to > 50% of SUSE Linux users already using my repository)
We will be promoting the Build Service very aggressively soon. A re-design of the web frontend is on the way and the commandline tools already work very well (IMO).
OK. But the web frontend currently is only targeted at packagers AFAIK. I really mean the end-user side of things. Don't know whether there are plans to also design an interface that's usable for end-users. And if so, what those plans look like. Unfortunately, it's all happening behind the SUSE curtain :( Navigating the BS repositories/directories is currently a PITA because there's no real concept for how those should be organized (I *don't* think putting stuff into home:/home:pbleser/smart would be a good idea, for example). There must be a single summary page that lists all the projects and packages that are in the BS.
2) I preconfigure my smart package with a lot of channel files, including packman and guru so... legal issues ?
Indeed -- but I'd rather split those channel files into a new package and have smart depend on it (or suggest it). I might even be able to put a channel package into SUSE Linux, with a reduced set of channels.
Mmmmmyeah, that would be a technical option, but not a good thing for end-users IMO. When I look at the current situation with 10.1 and its broken zypp, end-users are already struggling to install my smart RPM (mostly because it depends on rpm-python, that is not installed by default) and have to jump a few hoops because YaST2 or rug just won't work on their system: http://dev-loki.blogspot.com/2006/05/how-to-install-and-use-smart-on-suse.ht... http://spinink.net/2006/05/20/installing-smart-package-manager/ So adding another package/dependency would make things even more complex. And from a technical POV, if I put those channels into, say, smart-suse-channels.rpm, you can't really make smart.rpm depend on it because smart-suse-channels.rpm won't be in the Build Service.
At some point, smart will be in the packman repository, and then the BuildService becomes even less interesting: - no mirror infrastructure yet
This is WIP at the moment. We already push to ftp-1.gwdg.de and another mirror. Check out http://software.openSUSE.org/
Yes, I've read Adrian's mail about that. Good news :)
- no web frontend as with packman [1] [1] see http://packman-test.links2linux.org
;)
No kidding, it's really an advantage of hosting it at Packman instead of the Build Service ;)
But as for maintaining the smart package for Factory, yes, we could do it together in the BuildService (if that's already feasible with the current implementation of BS) so when I add patches to my package, I can also add them to the smart project in the BuildService.
Exactly -- have you tried osc (the python cmdline client to the openSUSE Build Serivce)?
I gave it a quick shot which was not very concluding, but mostly
because I didn't know where to create my projects (sent a mail to
opensuse-packaging two weeks ago but no reply, and it's been
reorganized anyway).
I definitely have to give it another shot. osc is obviously the
approach that I prefer and suits me best, a simple CLI client (and not
a web frontend).
Thanks to Peter for writing it :)
I don't want to discard or discredit your efforts on the BuildService,
but I really don't see any advantage for me in using it at the moment,
it's rather the opposite:
- I build for SUSE 9.1 -> 10.1, and only 10.0, 10.1 and Factory are in
the BS as of now (AFAIK)
- no web frontend for end-users as I'll have with Packman
Note that I don't care at all about building for other distributions.
What would make the BS more compelling to me would be to have a ppc
build target (and providing what I'm missing, above ;)).
Of course, that's my very personal POV, in the light of building
packages that are not provided at all on SUSE Linux or that could only
be built as a crippled subset because of potential legal/patent issues.
It's a totally different case concerning packages that are already in
the distribution, that I could co-maintain directly and that are built
as full-fledged because they're not in the gray legal/patent realm.
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Am Monday 29 May 2006 12:53 schrieb Pascal Bleser:
Christoph Thiel wrote:
On Mon, 29 May 2006, Pascal Bleser wrote:
And Christoph because you might want to check whether you've got all of those patches in the SL10.1/Factory smart RPM (but if you do a new build, please don't have a release >= 25 that supersedes my package again ;D).
I'll check our smart package soon. Now, that we have the openSUSE Build Service up and running, we might consider working on the smart package together and share the maintainership. How about that?
I don't think so.
Well, we could, and I would base my own spec on the one in the build service (though there wouldn't be any benefit for me, rather the opposite, it would be more work).
The buildservice is not interesting to me ATM because
1) the buildservice is not advertised anywhere as a repository for packages (as opposed to > 50% of SUSE Linux users already using my repository)
We will be promoting the Build Service very aggressively soon. A re-design of the web frontend is on the way and the commandline tools already work very well (IMO).
OK. But the web frontend currently is only targeted at packagers AFAIK. I really mean the end-user side of things. Don't know whether there are plans to also design an interface that's usable for end-users. And if so, what those plans look like.
Yes, we do plan to have also an end user web front end. And a GUI tool as well.
Unfortunately, it's all happening behind the SUSE curtain :(
We do develop in the public svn. Have a look esp. at the TODO file. Andreas is currently heavily working on the new web frontend, which is the reason that the current installed one on build.o.o does not change ...
Navigating the BS repositories/directories is currently a PITA because there's no real concept for how those should be organized (I *don't* think putting stuff into home:/home:pbleser/smart would be a good idea, for example).
The projects and also this dirs are caused by technical issues in first place. It is not intended to have everybody to search through all those directories. Yes, we do need a search functionality and a end-user usable browsing interface. This is what the team is working on atm.
There must be a single summary page that lists all the projects and packages that are in the BS.
yes ...
But as for maintaining the smart package for Factory, yes, we could do it together in the BuildService (if that's already feasible with the current implementation of BS) so when I add patches to my package, I can also add them to the smart project in the BuildService.
Exactly -- have you tried osc (the python cmdline client to the openSUSE Build Serivce)?
I gave it a quick shot which was not very concluding, but mostly because I didn't know where to create my projects (sent a mail to opensuse-packaging two weeks ago but no reply, and it's been reorganized anyway). I definitely have to give it another shot. osc is obviously the approach that I prefer and suits me best, a simple CLI client (and not a web frontend). Thanks to Peter for writing it :)
I don't want to discard or discredit your efforts on the BuildService, but I really don't see any advantage for me in using it at the moment, it's rather the opposite: - I build for SUSE 9.1 -> 10.1, and only 10.0, 10.1 and Factory are in the BS as of now (AFAIK) - no web frontend for end-users as I'll have with Packman
Note that I don't care at all about building for other distributions.
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
Of course, that's my very personal POV, in the light of building packages that are not provided at all on SUSE Linux or that could only be built as a crippled subset because of potential legal/patent issues. It's a totally different case concerning packages that are already in the distribution, that I could co-maintain directly and that are built as full-fledged because they're not in the gray legal/patent realm.
I think we do have different goals with the build service and with packman. Which is complete okay. But we should have of course an ongoing discussion where we can work together to avoid double work. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
On Mon, May 29, 2006 at 01:04:36PM +0200, Adrian Schroeter wrote:
Am Monday 29 May 2006 12:53 schrieb Pascal Bleser:
Unfortunately, it's all happening behind the SUSE curtain :(
We do develop in the public svn. Have a look esp. at the TODO file. Andreas is
Sorry, but this is more or less a joke as it is in the moment from an (external) developer's point of view. There is no working backend available for external developers (even not a working dummy backend). This makes every effort to establish a local test system to evaluate the results of changes you do to the code impossible or at least so complicated that it is no longer fun to work on it. I suppose you as s software developer are aware that this is not the way you can do reasonable work. You don't need to explain me the problems again about pending decissions for releasing further parts of the system to the public but as long as you are developing internally without providing any reasonable infrastructure for external developers you are walking further and further away from external developers. As long as this does not _really_ change I am fully of the opinion of Pascal: It does not really provide additional value for me too. For me it is also easier to work on _our_ internal build system without doing any big effort to integrate stuff we developed there to your system. I will play around with the openSUSE build service and will do bug reports to stay up-to-date but as long as there is no running system I have some controll over, I will not even try to fix the problems myself because it is a waste of time, and I have a build system at hand that fits my needs _much_ better. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Mon, May 29, 2006 at 01:30:59PM +0200, Robert Schiele wrote:
Sorry, but this is more or less a joke as it is in the moment from an (external) developer's point of view.
Depends on the type of work you want to do. Pascal wants to work on an end user interface, this can be done very well without a working dummy backend. Just use the real API server for testing. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Mon, May 29, 2006 at 02:13:19PM +0200, Michael Schroeder wrote:
On Mon, May 29, 2006 at 01:30:59PM +0200, Robert Schiele wrote:
Sorry, but this is more or less a joke as it is in the moment from an (external) developer's point of view.
Depends on the type of work you want to do. Pascal wants to work on an end user interface, this can be done very well without a working dummy backend. Just use the real API server for testing.
That's what I happen to do :-) Regards, Peter -- SUSE LINUX Products GmbH Thought is limitation. Research & Development Free your mind.
On Mon, 29 May 2006, Pascal Bleser wrote:
(moving this thread from smart-maintainers to opensuse-buildservice, I think its content is more relevant here ;))
Indeed.
2) I preconfigure my smart package with a lot of channel files, including packman and guru so... legal issues ?
Indeed -- but I'd rather split those channel files into a new package and have smart depend on it (or suggest it). I might even be able to put a channel package into SUSE Linux, with a reduced set of channels.
Mmmmmyeah, that would be a technical option, but not a good thing for end-users IMO. When I look at the current situation with 10.1 and its broken zypp, end-users are already struggling to install my smart RPM (mostly because it depends on rpm-python, that is not installed by default) and have to jump a few hoops because YaST2 or rug just won't work on their system: http://dev-loki.blogspot.com/2006/05/how-to-install-and-use-smart-on-suse.ht... http://spinink.net/2006/05/20/installing-smart-package-manager/
So adding another package/dependency would make things even more complex.
And from a technical POV, if I put those channels into, say, smart-suse-channels.rpm, you can't really make smart.rpm depend on it because smart-suse-channels.rpm won't be in the Build Service.
So, why would users want to install your smart package, instead of going for the one that's already in the distribution? Only because of the preconfigured channels? Installing the SUSE smart package (+requirements), after doing a default CD / DVD or network installation, should be working without any problems, even with libzypp. To solve the channel Problem, we should look into registering a mime-type for .channel (or .repo) files, to handle them with a helper script when $users tries to access them.
I don't want to discard or discredit your efforts on the BuildService, but I really don't see any advantage for me in using it at the moment, it's rather the opposite: - I build for SUSE 9.1 -> 10.1, and only 10.0, 10.1 and Factory are in the BS as of now (AFAIK)
9.3 has been added recently. [9.1 has just been official discontinued and Adrian is telling me, that 9.2 won't be added to the Build Serivce, right?) CORE9 (SLES9 / NLD9) might be an interesting target in the future.]
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
+1 ;) Regards Christoph
Christoph Thiel wrote:
On Mon, 29 May 2006, Pascal Bleser wrote:
2) I preconfigure my smart package with a lot of channel files, including packman and guru so... legal issues ? Indeed -- but I'd rather split those channel files into a new package and have smart depend on it (or suggest it). I might even be able to put a channel package into SUSE Linux, with a reduced set of channels. Mmmmmyeah, that would be a technical option, but not a good thing for end-users IMO. When I look at the current situation with 10.1 and its broken zypp, end-users are already struggling to install my smart RPM (mostly because it depends on rpm-python, that is not installed by default) and have to jump a few hoops because YaST2 or rug just won't work on their system: http://dev-loki.blogspot.com/2006/05/how-to-install-and-use-smart-on-suse.ht... http://spinink.net/2006/05/20/installing-smart-package-manager/
So adding another package/dependency would make things even more complex.
And from a technical POV, if I put those channels into, say, smart-suse-channels.rpm, you can't really make smart.rpm depend on it because smart-suse-channels.rpm won't be in the Build Service.
So, why would users want to install your smart package, instead of going for the one that's already in the distribution? Only because of the preconfigured channels?
Two reasons: - preconfigured channels 99% of people want to use anyway - up-to-date builds Granted, at the moment there isn't much development happening with smart, but that will change soon as Gustavo (Niemeyer, the smart maintainer) will get dedicated time to work on it from Canonical (at least it's very likely, he told me so last week). Now, if the Build Service is easily accessible by end-users and establishes itself as an *easy* package installation channel for them (like Packman or my site), it's a different story. They wouldn't further be dependent on the version that's shipped with a SUSE Linux release, but could update directly to the latest build that would be maintained in the BS. Nevertheless, preconfigured channels is a major feature. Not to me, not to you, nor to most experienced users, as adding channels or especially just adding some .channel files is pretty trivial with smart, but it does to less experienced end-users. The feedback has really been great on IRC, everyone is very happily using it. It lacks a few features (when compared to apt-rpm or y2pmsh) and has some the latter don't, but it works, it's stable and I only got very few bug reports that I could fix very quickly (see the batch of patches I've submitted upstream, it's the original mail that's not in this thread.. well.. not on this list ;D). Just to say that those preconfigured channels are part of its acceptance: just install my smart RPM (and rpm-python), "smart update" and it works, including for packman and guru, which almost everyone asks for anyway (for mp3, video codecs, latest amarok, latest gimp, etc...) as well as supplementary KDE, latest wine packages (build by Marcus Meissner), latest mozilla.org packages. Note that those 3 are disabled by default, but can be enabled very easily: smart channel --enable suse-kde smart channel --enable suse-mozilla smart channel --enable suse-wine And it includes 4 or 5 mirrors for every channel too, out of the box.
Installing the SUSE smart package (+requirements), after doing a default CD / DVD or network installation, should be working without any problems, even with libzypp.
Unfortunately it doesn't :\ Usually people come asking for a solution when they're stuck with a non-working zypp (doesn't install anything, crashes, takes huge amounts of resources, etc...), which is when we (on IRC) tell them to use smart instead, at least until zypp is fixed.
To solve the channel Problem, we should look into registering a mime-type for .channel (or .repo) files, to handle them with a helper script when $users tries to access them.
Right, that would be very neat.
I don't want to discard or discredit your efforts on the BuildService, but I really don't see any advantage for me in using it at the moment, it's rather the opposite: - I build for SUSE 9.1 -> 10.1, and only 10.0, 10.1 and Factory are in the BS as of now (AFAIK)
9.3 has been added recently. [9.1 has just been official discontinued and Adrian is telling me, that 9.2 won't be added to the Build Serivce, right?) CORE9 (SLES9 / NLD9) might be an interesting target in the future.]
Mmmm.. OK, I guess I'm going to drop 9.1 builds as well then. Don't know about 9.2, I think it's not being used a lot any more. From the feedback I get, it's usually either 9.1 or 9.3. And yes, CORE9 and CORE10 would be nice :) I regularly get requests for building my packages (at least some of them) on SLED9 or SLES9, but I can't do that ... or rather I'm not willing to do that if I have to pay for a license.
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
+1 ;)
(and IMO, as a feature, ppc > CORE9/CORE10 ;))
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On 2006-05-29 16:25:10 +0200, Pascal Bleser wrote:
Just to say that those preconfigured channels are part of its acceptance: just install my smart RPM (and rpm-python), "smart update" and it works, including for packman and guru, which almost everyone asks for anyway (for mp3, video codecs, latest amarok, latest gimp, etc...) as well as supplementary KDE, latest wine packages (build by Marcus Meissner), latest mozilla.org packages. Note that those 3 are disabled by default, but can be enabled very easily: smart channel --enable suse-kde smart channel --enable suse-mozilla smart channel --enable suse-wine
i would like to mention that i hate the current behavior of smart. it bothers me to enable all kind of channels once i install your rpm and start it for the first time. if we even think of doing such "smart source" package we should fix that behavior first. taking into account the number of projects we already have. and this number will grow darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
--snip--
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
I also would be interested in this. I would also like the possibility to turn different build targets on/off per package.
Of course, that's my very personal POV, in the light of building packages that are not provided at all on SUSE Linux or that could only be built as a crippled subset because of potential legal/patent issues. It's a totally different case concerning packages that are already in the distribution, that I could co-maintain directly and that are built as full-fledged because they're not in the gray legal/patent realm.
I would like to personally thank SUSE for allowing others to use the Build Service. I have 19 packages (and growing) in there at present and find it very usefull! Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
--snip--
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
I also would be interested in this.
I would also like the possibility to turn different build targets on/off per package.
That should be supported with the "ExclusiveArch" and/or "ExcludeArch" tags in spec files, e.g.: ExclusiveArch: %ix86 x86_64 ExcludeArch: ppc ppc64 See http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-EXCLU... http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-EXCLU... I don't know whether that's currently supported by the BS though.
Of course, that's my very personal POV, in the light of building packages that are not provided at all on SUSE Linux or that could only be built as a crippled subset because of potential legal/patent issues. It's a totally different case concerning packages that are already in the distribution, that I could co-maintain directly and that are built as full-fledged because they're not in the gray legal/patent realm.
I would like to personally thank SUSE for allowing others to use the Build Service. I have 19 packages (and growing) in there at present and find it very usefull!
Hey, sure, I'm not bashing the BS ;)
Just that my situation (and for most of 3rd party SUSE Linux packagers
who are out there since some time) is pretty different: I already have
an existing infrastructure that works great.
I'm just saying that compared to that, the BS doesn't provide any
benefits as of now, at least nothing compelling.
cheers
--
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Mon 29 May 2006 17:29, Pascal Bleser wrote:
Peter Nixon wrote:
--snip--
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
I also would be interested in this.
I would also like the possibility to turn different build targets on/off per package.
That should be supported with the "ExclusiveArch" and/or "ExcludeArch" tags in spec files, e.g.: ExclusiveArch: %ix86 x86_64 ExcludeArch: ppc ppc64
See http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-EXCL USIVEARCH http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-EXCL UDEARCH
I don't know whether that's currently supported by the BS though.
I just tested it, and got the error message (during the build): "error: Architecture is not included: x86_64" I think it would be a good idea for that to be checked before trying to build so that the package would show as "disabled" or something similar instead of "Failed". In any case "ExclusiveArch" and/or "ExcludeArch" solves only the architecture issue, but doesn't allow you to for example say "Don't build this package for SUSE 9.3"... I do know about "%if %suse_version > 0" and "%if %sles_version > 0" however these will still attempt to build and then show as failed, and wrapping the whole spec file in an if statement seems a fairly hackish way to solve the issue. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Am Monday 29 May 2006 20:52 schrieb Peter Nixon:
On Mon 29 May 2006 17:29, Pascal Bleser wrote:
Peter Nixon wrote:
--snip--
What would make the BS more compelling to me would be to have a ppc build target (and providing what I'm missing, above ;)).
I also would be interested in this.
I would also like the possibility to turn different build targets on/off per package.
That should be supported with the "ExclusiveArch" and/or "ExcludeArch" tags in spec files, e.g.: ExclusiveArch: %ix86 x86_64 ExcludeArch: ppc ppc64
See http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-EX CL USIVEARCH http://www.rpm.org/max-rpm/s1-rpm-specref-preamble.html#S3-RPM-SPECREF-EX CL UDEARCH
I don't know whether that's currently supported by the BS though.
I just tested it, and got the error message (during the build):
"error: Architecture is not included: x86_64"
I think it would be a good idea for that to be checked before trying to build so that the package would show as "disabled" or something similar instead of "Failed".
yes, mls said as well that this might be a good idea. However this was on some fair, so better create an enhancement bugreport for this ;)
In any case "ExclusiveArch" and/or "ExcludeArch" solves only the architecture issue, but doesn't allow you to for example say "Don't build this package for SUSE 9.3"...
I do know about "%if %suse_version > 0" and "%if %sles_version > 0" however these will still attempt to build and then show as failed, and wrapping the whole spec file in an if statement seems a fairly hackish way to solve the issue.
-- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
participants (8)
-
Adrian Schröter -
Christoph Thiel -
Dr. Peter Poeml -
Marcus Rueckert -
Michael Schroeder -
Pascal Bleser -
Peter Nixon -
Robert Schiele