BST IRC SESSIONS-transcript-051212

From openSUSE

--- Log opened Mon Dec 12 16:59:31 2005
17:00 @<henne> Welcome to the openSUSE Build Server Team Q&A Session!
17:00 @<henne> Some technicality's:
17:00 @<henne> This channel is moderated during the time of the session.
17:00 @<henne> But it has +z set so the operators (but nobody else) can see what youre writing. So if you have a question or remark
just write it.
17:00 @<henne> The topics of this session are:
17:00 @<henne> The Build Service Team offsite meeting minutes: http://www.opensuse.org/BST_3linden_Minutes_en
17:00 @<henne> The Build Service Team technical whitepaper: http://www.opensuse.org/images/1/19/Oss_whitepaper.pdf
17:01 @<henne> I hope you have at least read them ;)
17:01 @<henne> The purpose of this session is to clear questions you might have about things said in these documents or about the 
project in general.
17:01 @<henne> Lets start with some introductions
17:01 @<henne> mls_: will you go first? :)
17:02 @<henne> ok then i go first
17:02 @<henne> most of you should know me im henne
17:02 @<henne> i work at SUSE r&d as a packager
17:02 @<henne> in the Build Service Team i have no specific task
17:03 @<henne> im just around packaging since a long time
17:03 @<henne> and in the suse community longer :)
17:03 @<henne> darix: please go
17:04 @<henne> darix: your introduction
17:04 @<darix> i am packager at suse r&d aswell. long term suse linux user and packager since quite some time. i will help my team at 
the backend part :)
17:04 @<darix> lrupp: next?:)
17:04 +<lrupp> o.okay.
17:05 @<darix> lrupp: just a short introduction
17:05 +<lrupp> please wait a minute - gaim and me are not really friends... ;-)
17:05 @<henne> god
17:05 @<henne> jw: go ahead
17:05 @<darix> lrupp: you can type
17:05 +<mls_> Argl ;-)
17:05 @<darix> that is enough :|
17:06 +<jw> lrupp was at least better with OpenOFFICE :-)
17:06 +<lrupp> so - hopefully it works now
17:06 +<jw> lrupp, your turn?
17:06 @<henne> guys
17:06 +<lrupp> I'm a member of the distribution team for about 4 month now. At this time my "main target" is CD-mastering
17:07 +<lrupp> ...and bug fixing of my packages... ;-)
17:07 @<henne> good. jw go ahead
17:07  * henne cracks the whip
17:08 +<jw> I am also with the SUSE dist team, a seasoned perl hacker and I am also reviewing licenses and legal stuff.
17:08 @<henne> mls_: no its your turn :)
17:08 +<jw> Those minutes from Baernfels were written by lrupp and myself.
17:08 +<mls_> Hi folks!
17:08 +<mls_> I'm one of the architects of SuSE's internal build system.
17:09 +<jw> I am currently spell checking mls's whitepaper .-)
17:09 +<mls_> I did many parts of the design of the openSUSE build service.
17:09 +<mls_> There's also a white paper about it available written by me.
17:09 +<mls_> (Sorry about the typos, it was put on out in a bit of a hurry.)
17:09 @<henne> cornelius
17:09 +<mls_> A improved version will come soon, thanks jw.
17:09 +<cornelius> I'm Cornelius. Some of you might know me from my KDE involvement.
17:09 +<cornelius> At SUSE I'm working in the tools team.
17:10 +<cornelius> I will work on getting the build service implemented, focusing on the frontend.
17:10 @<henne> can everybody from the BST please state theyr realname
17:10 @<henne> s/y/i/
17:10 +<mls_> Michael Schroeder
17:10 @<henne> Henne Vogelsang
17:10 +<jw> Juergen Weigert
17:10 +<cornelius> Cornelius Schumacher
17:10 @<darix> Marcus Rueckert
17:11 +<lrupp> Lars Rupp
17:11 @<henne> ok. there we go
17:11 @<henne> first question please :)
17:11 @<henne> remember. you can just ask your question. darix and i will pick them up
17:12 +<jw> where are our  teamleads? ro and freitag?
17:12 +<mls_> Who needs them ;-)
17:12 @<darix> yaloki: first question?
17:12 @<henne> first question from liviudm
17:12 @<henne> Projects based on SUSE Linux will be able to use the openSUSE Build System?
17:13 @<henne> who wants to answer?
17:13 +<mls_> What do you mean by that question?
17:13 @<darix> mls_: i think he refers to projects like SUPER/SLICK.
17:13 +<mls_> A project compiling on suse will still compile in the build service.
17:14 @<henne> second question: a question to jpackage RPMs: will the jpackage structure be used in opensuse for all java-related-RPMs  ?
17:15 @<darix> as mentioned in the white paper from Michael Schroeder we have a layering modell for projects. So SUPER would a project 
that depends on our base distribution and add their own patches and fixes.
17:15 @<henne> <liviudm> I have a project, SESUSE. Unfortunately I don't have a powerfull computer to compile all that stuff. gcc took
me 8 hours. I will be very happy if I could use this system to build at  least the most time consuming parts of the distribution
17:15 @<darix> so the answer is yes. :)
17:15 +<mls_> Same goes for jpackage
17:16 +<mls_> You can use any structure you like as long as it compiles
17:16 @<darix> oc2pus asked: a question to jpackage RPMs: will the jpackage structure be used in opensuse for all  java-related-RPMs  ?
17:16 @<darix> oc2pus: our java rpms already follow that layout. :)
17:16 +<mls_> Whether the package will get into "main" openSUSE is a different question
17:16 +<jw> jpackage clobbers the namespace with lots of short names. I don't like that much.
17:17 @<darix> henne: next?
17:17 +<mls_> (Don't we already use jpackage structure in 10.0?)
17:17 @<henne> oc2pus: does that answer your question?
17:17 @<henne> mls_: we do
17:17 @<darix> mls_: yes.
17:17 @<henne> <oc2pus> in part's, yes
17:18 @<henne> a question from houghi
17:18 @<henne> How easy will it be to add your own sources e.g. makeSUSEdvd?
17:19 +<cthiel> houghi: if you like to add it as a package, it will be very easy... ;)
17:19 @<henne> right. thats the first and only thing you have to have
17:19 @<henne> a package
17:19 @<henne> or rather a spec file that buildsa
17:19 +<cthiel> houghi: if you just want to add the functionality of makeSUSEdvd, it don't think the build service place to add it
17:19 @<henne> -a
17:20 @<darix> I see the paper mostly mentions software developers as the main target, but I think the focus  might be wrong there, as 
packaging is a very specific topic and requires a lot of know-how  about the distribution. In the paper I mostly see stuff about 
software authors but nothing  about packagers.
17:20 @<darix> question from yaloki
17:21 @<darix> yaloki: is that the complete question?:)
17:22 @<henne> yaloki: ?
17:22 +<mls_> Well, maybe you should substitute some of the "software authors" in the paper with "packagers"
17:22 @<henne> yaloki: i think your right. software authors are mostly not the packagers
17:23 @<henne> yaloki: but those are just terms in the whitepaper
17:23 +<mls_> Well, maybe the build systems helps to make more authors packagers ;-)
17:23 @<henne> we hope so
17:23 @<henne> ok next question
17:23 @<darix> henne: your turn
17:23 @<henne> again from liviudm
17:23 @<henne> Another question: Will Novell AutoBuild or the new Build system go open source?
17:24 @<henne> let me answer that
17:24 +<mls_> Good questions. The "forces in power" are deciding this right now.
17:24 +<mls_> Sorry henne
17:24 @<henne> right. were not sure what we are going to do now
17:24 @<henne> this is all in a very early state
17:24 +<cthiel> but if you read the minutes, you'll find out that we are pushing for open source ;)
17:24 +<mls_> many parts will be open source.
17:25 @<darix> question from netmask: Mandriva uses an automatic package validation scheme called 'rpmlint', which runs over the  
package and checks for constraints over packaging rules like description format, pkg group,  file permissions, dependencies and such...
will that be handled on the new suse build system  too?
17:25 @<darix> bugfinder: maybe a turn for you?
17:25 +<bugfinder> yes, rpmlint is used as well
17:26 +<bugfinder> probably with a "localized" configuration, but we run rpmlint
17:26 +<bugfinder> actually this is only one means of what we call "build-checks"
17:26 @<henne> a question from benJIman
17:26 +<mls_> (We do lots of this already in our current system)
17:26 @<henne> Could you clarify what is the intended destination for the packages once they are built. There is a mention of a RPM 
Repository Interface in the Minutes, Is it planned to have a  central meta-repository that links to where packages are actually hosted,
 or to have a central repository that others can mirror, or something else. Also are there any legal issues
