Re: dput-ng/1.1 in unstable
On Thu, Dec 6, 2012 at 4:02 AM, Paul Tagliamonte wrote: > While the traceback is ugly, that's valid. Note 0xDEFACED isn't 8 long, > it's 7. Even though it's unlikely we'd get that key, I figured the DD > would use a UID that's valid. Anything less than the full fingerprint (8, 7 or whatever) should be considered ambiguous[1]. If there are multiple keys matching the partial fingerprint (of any size), that should be an error. I don't think a partial fingerprint that is 7 characters long should be treated any different than one that is 8 characters. 1. http://www.asheesh.org/note/debian/short-key-ids-are-bad-news -- 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/CAKTje6E+yuMn4+WEqj_gqriPzwmTh5YBpe-Xu+FM7Y=pg9y...@mail.gmail.com
Re: dput-ng/1.1 in unstable
On Wed, Dec 05, 2012 at 08:41:07PM +0100, Benjamin Drung wrote: > Am Dienstag, den 04.12.2012, 10:01 -0500 schrieb Paul Tagliamonte: > > Advantages > > -- > > * dcut support, including management of DM permissions [4] > > I wanted to play with DM permission support and tried an example from > the man page of dcut (adding -O test): Cool. > > $ dcut dm --dm 0xDEFACED --allow glibc linux --deny kfreebsd9 this flag changed. Will fix docs. > > $ dcut -O test dm --uid 0xDEFACED --allow glibc linux --deny kfreebsd9 > Uploading commands file to ftp.upload.debian.org > (incoming: /pub/UploadQueue/) > dput.commands.dm.DmCommandError: DM fingerprint lookupfor argument > 0xDEFACED failed. GnuPG returned error: gpg: error reading key: > malformed user id While the traceback is ugly, that's valid. Note 0xDEFACED isn't 8 long, it's 7. Even though it's unlikely we'd get that key, I figured the DD would use a UID that's valid. It validates the key by checking the DM keyring. You can override that check (if the keyring is out of date, etc) by using --force. Something like: $ dcut -O test dm --uid CACE80AE01512F9AE8AB80D61C01F443C9C93C5A --allow fluxbox or: $ dcut -O test dm --uid "John Stamp " --allow fluxbox If you'd like to fix the docs, that'd be welcome, or I can get to it later on tonight. > > -- > Benjamin Drung > Debian & Ubuntu Developer > Cheers, 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: dput-ng/1.1 in unstable
Am Dienstag, den 04.12.2012, 10:01 -0500 schrieb Paul Tagliamonte: > Advantages > -- > * dcut support, including management of DM permissions [4] I wanted to play with DM permission support and tried an example from the man page of dcut (adding -O test): $ dcut dm --dm 0xDEFACED --allow glibc linux --deny kfreebsd9 usage: dcut [HOST] dm [-h] --uid DM [--allow [PACKAGES [PACKAGES ...]]] [--deny [PACKAGES [PACKAGES ...]]] dcut [HOST] dm: error: argument --uid is required $ dcut -O test dm --uid 0xDEFACED --allow glibc linux --deny kfreebsd9 Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) Traceback (most recent call last): File "/usr/bin/dcut", line 90, in upload_command(args) File "/usr/lib/python2.7/dist-packages/dput/command.py", line 185, in invoke_dcut command.validate(args) File "/usr/lib/python2.7/dist-packages/dput/commands/dm.py", line 113, in validate (args.dm, err)) dput.commands.dm.DmCommandError: DM fingerprint lookupfor argument 0xDEFACED failed. GnuPG returned error: gpg: error reading key: malformed user id -- Benjamin Drung Debian & Ubuntu Developer -- 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/1354736467.7752.3.camel@deep-thought
Re: [buildd-tools-devel] Bug#687396: sbuild: building pyca fails silently
On 12/05/2012 04:34 PM, Julien Cristau wrote: > On Wed, Dec 5, 2012 at 15:17:11 +0100, Roland Stigge wrote: >> On 12/05/2012 03:11 PM, Roland Stigge wrote: >>> But don't worry - it's just a minor change and at least fixes the issue >>> for the protocol. ;-) So others won't be disturbed by it during bug >>> squashing. >> >> So please consider sbuild 0.63.2-1.1 for wheezy (freeze exemption). >> (Maybe Roger will override the package which is now in the DELAYED queue.) >> > What's the justification for making this bug severity:serious? Things > breaking with a "0" debian revision kinda seems like a "don't do that > then" situation… Right, I just checked Policy, 5.6.12 Version: "The package management system will break the version number apart at the last hyphen in the string (if there is one) to determine the upstream_version and debian_revision. The absence of a debian_revision is equivalent to a debian_revision of 0." When pyca_20031119-0_all.deb and pyca_20031119_all.deb are equivalent, and pyca_20031119_all.deb is definitely a native package, we shouldn't have accepted sth. like pyca_20031119-0.diff.gz into the archive. Now the question is, how to handle the mess? :-) Maybe prevent uploads of -0.diff.gz and -0.debian.tar.bz2 in the future, and in tools like sbuild, work around the respective broken packages with a strategy like in the patch in #687396. The case without revision is known to be handled well. And for "-0" packages with Debian specific diffs/tgzs, handle them as non-native package, even though this is formally a forbidden case. Thanks, Roland -- 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/50bf70c6.2090...@debian.org
Bug#695210: ITP: python-xtermcolor -- Python library for terminal color support
Package: wnpp Severity: wishlist Owner: "Salvo 'LtWorf' Tomaselli" * Package name: python-xtermcolor Version : 1.2 Upstream Author : Scott Frazer * URL : https://github.com/broadinstitute/xtermcolor/ * License : MIT Programming Lang: Python Description : Python library for terminal color support Library with simple API to print colored text on terminals, it supports RGB and ANSI colors. -- 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/20121205134313.2448.24915.report...@galileo.dmi.unict.it
Bug#695200: ITP: python-ws4py -- WebSocket library for Python
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: python-ws4py Version : 0.2.3 Upstream Author : Sylvain Hellegouarch * URL : http://www.defuze.org/oss/ws4py/docs/ * License : BSD Programming Lang: Python Description : WebSocket library for Python Python library providing an implementation of the WebSocket protocol defined in RFC 6456. -- 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/20121205121758.31757.51555.reportbug@myh
Re: Contributor agreements and copyright assignment (was Re: Really, about udev, not init sytsems)
On 12/05/2012 06:15 AM, Steve Langasek wrote: > I understand that concern and recognize that this is a not-uncommon > sentiment among Debian folks; this very closely parallels the question of > whether one is willing to release software under a BSD license - or the MPL > - vs. the GPL. But while some people do object to releasing their patches > under a BSD license, there's certainly room for BSD code in Debian. The > same is true of GPL works with contributor agreements. Yes, some folks will > choose not to contribute to it on upstream's terms, but there are still > plenty of others who will. I don't really want to go into the CLA debate (others have better things to share than me about it). But I think we all agree that, for some in Debian (I'm not talking about myself here), the Ubuntu CLA is (at least) annoying, to the point it has been mention in the init debate. So, my question to you Steve is: has this been discuss inside Canonical recently? Would it be possible that Canonical rethinks its contribution policy for at least Upstart (eg: wave the CLA signing requirement for Upstart)? Or is this something that you think has very little chance to change? Cheers, Thomas -- 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/50bf29fb.2090...@debian.org
Bug#695195: ITP: vcr -- record test suite HTTP interactions and replay during future test runs
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-CC: debian-devel@lists.debian.org, debian-cl...@lists.debian.org, Control: affects -1 + cloud.debian.org Package name: vcr (ruby-vcr) Version: 2.9.0 Upstream Author: 2010-2012 Myron Marston URL: https://github.com/myronmarston/vcr License: MIT Description: record test suite HTTP interactions and replay during future test runs VCR provides a simple API to record and replay your test suite's HTTP interactions. . It works with a variety of HTTP client libraries, HTTP stubbing libraries and testing frameworks. -- 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/20121205144637.804410d4bde6041f8244c...@debian.or.jp
Bug#695194: ITP: webmock -- Library for stubbing HTTP requests in Ruby
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-CC: debian-devel@lists.debian.org, debian-cl...@lists.debian.org, Control: affects -1 + cloud.debian.org Package name: webmock (ruby-webmock) Version: 1.9.0 Upstream Author: 2009-2012 Bartosz Blimke URL: https://github.com/bblimke/webmock License: MIT Description: Library for stubbing HTTP requests in Ruby WebMock allows stubbing HTTP requests and setting expectations on HTTP requests. -- 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/20121205144621.250e24173ffb0671c6587...@debian.or.jp
Re: dput-ng/1.1 in unstable
On Tue, 2012-12-04 at 10:01 -0500, Paul Tagliamonte wrote: [...] > * We deliberately do not support some rare dput configuration settings > by design choice. In particular, dinstall post-upload support, and > rsync based uploads (which eventually is a special treatment of SCP > uploads in dput traditional) [...] > You may apt-get install dput-ng and use it as a drop-in replacement to > the older dput package. It will provide the same executables and replace > dput. It is not possible by choice to use both tools in parallel. The > command line interface emulates the old interface for dput. The dcut > command line interface is not call compatible, but provides more > features and (we claim) an easier to use interface. [...] This seems tasteless. It's a 'drop-in replacement' that hijacks all the existing package's names, but actually it's deliberately incompatible? Is it that hard to think of a new name? Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Contributor agreements and copyright assignment
Russ Allbery writes: > Bjørn Mork writes: > >> IANAL, but I believe you are wrong there. You give them much wider >> rights than this by assigning the copyright to the FSF. The copyright >> owner is free to relicense the work in any way they want. > > Have you see the copyright assignment contract that you make with the FSF? Seen and signed :-) > It would be a breach of that contract for them to relicense the work in > any way they want. The contract really does try to address this issue. > > The assignment isn't a unilateral act. The FSF promises to do things in > return for the assignment. Yes. It is pretty clear that the FSF as such cannot redistribute your work under another license. I most certainly may be wrong, and likely is, but I still believe there still is a tiny possiblity that the copyright assignment is transferred as an asset, without being bound by the other parts of the contract. > Now, bankruptcy is indeed a potential problem, since bankruptcy courts can > do all sorts of things, including dissolve or partly dissolve contracts. > But even in that admittedly dangerous situation, I do think there's a fair > amount of legal protection involved. (And one gets some additional legal > protection from the FSF being a non-profit under US law.) Good. Let's hope it won't be necessary. >> I still don't think issues like this should prevent anyone from >> contributing to any currently open source project. Yes, it will be >> frustrating if your work ends up being part of some proprietary >> software, but it's even worse if you cannot contribute to these projects >> out of fear of that happening. > > The main issue for some of us is not so much the ethical objections to > these sorts of agreements but rather the fact that our employers flatly > are not interested in signing anything of the sort, ever, with anyone. > Much of my free software work is done as part of my day job, and my > employer is unwilling to sign any of these agreements (but is fine with me > releasing my work under free software licenses). Yes, that is an important problem with such policies. Bjørn -- 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/87boe87vqv@nemi.mork.no
