[opensuse-buildservice] Help needed for Packaging
Hi everybody, I'm quiet new to RPM packaging and the BuildService. Nevertheless, I offered myself to maintain some games inside the BuildService (my goal will be UFO:AI, but for 'training' I accepted to maintain Ri-Li and SuperTuxKart. For the moment I'm trying to make the build of SuperTuxKart, which fails with a message, plib 1.8.4 had to be installed when checking the logfile. plib is noted in the BuildRequires tag and according the logfile plib 1.8.4 also got installed. Any ideas what I could miss there? Dominique
Dne Tuesday 19 September 2006 08:54 Dominique Leuenberger napsal(a):
Hi everybody, Hi Dominique
plib is noted in the BuildRequires tag and according the logfile plib 1.8.4 also got installed.
Any ideas what I could miss there? try remove plib from BuildRequires and add plib-devel
Dominique
Pavel -- Pavel Nemec package-maintainer http://en.opensuse.org/Czech_Packagers_Team --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: pnemec@suse.cz Lihovarska 1060/12 tel:+420 2 9654 2373 190 00 Praha 9 fax:+420 2 9654 2374 Ceska republika http://www.suse.cz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominique Leuenberger wrote:
I'm quiet new to RPM packaging and the BuildService. Nevertheless, I offered myself to maintain some games inside the BuildService (my goal will be UFO:AI, but for 'training' I accepted to maintain Ri-Li and SuperTuxKart.
http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=Games/ri-li/
http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=Games/supertuxkart/
Is it really necessary that people build stuff we already have at
packman or in my repository, _without any notice_ ?
Please check
http://packman-test.links2linux.org/search
http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/src/
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Tue, Sep 19, 2006 at 09:05:01AM +0200, Pascal Bleser wrote:
Dominique Leuenberger wrote:
I'm quiet new to RPM packaging and the BuildService. Nevertheless, I offered myself to maintain some games inside the BuildService (my goal will be UFO:AI, but for 'training' I accepted to maintain Ri-Li and SuperTuxKart.
http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=Games/ri-li/ http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=Games/supertuxkart/
Is it really necessary that people build stuff we already have at packman or in my repository, _without any notice_ ?
Please check http://packman-test.links2linux.org/search http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/src/
Thanks for the hint. I didn't know about your repository yet. Any plans to transfer it to the openSUSE buildservice or has this already been discussed on some mailing list? Best regards, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany ------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Dirsch wrote:
On Tue, Sep 19, 2006 at 09:05:01AM +0200, Pascal Bleser wrote:
Dominique Leuenberger wrote:
I'm quiet new to RPM packaging and the BuildService. Nevertheless, I offered myself to maintain some games inside the BuildService (my goal will be UFO:AI, but for 'training' I accepted to maintain Ri-Li and SuperTuxKart.
http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=Games/ri-li/ http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=Games/supertuxkart/
Is it really necessary that people build stuff we already have at packman or in my repository, _without any notice_ ?
Please check http://packman-test.links2linux.org/search http://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/RPMS/src/
Thanks for the hint. I didn't know about your repository yet. Any
Um.. you gotta be kidding ;) http://rpm.pbone.net/index.php3/stat/15/sort/1
plans to transfer it to the openSUSE buildservice or has this already been discussed on some mailing list?
Those packages ? All my packages ?
No, I have no plans to transfer whatsoever to the BuildService at the
moment.
I've already posted my """gripes""" (well, not really gripes, *I know
it's WIP* ;)) on the list.
To summarize:
- - it's more work for me to use the BS (even with osc, although it is
orders of magnitudes better than the web interface IMO) than using my
own build scripts (they work more or less like y2pmbuild), and
time/effort is a very critical resource for me as I maintain those
700-800 active projects exclusively during my spare time
- - IMO the Build Service as it is now is not very user-friendly. No
overall list of all packages/projects, no search function. I know it's
in the works, and I really don't mean to criticize the great work of
Adrian, Peter, Michael, and all the others involved, but until then, I
think it is _much_ more convenient for people to use my site or packman,
with a nice web interface ([1]) and features like an RSS feed, a single
repository, search, etc...
- - I currently don't maintain KMPs or other packages that are highly
dependent on others, so I wouldn't benefit much from the automatically
triggered rebuilds
- - I don't build nor plan to build for Factory, no time for that
(although that's possibly the only advantage I would gain from using the
BS, but Factory is there to test, not to use it as a productive system,
so people who use Factory don't need my packages - at least, so I assume)
[1] especially the new one that will go live soon:
http://packman-test.links2linux.org
Don't take me wrong, I really don't mean to sound rude or something :)
The BS is a great project and it will definitely develop into something
that wipes away my current "gripes" (please take that word with a grain
of salt).
But in the current state, I don't see any benefit for me to use the BS
instead of my own build tools. If it means more work, needs more time,
less convenience both for me and the people who use my packages, I don't
have any reason to switch now.
The only thing I don't appreciate is that a lot of packages the packman
team or I maintain (often since quite some time) show up in the BS,
maintained by other people, without even getting a notice.
Thank you, how nice.
That's not how we community packagers do it. We talk to each other, try
to avoid duplicate work, mostly try to consolidate our work in the
packman infrastructure in order to provide the best possible experience
for SUSE users out there. Especially as the BS likes to generate high
release numbers, _which voids our work_ (and I would really like to
insist on this point).
Now when the BS will provide what I think are both my needs and those of
the people who use my packages, I would probably switch, let other
people do the packaging, and possibly retire from that activity or
concentrate on a few packages (700-800 specs are definitely too much for
a single person ;)).
But until then, packman provides the best packager infrastructure and
end-user experience, at least IMO.
Note, and I'll end my way-too-long-email-as-always with this, that I was
the first (and possibly only) one to say that a major problem with the
openSUSE community (as a whole) is that we lack community packagers. Not
enough people, too many single points of failure, and way too much work
for the people who currently take care of it.
So I'm pretty unemotional about that, if people take care of some or
most of the packages I build today, great, means more free time for me.
It's just that I care about the people who use my packages and the
service I can provide to them, and about SUSE Linux as it is the
distribution I've been using and advocating since 5.0 :)
Do I sound sad and somewhat disappointed ? you bet.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Tuesday 19 September 2006 8:07 pm, Pascal Bleser wrote:
The only thing I don't appreciate is that a lot of packages the packman team or I maintain (often since quite some time) show up in the BS, maintained by other people, without even getting a notice. Thank you, how nice.
That's not how we community packagers do it. We talk to each other, try to avoid duplicate work,
You didn't contact me when you decided to release perl-XML-Twig, perl-XML-XPath, and python-lxml packages, which I've been distributing since SUSE 8.1, 9.1, and 10.0, respectively. I was also not contacted when Packman released xmltv and mmpython packages, which I've been distributing, with proper names, since SUSE 8.0 and 8.2, respectively. Thank you, how nice.
mostly try to consolidate our work in the packman infrastructure in order to provide the best possible experience for SUSE users out there. Especially as the BS likes to generate high release numbers, _which voids our work_ (and I would really like to insist on this point).
That brings me to another point, you guys have been releasing newer versions of packages that SUSE distribute, for no good reason, without the testing that the SUSE packages get. I remember the time back in the apt days that a simple 'apt upgrade' caused me to get a newer version of alsa than the SUSE kernel had. All of a sudden, I couldn't compile programs against ALSA because the kernel/userspace headers didn't match. At that point I had to add rules to apt's not-for-the-mere-mortal config files to keep it from unnecessarily upgrading packages. I *never* put packages that SUSE already has in my repos. I can't afford the time to do the testing necessary to make sure I'm not breaking somebody's setup. I'll leave the version-itis to the Gentoo folks, thank you. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Oakley wrote:
On Tuesday 19 September 2006 8:07 pm, Pascal Bleser wrote:
The only thing I don't appreciate is that a lot of packages the packman team or I maintain (often since quite some time) show up in the BS, maintained by other people, without even getting a notice. Thank you, how nice.
That's not how we community packagers do it. We talk to each other, try to avoid duplicate work,
You didn't contact me when you decided to release perl-XML-Twig, perl-XML-XPath, and python-lxml packages, which I've been distributing since SUSE 8.1, 9.1, and 10.0, respectively.
I was also not contacted when Packman released xmltv and mmpython packages, which I've been distributing, with proper names, since SUSE 8.0 and 8.2, respectively.
Thank you, how nice.
James, I said we *try*. You tell me 3 packages, I can probably give you a good dozen (at the very least) that are being built in the BuildService and where I never got a single notification, whatsoever. At least the following people try hard to avoid duplication or merge/reconcile when it happens: - - the packman team - - oc2pus (just joined the packman team) - - my repository (and that probably accounts for 70% of the SUSE Linux packages coming from the community, so that's already quite good) We definitely need better communication across community packagers.. or rather, all packagers. I really hoped openSUSE would be a channel for that, but it didn't happen, though I tried to trigger it a few times (probably not hard enough, or maybe the time wasn't right, yet). Aren't the community packagers a critical aspect of a healthy Linux distribution ? Yeah, at least we agree on that. Maybe we should try to revive opensuse-packaging@opensuse.org
mostly try to consolidate our work in the packman infrastructure in order to provide the best possible experience for SUSE users out there. Especially as the BS likes to generate high release numbers, _which voids our work_ (and I would really like to insist on this point).
That brings me to another point, you guys have been releasing newer versions of packages that SUSE distribute, for no good reason, without the testing that the SUSE packages get. I remember the time back in the apt days that a simple 'apt upgrade' caused me to get a newer version of alsa than the SUSE kernel had. All of a sudden, I couldn't compile programs against ALSA because the kernel/userspace headers didn't match. At that point I had to add rules to apt's not-for-the-mere-mortal config files to keep it from unnecessarily upgrading packages.
I *never* put packages that SUSE already has in my repos. I can't afford the time to do the testing necessary to make sure I'm not breaking somebody's setup. I'll leave the version-itis to the Gentoo folks, thank you.
That's your point of view and your policy as a packager, great, why not.
Actually there is a real demand for having
- - packages that may not be provided by SUSE Linux or the Build Service
(we know what those packages are)
- - packages that are not part of SUSE Linux (but not for the reason above)
- - newer versions of packages shipped with SUSE Linux
Let me pick a few good examples from my repository:
- - amarok: the SUSE package is outdated (1.3.8, newest is 1.4.3), and the
BS package is crippled (no MP4 tagging support, no MySQL support, no
PostgreSQL support)
- - liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5
- - lftp: 10.1 ships 3.4.0, latest stable is 3.5.4
- - xchat: 10.1 ships 2.6.1, latest stable is 2.6.6
and I could go on.
And I won't even mention older SUSE versions like 10.0 or 9.3, for which
we provide up-to-date packages.
We all know what the policy of SUSE Linux is wrt that (no new versions,
backport patches when fixing security issues or severe bugs), and that's
perfectly fine, understandable and probably the only way to have a
consistent and tested distribution.
Nevertheless, newer versions of widely used projects (as the ones above,
but there are a lot more) sport a lot of enhancements and new features.
"for no good reason" - wth ? Are you really telling me that no one
should have amarok 1.4.3 as an option, but stick with 1.3.8 instead
because it has been tested by the SUSE QA team ? I'd knew a lot of
people who would switch distros if it was like that.
The "latest stable KDE" repository in the Build Service is also used by
a significant number of users... "for no good reason" ?
If people want to stick with a fully tested system that works fine for
them, only use the stock SUSE packages, fine.
If people want the features of newer versions of some packages they use
often, then they can get them from packman, guru, oc2pus, and many others.
I don't see what this has to do with "versionitis". Our work is a vital
part of the SUSE Linux ecosystem. Labeling that "versionitis" is just
name-calling.
It's almost surprising, but given how few time I can invest into testing
the packages I maintain and how many people use them, issues are really,
really rare, and the same is to be said for packman. So I guess that 1)
the developers are doing a pretty good job, 2) we're possibly not that
bad at packaging.
Actually, when I take a quick look at the packages in my repository, I'd
say 95% of them are packages that are _not_ shipped with SUSE Linux.
And as far as sticking with SUSE package versions and not breaking
systems, I can remember usr-local-bin gnome packages being poison for
anyone not really experienced with it, so none of us is perfect,
packaging errors or unforeseeable consequences can always happen (even
with packages made by the SUSE team) given how much of a complex matter
it is. But still, dubbing the packman repository as being bleeding-edge
stuff that nukes anyone but experts' systems is both untrue and somewhat
offensive.
James, I don't even understand why I'm telling you this, you already
know all that stuff.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Wednesday 20 September 2006 9:38 pm, Pascal Bleser wrote:
James, I said we *try*. You tell me 3 packages, I can probably give you a good dozen (at the very least) that are being built in the BuildService and where I never got a single notification, whatsoever.
That's actually a good reason to use the buildservice. You only have to make one search to avoid duplication.
At least the following people try hard to avoid duplication or merge/reconcile when it happens: - the packman team - oc2pus (just joined the packman team) - my repository (and that probably accounts for 70% of the SUSE Linux packages coming from the community, so that's already quite good)
I try very hard as well. I won't distribute something that I know you guys already have. So, how do we reconcile?
We definitely need better communication across community packagers.. or rather, all packagers. I really hoped openSUSE would be a channel for that, but it didn't happen,
Isn't this the point of the buildservice? What's the problem?
I *never* put packages that SUSE already has in my repos. I can't afford the time to do the testing necessary to make sure I'm not breaking somebody's setup. I'll leave the version-itis to the Gentoo folks, thank you.
That's your point of view and your policy as a packager, great, why not.
Actually there is a real demand for having - packages that may not be provided by SUSE Linux or the Build Service (we know what those packages are) - packages that are not part of SUSE Linux (but not for the reason above)
I never said there wasn't a demand. This is why we're all doing this.
- newer versions of packages shipped with SUSE Linux
Let me pick a few good examples from my repository: - amarok: the SUSE package is outdated (1.3.8, newest is 1.4.3), and the BS package is crippled (no MP4 tagging support, no MySQL support, no PostgreSQL support)
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
- liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5 - lftp: 10.1 ships 3.4.0, latest stable is 3.5.4 - xchat: 10.1 ships 2.6.1, latest stable is 2.6.6 and I could go on.
Yes, there are always newer versions of any software. However, some of us may want newer versions of one package, but not others. The buildservice makes separation of projects or topics really easy. Rug's unsubscribed services make this nicer, but it's still not ideal.
We all know what the policy of SUSE Linux is wrt that (no new versions, backport patches when fixing security issues or severe bugs), and that's perfectly fine, understandable and probably the only way to have a consistent and tested distribution.
Yup. I maintain a custom distribution with about 500 packages. My policy is the same.
"for no good reason" - wth ? Are you really telling me that no one should have amarok 1.4.3 as an option, but stick with 1.3.8 instead because it has been tested by the SUSE QA team ?
No. I use your Amarok. I was talking about ALSA, and stuff like imlib2, libogg, and curl that has the potential to break other software since they're linked to. There's no good reason to upgrade these things willy-nilly. If there's a bug, it should be reported to SUSE.
I'd knew a lot of people who would switch distros if it was like that. The "latest stable KDE" repository in the Build Service is also used by a significant number of users... "for no good reason" ?
Yes, but not everyone uses Factory, which does have the latest versions of *all* software. The ability to have separate repositories is the key here.
If people want to stick with a fully tested system that works fine for them, only use the stock SUSE packages, fine. If people want the features of newer versions of some packages they use often, then they can get them from packman, guru, oc2pus, and many others.
Ideally, they could get them from one place, in categories, like the build service.
I don't see what this has to do with "versionitis". Our work is a vital part of the SUSE Linux ecosystem. Labeling that "versionitis" is just name-calling.
As you said above:
liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5
You're saying that larger numbers are better. I don't doubt that there are bugfixes and new features, but those things can have unintended effects. How about a real world example? A few years ago, a vulnerability was found in a version of openssh. SUSE and the other major vendors fixed the problem and patched the existing version. The openssh guys responded by releasing a new version with a part of the auth system re-worked. This new, "better", version had an even bigger vulnerability. Everybody who blindly upgraded had to upgrade again, while those of us who played it safe were just fine.
It's almost surprising, but given how few time I can invest into testing the packages I maintain and how many people use them, issues are really, really rare, and the same is to be said for packman. So I guess that 1) the developers are doing a pretty good job, 2) we're possibly not that bad at packaging.
I was not trying to criticize your abilities. You all do a great job and I *do* benefit from your work. I just can't help but cringe when I see newer versions of base libraries in your repositories. It's too risky for me.
And as far as sticking with SUSE package versions and not breaking systems, I can remember usr-local-bin gnome packages being poison for anyone not really experienced with it, so none of us is perfect,
They were all part of GNOME, so users adding his repository knew what kind of packages they were getting, and how much of their system was affected. This is one of the reasons I like the buildservice. You can separate things into different repositories so everybody is clear about what they're getting.
it is. But still, dubbing the packman repository as being bleeding-edge stuff that nukes anyone but experts' systems is both untrue and somewhat offensive.
I didn't say that. I just said that some upgraded packages have possible unintended side-effects, which can break things. It happened to me with Packman's alsa. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Sep 21, 2006 at 02:21:11PM -0300, James Oakley wrote:
On Wednesday 20 September 2006 9:38 pm, Pascal Bleser wrote:
James, I said we *try*. You tell me 3 packages, I can probably give you a good dozen (at the very least) that are being built in the BuildService and where I never got a single notification, whatsoever.
That's actually a good reason to use the buildservice. You only have to make one search to avoid duplication.
If you also build packages for packages that are not under an OSS license or for a distribution that is not included, you cannot use the build service in a reasonable way because the public server does not allow them and you can't set-up a private one because parts of the build service itself are proprietary software. Thus it generally makes more sense for such packagers to use their own build system instead and invest their time there.
We definitely need better communication across community packagers.. or rather, all packagers. I really hoped openSUSE would be a channel for that, but it didn't happen,
Isn't this the point of the buildservice? What's the problem?
Communication problems are always a social problem in the first place. Tools can only provide some assistance here. If someone really designed the build service as a solution for _this_ problem then he actually has no clue about the problem.
- newer versions of packages shipped with SUSE Linux
Let me pick a few good examples from my repository: - amarok: the SUSE package is outdated (1.3.8, newest is 1.4.3), and the BS package is crippled (no MP4 tagging support, no MySQL support, no PostgreSQL support)
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
Some tools (e.g. YaST) allow to install single packages with their dependencies without the need to install _everything_ in a repository. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Thursday 21 September 2006 3:57 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 02:21:11PM -0300, James Oakley wrote:
On Wednesday 20 September 2006 9:38 pm, Pascal Bleser wrote:
James, I said we *try*. You tell me 3 packages, I can probably give you a good dozen (at the very least) that are being built in the BuildService and where I never got a single notification, whatsoever.
That's actually a good reason to use the buildservice. You only have to make one search to avoid duplication.
If you also build packages for packages that are not under an OSS license or for a distribution that is not included, you cannot use the build service in a reasonable way because the public server does not allow them
That's a very small minority of packages. That's no reason to shun it altogether.
and you can't set-up a private one because parts of the build service itself are proprietary software.
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
Thus it generally makes more sense for such packagers to use their own build system instead and invest their time there.
So we all have private build systems that we don't publish the source for? Yes, I'm guilty of that myself, having built multiple systems... What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
Isn't this the point of the buildservice? What's the problem?
Communication problems are always a social problem in the first place. Tools can only provide some assistance here. If someone really designed the build service as a solution for _this_ problem then he actually has no clue about the problem.
We have this mailing list, which we didn't have before, so we're actually talking. What do you think would need to change in the buildservice?
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
Some tools (e.g. YaST) allow to install single packages with their dependencies without the need to install _everything_ in a repository.
Yes, but I'm talking about the effects of apt/smart/yum/rug *upgrade*, which will update everything it sees. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2006-09-21 16:41:06 -0300, James Oakley wrote:
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
and why not use the current build service as is?
What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
sure. go ahead and provide such backend.
Yes, but I'm talking about the effects of apt/smart/yum/rug *upgrade*, which will update everything it sees.
package managers should not replaceuser brain. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Sep 21, 2006 at 10:16:20PM +0200, Marcus Rueckert wrote:
On 2006-09-21 16:41:06 -0300, James Oakley wrote:
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
and why not use the current build service as is?
Read my mail he was replying to and you will get the answer.
package managers should not replaceuser brain.
Very good point. ;-) Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Thursday 21 September 2006 5:16 pm, Marcus Rueckert wrote:
On 2006-09-21 16:41:06 -0300, James Oakley wrote:
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
and why not use the current build service as is?
Not all packages can be provided.
What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
sure. go ahead and provide such backend.
Ok.
Yes, but I'm talking about the effects of apt/smart/yum/rug *upgrade*, which will update everything it sees.
package managers should not replaceuser brain.
Not everyone knows what "alsa" is or whether it should be upgraded or not. Due to the lack of certain multimedia packages in SUSE, complete newbies are encouraged to use other repositories that may or may not cause side-effects. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2006-09-22 10:42:46 -0300, James Oakley wrote:
On Thursday 21 September 2006 5:16 pm, Marcus Rueckert wrote:
On 2006-09-21 16:41:06 -0300, James Oakley wrote:
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
and why not use the current build service as is?
Not all packages can be provided.
and thank makes you toss it for all packages? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Friday 22 September 2006 10:47 am, Marcus Rueckert wrote:
On 2006-09-22 10:42:46 -0300, James Oakley wrote:
On Thursday 21 September 2006 5:16 pm, Marcus Rueckert wrote:
On 2006-09-21 16:41:06 -0300, James Oakley wrote:
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
and why not use the current build service as is?
Not all packages can be provided.
and thank makes you toss it for all packages?
No, but others want to. I'd like to find a solution. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, Sep 21, 2006 at 04:41:06PM -0300, James Oakley wrote:
On Thursday 21 September 2006 3:57 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 02:21:11PM -0300, James Oakley wrote:
If you also build packages for packages that are not under an OSS license or for a distribution that is not included, you cannot use the build service in a reasonable way because the public server does not allow them
That's a very small minority of packages. That's no reason to shun it altogether.
Whether this is a minority of packages depends on what you are working on. But even if it is a minority I don't want to use two different tool sets.
and you can't set-up a private one because parts of the build service itself are proprietary software.
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
I an not sure whether it was ever really promised or not. It is just that I expected Novell to use an open development model when they announced _open_SUSE but aparently I was wrong and this is not what they wanted. What we have now is public test versions, a black-box build system and some communication channels. Those things are all nice and actually it is totally legitimate for Novell to open stuff whenever they like but what they are currently doing is definitely not what I would consider _open_ and thus the "open" in openSUSE seems to be missleading in my opinion.
Thus it generally makes more sense for such packagers to use their own build system instead and invest their time there.
So we all have private build systems that we don't publish the source for? Yes, I'm guilty of that myself, having built multiple systems...
That's exactly how it will work in my opinion until someone provides a system that is really open and does provide a new value.
What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
Well, I _had_ some big interest in integrating know-how from a project I am involved in into an open build system and then use this as a base for the project. Since the build service did not seem to become that open system we now have reached a level where switching to what the buildservice currently provides would be a big regression for us. So building a BS-compatible backend would be of some limited interest to me at the very moment. Since I am currently in a phase of changing employer, it might happen that this changes with the interest of my future employer.
Isn't this the point of the buildservice? What's the problem?
Communication problems are always a social problem in the first place. Tools can only provide some assistance here. If someone really designed the build service as a solution for _this_ problem then he actually has no clue about the problem.
We have this mailing list, which we didn't have before, so we're actually talking.
Yes, that's one step forward.
What do you think would need to change in the buildservice?
I didn't want to change anything with what I said here but wanted to say that a _tool_ does not _solve_ this problem, however you design it.
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
Some tools (e.g. YaST) allow to install single packages with their dependencies without the need to install _everything_ in a repository.
Yes, but I'm talking about the effects of apt/smart/yum/rug *upgrade*, which will update everything it sees.
Ok, but then this is obviously not the right way to use his repository (as well as mine). For my repository the philosophy is quite simple: Everything I build and can be published will be put into the repository. If someone likes it he could use it, if he does not like it he should skip this package. I am open to suggestions about packaging style or things like that but I might have reasons not to implement them. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
On Thursday 21 September 2006 6:10 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 04:41:06PM -0300, James Oakley wrote:
On Thursday 21 September 2006 3:57 pm, Robert Schiele wrote:
On Thu, Sep 21, 2006 at 02:21:11PM -0300, James Oakley wrote:
If you also build packages for packages that are not under an OSS license or for a distribution that is not included, you cannot use the build service in a reasonable way because the public server does not allow them
That's a very small minority of packages. That's no reason to shun it altogether.
Whether this is a minority of packages depends on what you are working on. But even if it is a minority I don't want to use two different tool sets.
Then let's build one set we can all use.
Yes, that is a problem. Backend source was promised, but not delivered. I'd be one of the first to download and use it if it were released.
I an not sure whether it was ever really promised or not. It is just that I expected Novell to use an open development model when they announced _open_SUSE but aparently I was wrong and this is not what they wanted. What we have now is public test versions, a black-box build system and some communication channels. Those things are all nice and actually it is totally legitimate for Novell to open stuff whenever they like but what they are currently doing is definitely not what I would consider _open_ and thus the "open" in openSUSE seems to be missleading in my opinion.
I'm more optimistic, myself. The distribution meetings are a good sign.
Thus it generally makes more sense for such packagers to use their own build system instead and invest their time there.
So we all have private build systems that we don't publish the source for? Yes, I'm guilty of that myself, having built multiple systems...
That's exactly how it will work in my opinion until someone provides a system that is really open and does provide a new value.
Ok. Let's fix it.
What if we started in on a BS-compatible backend? I'll have some time next week to start in. Is anybody else interested in such a thing?
Well, I _had_ some big interest in integrating know-how from a project I am involved in into an open build system and then use this as a base for the project.
I also had plans to consolidate my build systems into a better one for public consumption, but never got around to it. When SUSE's system was announced, I decided that it was better to join that community than distance myself from it.
Since the build service did not seem to become that open system we now have reached a level where switching to what the buildservice currently provides would be a big regression for us.
What's lacking? What do we need to do?
What do you think would need to change in the buildservice?
I didn't want to change anything with what I said here but wanted to say that a _tool_ does not _solve_ this problem, however you design it.
I understand that tools do not solve problems, but they can help by making it easier to collaborate.
Ok, but then this is obviously not the right way to use his repository (as well as mine). For my repository the philosophy is quite simple: Everything I build and can be published will be put into the repository. If someone likes it he could use it, if he does not like it he should skip this package. I am open to suggestions about packaging style or things like that but I might have reasons not to implement them.
Leaving repositories unsubscribed in rug works, but not everyone uses rug. I'd prefer separate repositories, which is something that's easy to do in the buildservice. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Oakley wrote:
On Wednesday 20 September 2006 9:38 pm, Pascal Bleser wrote:
James, I said we *try*. You tell me 3 packages, I can probably give you a good dozen (at the very least) that are being built in the BuildService and where I never got a single notification, whatsoever.
That's actually a good reason to use the buildservice. You only have to make one search to avoid duplication.
What search function ? ;)
At least the following people try hard to avoid duplication or merge/reconcile when it happens: - the packman team - oc2pus (just joined the packman team) - my repository (and that probably accounts for 70% of the SUSE Linux packages coming from the community, so that's already quite good)
I try very hard as well. I won't distribute something that I know you guys already have.
So, how do we reconcile?
Good question. An ideal solution would be to have some sort of package database with a search frontend and it would then show a reference to the repository that has it. Problem is, it cannot be hosted @ novell/opensuse.org because it would reference packages like ... you know which ones ;)
We definitely need better communication across community packagers.. or rather, all packagers. I really hoped openSUSE would be a channel for that, but it didn't happen,
Isn't this the point of the buildservice? What's the problem?
No I really mean communication between human beings (or bots ;)). Email, IRC, whatever. ...
Let me pick a few good examples from my repository: - amarok: the SUSE package is outdated (1.3.8, newest is 1.4.3), and the BS package is crippled (no MP4 tagging support, no MySQL support, no PostgreSQL support)
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
Yes and no. I'm really not sure it's the best approach. For someone who wants to use the latest versions of a lot of packages, that's a lot of repositories to subscribe to. No issue for somewhat experienced users, but every day I can see people struggle to even add the packman repository to their yast2. Yes, it's dead simple, no, they can't do it without assistance.
- liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5 - lftp: 10.1 ships 3.4.0, latest stable is 3.5.4 - xchat: 10.1 ships 2.6.1, latest stable is 2.6.6 and I could go on.
Yes, there are always newer versions of any software. However, some of us may want newer versions of one package, but not others. The buildservice makes separation of projects or topics really easy.
To me, the build service misses some key features to make it usable by beginners (the stuff I posted earlier in this thread). + there are a lot of packages we cannot maintain in the BS for the reasons we all know ...
"for no good reason" - wth ? Are you really telling me that no one should have amarok 1.4.3 as an option, but stick with 1.3.8 instead because it has been tested by the SUSE QA team ?
No. I use your Amarok. I was talking about ALSA, and stuff like imlib2, libogg, and curl that has the potential to break other software since they're linked to. There's no good reason to upgrade these things willy-nilly. If there's a bug, it should be reported to SUSE.
That's one option, but not necessarily everyone's preference. As long as it doesn't break the .so number, newer version is fine with me, at least for some packages.
I'd knew a lot of people who would switch distros if it was like that. The "latest stable KDE" repository in the Build Service is also used by a significant number of users... "for no good reason" ?
Yes, but not everyone uses Factory, which does have the latest versions of *all* software. The ability to have separate repositories is the key here.
I don't know, I don't think so. Or rather, it depends... lol If you look at KDE, Subversion or Apache, sure. If you look at my repository... how could I possibly split $ find . -type f -name '*.rpm' -a ! -name '*.src.rpm'|wc -l 10660 ?
If people want to stick with a fully tested system that works fine for them, only use the stock SUSE packages, fine. If people want the features of newer versions of some packages they use often, then they can get them from packman, guru, oc2pus, and many others.
Ideally, they could get them from one place, in categories, like the build service.
Possibly. But it's not easy to use as it is now for less experienced users. (btw, we really miss installation_sources -a on 10.1)
I don't see what this has to do with "versionitis". Our work is a vital part of the SUSE Linux ecosystem. Labeling that "versionitis" is just name-calling.
As you said above:
liferea: 10.1 ships 1.0, latest stable is 1.0.23, latest beta is 1.1.5
You're saying that larger numbers are better. I don't doubt that there are bugfixes and new features, but those things can have unintended effects. How about a real world example?
A few years ago, a vulnerability was found in a version of openssh. SUSE and the other major vendors fixed the problem and patched the existing version. The openssh guys responded by releasing a new version with a part of the auth system re-worked. This new, "better", version had an even bigger vulnerability. Everybody who blindly upgraded had to upgrade again, while those of us who played it safe were just fine.
James, I know this. But for that example, I can give you 5-15 packages every single day that do not break nor create new security issues. A single case hardly makes a rule.
It's almost surprising, but given how few time I can invest into testing the packages I maintain and how many people use them, issues are really, really rare, and the same is to be said for packman. So I guess that 1) the developers are doing a pretty good job, 2) we're possibly not that bad at packaging.
I was not trying to criticize your abilities. You all do a great job and I *do* benefit from your work. I just can't help but cringe when I see newer versions of base libraries in your repositories. It's too risky for me.
Categorization and single repos is tough for me to manage. Way too many packages and not enough categories for all that.
And as far as sticking with SUSE package versions and not breaking systems, I can remember usr-local-bin gnome packages being poison for anyone not really experienced with it, so none of us is perfect,
They were all part of GNOME, so users adding his repository knew what kind of packages they were getting, and how much of their system was affected.
This is one of the reasons I like the buildservice. You can separate things into different repositories so everybody is clear about what they're getting.
it is. But still, dubbing the packman repository as being bleeding-edge stuff that nukes anyone but experts' systems is both untrue and somewhat offensive.
I didn't say that. I just said that some upgraded packages have possible unintended side-effects, which can break things. It happened to me with Packman's alsa.
Which is why I said: shit happens (and will happen again).
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Thursday 21 September 2006 6:14 pm, Pascal Bleser wrote:
What search function ? ;)
That's being worked on. The build service is still under development, obviously.
So, how do we reconcile?
Good question. An ideal solution would be to have some sort of package database with a search frontend and it would then show a reference to the repository that has it. Problem is, it cannot be hosted @ novell/opensuse.org because it would reference packages like ... you know which ones ;)
That's a good idea. There have been places like rpmfind and rpmseek, but they were not ideal for various reasons. I already committed myself to building a backend in the short term, but I would like to return to this at some point...
We definitely need better communication across community packagers.. or rather, all packagers. I really hoped openSUSE would be a channel for that, but it didn't happen,
Isn't this the point of the buildservice? What's the problem?
No I really mean communication between human beings (or bots ;)). Email, IRC, whatever.
Yes I know. We *are* talking through the buildservice mailing list, are we not?
That's fine, I use your Amarok builds. However, it would be nice to be able to subscribe to an "Amarok" repository and not worry about something I don't want sneaking in.
Yes and no. I'm really not sure it's the best approach. For someone who wants to use the latest versions of a lot of packages, that's a lot of repositories to subscribe to.
Provide a global repository as well. Someone requested that very feature in the BS a while back.
Yes, there are always newer versions of any software. However, some of us may want newer versions of one package, but not others. The buildservice makes separation of projects or topics really easy.
To me, the build service misses some key features to make it usable by beginners (the stuff I posted earlier in this thread).
We have the source to the frontend, so we can add any missing features. All of the other existing systems, including yours and Packman's are completely closed.
+ there are a lot of packages we cannot maintain in the BS for the reasons we all know
Ok. Maintain them somewhere else, but keep it open.
No. I use your Amarok. I was talking about ALSA, and stuff like imlib2, libogg, and curl that has the potential to break other software since they're linked to. There's no good reason to upgrade these things willy-nilly. If there's a bug, it should be reported to SUSE.
That's one option, but not necessarily everyone's preference. As long as it doesn't break the .so number, newer version is fine with me, at least for some packages.
I've seen developers break things without bumping the soversion.
Yes, but not everyone uses Factory, which does have the latest versions of *all* software. The ability to have separate repositories is the key here.
I don't know, I don't think so. Or rather, it depends... lol If you look at KDE, Subversion or Apache, sure. If you look at my repository... how could I possibly split $ find . -type f -name '*.rpm' -a ! -name '*.src.rpm'|wc -l 10660 ?
You already did: http://linux01.gwdg.de/~pbleser/rpm-navigation.php That looks good to me.
Ideally, they could get them from one place, in categories, like the build service.
Possibly. But it's not easy to use as it is now for less experienced users. (btw, we really miss installation_sources -a on 10.1)
Yes, it would be nice to have a click-to-add interface. You could do that fairly easily with the repo files already generated in the buildservice: http://repos.opensuse.org/Apache/SUSE_Linux_Factory/Apache.repo
But for that example, I can give you 5-15 packages every single day that do not break nor create new security issues. A single case hardly makes a rule.
Sure, but don't you want to decrease risk? Not worrying about security issues is how machines get broken into.
Categorization and single repos is tough for me to manage. Way too many packages and not enough categories for all that.
You already did the work. See above.
I didn't say that. I just said that some upgraded packages have possible unintended side-effects, which can break things. It happened to me with Packman's alsa.
Which is why I said: shit happens (and will happen again).
Fine, but why do it if there's no good reason to do it? There was no good reason for a new ALSA package. -- James Oakley jfunk@funktronics.ca --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi Pascal,
Do I sound sad and somewhat disappointed ? you bet.
I'm sure there are quite a few gaps to close, and some of us still need to become more aware of community efforts. Thank you for your openness and constructive feedback. Regards, Peter -- SUSE LINUX Products GmbH Bug, bogey, bugbear, bugaboo: Research & Development A malevolent monster (not true?); Some mischief microbic; What makes someone phobic; The work one does not want to do. From: Chris Young (The Omnificent English Dictionary In Limerick Form)
participants (8)
-
Dominique Leuenberger -
Dr. Peter Poeml -
James Oakley -
Marcus Rueckert -
Pascal Bleser -
Pavel Nemec -
Robert Schiele -
Stefan Dirsch