17:26 +<bugfinder> some of these are implemented as brp-scripts, some external scripts and some in rpmlint
17:27 @<henne>  associatedwith this and how will they bce overcome?
17:27 @<henne> mls_: thats one for you
17:27 +<mls_> I guess it will be a central repository that gets mirrored
17:28 @<henne> follow up question from yaloki
17:28 @<henne> what about mad, lame
17:28 @<henne> jw: please
17:28 +<jw> ah, adrian is missing :-)
17:29 @<darix> jw: can you take that question?
17:29 +<jw> yes.
17:29 +<jw> novell cannot ship mp3 codecs for legal reasons.
17:29 +<jw> So, these packages have to be built by different packagers.
17:30 +<jw> We will probably not be able to monitor and provide assistance with all your packages.
17:30 +<jw> so you are on your own there.
17:30 @<darix> question from netmask:
17:30 @<darix> no docs on the wiki mentioned (at least I didn't see) if a changelog will be written after  detection of parent project 
changes, patch changes, or anything... if I understand correctly,  the build system will rebuild automatically, let's say, 'mrtg', if 
'gd' changed, so something  needs to be written on change log like "AutoRebuild: parent project 'gd' changed" or something
17:30 @<henne> ok lets go into discussion mode
17:30 @<darix>  like tat... will that ber handled automatically or the packager
17:31 +<yaloki> ok, let me repeat, jw, this is not a satisfactory answer ;)
17:31 +<yaloki> we know that. this means that there must be some way to mark some packages as not exportable to repositories but must 
be downloadable by the maintainers to be hosted elsewhere. Would that be possible ?
17:31 @<henne> yaloki: no
17:31 +<jw> possible is everything. I cannot say much more in a public forum like that. sorry.
17:31 @<henne> yaloki: as soon as we know about it we will remove these packages
17:32 @<henne> as they are illegal
17:32 +<yaloki> providing them in a repository is illegal
17:32 @<henne> guys
17:32 +<yaloki> ok, whatever, we'll discuss that elsewhere or later, next question ;)
17:32 @<henne> please understand that we are not able to answer these questions and you know why
17:33 @<henne> next question came from netmask again
17:33 +<mls_> Regarding the changelog: a package rebuild caused by a change in another package doesn't need a changelog entry.
17:33 +<mls_> Or do you mean "source links"?
17:34 @<henne> netmask?
17:34 +<mls_> The changelogs will get combined in that case.
17:34 +<mls_> I.e. the "link" will have a changelog entry that will be added to the specfile if the package is built.
17:34 @<henne> netmask asks: either source or dependency... how would you justfy a package rebuild if nothing changed? I mean, 
something has to clarify the need for the rebuild
17:34 +<mls_> No ;-)
17:35 +<mls_> I don'e need a changelog if the compiler was fixed.
17:35 @<darix> netmask: satisfied?:)
17:35 +<mls_> (i.e. a changelog in *every* package)
17:36 +<dragotin> I think the question was: "I mean, something has to clarify the need for the rebuild"
17:36 +<dragotin> and there is no answer to that yet
17:37 +<netmask> lets get an example, gtk changes, so some packages that claims "BuildRequires: gtk-devel" needs to be rebuilt... in 
that case, the last package (the one that needs gtk) won't change at all, just the buildrequires, so something needs to say "this 
package has been rebuild because the requirements changed"
17:37 @<henne> netmask: say that in the changelog?
17:37 +<mls_> Well, we might have a "reason of the last rebuild" in the UI. But I don't see a point of putting it the the changelog of 
the packages.
17:37  * henne neither
17:37 +<dragotin> no, not in the changelog, might get long ;-)
17:38 +<mls_> (That's the way we currently build packages - nobody complained so far)
17:38 @<darix> more questions?:)
17:38 @<henne> netmask: you might want to read chapter 5.2 from the whitepaper
17:38 +<netmask> that's why I mentioned just the direct BuildRequires
17:38 +<netmask> indirect requires won't need changelog entries
17:39 +<mls_> I.e. we may have a "rebuild history" for every package on the UI, but nothing in the package.
17:39 @<darix> next question from benJIman:
17:39 +<mls_> Dircet ones also need no changelog entries, trust me ;-)
17:39 +<netmask> mls_: I think that should do the trick... thanks
17:39 @<darix> Will the package manager that users will be using to obtain the packages be improved to cope  well with dynamic 
repositories, multiple mirrors, upgrades of specific projects etc
17:40 +<mls_> Hopefully ;-)
17:40 +<mls_> It's actually more a "must" feature.
17:40 @<henne> we are trying to keep that away untill we have a running prototype
17:41 @<henne> so there is not much to say about that "repository" client at the moment
17:41 @<henne> ok next question
17:41 @<henne> again from liviudm
17:41 @<henne> how can someone join the Build Server Team? Testing, configuration, development and other stuff like that...
17:42 @<henne> nobody?
17:42 @<darix> liviudm: i think that is most likely related on the Opensource status itself
17:43 +<mls_> Yes, I was about to answer the same.
17:43 @<darix> if we cant opensource it, it will be hard to let the community take part
17:43 +<dragotin> we will have open interfaces to the system
17:43 +<dragotin> there it will also be possible to implement own clients
17:44 +<dragotin> and if we once have an public accessible subversion, development will follow the rules
17:44 +<dragotin> that opensource projects are driven by
17:44 +<dragotin> IMO
17:44 @<henne> ok next question from yaloki
17:46 @<henne> another point: I see that the whitepaper lays out "neededforbuild" as being superior to "buildrequires". I don't agree 
to that because that makes it unportable. The RPMs should have  proper requires in the first place, to make transient requirements work
 properly. When using neededforbuild, spec files only work within the build system and are bound to a specific SUSE
