The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
Meetings/Built Service 2005-12-12/transcript
--- 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 email@example.com 18:32 @<henne> and firstname.lastname@example.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