jenkins vs. debile [was: Re: Bits from the Release]
Hi Zack, hi all, > On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote: > > How you can help (NEW-TEST-HELP) > > > > > > Add tests to your packages. The full specification for these tests > > are available from [AUTOPKG]. If you need inspiration, consider looking > > at some of the existing autopkgtests[FIND-AUTOPKG]. > > > > We need to have the autopkgtest tests run. Holger Levsen suggested > > that jenkins.debian.net has the necessary hardware to support these > > tests. > > > > Asheesh Laroia has kindly spent some time during DebConf13 researching > > and experimenting with setting up such jobs. > > So, in the context of work to periodically run various sorts of static > analysis tests on Debian packages [1], we (myself, Sylvestre Ledru, Léo > Cavaillé, and Matthieu Caneill) have considered using Jenkins. Based on > feedback from Matthias Klumpp and his experience in using Jenkins for > Tanglu, we have concluded that it didn't really scale to the point that > we needed (number of Debian packages * number of checkers). We ended up > using Paul Tagliamonte's debile infrastructure [2]. > Would you/Matthias be willing to share the feedback on jenkins more widely? I do presently run a system with ~60,000 jobs, and, yes, this is probably somewhat beyond what jenkins was meant to scale to. Yet jenkins does have the practical advantage of being widely used, with lots of plug-ins, and being well documented. Not all of this seems to be the case for debile at present... > I don't doubt that jenkins.d.n can be leveraged for the time being, > giving the low amount of autopkgtests currently available. But you might > want to check with Matthias or similar experiences before committing to > using Jenkins for this. > [...] I'd be happy to contribute mine as well, and one of the key points seems to be the level of interaction/user control people are looking for. Best, Michael pgpEf4uH71ZyW.pgp Description: PGP signature
Bug#694308: any update on adobe copyright in fonts in debian ?
Hi all, Looking forward to updaes. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADdDZR=cVcpH-MR-iObQcL9pvZCPAbTKTLFbePj6bu=fu64...@mail.gmail.com
Re: jenkins vs. debile [was: Re: Bits from the Release]
On Fri, Sep 27, 2013 at 10:05:01AM +0200, Michael Tautschnig wrote: > Hi Zack, hi all, Hi! > Would you/Matthias be willing to share the feedback on jenkins more widely? I > do > presently run a system with ~60,000 jobs, and, yes, this is probably somewhat > beyond what jenkins was meant to scale to. Yet jenkins does have the practical > advantage of being widely used, with lots of plug-ins, and being well > documented. Not all of this seems to be the case for debile at present... The case for debile isn't the case for Jenkins. They're different tools that *can* do similar things, but in very different ways. Debile is intended to work in "The Debian Way" - in so far as it understands what a source package is, what a binary package is, and can properly grok related stuff like suites, etc. Debile will have a plug-in archetecture, but this is not really the point. The point is that it will manage a given source package, and hand this out to build nodes for each arch (amd64, i386, armhf, armel, all), which will build for it's suite (stable, unstable, testing, any/all), and push the results back up. In addition, it can run static checks, and push the results back in a standard format (Firehose), which I've been working on closely with a red hat engineer, so that we can have compatable static result data. By 1.0 this will be smart enough to allow for: * proper rebuilds of a source package (I need to upgrade Django. Let me push it here and rebuild anything depending on Django to see how it works) * use for mentoring (run *tons* of static checks on it) * a gateway for normal DD uploads (push a package there, run all sorts of tests, if it passes piuparts, adequate, etc, then dput to ftp-master, otherwise destroy the upload and email), * and ongoing QA tool (rebuild all uploaded arch:all packages) To be honest, only the last part is something jenkins is suited for, and the actual "CI" part consists of a bot that watches for d-d-c emails, and uploads the package from incoming.d.o -> debile's internal incoming. Long term goals include proper dependency resolution and management, using something basic to start (topological sort?), and growing more complex until we're using apt's resolver (I assume, none of this is planned, just ideas), to do lightweight $WORLD rebuilds (of course, this will not be fit for bootstrapping, unless a bootstrapper gets involved) > > I don't doubt that jenkins.d.n can be leveraged for the time being, > > giving the low amount of autopkgtests currently available. But you might > > want to check with Matthias or similar experiences before committing to > > using Jenkins for this. > > > I'd be happy to contribute mine as well, and one of the key points seems to be > the level of interaction/user control people are looking for. Jenkins rocks, it's just not what Debile's for. They're not competing. I would never use debile to build nightly debs, for instance. I'd just jenkins. At best, I'd use jenkins and dput to a debile build setup. > > Best, > Michael Thanks for your interest, mt! Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Removing old unmaintained X drivers
Hi! On Thu, 2013-09-26 at 23:26:22 +0200, Julien Cristau wrote: > we (the debian X Strike Force) are thinking of removing the following > packages from the archive, unless somebody steps up (soon) to take care > of them. I assume here you mean maintaining them in Debian (or perhaps upstream too?). > The reason is they see 0 testing, nobody maintains them > upstream, if you're lucky people keep some of them building when APIs > change, if you're very lucky they get a release with all the build fixes > once in a while, and it's likely most of them don't have any users > anymore. Several of the below modules are claimed as maintained in upstream's MAINTAINERS file. If that's not the case I guess it would be nice to get that updated so that it's clear what's the status on them and so other people can step up there if they feel like it. > While it would probably be easy to get them to stop FTBFS > right now, it doesn't seem worth it to keep all of those drivers around > with the maintenance overhead that comes with that if nobody's going to > notice anyway. Sure, although several of them have newer releases upstream or fixes in master that make them build from source. > So please speak up if you want to see one of these in jessie. I'll keep an eye on the tdfx one upstream. If it got to be removed from Debian, I might consider taking over maintainership here. > xserver-xorg-video-voodoo Maintained upstream. New release builds. > xserver-xorg-video-chips > xserver-xorg-video-glint > xserver-xorg-video-i128 > xserver-xorg-video-i740 > xserver-xorg-video-rendition > xserver-xorg-video-tdfx > xserver-xorg-video-tga > xserver-xorg-video-tseng Maintained upstream. Master builds. > xserver-xorg-video-s3virge > xserver-xorg-video-suncg14 > xserver-xorg-video-suncg3 > xserver-xorg-video-suncg6 > xserver-xorg-video-sunleo > xserver-xorg-video-suntcx Unmaintained upstream. New release builds. > xserver-xorg-video-apm > xserver-xorg-video-ark Unmaintained upstream. Master builds. > xserver-xorg-video-newport > xserver-xorg-video-s3 > xserver-xorg-video-sis Unmaintained upstream. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130927172737.ga25...@gaara.hadrons.org
Re: Decision on R datasets
Faheem Mitha faheem.info> writes: > I'm sorry to hear that you will not be working on R packaging for > Debian any more. Unfortunately. there are very few people working on R > packaging in Debian. There is Dirk, of course, but few other names > appear consistently. In particular, there is nothing like a R > packaging team despite R's significant and growing importance in the > larger FOSS community. There is Don Armstrong's r-debian.debian.net which turns CRAN packages into Debian packages (building on two earlier cran2deb efforts I was involved in, once with an extremely gifted GSoC student). And there is Michael Rutter's c2d4u variant using launchpad (for Ubuntu). Both autogenerated thousands of packages. Within Debian, it is complicated. I am not sure what percentage of CRAN we should package. The most important packages, yes. But indiscriminately? Not sure. Installing in /usr/local and using R to update works really well too. Dirk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130927t221408-...@post.gmane.org
Re: Removing old unmaintained X drivers
On Fri, Sep 27, 2013 at 19:27:37 +0200, Guillem Jover wrote: > Hi! > > On Thu, 2013-09-26 at 23:26:22 +0200, Julien Cristau wrote: > > we (the debian X Strike Force) are thinking of removing the following > > packages from the archive, unless somebody steps up (soon) to take care > > of them. > > I assume here you mean maintaining them in Debian (or perhaps upstream > too?). > If they're maintained upstream the XSF can probably keep maintaining the packages. > > The reason is they see 0 testing, nobody maintains them > > upstream, if you're lucky people keep some of them building when APIs > > change, if you're very lucky they get a release with all the build fixes > > once in a while, and it's likely most of them don't have any users > > anymore. > > Several of the below modules are claimed as maintained in upstream's > MAINTAINERS file. If that's not the case I guess it would be nice to > get that updated so that it's clear what's the status on them and so > other people can step up there if they feel like it. > I admit I didn't cross-check against the MAINTAINERS file. But at least some that are listed as maintained there were removed in X11R7.7: http://www.x.org/releases/X11R7.7/doc/xorg-docs/ReleaseNotes.html#Removed_in_this_Release > > While it would probably be easy to get them to stop FTBFS > > right now, it doesn't seem worth it to keep all of those drivers around > > with the maintenance overhead that comes with that if nobody's going to > > notice anyway. > > Sure, although several of them have newer releases upstream or fixes > in master that make them build from source. > Getting the packages to build this time isn't a big issue. But if these drivers get no testing I think it's better to not ship them than to ship them broken. And if they have no users then time spent maintaining/fixing them could be better spent elsewhere. > > So please speak up if you want to see one of these in jessie. > > I'll keep an eye on the tdfx one upstream. If it got to be removed > from Debian, I might consider taking over maintainership here. > Thanks. > > xserver-xorg-video-voodoo > > Maintained upstream. New release builds. > The last change from Alan (who's listed as maintainer) was 5 years ago... > > xserver-xorg-video-chips > > xserver-xorg-video-glint > > xserver-xorg-video-i128 > > xserver-xorg-video-i740 > > xserver-xorg-video-rendition > > xserver-xorg-video-tdfx > > xserver-xorg-video-tga > > xserver-xorg-video-tseng > > Maintained upstream. Master builds. > I think that's yet another case of MAINTAINERS being outdated. Cheers, Julien signature.asc Description: Digital signature
Re: Removing old unmaintained X drivers
Hello, On Thu, 26 Sep 2013 23:26:22 +0200 Julien Cristau wrote: > xserver-xorg-video-s3 I'd vote for this one, but I can't maintain it, unfortunately. -- WBR, Andrew signature.asc Description: PGP signature
Re: Decision on R datasets
Dirk Eddelbuettel debian.org> writes: > There is Don Armstrong's r-debian.debian.net which turns CRAN packages Sorry: http://debian-r.debian.net/ is the correct address. Dirk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130928t004704-...@post.gmane.org
Re: jenkins vs. debile [was: Re: Bits from the Release]
Hi! 2013/9/27 Michael Tautschnig : >> [...] > > Would you/Matthias be willing to share the feedback on jenkins more widely? I > do > presently run a system with ~60,000 jobs, and, yes, this is probably somewhat > beyond what jenkins was meant to scale to. Yet jenkins does have the practical > advantage of being widely used, with lots of plug-ins, and being well > documented. Not all of this seems to be the case for debile at present... > >> I don't doubt that jenkins.d.n can be leveraged for the time being, >> giving the low amount of autopkgtests currently available. But you might >> want to check with Matthias or similar experiences before committing to >> using Jenkins for this. >> > [...] > Additionally to the points Paul already mentioned: The lots of plugins stuff does not really matter for the Debian use-case, because Jenkins was built for an entirely different purpose. For example: In Debian, we need at least 5 states a build can be in: dependency-wait, building, uploaded, installed and failed. Jenkins only provides built and failed, and adding more states is lots of work. Also, packages function differently compared to Jenkins jobs: You can e.g. build different versions of a single package, so foobar is build in versions 1.0 and 1.2 for different target suites. This can not be easily reflected in Jenkins. We worked around all of these issues in Tanglu. For example, we have a depwait state by taking the control over builds from Jenkins to an external application and adding dependency-wait information to the job descriptions. We can then find stuff in depwait using a RegEx. To solve the multiple-versions issue, we append the version number to the jobname, and jobs get renamed if necessary by the Jenkins-controlling tool. Because we don't have uploaded/installed states, the Jenkins-helper is patrolling the jobs to guess these states and schedule rebuilds. You can see the stuff in action here: http://buildd.tanglu.org/ (currently, some build slaves are broken, which is really sad and needs to be fixed soon) So, I really think that Debile is a sane approach with less hackish solutions. I will start to work on it too, as soon as I find time, and most likely migrate Tanglu to it, so we do no longer rely on Jenkins for that. On the pro side, of course, Jenkins has cool plugins to analyze job output, and it has live buildlogs - but having it build the Debian archive is hackish. Also, Jenkins gets incredibly slow... The machine powering our build-master and archive is very powerful (Octocore, I think at least 16GB of RAM), and Jenkins performance is still bad. Maybe because it is using one large XML file to store job data. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKNHny-d2Tb4AyAU_4OxF+B6OAkULPUX+Six-kBEs=tk9q_...@mail.gmail.com
Special offer for Kyocera toners
Deas Sir, We are manufacturer of copier toners, located in Shenzhen city of China. All products will be supplied with good quality. We are running a new promotion from Sep 23 to Oct 23. 100% new compatible copier toners Brand: Kyocera TK1130 USD11.70/PC @ QTY. 300PCS TK580 USD108/SET @ QTY. 50 SETS Packing: neutral box Shall you are interested in, please do not hesistate to contact us. Warm regards, Bonnie Liu - Shenzhen Mework Office Consumable Co., Ltd. Tel:86-755-2721 4330 Fax: 86-755-2310 4160 Website: www.meworktoner.com Email: bon...@meworktoner.com MSN: suningbon...@126.com Skype: suningbonnie -
Bug#724801: ITP: yt -- yt is a command-line front-end to YouTube
Package: wnpp Severity: wishlist Owner: "Javier P.L." * Package name: yt Version : 2013.09.28 Upstream Author : Rich Wareham * URL : https://github.com/rjw57/yt * License : MIT Programming Lang: Python Description : yt is a command-line front-end to YouTube yt is a command-line front-end to YouTube which allows you to browse YouTube videos and play them directly from the command-line. It uses youtube-dl and mplayer or omxplayer to actually play the videos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130928052848.18165.24637.report...@sup.lan