17:46 @<henne>  Linux rlease, as it is now, baecause it includes too many packages
17:46 @<henne> when resolving neededformbuild. Community packagers don't work that way though, as most of use do "single source": one 
spec file for several SUSE versions. Question is: neededforbuild
17:46 @<henne> is set  and won't be discussed.. ?
17:46 @<darix> i will repeat the full question. there is a part missing:
17:46 @<darix> another point: I see that the whitepaper lays out "neededforbuild" as being superior to "buildrequires". I don't agree 
to that because that makes it unportable. The RPMs should have proper requires in the first place, to make transient requirements work 
properly. When using neededforbuild, spec files only work within the build system and are bound to a specific SUSE Linux release, as it
 is  now, because it includes too many packages when resolving ...
17:46 @<darix> ... neededformbuild. Community packagers don't work that way though, as most of use do "single source": one spec file 
for several SUSE versions. Question is: neededforbuild is set and won't be discussed.. ?
17:46 +<mls_> Huh?
17:47 +<mls_> The white paper says that "neededforbuild" will be replaced by "buildrequires". Isn't that what you ask for?
17:47 +<mls_> (Maybe the section was a bit unclear)
17:47 +<yaloki> erm... ok, sorry, that's not the way I understood it in the paper
17:48 +<yaloki> if it is, then fine, awesome ;)
17:48 @<henne> ok next question
17:48 +<mls_> The goal is that you *don't* have to write a list of all rpms.
17:48 @<darix> netmask again:
17:48 @<darix> it would be nice if the build logs are public too, so if I'm interested on  knowing the package history, but I'm not the
 maintainer neither a reviewer, I can track it  down for future reference :)
