Re: Popularity of bzr-builddeb and dh-make
On Thu, 11 Oct 2012 16:31:00 -0700, Steve Langasek wrote: >The popularity of subversion >for packaging is a measure of inertia and/or ignorance, not of the >appropriateness of the tool. I find this attitute improperly offensive. The choice of tool is the decision of the maintainer, and subversion does version control rather well for most uses. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1tonac-0001xl...@swivel.zugschlus.de
Re: (seemingly) declinging bug report numbers
On Thu, 11 Oct 2012 02:46:18 +0200, Christoph Anton Mitterer wrote: >First declining bug numbers are not necessarily a problem, because it >could just mean that we're getting better and better, or that more and >more upstream issues are reported upstream (which would be a good thing >IMHO), or that the maintainers already catch many problems themselves. I have adopted, in the last years, a stance of looking for a package's maintainer first before I file a bug. With certain individuals, or certain teams, I do not bother filing Debian bugs any more because they tend to be closed with "send a patch, kthxbye" anyway, or they'll rot away in the BTS without maintainer reaction, and after a few years, being closed with "upstream has released three times since this bug reports was filed, things are likely that this bug is fixed, closing it without further checking, feel free to re-open if it's still present". This is, imo, the result of Debian's lack of personpower in core areas of the distribution. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1tonac-0001xl...@swivel.zugschlus.de
Supplier of A4 paper
Dear manager: Nice time! Very happy to hear that you need A4 paper We have 80g, 70g and so on If you still need that pls reply me let us contact detail Pls reply me Best wishes, Mr.Li (Manager) HANGZHOU XINHAO INDUSTRY CO., LIMITED ADD: NO.124 JINCHENG ROAD, XINDENG TOWN, FUYANG CITY,HANGZHOU, ZHEJIANG,CHINA Foreign Trade Department : +86-18314872576 E-mail: hzxin...@gmail.com Yahoo: hzxin...@yahoo.com
Re: (seemingly) declinging bug report numbers
On Wed, 2012-10-17 at 08:58 +0200, Marc Haber wrote: > On Thu, 11 Oct 2012 02:46:18 +0200, Christoph Anton Mitterer > wrote: > >First declining bug numbers are not necessarily a problem, because it > >could just mean that we're getting better and better, or that more and > >more upstream issues are reported upstream (which would be a good thing > >IMHO), or that the maintainers already catch many problems themselves. > > I have adopted, in the last years, a stance of looking for a package's > maintainer first before I file a bug. With certain individuals, or > certain teams, I do not bother filing Debian bugs any more because > they tend to be closed with "send a patch, kthxbye" anyway, Even some bugs _with_ patches are treated the same way or kept open and never acted on. Shouldn't the number of open bugs be decreasing with time, not being constant or increasing as is the case for some packages? > or they'll > rot away in the BTS without maintainer reaction, and after a few > years, being closed with "upstream has released three times since this > bug reports was filed, things are likely that this bug is fixed, > closing it without further checking, feel free to re-open if it's > still present". True, very true. Or bugs are closed due to a package being removed from the distribution, and never attended to at all. > This is, imo, the result of Debian's lack of personpower in core areas > of the distribution. Might be so, what to do about it? Maybe more team-maintained packages. And better procedures for package salvaging, as the current discussion thread on salvaging packages shows. -- 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/1350459672.5747.36.ca...@hp.my.own.domain
Re: (seemingly) declinging bug report numbers
On 2012-10-17, Svante Signell wrote: > Even some bugs _with_ patches are treated the same way or kept open and > never acted on. Shouldn't the number of open bugs be decreasing with > time, not being constant or increasing as is the case for some packages? in many cases, the amount of open bug reports is more a function of number of users of a given package, rather than a function of the age of the package. > Might be so, what to do about it? Maybe more team-maintained packages. > And better procedures for package salvaging, as the current discussion > thread on salvaging packages shows. Neither of those gets *more people* in the teams of core packages. /Sune - who would like a couple of DDs and a dozen of bug workers for pkg-kde -- 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/slrnk7sp0f.me.nos...@sshway.ssh.pusling.com
Re: Popularity of bzr-builddeb and dh-make
For git we have gitweb, gitolite, git-daemon, pristine-tar. I'd like to have similar for bzr, hg and svn. It's not about technology, but about collaboration. That's why I prefer git. 2012/10/17 Marc Haber : > On Thu, 11 Oct 2012 16:31:00 -0700, Steve Langasek > wrote: >>The popularity of subversion >>for packaging is a measure of inertia and/or ignorance, not of the >>appropriateness of the tool. > > I find this attitute improperly offensive. The choice of tool is the > decision of the maintainer, and subversion does version control rather > well for most uses. > > Greetings > Marc > -- > -- !! No courtesy copies, please !! - > Marc Haber | " Questions are the | Mailadresse im Header > Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ > Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 > > > -- > 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/e1tonac-0001xl...@swivel.zugschlus.de > -- 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/call-q8xzg7_se9yuprgh_a5asu8v+ktzxy6j5_q0gzk+0cq...@mail.gmail.com
Re: Popularity of bzr-builddeb and dh-make
On Wed, 17 Oct 2012 12:57:18 +0400 Игорь Пашев wrote: > For git we have gitweb, gitolite, git-daemon, pristine-tar. > I'd like to have similar for bzr, hg and svn. > > It's not about technology, but about collaboration. No, LP is good website for development with collaboration. (A workflow is also important piece of development) Anyway, it's just asking packaging-dev pulls/suggests certain package or not by default. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- 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/20121017180751.74cb89806dab944d9ca6d...@debian.or.jp
Re: Popularity of bzr-builddeb and dh-make
2012/10/17 Hideki Yamane : > No, LP is good website for development with collaboration. Can I have my own LP, please? -- 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/CALL-Q8wJRMFqyV=p6+baq29qxk+ug3rpakpzgi3qqwwrobz...@mail.gmail.com
Re: Popularity of bzr-builddeb and dh-make
Hello, On 17.10.2012 11:13, Игорь Пашев wrote: > 2012/10/17 Hideki Yamane : >> No, LP is good website for development with collaboration. > > Can I have my own LP, please? https://dev.launchpad.net/Running should help you with that. Have a great day, Daniel -- 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/507e7805.7090...@ubuntu.com
Re: Popularity of bzr-builddeb and dh-make
On Wed, 17 Oct 2012 13:13:42 +0400 Игорь Пашев wrote: > Can I have my own LP, please? Well, you can get source code. see https://dev.launchpad.net/Trunk # I just annoyed heavily relying on LP as my previous mails in thread. However, it looks good for me. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYaman -- 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/20121017181954.1dd9e02589dfd9328c777...@debian.or.jp
Bug#690754: ITP: ruby-recaptcha -- Ruby helpers for the reCAPTCHA API
Package: wnpp Severity: wishlist Owner: "David Martínez Moreno" * Package name: ruby-recaptcha Version : 0.3.2 Upstream Author : Jason L Perry, * URL : http://ambethia.com/recaptcha/ * License : Copyright (c) 2007 Jason L Perry Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Programming Lang: Ruby Description : Ruby helpers for the reCAPTCHA API This plugin gives a high-level interface for using reCAPTCHA authentication methods in your ruby programs. . In your views you can use the recaptcha_tags method to embed the needed Javascript, and you can validate in your controllers with verify_recaptcha. -- 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/20121017093935.27826.64457.report...@belgarath.thefacebook.com
Re: (seemingly) declinging bug report numbers
On Mon, Oct 15, 2012 at 03:25:21AM +0200, Christoph Anton Mitterer wrote: > On Sat, 2012-10-13 at 20:35 +0200, Wouter Verhelst wrote: [...] > > If anything, Ubuntu is > > gaining ground on non-free software. You can't be angry about that. > That's a tricky question... ask yourself what RMS would probably answer. He'd probably answer that ubuntu is more free than windows, and that that's therefore a good thing. But to be perfectly blunt, I don't give a rat's ass what RMS thinks. I'm not a member of the Church of Free Software, nor do I want to be. Debian is the club I'm a member of, and that's more than enough for me. > Making opensource more open for proprietary stuff is sometimes simply > necessary... but this may ultimately also become a big threat for the > free software world, namely then when that non-free stuff plays such an > important role that we couldn't get rid of it anymore. Ah, well, I think you misunderstood me here. What I meant is that ubuntu is gaining ground on things like Windows and MacOS. I didn't mean to refer to non-free software packaged with ubuntu, nor to non-free producers who support ubuntu. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. signature.asc Description: Digital signature
Re: Discarding uploaded binary packages
On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote: > also sprach Holger Levsen [2012.10.16.0945 +0200]: > > > We have not cared enough for almost 20 years that 9 out of 10 binary > > > packages in use (i386 until 2005, amd64 since then) are built on > > > machines that are individually maintained according to widely > > > varying security standards to do anything about it, AFAICT. > > > > your point being? > > That our users don't seem to care, and that probably is why we > haven't done anything about it. Out of curiosity, how would a user /know/ whether a package has been built via a buildd rather than on a DD's local machine? -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201210171228.14376.chris.kna...@coredump.us
Re: Discarding uploaded binary packages
On Wed, 17 Oct 2012 12:28:14 -0400 Chris Knadle wrote: > Out of curiosity, how would a user /know/ whether a package has been built > via > a buildd rather than on a DD's local machine? Check the wannabuild logs for the package. A listing of Installed without a build log means that the binaries for that architecture were uploaded by the DD. https://buildd.debian.org/status/package.php?p=qof No logs for amd64, so developer (me) uploads amd64 binaries. All the other "Installed" listings link to the build log for that version on that architecture. Any source package which only has Architecture: all binary packages is uploaded by the DD although there can be binNMU's. https://buildd.debian.org/status/package.php?p=emdebian-grip So this counts for the majority of the perl, shell, python and other interpreted language packages. Build logs are accessible via the PTS too: http://packages.qa.debian.org/e/emdebian-grip.html -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpqleLrBantu.pgp Description: PGP signature
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 12:28:14PM -0400, Chris Knadle wrote: > On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote: > > also sprach Holger Levsen [2012.10.16.0945 +0200]: > > > > We have not cared enough for almost 20 years that 9 out of 10 binary > > > > packages in use (i386 until 2005, amd64 since then) are built on > > > > machines that are individually maintained according to widely > > > > varying security standards to do anything about it, AFAICT. > > > > > > your point being? > > > > That our users don't seem to care, and that probably is why we > > haven't done anything about it. > > Out of curiosity, how would a user /know/ whether a package has been built > via > a buildd rather than on a DD's local machine? Everyone can check buildd.debian.org for the lack of a build log on a particular architecture for a given version. That's a fairly good indicator. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- 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/20121017164514.gc22...@grep.be
Re: Discarding uploaded binary packages
On Wednesday, October 17, 2012 12:45:14, Wouter Verhelst wrote: > On Wed, Oct 17, 2012 at 12:28:14PM -0400, Chris Knadle wrote: > > On Tuesday, October 16, 2012 05:04:55, martin f krafft wrote: > > > also sprach Holger Levsen [2012.10.16.0945 +0200]: > > > > > We have not cared enough for almost 20 years that 9 out of 10 > > > > > binary packages in use (i386 until 2005, amd64 since then) are > > > > > built on machines that are individually maintained according to > > > > > widely varying security standards to do anything about it, AFAICT. > > > > > > > > your point being? > > > > > > That our users don't seem to care, and that probably is why we > > > haven't done anything about it. > > > > Out of curiosity, how would a user /know/ whether a package has been > > built via a buildd rather than on a DD's local machine? > > Everyone can check buildd.debian.org for the lack of a build log on a > particular architecture for a given version. That's a fairly good > indicator. Okay that's good to know. Thanks. I'm glad this came up again now, because the discussion has explained some of the detial behind some of the statements I've heard at DebConfs concerning "Debian will be using source-only uploads `any day now`". ;-) -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201210171316.27314.chris.kna...@coredump.us
Re: Discarding uploaded binary packages
Hi! Joerg Jaspert writes: > Its for after wheezy, definitely. > Also, there are some open issues to be solved for this to happen. > The most important is being able to deal with arch all packages. And > worse - arch all packages able to build only on certain architectures. > But thats outside dak and my area. Goto the buildd/wanna-build people to > help for that. Also remeber, there are packages like cmucl that can only be built by the same upstream release of itself and can currently survive in Debian because the maintainer can upload a bootstrapped binary package along the source Regards Christoph -- 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/871ugxgddd@mitoraj.siccegge.de
Bug#690800: ITP: pymc -- Bayesian statistical models and fitting algorithms
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko * Package name: pymc Version : 2.2 Upstream Author : PyMC Team * URL : http://pymc-devs.github.com/pymc * License : MIT/X Programming Lang: Python Description : Bayesian statistical models and fitting algorithms PyMC is a Python module that implements Bayesian statistical models and fitting algorithms, including Markov chain Monte Carlo. Its flexibility and extensibility make it applicable to a large suite of problems. Along with core sampling functionality, PyMC includes methods for summarizing output, plotting, goodness-of-fit and convergence diagnostics. -- 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/20121017183509.12689.94656.report...@novo.onerussian.com
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: > Joerg Jaspert writes: > > Its for after wheezy, definitely. > > Also, there are some open issues to be solved for this to happen. > > The most important is being able to deal with arch all packages. And > > worse - arch all packages able to build only on certain architectures. > > But thats outside dak and my area. Goto the buildd/wanna-build people to > > help for that. > Also remeber, there are packages like cmucl that can only be built by > the same upstream release of itself and can currently survive in Debian > because the maintainer can upload a bootstrapped binary package along > the source Which is, frankly, an absurd requirement. Someone should fix this package to bootstrap properly, and if disallowing binary uploads forces the issue, that's a good thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Discarding uploaded binary packages
On 17 October 2012 19:30, Christoph Egger wrote: > Hi! > > Joerg Jaspert writes: >> Its for after wheezy, definitely. >> Also, there are some open issues to be solved for this to happen. >> The most important is being able to deal with arch all packages. And >> worse - arch all packages able to build only on certain architectures. >> But thats outside dak and my area. Goto the buildd/wanna-build people to >> help for that. > > Also remeber, there are packages like cmucl that can only be built by > the same upstream release of itself and can currently survive in Debian > because the maintainer can upload a bootstrapped binary package along > the source See Debian Policy 7.8 Additional source packages used to build the binary - Built-Using [1] Is exactly what should be used here. And the bootstrap package should be uploaded into Debian, to facilitate downstream users and distributions to bootstrap that package by themselves as well & provide a clear lock-step build-deps. [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using Regards, Dmitrijs. -- 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/canbhlujckg-xsogfjevdn_bax0jvzy8jkouavvhphrkmyr7...@mail.gmail.com
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: > Hi! > > Joerg Jaspert writes: > > Its for after wheezy, definitely. > > Also, there are some open issues to be solved for this to happen. > > The most important is being able to deal with arch all packages. And > > worse - arch all packages able to build only on certain architectures. > > But thats outside dak and my area. Goto the buildd/wanna-build people to > > help for that. > > Also remeber, there are packages like cmucl that can only be built by > the same upstream release of itself and can currently survive in Debian > because the maintainer can upload a bootstrapped binary package along > the source So, you currently upload every arch with the sourceful upload? Or do you upload, wait for the buildd build-dep lock, and do a binary-only upload? I don't think anyone wants to get rid of binary-only uploads. Binary only uploads get rejected if there is no source package anyway, so it's pretty easy to still allow binary-only-uploads and strip a .deb on the sourceful upload. No reason to make this default, though. > > Regards > > Christoph > > > -- > 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/871ugxgddd@mitoraj.siccegge.de > -- .''`. 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: delegation for the Policy Editors
On Wed, Oct 17, 2012 at 09:51:48PM +0200, Stefano Zacchiroli wrote: > (Andreas Barth, Bill Allombert, and Russ Allombert have confirmed their > interest in working as editors and remain on board.) Erm, overzealous M-/ in my favorite editor :-) So let's thank here Andreas Barth, Bill Allombert, and Russ **Allbery** for their persistence in torturing Debian packages quality! (… and luckily, I did it right in the actual formal delegation text, phew.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Discarding uploaded binary packages
* Michael Gilbert [121016 04:59]: > Anyway, all of these build system path sanitization issues can be > eliminated by using the buildds for all architectures, since paths > will start with at least /build that requires root-level action to > exist on users' systems. They are not eliminated by using only buildds. They are only moved towards people that want to build their privately patched software then, which is something they have a right to do. A package not building properly or differently when built in a clean system with all the build-depended packages installed and all the build-conflicted packages not installed is a critical bug. Recreating binary packages uploaded by maintainers has some merrits, but this is definitely not one of them... Bernhard R. Link -- 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/20121017200750.ga5...@client.brlink.eu
Re: Discarding uploaded binary packages
Paul Tagliamonte writes: > On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: >> Joerg Jaspert writes: >> > Its for after wheezy, definitely. >> > Also, there are some open issues to be solved for this to happen. >> > The most important is being able to deal with arch all packages. And >> > worse - arch all packages able to build only on certain architectures. >> > But thats outside dak and my area. Goto the buildd/wanna-build people to >> > help for that. >> >> Also remeber, there are packages like cmucl that can only be built by >> the same upstream release of itself and can currently survive in Debian >> because the maintainer can upload a bootstrapped binary package along >> the source > > So, you currently upload every arch with the sourceful upload? Or do you > upload, wait for the buildd build-dep lock, and do a binary-only upload? Guess why this package is Arch: i386 only ;-) I'm not uploading at all just being in the same packaging team. > I don't think anyone wants to get rid of binary-only uploads. I read Joerg's Mail as dropping all *.deb that aren't signed by a buildd. Regards Christoph -- 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/87wqyog8ns@mitoraj.siccegge.de
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 4:07 PM, Bernhard R. Link wrote: > * Michael Gilbert [121016 04:59]: >> Anyway, all of these build system path sanitization issues can be >> eliminated by using the buildds for all architectures, since paths >> will start with at least /build that requires root-level action to >> exist on users' systems. > > They are not eliminated by using only buildds. They are only moved > towards people that want to build their privately patched software > then, which is something they have a right to do. A package not > building properly or differently when built in a clean system with > all the build-depended packages installed and all the > build-conflicted packages not installed is a critical bug. > > Recreating binary packages uploaded by maintainers has some merrits, > but this is definitely not one of them... Really? Take a look the affected isc-dhcp package. The prefix for the amd64 architecture (the one I built and uploaded) is /home// which someone with a account can put code in. The other architectures are /build/build-isc-dhcp which does not exist without root creating it at some point. Now that's still not right, but its more of a hurdle for someone trying to take advantage of the issue. Anyway, reading again, I not sure that your reply actually considers build path sanitization problems, which is what my statement was about. Best wishes, Mike -- 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/CANTw=mnu06tmmwz9ntzrnt9vvptkuo+bdx1cp1+rs6thgor...@mail.gmail.com
Re: Discarding uploaded binary packages
* Michael Gilbert [121017 22:19]: > Anyway, reading again, I not sure that your reply actually considers > build path sanitization problems, which is what my statement was > about. I'm stating that doing all the builds on buildds will not avoid the need to fix the package. (Unless you are arguing that people locally modifying their packages are supposed to get security problems). Bernhard R. Link -- 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/20121017205532.gb5...@client.brlink.eu
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 4:55 PM, Bernhard R. Link wrote: > * Michael Gilbert [121017 22:19]: >> Anyway, reading again, I not sure that your reply actually considers >> build path sanitization problems, which is what my statement was >> about. > > I'm stating that doing all the builds on buildds will not avoid the > need to fix the package. Ubuntu chose to come to that conclusion on this issue. > (Unless you are arguing that people locally > modifying their packages are supposed to get security problems). That is true: if there is a build path sanitization issue, then if the user chooses to rebuild the package they will get their own rogue paths. So, yes, we should always fix those issues when they're found, but at least for people using buildd'd packages, it's less of a problem. Best wishes, Mike -- 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/CANTw=moucn6danyx5-hqenjzfufsaxgshahuem0_x4ox48z...@mail.gmail.com
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 5:23 PM, Michael Gilbert wrote: > That is true: if there is a build path sanitization issue, then if the > user chooses to rebuild the package they will get their own rogue > paths. So, yes, we should always fix those issues when they're found, > but at least for people using buildd'd packages, it's less of a > problem. Maybe someone would be interested in writing a lintian check for these issues? Something a bit more advanced than this $ strings /sbin/dhclient | grep ^PATH PATH=/home/zero79/source/git/isc-dhcp/debian/tmp/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin would have caught the issue (advanced aspect being that reasonable paths are ok'd). Best wishes, Mike -- 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/CANTw=mmcwq_zaz_qov6poa9j5xmdcwykxgnci3kvay9pacb...@mail.gmail.com
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 05:23:22PM -0400, Michael Gilbert wrote: > if there is a build path sanitization issue, then if the > user chooses to rebuild the package they will get their own rogue > paths. So, yes, we should always fix those issues when they're found, > but at least for people using buildd'd packages, it's less of a > problem. For the build path, I see no benefit in having it be always the same on buildds. What about intentionally keeping the path diverse? Heck, we could even make sure it's >4096 characters long to weed out PATH_MAX brain damage, but that's probably something that belongs in Lucas Nussbaum land. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 -- 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/20121017214008.ga30...@angband.pl
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 08:56:56AM +0200, Joerg Jaspert wrote: > Its for after wheezy, definitely. > Also, there are some open issues to be solved for this to happen. > The most important is being able to deal with arch all packages. And > worse - arch all packages able to build only on certain architectures. > But thats outside dak and my area. Goto the buildd/wanna-build people to > help for that. It's not exactly outside of dak. I think we should sketch out what's needed post-wheezy. (I.e. it would help us if the uploads accepted would be machine readable so that we can figure out what exactly, mainly architecture-wise, entered the archive and when. Given that we won't have fully architecture independent builds we'd also need to deal with rejects because the arch:all entered the archive through another upload. I have a set of notes on that at home.) > Adjusting dak then to throw away stuff and only allow buildd keys to > have .debs pass through isn't all that hard. I don't think that will happen or we'll have a GR about it. (The throw-away of binary-only uploads, that is.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Popularity of bzr-builddeb and dh-make
On Wed, Oct 17, 2012 at 11:19:01AM +0200, Daniel Holbach wrote: > On 17.10.2012 11:13, Игорь Пашев wrote: > > 2012/10/17 Hideki Yamane : > >> No, LP is good website for development with collaboration. > > Can I have my own LP, please? > https://dev.launchpad.net/Running should help you with that. With the danger of being sued if you put up the result onto the public interwebs. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Popularity of bzr-builddeb and dh-make
On Wed, Oct 17, 2012 at 11:43:36PM +0200, Philipp Kern wrote: > On Wed, Oct 17, 2012 at 11:19:01AM +0200, Daniel Holbach wrote: > > On 17.10.2012 11:13, Игорь Пашев wrote: > > > 2012/10/17 Hideki Yamane : > > >> No, LP is good website for development with collaboration. > > > Can I have my own LP, please? > > https://dev.launchpad.net/Running should help you with that. > > With the danger of being sued if you put up the result onto the public > interwebs. Could you please expand on that? Logo / trademark reasons or license issues? > > Kind regards > Philipp Kern -- .''`. 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: Discarding uploaded binary packages
On 17.10.2012 21:49, Steve Langasek wrote: > On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: >> Joerg Jaspert writes: >>> Its for after wheezy, definitely. Also, there are some open issues to >>> be solved for this to happen. The most important is being able to deal >>> with arch all packages. And worse - arch all packages able to build >>> only on certain architectures. But thats outside dak and my area. Goto >>> the buildd/wanna-build people to help for that. > >> Also remeber, there are packages like cmucl that can only be built by the >> same upstream release of itself and can currently survive in Debian >> because the maintainer can upload a bootstrapped binary package along the >> source > > Which is, frankly, an absurd requirement. Someone should fix this package > to bootstrap properly, and if disallowing binary uploads forces the issue, > that's a good thing. you know better. The last one I did identify is eigenbase-resgen. Others that come to mind are fpc, mlton, ... and adding new features / packages to the GNU toolchain requires manual interaction for glibc/gcc uploads, which can't be done with source only uploads. Matthias -- 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/507f27a1.2030...@debian.org
Re: Popularity of bzr-builddeb and dh-make
Paul, am Wed, Oct 17, 2012 at 05:48:39PM -0400 hast du folgendes geschrieben: > > With the danger of being sued if you put up the result onto the public > > interwebs. > Could you please expand on that? Logo / trademark reasons or license > issues? it's not very hard to find https://dev.launchpad.net/LaunchpadLicense It's designed not to be run outside Canonical except for development. And it's not just the logo/trademark, no. I'd completely understand that. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Popularity of bzr-builddeb and dh-make
On 2012-10-17 23:55:08 +0200 (+0200), Philipp Kern wrote:
> am Wed, Oct 17, 2012 at 05:48:39PM -0400 hast du folgendes geschrieben:
> > > With the danger of being sued if you put up the result onto the public
> > > interwebs.
> >
> > Could you please expand on that? Logo / trademark reasons or license
> > issues?
>
> it's not very hard to find https://dev.launchpad.net/LaunchpadLicense
>
> It's designed not to be run outside Canonical except for development.
> And it's not just the logo/trademark, no. I'd completely understand that.
The section to which you seem to be referring is relevant
specifically to "image and icon files in Launchpad." If you replace
those with your own artwork or some other released under a
compatible license and respect any other requirements of the AGPLv3,
it doesn't sound like there should be any concern on the part of
Canonical. What am I missing?
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
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/20121017221635.gl22...@yuggoth.org
Re: Popularity of bzr-builddeb and dh-make
On 17 October 2012 22:55, Philipp Kern wrote: > Paul, > > am Wed, Oct 17, 2012 at 05:48:39PM -0400 hast du folgendes geschrieben: >> > With the danger of being sued if you put up the result onto the public >> > interwebs. >> Could you please expand on that? Logo / trademark reasons or license >> issues? > > it's not very hard to find https://dev.launchpad.net/LaunchpadLicense > > It's designed not to be run outside Canonical except for development. > And it's not just the logo/trademark, no. I'd completely understand that. > Huh?! Please read it again. Code is licensed under under the GNU Affero General Public License, version 3 Image and icon files are copyrighted, but can be used in dev environments Similar to how e.g. Firefox is Iceweasel in Debian. So yes you can run in outside of Canonical as long as you provide your own images & icons (there are not that many and readily replaceable with tango icons) @Jeremy I don't think you are missing anything =) Regards, Dmitrijs. -- 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/canbhluifyhoaxydbnk9rdkd7ketbj9y+jpjbq0a4ui5jeok...@mail.gmail.com
Re: Popularity of bzr-builddeb and dh-make
On 17 October 2012 09:57, Игорь Пашев wrote: > For git we have gitweb, gitolite, git-daemon, pristine-tar. > I'd like to have similar for bzr, hg and svn. > bzr-builddeb gives pristine-tar support bzr serve is the equivalent of git-daemon and it is builtin loggerhead is replacement for gitweb Above three are packaged in debian. Loggerhead is used @ http://anonscm.debian.org/loggerhead/ as well as savannah and launchpad. gitolite - 3 replacements are listed here http://serverfault.com/questions/325721/something-like-gitolite-for-bazaar (I wouldn't be expecting them to be 100% feature complete, but actually it's easier in bzr since branches are direcories and code repository can be separate form the branch, you can simply use POSIX ACL on the folders, yet share the main repo with stacked branches) > It's not about technology, but about collaboration. > > That's why I prefer git. > Huh, these two contradict each other unless you somehow imply that all of the people you ever would want to collaborate with use git. Regards, Dmitrijs. > 2012/10/17 Marc Haber : >> On Thu, 11 Oct 2012 16:31:00 -0700, Steve Langasek >> wrote: >>>The popularity of subversion >>>for packaging is a measure of inertia and/or ignorance, not of the >>>appropriateness of the tool. >> >> I find this attitute improperly offensive. The choice of tool is the >> decision of the maintainer, and subversion does version control rather >> well for most uses. >> >> Greetings >> Marc >> -- >> -- !! No courtesy copies, please !! - >> Marc Haber | " Questions are the | Mailadresse im Header >> Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ >> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 >> >> >> -- >> 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/e1tonac-0001xl...@swivel.zugschlus.de >> > > > -- > 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/call-q8xzg7_se9yuprgh_a5asu8v+ktzxy6j5_q0gzk+0cq...@mail.gmail.com > -- 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/CANBHLUgfpgDkJq0c-1UjXM1Q=5k+owkcon1ma-zisjf0n5w...@mail.gmail.com
Re: Discarding uploaded binary packages
On Wed, Oct 17, 2012 at 11:48:17PM +0200, Matthias Klose wrote: > On 17.10.2012 21:49, Steve Langasek wrote: > > On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: > >> Joerg Jaspert writes: > >>> Its for after wheezy, definitely. Also, there are some open issues to > >>> be solved for this to happen. The most important is being able to deal > >>> with arch all packages. And worse - arch all packages able to build > >>> only on certain architectures. But thats outside dak and my area. Goto > >>> the buildd/wanna-build people to help for that. > >> Also remeber, there are packages like cmucl that can only be built by the > >> same upstream release of itself and can currently survive in Debian > >> because the maintainer can upload a bootstrapped binary package along the > >> source > > Which is, frankly, an absurd requirement. Someone should fix this package > > to bootstrap properly, and if disallowing binary uploads forces the issue, > > that's a good thing. > you know better. The last one I did identify is eigenbase-resgen. Others > that come to mind are fpc, mlton, ... I am aware that other such packages exist. I just don't think we should support them if they can't be bootstrapped properly. > and adding new features / packages to the GNU toolchain requires manual > interaction for glibc/gcc uploads, which can't be done with source only > uploads. For the benefit of other readers on this list, the unstated context here is that there's a non-zero incidence of having to manually re-bootstrap compilers in the Ubuntu archive. The intermediate binaries used in this bootstrapping are discarded and never published to Ubuntu in order to conserve the "no binary uploads" rule, and this does impose some non-negligible overhead on the folks who tend these toolchain packages, due to the highly constrained build environment they have to work in. So yes, this is something that should be accounted for if Debian moves to a model where binary uploads are discarded and rebuilt. However, I suspect that for all the sensible cases, the proposal to add staged-build metadata (for bootstrapping circular build-dependencies on new ports) would be sufficient to make this problem go away too. But I'm a lot less concerned about the kinds of self-build-depending packages whose names are frequently taken in vain (raise your hand if you've ever tried to fix an RC bug in mlton). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#690819: ITP: redmine-plugin-recaptcha -- Redmine plugin to add a reCAPTCHA to user self-registration
Package: wnpp Severity: wishlist Owner: "David Martínez Moreno" * Package name: redmine-plugin-recaptcha Version : 0.1.0 Upstream Author : Shane StClair * URL : https://github.com/srstclair/redmine_recaptcha * License : MIT Programming Lang: Ruby Description : Redmine plugin to add a reCAPTCHA to user self-registration This plugin gives Redmine the ability to display reCAPTCHA authentication in order to allow user self-registration and prevent spam. Before using it, you will need to sign-up for a reCAPTCHA key at http://www.google.com/recaptcha. -- 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/20121017230416.28022.69181.report...@belgarath.thefacebook.com
Re: Discarding uploaded binary packages
On Thu, 18 Oct 2012, Michael Gilbert wrote: > Maybe someone would be interested in writing a lintian check for these > issues? Something a bit more advanced than this > > $ strings /sbin/dhclient | grep ^PATH > PATH=/home/zero79/source/git/isc-dhcp/debian/tmp/usr/sbin:/sbin:/bin:/usr/s > bin:/usr/bin > > would have caught the issue (advanced aspect being that reasonable > paths are ok'd). Having a PATH set isn't a problem if it's set to something like /sbin:/bin or something else restrictive. The PATH isn't the problem here anyway it's the use of a directory under /home which would potentially be a problem if it's used for configuration files or data files. We could have a lintian warning for any occurance of the string "/home" in a packaged file and have error conditions for "/build" and the current value of $HOME for the account running lintian. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201210181320.44098.russ...@coker.com.au
Re: Bug#690569: Bug#690142: remote named DoS on recursor (CVE-2012-5166) and Bug#690569 (DNS wildcards fail to resolve with DNSSEC enabled)
On Wed, Oct 17, 2012 at 1:57 PM, Michael Gilbert wrote: > On Tue, Oct 16, 2012 at 6:49 PM, Matthew Grant wrote: > > Can Bug #690569 (DNS wildcards fail to resolve with DNSsec enabled - > breaks > > RFC 4035)be reclassified as grave, or at least Important severity? > You implied a bug severity increase. Its now at important. > > > > We need to get something done about this one. Having to turn off DNSSEC > > validation to get correct resolution behaviour is not good for security > re > > DNS cache poisoning attacks, which is why DNSSEC was implemented in DNS. > > I did a diff between 9.6-R5 and -R6 and extracted the parts seeming to > relate to wildcard handling. Someone will have to look at whether > those are the right changes and if they're complete, and then port it > to the current version. See attached. > Checked diff. Its looks a mess. Have you compiled bind9 package and checked that it handles wiildcard query? I am not confident that data structures are handled correctly. (Used to be professional router C programmer, and have extensive kernel patch experience) Could someone on the security team who knows bind9 look at this please to see if they can patch bind9 9.8.1.dfsg-4.2 and 9.7.3 (squeeze)? > > Also, to resolve this, is it alright to NMU Bind 9.8.4 (latest 9.8.x) > > please. Lamount Jones, it would be good if you could do this please? > Does > > not look that hard. Have looked in bind9 package git. > > No. We're in the freeze now. Fixes need to be backported. > If backporting a fix is not possible with the certainty of no introduced bugs, we have no choice. Debian Bind9 cannot ship with a basic DNS protocol handling error. As it stands it is severely broken in the resolver. DNSSEC on the Internet is now a must. ISC have been diligent in backporting fixes to their 9.8.x minor version stream. There are only one or 2 new features, and I believe 1 or 2 configuration changes that are backwards compatible Consequently Bind 9.8.4 (or 9.7.7) is mostly coherent with Debian's policy of back porting fixes. (ISC really know their own data structures, but also unfortunately do not make their VCS publicly available, only release complete tarballs, so finding the 100% correct patch can be a major problem.) I believe a policy exception is possible in this case if needed, given that bind9 is such an important piece of software. My case is put. Could the security team please help to determine what to do. Regards, Matthew Grant
Re: Discarding uploaded binary packages
On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote: > We could have a lintian warning for any occurance of the string "/home" in a > packaged file and have error conditions for "/build" and the current value of > $HOME for the account running lintian. Based on a quick grep of /usr/bin on my laptop, this is going to have a fair number of false positives; commented out paths, paths in POD documentation, URLs, paths outside of /home that include /home in their name somewhere. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6glutn+ec2hmnoekkpeslf85hgbuyqmqav--mgd0yp...@mail.gmail.com
Re: Discarding uploaded binary packages
On Thu, 18 Oct 2012, Paul Wise wrote: > On Thu, Oct 18, 2012 at 10:20 AM, Russell Coker wrote: > > We could have a lintian warning for any occurance of the string "/home" > > in a packaged file and have error conditions for "/build" and the > > current value of $HOME for the account running lintian. > > Based on a quick grep of /usr/bin on my laptop, this is going to have > a fair number of false positives; commented out paths, paths in POD > documentation, URLs, paths outside of /home that include /home in > their name somewhere. For a warning it doesn't matter much if we have a few false-positives. For the error conditions that I suggest for /build and $HOME I find it difficult to imagine false-positives except the case where a DD uses their own home directory as an example in help text, and that can't be a good practice anyway. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201210181337.00861.russ...@coker.com.au
Re: Discarding uploaded binary packages
On Thu, Oct 18, 2012 at 10:37 AM, Russell Coker wrote: > For a warning it doesn't matter much if we have a few false-positives. For > the error conditions that I suggest for /build and $HOME I find it difficult > to > imagine false-positives except the case where a DD uses their own home > directory as an example in help text, and that can't be a good practice > anyway. Since you don't seem to believe me, please try this command yourself grep -r /home /usr/bin/ /usr/games There are lots of false positives. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6FYfzcbAFwkAaQ_MKyrwSQkPp_=zib5YcMrMBC=4yb...@mail.gmail.com
Re: (seemingly) declinging bug report numbers
On Wed, 17 Oct 2012 07:53:01 + (UTC), Sune Vuorela wrote: >On 2012-10-17, Svante Signell wrote: >> Even some bugs _with_ patches are treated the same way or kept open and >> never acted on. Shouldn't the number of open bugs be decreasing with >> time, not being constant or increasing as is the case for some packages? > >in many cases, the amount of open bug reports is more a function of >number of users of a given package, rather than a function of the age of >the package. And a function of the size of the package. Many packages are a nightmare to maintain just because of sheer size, but I still feel that Debian SHOULD[1] take care of Upstream Bugs as well and not require people to report upstream bugs directly to upstream. >> Might be so, what to do about it? Maybe more team-maintained packages. >> And better procedures for package salvaging, as the current discussion >> thread on salvaging packages shows. > >Neither of those gets *more people* in the teams of core packages. Ack. > - who would like a couple of DDs and a dozen of bug workers for pkg-kde Amen. Greetings Marc [1] in the sense of RFC 2119. -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1toieu-0002md...@swivel.zugschlus.de
Re: Popularity of bzr-builddeb and dh-make
On Wed, Oct 17, 2012 at 10:16:35PM +, Jeremy Stanley wrote: > The section to which you seem to be referring is relevant > specifically to "image and icon files in Launchpad." If you replace > those with your own artwork or some other released under a > compatible license and respect any other requirements of the AGPLv3, > it doesn't sound like there should be any concern on the part of > Canonical. What am I missing? The last time I looked this was a non-negligible amount of files, but I lack the resources to re-check. The point was that you cannot take it as-is and answering "here's the source" to "I want my own LP for non-LP development" is not exactly the truth. I don't know if they split the encumbered files off the main repository. Maybe I'm too pessimistic here. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Popularity of bzr-builddeb and dh-make
]] Dmitrijs Ledkovs > loggerhead is replacement for gitweb As one of the alioth admins, I'd like to contest this statement. loggerhead is a replacement for gitweb in the same way that crawling is a replacement for sprinting. Yes, we «run» it, but it's memory-hungry, slow and crash-prone. It also wedges randomly and sometimes forgets about half the repositories that exists on alioth. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d30gwazb@qurzaw.varnish-software.com
