mentors.debian.net reloading
Valued community... We have been running mentors.debian.net for years already and I really enjoy seeing how many people are using it. It was a lot of effort writing all the scripts and magic that makes the service useful although a lot may be hidden in the background. It is watching debian-devel-changes to see if packages were sponsored. It is monitoring downloads to give the package maintainer statistical information. It announces new uploads on IRC. It informs the Uploaders:. It does a lot of QA checks etc. Many parts of the site need improvement though and I received a lot of feature requests during the last months already. Unfortunately the Python code isn't something to be entirely proud of. So it makes sense to rethink and refactor its design instead of quickly adding dirty hacks to add features. I read Lucas Nussbaum's blog entry on [0] and while it comes up with only few things I did not yet have on the todo list I think he's right. And he motivated me to start working on the concepts these days. So the goal is to make mentors.debian.net a hybrid of what it currently is (with cleaner Python code) and a social networking site. I was also pointed at the svnbuildstat site [1] to gather ideas although it rather deals with how well the team-maintained packages build. And there is Ubuntu's effort of personal package archives [2] where their Launchpad application allows people to publish packages they upload. Last but not least we have the sponsors site [3] run by Neil McGovern which is also a classic in package sponsoring. I don't think we have many clashes with other services though. I wouldn't like to steal anybody's show. Least do I like to hear of other people making similar efforts. Competition is a good thing of course but I'd find it demotivating to offer a service and investing a whole lot of spare time only to find out to be in a race-condition with a competitive project. That would be a waste of time. I don't want to win a prize. I'd like to improve the service while making it more useful and having a little fun while doing that. So the reason I'm posting here is that I'd like to allow everybody to contribute ideas and perhaps even manpower to the redesign. In the past we have started the project as a team but since everyone else had their own priorities and since such a big project can't be coded in a month they lost interest so that in the end it was me poor guy being left alone. I don't mind that but I'd rather enjoy if other enthusiasts would have fun with concepts, database design, web design, Python/Pylons coding, doing user support etc. so that we may create an even better mentors site than it is now. I have summarized a current list of ideas on my wiki [4]. If you like to edit the page please register an account at the wiki and mail me your wiki name. Due to spamming the wiki is read-only for the public crowd by default. Feel free to drag items out of that list and discuss it here. I intend to create a few mockups in the next days so that it may become clearer what ideas I have on my mind. If you like to get your hands dirty feel free to subscribe to the mentors-ops [5] mailing list. Hopefully we'll get a nice team together and have some coding fun. Thanks for your time. Kindly Christoph [0] http://www.lucas-nussbaum.net/blog/?p=258 [1] http://svnbuildstat.debian.net/ [2] https://launchpad.net/ubuntu/+ppas [3] http://sponsors.debian.net/ [4] http://workaround.org/moin/MentorsTodoList [5] http://workaround.org/cgi-bin/mailman/listinfo/mentors-ops -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: ustr
Dear mentors, I am looking for a sponsor for my package ustr. * Package name: ustr Version : 1.0.1-1 Upstream Author : James Antill [EMAIL PROTECTED] * URL : http://www.and.org/ustr/ * License : LGPL, BSD, MIT Section : libs It builds these binary packages: libustr-1.0-1 - Micro string library: shared library libustr-1.0-1-dbg - Micro string library: debugging symbols libustr-debug-1.0-1 - Micro string library: shared library for debugging libustr-debug-dev - Micro string library: development stuff for debugging libustr-dev - Micro string library: development stuff libustr-doc - Micro string library: documentation The package appears to be lintian clean. The upload would fix these bugs: 447269 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/ustr - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/ustr/ustr_1.0.1-1.dsc I would be glad if someone uploaded this package for me. Ustr (Micro string library) is a string API for C. It has tiny overhead over just plain strdup(), is much safer, is easier to use, is faster for many operations, can be used with read-only or automatically allocated data. You don't even need to link to the library to use it (so there are no dependencies). The cdbs is used for packaging. Ustr is used in a new SELinux user space code in libsemanage, so ustr will be build-dependency for this probably. Sorry for my English. Maybe some texts in the package may need a correction. Kind regards -- Zito -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 26/10/07 at 11:42 +0200, Christoph Haas wrote: It does a lot of QA checks etc. Could you please describe what's currently being done wrt QA checks? I have summarized a current list of ideas on my wiki [4]. Any reason why wiki.d.o is not used for this? It would make it much easier for people to contribute. Some comments: Please seperate features list and implementation details: if you want other people to contribute, you might have to be flexible with things such as which framework/language you choose. Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing section of the source package - anything to consider?
Hi Daniel, * Daniel Leidert [EMAIL PROTECTED] [2007-10-26 09:09]: I simply want to change the section of the source package (from devel to science). Is there anything special I have to consider? Do I have to inform the ftp masters? No, if you upload a package with a changed section you will get a mail back describing an override disparity from the installer on ftp-master. You can then reply why this is correct and they will change the section in their list then. Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgp63jWieT36M.pgp Description: PGP signature
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 12:11:06PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 11:42 +0200, Christoph Haas wrote: It does a lot of QA checks etc. Could you please describe what's currently being done wrt QA checks? Done. See Uploading/Importer on http://wiki.debian.org/DebianMentorsNet I have summarized a current list of ideas on my wiki [4]. Any reason why wiki.d.o is not used for this? It would make it much easier for people to contribute. Right. Moved to wiki.debian.org. Some comments: Please seperate features list and implementation details: if you want other people to contribute, you might have to be flexible with things such as which framework/language you choose. Regarding frameworks: since I'm pretty active in the Pylons project and probably will have to do 50% of the work myself anyway (currently 99%) I chose the weapons. I hope others are more flexible and like my choice. :) The list is deliberately kept a bit sketchy. When it comes to planning the actual application I intend to have a thorough documentation. Right now it's more like mental notes on how to do certain things. Just ignore them if they don't make sense. Nothing is fixed on the list. But I won't turn a coffee machine into an nuclear power plant so some parameters are fixed. And it will have to be Python because otherwise even the utility libraries would have to be rewritten. It's not like we'd have to start entirely from scratch. Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. Might be helping the sponsor to determine if the package builds. But I'm not sure if it's worth it. Just my personal opinion. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 12:11:06PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 11:42 +0200, Christoph Haas wrote: It's time for me to introduct svnbuildstat.d.n :). I began to work on svnbuildstat 1,5 year ago. We, the Debian Games Team, saw the number of packages in our repository constently growing up (170 today). We were about 10 actives maintainers and it was had to find the packages to take care on. The initial release was based on a collection of shell script and pbuilder. The builds were done directly on my server. But there were some problems: * The tool was designed to fetch information from just one svn repository * They was no database and doing statistic stuff without a DB sucks big * time! * The shell scripts were hard to maintain * Resource expensive stuff were done directly on the webserver (the build, lintian, linda, piuparts) Some mouths after I rewrote from scratch what is the current svnbuildstat.d.n. This time it's based on a real database and a modern MVC framework. It's definitivly a better solution. I used : * Perl; * Catalyst, a MVC framework; * DBIx::Class a DB abstaction layer like Hebernate; * PostgreSQL (the DB is about 500MB today) * a collection of perl scripts to retrieve the different informations * a client/server model for the build/lintian/linda/piuparts. Just a * status file is returned to the server at the end of the process. Today, I'm working these point: * The agent does too much stuff, I want to split it to have one agent * per service (build, lintian, ...). Today, if I want to change the * lintian revision, I've to update of the build host and one of them is * behind a firewall. * Ondrej Certik is working on a patch for pbuilder to detect the no space on device errors. it's most of the false positive. * The DB schema needs some clean up. I already did most of them (I wish:)). * being able to accept other sources of packages. I want to be able to retrive information for the rest of the VCS used in Debian but also from a pool of packages like mentors.debian.net or ftp.debian.org * RPC services. * Thanks to Ondrek Certif, svnbuildstat has a tutorial now on wiki.d.o but there is still a lot to do here * I want to get another server. Mine is a bit to slow. I think, svnbp should be (one day*) used as backend for http://mentors.debian.net/ but also for Lucas's QA check. *Like most of yours, I've a family, packages and softwares to maintain and a job. To be honest, it's hard for me the give a clear planning. The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat Regards, Gonéri signature.asc Description: Digital signature
Re: mentors.debian.net reloading
Hi, The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat I believe Debian needs the same as Ubuntu has: Personal Package Archives, where new maintainers could upload their source packages and the service will automatically build and check the package. And if the service says YES, it means the package will builds on buildd hosts and is lintian/linda/piuparts clean, all bugs are correctly closed, etc. etc.. I, as a user, need this feature, so that when I fix something in a package, or create a new one, can simply check it a little at my computer and then upload it to Debian PPA and it will do the rest of the checks for me. And if it says YES, I'll ask my sponsor to upload it. At the moment I need to do all of this by hand and it's very time consuming. And then my sponsor needs to do the same, to be sure I didn't make a mistake. With Debian PPA, my sponsor can easily be sure the technical things are ok and concenrate on QA. There is of course a question who will provide the resources for DebPPA. But as first step, all the building blogs should be as Debian packages, so that I can just install a few packages, setup a few config files and I'll be having my own DebPPA up and running. I started: http://code.google.com/p/debppa/ It contains links to all relevant discussions about this issue. But when I found svnbuildstat, I want to work with Goneri. As Gonéri said, we are trying to create such building blogs - a server that will accept source packages (I only need source packages, Goneri also needs input from VCS), and buildbots, that will do the compiling. As I see, we all have a little different views and what the service should or shouldn't be doing. But if we make sure we create robust and small building blocks, then all of us can easily set up a service that each of us wants. Ondrej
Re: mentors.debian.net reloading
It could be better. I just doubt that the private issue is the problem. Everybody who likes to get involved could always join the team. We are open. So it's really no giant master plan that the sources weren't made public yet. Perhaps with the relaunch we can start to make I think it is a major problem, that anyone who wants to create a similar things, like me, but for example providing the building and personal archives (that you don't want, or at least didn't want, because of the download bandwidth) has to reinvent everything from scratch. everything public right from the start. The only reason it's a one-man-show is that from our 3-people-team one (Ivo) is studying like hell and the other (Matthijs) is kept busy by his boss at work. I don't intend to be posessive here. mentors.debian.net was invented to improve the sponsorees' situation. I'm confident it has done that and believe that way more packages are sponsored instead of trashed. I wouldn't want to see it perish for no reason. But I'm also not the showstopper when it comes to changing things. There is no doubt mentors.debian.net is doing it's job and doing it well, so no need to perish it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 26/10/07 at 14:18 +0200, Christoph Haas wrote: Please seperate features list and implementation details: if you want other people to contribute, you might have to be flexible with things such as which framework/language you choose. Regarding frameworks: since I'm pretty active in the Pylons project and probably will have to do 50% of the work myself anyway (currently 99%) I chose the weapons. I hope others are more flexible and like my choice. :) The list is deliberately kept a bit sketchy. When it comes to planning the actual application I intend to have a thorough documentation. Right now it's more like mental notes on how to do certain things. Just ignore them if they don't make sense. Nothing is fixed on the list. But I won't turn a coffee machine into an nuclear power plant so some parameters are fixed. And it will have to be Python because otherwise even the utility libraries would have to be rewritten. It's not like we'd have to start entirely from scratch. Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. Might be helping the sponsor to determine if the package builds. But I'm not sure if it's worth it. Just my personal opinion. I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. Your emotion chip went a bit wrong, but not totally ;) I have the feeling that the lack of open-ness in mentors.d.n caused several people to reinvent it (with sponsors.d.n and REVU). Of course, it's not the only cause, but I have the feeling that mentors could be much better than it currently is, but isn't, because of the fact that it was developed privately. I hope that things will change, but everybody has to have an open mind if we want this to happen. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 14:18 +0200, Christoph Haas wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). Right. But although I used to sponsor a lot of packages hardly any of them actually failed to build. Mostly because the maintainer forget a certain dependency. But it's certainly possible to run pbuilder on the package. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. Your emotion chip went a bit wrong, but not totally ;) I have the feeling that the lack of open-ness in mentors.d.n caused several people to reinvent it (with sponsors.d.n and REVU). I know that several people have asked for the source code of mentors.debian.net and I always hesitated because in the beginning the code stunk and I feared security implications. (Yes, I believe that security by obscurity partly works.) sponsors.debian.net came up shortly *after* the time that mentors.debian.net was put online. And we talked about how to join forces in the early stages. REVU was developed a while after mentors.debian.net was launched. I'm not sure but I think mentors.debian.net was already there when nobody even talked about Ubuntu. Mark invited me to the Ubuntu conference in Mataro in 2004 after mentors.d.n was online for a while. It was the time that the MOTU process and REVU was planned. And IMHO REVU doesn't do as much as mentors.d.n - although it has a comment feature already. Of course, it's not the only cause, but I have the feeling that mentors could be much better than it currently is, but isn't, because of the fact that it was developed privately. It could be better. I just doubt that the private issue is the problem. Everybody who likes to get involved could always join the team. We are open. So it's really no giant master plan that the sources weren't made public yet. Perhaps with the relaunch we can start to make everything public right from the start. The only reason it's a one-man-show is that from our 3-people-team one (Ivo) is studying like hell and the other (Matthijs) is kept busy by his boss at work. I don't intend to be posessive here. mentors.debian.net was invented to improve the sponsorees' situation. I'm confident it has done that and believe that way more packages are sponsored instead of trashed. I wouldn't want to see it perish for no reason. But I'm also not the showstopper when it comes to changing things. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Hello, On Fri, 26 Oct 2007, Christoph Haas wrote: That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Perhaps this is not what your question is about but, ... One way is to use some package caching proxy like approx (which I use) to get the packages. Over time this builds itself a copy of the relevant portions of the Debian archive. Of course, since the builds are against unstable the cache gets out-of-date often but most of these caching tools are good at handling that. Regards, Kapil. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Hi, There is of course a question who will provide the resources for DebPPA. You could at least ping the experimental/backports/volatile people. I started: http://code.google.com/p/debppa/ Why on code.google.com? Is Alioth not good enough? Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On 26/10/07 at 16:06 +0200, Christoph Haas wrote: On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 14:18 +0200, Christoph Haas wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) It works fine, but takes some time. I ran piuparts several times over the whole archive, without running into severe problems. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). Right. But although I used to sponsor a lot of packages hardly any of them actually failed to build. Mostly because the maintainer forget a certain dependency. But it's certainly possible to run pbuilder on the package. What Ondrej proposes is to turn mentors into a package archive, where packages would be built automatically on several arches, and people could download them. In that case, it's required to build package for all archs available in the service (you can't ask the uploader to do that hmiself). -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: throttle
Dear mentors, I am looking for a sponsor for my package throttle. * Package name: throttle Version : 1.1-1 Upstream Author : James Klicman [EMAIL PROTECTED] * URL : http://klicman.org/throttle/ * License : GPL 2 or later Section : utils It builds these binary packages: throttle - bandwidth limiting pipe The package appears to be lintian clean. The upload would fix these bugs: 426891 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/throttle - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/throttle/throttle_1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Giovanni Mascellani -- Giovanni Mascellani [EMAIL PROTECTED] Pisa, Italy Web: http://giomasce.altervista.org SIP: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] / [EMAIL PROTECTED] GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) signature.asc Description: PGP signature
Re: mentors.debian.net reloading
On Fri, 26 Oct 2007, Christoph Haas wrote: Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. Might be helping the sponsor to determine if the package builds. But I'm not sure if it's worth it. Just my personal opinion. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. It is a rented virtual root server with enough power and 1 TB of free traffic that I pay for from my spare money. I think it would be able to do that if needed. I might get you wrong but to me you sound more like If you are incapable of running the service properly then let someone else step up instead of I think that test builds are important. If you agree but don't have the proper resources I can perhaps offer some computing power.. Sorry if my emotion chip got you wrong. I would like to briefly comment that if you want some compute time for something lke this, let me know. I see above that you think you should be okay, but should that ever change let me know; I'd be very happy to donate my spare cycles to making package sponsoring work better. I'm personally very much a fan of automatic testing/building of packages. -- Asheesh. -- I am not now, nor have I ever been, a member of the demigodic party. -- Dennis Ritchie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 04:51:01PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 16:06 +0200, Christoph Haas wrote: On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote: On 26/10/07 at 14:18 +0200, Christoph Haas wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) It works fine, but takes some time. I ran piuparts several times over the whole archive, without running into severe problems. I'll try that out. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). Right. But although I used to sponsor a lot of packages hardly any of them actually failed to build. Mostly because the maintainer forget a certain dependency. But it's certainly possible to run pbuilder on the package. What Ondrej proposes is to turn mentors into a package archive, where packages would be built automatically on several arches, and people could download them. In that case, it's required to build package for all archs available in the service (you can't ask the uploader to do that hmiself). Did Ondrej say that we need a public buildd? Actually that is something I would ratner not do because I have certain (very bad) experience with it. When we kept the uploaded binary (.deb) packages our support mailbox was literally flooded with end-users (!) complaints that the packages were buggy. They used it as debian-multimedia or other inofficial binary package repositories. I think that making it more a PPA-style service it a good idea - for *source* packages. But don't you think the focus is still the sponsoring process? I can't think of a case where people want to publish Debian packages but don't want them to get into Debian. Traffic is another concern. Without binary packages we are having less than 1 GB traffic from mentors. With binary packages it was a few hundred GB. I didn't have to pay for it but if people (ab)use it as marillat V2.0 then I wouldn't bet on the numbers any more. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Friday 26 October 2007 15:26, Lucas Nussbaum wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. I'm not sure if I understand this right, but what would be done with the result of the tests you'd run on mentors? My problem with piuparts is not the setting up, but the amount of false positives it gives, at least on my packages. If you flag packages as does not pass piuparts it may be percieved as a package being of inferior quality, but there may be many reasons to fail piuparts. Most notably piuparts can not discriminate between a problem in my package or in a package I depend on. That could have changed of course in the very recent past? To be clear, I think that piuparts is a very worthwhile tool, but not something to require of packages to pass, or to use as a binary quality measurement for a package. The results are very useful, but only if you thoroughly inspect the cause of failure. Which has to happen by hand. Thijs pgprpQLavkeRr.pgp Description: PGP signature
RFC: csound
Hi mentors, I am looking for comments on the package csound. Csound is a sound and music synthesis system. Drawing from over 450 signal processing modules, it can be used to model virtually any synthesizer or multi-effect processor. This new version (as compared to Debian's version) contains a large number of improvements, including: * New opcodes/reworked opcodes * New frontends * A C API for creating programs * Several bindings for the C API (C++, lua, java, tcl, python) * tclsh and wish interfaces * LADSPA plugin generator * CSoundAC, and Algorithmic Composition library * PureData csoundapi~ opcode. The package has been taken over from Hans Fugal with his blessing. There is one lintian warning but it is taken care of, so please ignore it (config.log is deleted at clean). You can find the source package at mentors: - URL: http://mentors.debian.net/debian/pool/main/c/csound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/csound/csound_5.07.0.dfsg-1.dsc -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Did Ondrej say that we need a public buildd? Actually that is something I would ratner not do because I have certain (very bad) experience with it. When we kept the uploaded binary (.deb) packages our support mailbox was literally flooded with end-users (!) complaints that the packages were buggy. They used it as debian-multimedia or other inofficial binary package repositories. I think that making it more a PPA-style service it a good idea - for *source* packages. But don't you think the focus is still the sponsoring process? I can't think of a case where people want to publish Debian packages but don't want them to get into Debian. PPA is a means how to get the packages to Debian and to ease the process of it, for everyone. And I think we need a public PPA. Your technical counterarguments can be solved imho, see below. Besides those you also have a social argument - that you fear it will actually decrease the number of new packages in Debian, or that it will increase the number of unhappy users. I think it will actually be the opposite, but that's just my opinion. --- By providing buildbots as a debian package, so that anyonce with a computing power can just install the bot and it will automatically start compiling the packages and uploading them to PPA etc (as to security, I am sure that can be solved satisfactorily too). The traffic can be solved by providing an easy packages, so that more people can host PPA on their servers. Etc. Basically I think all of those and similar problems can be solved, if we want to. There is of course a question who will provide the resources for DebPPA. You could at least ping the experimental/backports/volatile people. Right. But even if we don't find anyone now, who can host it, I still would like to have those packages, so that I can at least easily install it for myself. I started: http://code.google.com/p/debppa/ Why on code.google.com? Is Alioth not good enough? Google has much better interface and I can create wiki pages with documentation in there. But alioth is powered by gforge, right? That looks quite good too: http://gforge.org/projects/gforge/ And even seems to have wiki. Is alioth going to be upgraded? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 03:47:09PM +0200, Ondrej Certik wrote: The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat I believe Debian needs the same as Ubuntu has: Personal Package Archives, where new maintainers could upload their source packages and Agreed. the service will automatically build and check the package. Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? During the sponsoring process having a binary package is pretty useless. A sponsor will/should always take the source package, build it again and check both the source and the binary package. And if the service says YES, it means the package will builds on buildd hosts and is lintian/linda/piuparts clean, all bugs are correctly closed, etc. etc.. I, as a user, need this feature, so that when I fix something in a package, or create a new one, can simply check it a little at my computer and then upload it to Debian PPA and it will do the rest of the checks for me. And if it says YES, I'll ask my sponsor to upload it. So far so good. Although you shouldn't rely on an automated tool but rather use it in addition. I wouldn't sponsor a package just because lintian doesn't complain. At the moment I need to do all of this by hand and it's very time consuming. So is package maintenance. And then my sponsor needs to do the same, to be sure I didn't make a mistake. Correct. Because the sponsor will be responsible for the package at that moment. The only solution I see here is that the package maintainer becomes a Debian developer or Debian contributor. With Debian PPA, my sponsor can easily be sure the technical things are ok and concenrate on QA. Aren't technical things == QA? There is of course a question who will provide the resources for DebPPA. And for the many architectures we have. It contains links to all relevant discussions about this issue. But when I found svnbuildstat, I want to work with Goneri. As Gonéri said, we are trying to create such building blogs - a server that will accept source packages (I only need source packages, Goneri also needs input from VCS), and buildbots, that will do the compiling. Isn't that what buildds are about? Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 07:55:09PM +0200, Ondrej Certik wrote: PPA is a means how to get the packages to Debian and to ease the process of it, for everyone. What do you mean by get the package to Debian? Sponsorship? Or creating a competing repository for end-users? Besides those you also have a social argument - that you fear it will actually decrease the number of new packages in Debian, or that it will increase the number of unhappy users. I think it will actually be the opposite, but that's just my opinion. I'm scared by the thought that there will be a dozen PPAs that end-users will use to get their software from third-party sources. IMHO good packages should go officially into Debian. And bad packages should go to hell. Sponsorship might be a problem sometimes which may be solved by the Debian Maintainer status which should allow you to upload packages into Debian. I would hate to read on mailing lists the version of 'kaffeine' in Debian is outdated. There is a newer version in PPA X that you could use. Or you use the version in PPA Y which is even newer but I hard it's broken. (shiver) Basically I think all of those and similar problems can be solved, if we want to. I'm absolutely on your side. Just not for the binary package part which scares me. Christoph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, 26 Oct 2007, Christoph Haas wrote: On Fri, Oct 26, 2007 at 03:47:09PM +0200, Ondrej Certik wrote: The sources: http://svn.debian.org/wsvn/collab-qa/svnbuildstat/?rev=0sc=0 The wiki page: http://wiki.debian.org/svnbuildstat I believe Debian needs the same as Ubuntu has: Personal Package Archives, where new maintainers could upload their source packages and Agreed. the service will automatically build and check the package. Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? Every once in a while, people post to debian-mentors about their package failing to build on the buildd for some architecture they don't have access to. It'd be nice to get automated complaints about that before buildd time. This does not need to be part of the core Debian Mentors architecture; someone could just automatically grab all the .dsc files and spend CPU cycles emulating every architecture we have and building some packages and posting the log. (I'm willing to use my cycles for that, for example.) -- Asheesh. -- Nothing is as simple as it seems at first Or as hopeless as it seems in the middle Or as finished as it seems in the end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Google has much better interface and I can create wiki pages with documentation in there. But alioth is powered by gforge, right? You can just use your favorite wiki software on alioth. -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, 26 Oct 2007, Christoph Haas wrote: One idea I have (but is not sure it should go into mentors though) is to try to add a use-report to build-report, anybody could download and try to build and accually use the package, then submit a report that the program accually works and does what's in the description. Also a rating on the package maybe ? And a possibillity to vote for the package maybe, then a sponsor can use that information if the want in the decission what packages to sponsor? //Henrik Andreasson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26-10-2007 11:26, Lucas Nussbaum wrote: I'm more interested in piuparts tests than in builds, actually. The point is that most DDs don't use piuparts because there's not many benefits in spending time setting it up. Having a piuparts installation working on mentors.d.n would allow everybody to easily test his packages. Regarding builds, it might not be necessary, but it's still good to have. When packages are waiting for a long time, rebuilding them from time to time could exclude some packages that are no longer candidates for sponsorship (since they fail to build). I'm not sure if Ana is subscribed to -mentors, so I'm cc:ing her. Ana (cc:ed), aren't you working on something like piuparts.d.n (or maybe piuparts.d.o)? Perhaps it could be related/integrated with mentors.d.n? Take a look at this thread: http://lists.debian.org/debian-mentors/2007/10/msg00301.html Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIkfmCjAO0JDlykYRAroUAKCLkRTHv8ll+guAHaWRSSoHsCJl3wCg004g HPwX94l1ikgOmuNg6nDEGx8= =ypEm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Asheesh Laroia [EMAIL PROTECTED] (26/10/2007): Everybody suddenly seems to think that yet another buildd is a great idea. Why is it? Every once in a while, people post to debian-mentors about their package failing to build on the buildd for some architecture they don't have access to. It'd be nice to get automated complaints about that before buildd time. I had such a problem on a very single architecture (hppa) for openscenegraph. Once that one *knows* that there are some problems on this or that arch, the point is about solving it. Not being told in advance whether this problem is fixed, or isn't. BTW, buildd time is considered cheap these days (discussed some time ago on d-release@ or #d-release) — although I agree that periodically some archs have troubles to keep up. This does not need to be part of the core Debian Mentors architecture; someone could just automatically grab all the .dsc files and spend CPU cycles emulating every architecture we have and building some packages and posting the log. (I'm willing to use my cycles for that, for example.) I'd better see the possibility of getting an access to the offending archs to try and figure out what the problems are and to fix them. Depending on the archs, it can be easy to get an account (hppa is a very good example, thanks to the available clusters), or it can be very tricky; in that latter case, emulation can help a lot. Cheers, -- Cyril Brulebois signature.asc Description: Digital signature
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 10:34:03PM +0200, Cyril Brulebois wrote:
[...]
I'd better see the possibility of getting an access to the offending
archs to try and figure out what the problems are and to fix them.
Depending on the archs, it can be easy to get an account (hppa is a very
good example, thanks to the available clusters), or it can be very
tricky; in that latter case, emulation can help a lot.
I went to the extreme of trying to collect and maintain Debian on an
actual physical representative from each supported architecture (I'm
up to 9 now, missing arm, ia64 and s390 still), and can say from
experience that it's neither a simple nor entirely cheap
alternative.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
Christoph Haas wrote: That would mean getting the package in Debian (with the dependencies), installing it, testing upgrading to the new deb etc., right? I just worry what happens if I try that with a package that pulls in 1 GB of dependencies. How would that work? (Disclaimer: I have just recently begun to actually use piuparts.) Best option is to run something like apt-proxy or even squid (if you can't afford a full mirror) so you don't have to pull and pull again the same packages all the time. I don't think that downloading the dependency would be the issue, unless you have a VERY slow network. I don't intend to be posessive here. mentors.debian.net was invented to improve the sponsorees' situation. I'm confident it has done that and believe that way more packages are sponsored instead of trashed. I don't know if it helped that some package were not trashed, but I'm 100% sure that what you did is VERY convenient. Lucas Nussbaum wrote: Regarding CPU-intensive QA tests (builds and piuparts runs): I think that it's very important to do them on mentors. I don't think that resources are a problem: nobody said that you _had_ to host mentors yourself. If a server is needed, we could provide it as sponsorship. Something like a core 2 quad core (Q6600) running Xen with few gigabytes of RAM could be provided if it's needed to have such power, and if it can help to have such computer. Let me know if you want us to do so. Thomas Goirand, GPLHost CEO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