17:49 +<dragotin> build logs will be visible in the GUI
17:49 +<mls_> the build log of the last build. I don't think we will keep all of the old logs.
17:49 +<dragotin> well, good point ;-)
17:50 +<mls_> Basically we'll keep the logs as long as we keep the rpms.
17:50 @<henne> another question from netmask
17:50 +<mls_> (or .debs...)
17:50 @<henne> the "needforbuild" issue makes me think about the "multi-distro-driven" mentioned for the build system... how would you 
handle package name definitions across distros? not all will be LSB (I think even suse needs to get better on this issue), so there 
will be a lot of package naming issues on requires and build requires (like suse MozillaFirefox and Mandriva calling 
mozilla-firefox)... will the packager need to write each
17:51 +<mls_> Good point. We probably will have a package translation mechanism, so that you don't have to put lots of "%if" statements
 in the spec files.
17:51  * henne writes that down :)
17:51 +<mls_> We already have this for our "PLUS" trees, e.g. the KDE/GNOME update service
17:52 @<darix> netmask: satisfied?
17:52 +<mls_> The "jave"package is one example, it has lots of names depending on the architecture/version
17:52 @<darix> aka_druid_ had to wait a bit longer. sorry for that. the question:
17:52 @<darix> seems like the service as discribed in the minutes is a little complex and will need some  computaional resource. Is 
this infrasctructure available? And the coding is already been  done or we are in the planning stage right now?
17:53 @<darix> cornelius: maybe you can start?:)
17:54 +<cornelius> for the frontend we are currently starting to code.
17:54 +<mls_> coding: wellll, our "internal" system does many parts of it already, so it's kind of a rewrite to clean things up a bit.
17:54 +<cornelius> for the backend we of course rely on what we already have.
17:54 +<mls_> But we don't have any GUI, yet.
17:54 @<henne> and the hardware will probably come from a partner of novell
17:55 @<henne> aka_druid_: so to sum it up. were in the early stage :)
17:55 +<mls_> We already have some hardware. But the more the merrier ;-)
17:55 @<henne> question from schiele
17:55 @<henne> about the package translation mechanism
17:56 @<henne> Note, an alternative to translation tables could be allowing specifying the RPM dependencies (like files or shared 
objects)
17:56 @<henne> would that be possible?
17:56 @<henne> mls_?
17:56 +<mls_> I don't like that because you have to do much work to find out which package provides a file.
17:56 +<mls_> It would make things much more complicated implementationwise.
17:57 +<schiele> You could cache the information the same way you cache RPM symbols.
17:58 +<mls_> It's probably doable, but I don't think it's worth the hassle.
17:58 +<mls_> If it turns out that it helps a lot it can always be added.
17:59 @<henne> schiele: does that answer your question? :)
17:59 +<schiele> It does. Actually it was more a note than a question. ;-)
17:59 @<henne> thanks
17:59 @<henne> any more questions?
17:59 @<henne> did we forget one?
18:00 +<yaloki> is the concept of the build resources already layed out to be centralized ? what about having a decentralized, trusted 
model like debian has with automated builds and tests on hardware provided by trusted builders ?
18:00 +<yaloki> and, related to that, I think the trust model is a key issue, what are your current thoughts about it ? (I mean, how to
 implement it)
