(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.h…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/
/\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be>
_\_v http://www.fosdem.orghttp://opensuse.org
Hi Adrian:
I don't think that works (just tested it).
BTW, on Red Hat/Fedora, /usr/lib/libfreetype.a is provided by freetype-devel, however, it is provided by libfreetype6-static-devel on Mandriva 2006, so perhaps you want to add that to your mapping such that freetype-devel on Red Hat/Fedora expands to freetype-devel and libfreetyp6-static-devel.
P.S. Build on Mandriva 2006 gives: "error: cannot open Pubkeys index using db3 - No such file or directory (2)" - not sure if this is known issue or not.
Cheers,
Bernard
________________________________
From: Adrian Schröter [mailto:adrian@suse.de]
Sent: Mon 29/05/2006 22:56
To: opensuse-buildservice(a)opensuse.org
Subject: Re: [opensuse-buildservice] Mandriva 2006 check in spec file
Am Tuesday 30 May 2006 04:13 schrieb Bernard Li:
> Hi Guys:
>
> Anybody knows the equivalent of "%if %{?suse_version:1}0" under Mandriva
> 2006?
does
%if %_host_vendor = "mandriva"
work ?
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Hi Guys
I am building a bunch of packages at present (sipxpbx) which have a convoluted
set of dependencies. As it turns out all of the dependencies are provided by
SUSE 10.1, some are missing in 10.0 and many more are missing in 9.3
For example, one set of dependencies is "ruby, rubygems, rake".
Now, given that these are all provided by SUSE 10.1, how can I provide these
packages to SUSE 10.0 and 9.3 users? I could of course take the source rpms
from 10.1, and add them to my project, but that then means to I am providing
a package for 10.1 which already exists..
At a minimum I would like a way to enable/disable build targets per package,
which would make this solution workable.
A more preferable solution (although one that may require a bit more work)
would be the ability to link a SUSE 10.1 package into my project which should
then be transparently built for my other build targets if they don't provide
it.
Is this possible?
Cheers
--
Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
Hello,
I wanted to create a modified courier-authlib package (to be exact: with
added mysql backend, requires just a specfile patch AFAIK) for 10.1, but
wasn't able to link to the package.
Michael Schröder told me that the sources for 10.1 were not uploaded - I
think this should be changed ;-)
The reasons why I do not want to link to the Factory package are the
same with for YOU updates - I want to minimize the changes I need to do
to the whole system (so: no version upgrades) and would like to have an
automated package rebuild in case there's a security update for
courier-authlib.
Of course, I can upload the 10.1 sources myself - but I don't consider
this a very good idea...
BTW: Can I upload a src.rpm instead of a tarball also?
Regards,
Christian Boltz
PS: Maybe wildcard linking would be an interesting feature ("link to
package foobar from the distributions I'm building packages for") -
but in this case you would need the option to apply a patch to a
limited set of your build targets.
The alternative is to create a project per target distribution and
to apply the patch to the distributions that need it.
--
wie jeder weiß ist Debian auf ISDN die langsamste bekannte Methode
Selbstmord zu begehen ("Selbstmord durch Erosion")
[http://blog.koehntopp.de/archives/113-Debian-ist-doch-schlecht..html]
Hello,
when adding a build target (say "SUSE:SL-10.0/standard") I can enter a
name for that target.
Browsing around on software.opensuse.org, I found several different
names for the same distribution:
- SL10.0
- SuLi100
- SUSE_Linux_10.0
This is not very user-frendly.
I think the naming should be more standardized - at least in a soft way:
When choosing something in the "Platform" dropdown, the "Name" field
should be filled with the name of the selected Platform as default.
In case someone builts on top of another project (like a package for
KDE4 on SL 10.1), the default should be the underlying distribution
(here: SL 10.1).
Opinions?
Regards,
Christian Boltz
--
>> I was already 21 when color tv got introduced in Germany...
> Old Fart, ain't cha? <grin>....
Oh no. Linux is keeping you young, and OpenSUSE even can make younger.
SUSE people, please tell this your marketing team. ;-))
[Eberhard Moenkeberg and > Patrick Shanahan in opensuse]
Hi,
we do support now the new ftp directory layout for the repositories.
The packages and repositories do get signed with a new openSUSE build service
key.
The bug not to remove all subpackages got fixed as well.
What does this mean ?
We are ready to get synced from our mirrors and that means we can really
provide usefull rpms now with the build service :)
I will trigger soon a complete rebuild to have only signed rpms and the new
directory layout everwhere. This is hopefully the last complete rebuild we
will ever need, because our basic configuration for the repositories should
be final now.
Do not wonder, when your rpms in software/repos.opensuse.org do disappear, it
is because of the rebuild.
Next steps:
* get mirrors (I will write a mail to our mirror admins).
* stop classic ftp.suse.com supplementary and project updates and get the
SUSE packagers on the openSUSE build service
* support export of debian packages
* rename Fedora, Mandriva and Debian distros to use the namespaces as well
(Fedora:4 instead of FC4 for example).
* add SUSE Linux 9.3 and SLES 9 targets
* add Ubuntu target.
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian(a)suse.de
OK. It now appears that java-1_5_0-sun-devel is available in
"SUSE:SL-10.0/standard" (excellent...) but not "SUSE:SL-10.1/standard"..
Can it be added to "SUSE:SL-10.1/standard" also? please?
--
Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