18:00 @<henne> yaloki: we talked about distributed builds
18:01 @<henne> yaloki: the thing with those is that it costs more to distribute then to build these days
18:01 +<yaloki> yes, but so does to submit the package for building into the openSUSE build server infrastructure ;)
18:02 @<henne> wait
18:02 @<henne> those are two things
18:02 @<darix> yaloki: you think in a to small scale. i think once your package is building for 9.x-10.x at the same time ... you will 
appreciate only 1 upload
18:02 @<henne> the one thing is ditributed build resources
18:02 @<henne> and the other thing are distributed build services
18:03 @<henne> as you can read in the meeting minutes we want the build service decentralized
18:03 @<henne> but that of course is also a question of opensource or not
18:03 +<yaloki> exactly
18:03 +<bugfinder> and it will be possible to do a local build for own testing (as it has been possible before)
18:04 +<yaloki> ok
18:04 +<yaloki> given it's opensourced
18:04 +<yaloki> ok, thanks
18:04 @<darix> yaloki: the client part will be most likely
18:04 @<henne> any more questions?
18:04 @<henne> oh i forgot the trust model question
18:05 @<henne> yeah
18:05 @<darix> henne: why did you devoice klaas?:)
18:05 +<dragotin> I think we do not have a very detailed plan about the trust model yet
18:05 @<henne> lrupp: can you answer that?
18:05 +<dragotin> yaloki: input is very appreciated
18:06 +<dragotin> darix: I was cool enough to fly out of the channel and devoice me myself ;-)
18:06 @<darix> ah
18:06 @<henne> yaloki: thats one of the things we need to discuss in detail on the mailinglists
18:06 @<henne> yaloki: we dont have anything there
18:06 +<mls_> With the "layering" model, a project and packages in the project cannot be more trustworthy as the projects it is layered
 on.
18:07 @<henne> ok
18:07 @<henne> any other questions?
18:07 +<mls_> But we don't have a concept (yet) where users and projects an earn trust levels or something like that
18:07 +<mls_> (But you can always trust the openSUSE Factory packages ;-)
18:07 @<henne> ok a question from sPiN
18:08 @<henne> i just came in on this so let me know if this is offtopic or covered in the witepapers, distrubuted building.. is this 
like how gentoo allows you to form a cluster of sorts to build packages faster?
18:08 @<henne> sPiN: no :)
18:09 @<darix> sPiN: the current build system already has solutions for that. like icecream
18:09 @<darix> yaloki> how about having stronger guidelines and policies on how to write spec files for SUSE, such as  Debian or Fedora
 has ?
18:09 @<henne> bugfinder: can you take that one?
18:09 +<mls_> Yes, we'll need that.
18:10 +<bugfinder> well, some of the questions never were an issue internally, since all specfiles were preprocessed
18:10 +<bugfinder> since we probably won't want this for the buildserver, we'll have to do lots of this manually by writing docs and 
running check-scripts
18:11 +<yaloki> yes but with the involvement of packagers from the community...
18:11 +<mls_> Of course you will be able to do what you like, we don't restrict you (as long as it builds)
18:11 +<bugfinder> instead of replacing and re-arraning things inline
18:11 +<yaloki> yes, well, validation is one thing, but having stronger guidelines is another, like doing autoreconf -fi, using 
%suse_update_desktop_files, etc...
18:11 +<bugfinder> depends on what you include in guidelines
18:11 @<henne> yaloki: thats another social engeniering thing we need to figure out
18:12 @<henne> yaloki: A) trust system B) Quality assurance
18:12 +<bugfinder> lots of these just come with the checking scripts, others evolve with the set of architectures included (for 
autoconf ...)
18:12 +<yaloki> the point is that, with having packagers coming from the community, not everyone has the same experience with packaging
 on SUSE, and the stronger the guidelines, the better maintainable they are.
18:12 +<yaloki> and the easier it is to write toolchains to validate or generate
18:13 +<bugfinder> yes, I see the bigger problem in keeping the guidelines from growing to a 1000p document ...
18:13 +<yaloki> ok, you're aware of it and agree we need to figure out something, that answers my question. thank you.
18:13 @<henne> ok two more questions
18:14 +<mls_> Those guidelines are only necessary if the maintainers want to push their package in "higher" trust levels, ie. openSUSE 
Factory.
18:14 @<henne> i need a smoke 8)
18:14 @<darix> henne: junkie!
18:14 @<darix> benJIman: ask your question
18:15 @<henne> benJIman?
18:15 +<benJIman> regarding yaloki's comments about some packagers having more experience packaging for suse, have you considered aving
 trusted packagers who could moderate out or correct dodgy packages?
18:15 @<darix> hm
18:15 @<darix> have you considered having trusted packagers who could "moderate" out or correct dodgy  packages?
18:16 @<henne> ok something fundamental that seems not clear to me
18:16 @<darix> it seems freenode has some difficulties again.
18:16 +<dragotin> that's part of the trust system, right?
18:16 @<darix> dragotin: yes.
18:16 @<henne> yes. part of the trust/rating system
18:16 @<henne> we need to define that together
18:17 +<mls_> You talk about openSUSE Factory?
18:17 @<darix> mls_: i think the trust model in general
18:17 +<mls_> Current concept: The project maintainers can modify the sources of packages belonging to the project.
18:18 +<mls_> You can add other maintainers to single packages, so that they can modify it (and only it)
18:18 +<dragotin> maybe something like ' [] allow packagers from level SuperPackager and above to fix my package '
18:18 +<dragotin> in the project management page
18:19 +<mls_> Yes, maybe something like that.
18:19 +<dragotin> and with various levles
18:19 +<dragotin> just a quick idea
18:19 +<mls_> We need trust levels first ;-)
18:19 +<dragotin> yes, sure, a concept ;-)
18:19 @<henne> ok as you can see we need to figure out the trust system/rating system
18:20  * henne puts that onto his agenda
18:20 @<henne> question from netmask and then the last question from yaloki
18:20 @<darix> netmask: your turn
18:20 +<netmask> how would you handle rpm macros on the multi-version-multi-distro issue? there could even be some suse macros present 
on 10.0 but not on 9.3... would you think about that 'translation' thing too?
18:21 @<henne> mls_?
18:21 @<darix> bugfinder?
18:21 +<mls_> Macros. Ok, my vision about that.
18:21 +<mls_> Every project can define its own macros.
18:21 +<mls_> If you layer a project macros will get concatenated so that you get all the macros of the lower layers but can overwrite 
them
18:22 @<darix> mls_: done?:)
18:22 +<mls_> I'm not sure if we should do the translation by using rpm macros, as they won't be expanded in the source rpm.
18:23 +<netmask> ok, so you mean that macros from 10.0 used on spec files to be built on 9.3 will get auto copied, or the packager will
 have to write some sort of .rpmmacros for that?
18:23 +<mls_> But I'm pretty undecided about the translation stuff, so you may be able to convince me ;-)
18:24 +<mls_> No, the 10.0 project will come with the 10.0 macros, the 9.3 project will have 9.3 macros and so on
18:24 @<henne> netmask: but youre talking about suse_macros
18:24 @<darix> netmask: everything cleared?
18:24 +<netmask> I didn't suggest the translation :) 13:52 <+mls_> Good point. We probably will have a package translation mechanism
18:24 @<henne> netmask: you probly have to do that as you are doing it right now
18:24 @<henne> netmask: with %if's
18:24 +<mls_> If you base your project on the 10.0 project you'll automatically get all the 10.0 macros.
18:25 +<netmask> ok, but it's similar to the package naming issue, thus I mentioned the translation thing
18:25 +<mls_> We currently don't do it with %ifs, but have a overengineered neededforbuild translation engine ;-)
18:25 @<darix> i wonder whoms fault that is
18:25 @<darix> :p
18:25 @<henne> and specs are for single distributions...
18:26 +<netmask> so it's another thing to be discussed later...
18:26 @<darix> netmask: everything cleared?
18:26 +<mls_> No, we have specs for multiple distributions, all the stuff in PLUS (KDE/Gnome)
18:26 +<netmask> clear
18:26 @<henne> netmask: satisfied?
18:26 +<netmask> k
18:26 @<henne> thank you
18:27 +<yaloki> key question: will packagers (with a high trust level, obviously) from the community be able to contribute packages 
into factory ? or contribute on packages that are in factory ? (as the SUSE Linux product management still decides about what gets into
 the SUSE Linux distro, which is fine)
18:27 @<darix> pascal your turn.
18:27 +<cthiel> yaloki: sure
18:27 +<yaloki> ok, just wanted to see that as a clear statement for everyone :)
18:27 +<mls_> They can "submit" i.e. propose packages for transfer to factory.
18:27 @<henne> yaloki: did you read the whitepaper chapter 4?
18:28 +<mls_> The factory maintainers then look at the diff and decide if the package meets the opensuse policies
18:28 @<darix> yaloki: guess why i invite you all the time on cooperating on packages we have both :)
18:28 +<mls_> If everything is fine it gets copied into opensuse.
18:28 +<yaloki> ok, thank you
18:28 +<mls_> But it's not a big deal if a package is not in factory
18:29 @<henne> alright
18:29 @<henne> that was it
18:29 +<mls_> That's one of the main points of the build system, that it's easy to create different projects
18:29 +<mls_> so that the user can decide which project he needs
18:30 +<mls_> It's more a QA thing: if it's in opensuse somebody else looked at it.
18:30 +<mls_> So it has a higher trust level.
18:30 @<henne> yaloki: does that answer your question?
18:31 +<yaloki> henne: yes it does, thank you Michael
18:31 @<henne> ok i think we can call it a day now
18:31 @<henne> thank you all for participating and for the nice questions
18:31 +<mls_> Oh "opensuse" in my comment should be "factory"
18:32 @<henne> i hope we could answer some of them
18:32 @<henne> you see that we still are in the early stage of making this build service a success
18:32 @<henne> and you can all participate in making it better
18:32 +<yaloki> could we just please have mentioned that the concept will be further discussed on opensuse-packaging ?
18:32 +<dragotin> thanks henne for moderation :)
18:32 @<henne> lokk out for BST topics on opensuse@opensuse.org
18:32 @<henne> and opensuse-packaging@opensuse.org
18:32 +<yaloki> ok, thanks
18:33 @<henne> alright
18:33 @<henne> thanks
18:33 +<cthiel> thx for your time everyone...
--- Log closed Mon Dec 12 18:33:39 2005