Re: Question on DPL delegations.
Hi, On 26/03/14 at 07:31 +0900, Charles Plessy wrote: Le Tue, Mar 25, 2014 at 05:44:55PM +0100, Lucas Nussbaum a écrit : Internally, we would need to adjust, but I'm quite sure that we would manage. Actually, the lack of a DPL might make everybody feel more enabled/empowered to solve problems that are usually deferred to the DPL, which could be a good thing. Hi Lucas and Neil, without DPL, there would be no DPL delegations. I have a question for you related to delegations. When a delegate is completely inactive as a delegate, do you think that his delegation should be renewed ? The DPL makes the final decision about delegations, but it should generally be the conclusion of a discussion with the team. Delegations without the team's agreement should be limited to extreme cases, for teams which are very dysfunctional. It happened in the past, but I hope that this will never happen again. There are good reasons for keeping people whose activity level has reduced in a team. For example, in cases where the team has to make difficult policy decisions (e.g. DAM or ftpmasters), they can serve as the team's long term memory, and provide additional viewpoints. There are also good reasons for not keeping them in the team: they might be perceived as badge collectors by the rest of the team, or as people who like to express their opinion and influence the team's decisions but do not do the resulting work. That can have a very negative impact on the atmosphere inside the team. It's difficult to draw a general line, and I believe that each case should be examined separately, with the delegate in question, and with the rest of the team. Lucas signature.asc Description: Digital signature
Re: non-free?
On 25/03/14 at 07:21 +0800, Paul Wise wrote: For opening RAR 3.0 archives, you can replace rar with unar these days. Nice; if it really works with all RAR 3.0 archives, it might be worth updating the unrar-free package description, which currently says: Description-en: Unarchiver for .rar files Unrar can extract files from .rar archives. Can't handle some archives in the RAR 3.0 format, only the non-free unrar package can do that. In practice almost everyone has non-free in their sources.list due to most firmware being non-free. Also most developers will have non-free in their sources.list due to various GNU documentation being in non-free. Also most users will have non-free in their sources.list due to things like Flash. At DebConf we discussed adding additional sub-components (non-free/docs non-free/hw non-free/web non-free/games etc) for different purposes. People needing specific classes of non-free software could then enable just those subclasses that they need. I think this would help in addition to your suggestion. Indeed. Lucas signature.asc Description: Digital signature
Re: non-free?
On 25/03/14 at 10:25 +, Steve McIntyre wrote:
On Tue, Mar 25, 2014 at 09:32:26AM +0100, Frank Lin PIAT wrote:
On Tue, 2014-03-25 at 15:29 +0900, Stefano Zacchiroli wrote:
Because as long as we document it, it's very hard to claim that
non-free is not part of Debian, when you could just add it as a
keyword side-by-side with main in your sources.list.
The firmware have been moved from main to non-free a few years ago. The
unintended consequences is that almost every system now use the non-free
suite.
Therefore users are more likely to install non-free packages.
Yup. Various conversations have happened around firmware in the last
few years, but this is an effect that some people may not be aware
of. So...
Neil and Lucas: what do you have to say on this front? Of all the
things that *could* be done here, what would you like to see
personally?
I think that most of the ideas about increasing awareness about non-free
software are good ideas, and I'd like to see the ones for which we can find
volunteers implemented ;)
Something else that would be nice to have is a way to track the story
behind each piece of non-free software. There are some cases where
software ends up in non-free for rather obscure (but correct!) reasons.
It would be great to have a place to document those reasons, the
freedoms that are given up when using that piece of software, the state
of alternatives, pointers to relevant bugs or contact points that one
cloud lobby, etc.
It would be quite easy to do that by starting from the popcon ranking of
non-free packages[1]. Maybe something for a wiki.non-free.org?
Lucas
[1] UDD query: select package, insts from popcon
where package in (select package from packages where release='sid' and
component in ('non-free', 'contrib'))
order by insts desc limit 30;
signature.asc
Description: Digital signature
Re: non-free?
On 27/03/14 at 20:38 +0800, Paul Wise wrote: On Thu, 2014-03-27 at 10:32 +0100, Lucas Nussbaum wrote: Nice; if it really works with all RAR 3.0 archives, it might be worth updating the unrar-free package description, which currently says: Description-en: Unarchiver for .rar files Unrar can extract files from .rar archives. Can't handle some archives in the RAR 3.0 format, only the non-free unrar package can do that. Wrong package, you are looking at unrar not unar. No, I'm saying that, if unar can open all RAR 3.0 archives, the unrar-free package description should probably be updated to point to unar rather than unrar. Lucas signature.asc Description: Digital signature
Re: non-free?
On Thu, Mar 27, 2014 at 5:53 PM, Lucas Nussbaum wrote: Something else that would be nice to have is a way to track the story behind each piece of non-free software. There are some cases where software ends up in non-free for rather obscure (but correct!) reasons. It would be great to have a place to document those reasons, the freedoms that are given up when using that piece of software, the state of alternatives, pointers to relevant bugs or contact points that one cloud lobby, etc. The old way was to store (most of) that information here: http://nonfree.alioth.debian.org/ Now Debian policy (section 12.5) says it should be stored in debian/copyright. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gxp5vv23fzhxex386w2x1mvezdgduk_y-frtggvyq...@mail.gmail.com
``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
[ Cc:-ing -policy ] On Thu, Mar 27, 2014 at 09:10:05PM +0800, Paul Wise wrote: Now Debian policy (section 12.5) says it should be stored in debian/copyright. Right. For reference here is the relevant snippet from §12.5: Packages in the _contrib_ or _non-free_ archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why. and from Copyright Format 1.0: Disclaimer Formatted text, no synopsis: this field is used for non-free or contrib packages to state that they are not part of Debian and to explain why (see Debian Policy section 12.5). Questions for my -policy friends: can I conclude from the above that the Disclaimer field is to be used _only_ for contrib/non-free packages, and only to explain the reason of their (transitive) non-free-ness? Or is there a risk of overloading it for other reasons? (The current text implies it is not, but the name is a bit generic, and I prefer safe over sorry.) If so, I'll be happy to batchly extract those reasons and publish them somewhere at *.non-free.org. Similarly, once published, it could probably also be used to make vrms show the reason of non-free-ness, which as discussed elsewhere in this thread would be rather cool. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former 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: non-free?
On Thu, Mar 27, 2014 at 01:58:26PM +0100, Lucas Nussbaum wrote: On 27/03/14 at 20:38 +0800, Paul Wise wrote: On Thu, 2014-03-27 at 10:32 +0100, Lucas Nussbaum wrote: Nice; if it really works with all RAR 3.0 archives, it might be worth updating the unrar-free package description, which currently says: Description-en: Unarchiver for .rar files Unrar can extract files from .rar archives. Can't handle some archives in the RAR 3.0 format, only the non-free unrar package can do that. Wrong package, you are looking at unrar not unar. No, I'm saying that, if unar can open all RAR 3.0 archives, the unrar-free package description should probably be updated to point to unar rather than unrar. If unar can open all rar-archives, why not drop unrar and unrar-nonfree from the archives? That way we'd be rid of one crippled and one non-free package, all in one fell swoop :) Kind regards, David Weinehall -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140327164937.gn25...@hirohito.acc.umu.se
Re: ``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
Stefano Zacchiroli z...@debian.org writes: On Thu, Mar 27, 2014 at 09:10:05PM +0800, Paul Wise wrote: Now Debian policy (section 12.5) says it should be stored in debian/copyright. Right. For reference here is the relevant snippet from §12.5: Packages in the _contrib_ or _non-free_ archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why. and from Copyright Format 1.0: Disclaimer Formatted text, no synopsis: this field is used for non-free or contrib packages to state that they are not part of Debian and to explain why (see Debian Policy section 12.5). Questions for my -policy friends: can I conclude from the above that the Disclaimer field is to be used _only_ for contrib/non-free packages, and only to explain the reason of their (transitive) non-free-ness? Or is there a risk of overloading it for other reasons? (The current text implies it is not, but the name is a bit generic, and I prefer safe over sorry.) I believe the intent was for it to be used only for this purpose. It probably would have been better to give it a more unambiguous name. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ha6jpnd2@windlord.stanford.edu
Re: ``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
On Thu, Mar 27, 2014 at 10:23:05AM -0700, Russ Allbery wrote: Stefano Zacchiroli z...@debian.org writes: Questions for my -policy friends: can I conclude from the above that the Disclaimer field is to be used _only_ for contrib/non-free packages, and only to explain the reason of their (transitive) non-free-ness? Or is there a risk of overloading it for other reasons? (The current text implies it is not, but the name is a bit generic, and I prefer safe over sorry.) I believe the intent was for it to be used only for this purpose. It probably would have been better to give it a more unambiguous name. As one of the DEP5 drivers, I believe Russ is correct. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140327173202.gd5...@mavolio.codethink.co.uk
Re: All DPL candidates: about the PPAMAIN
Hi Thomas, On Sat, Mar 15, 2014 at 03:07:39PM +0800, Thomas Goirand wrote: Though, it is my understanding that those who are capable of doing the work are too busy. So what is your plan? Is using Debian money for sponsoring that work one of the things you would do? If yes, up to what amount would you accept to spend? (note: I think it would be money wisely spent) I'm very wary of using Debian money directly to pay people for development. No matter what your view on if this is good expenditure, I think it's been shown that this is highly divisive to the project. We're a community of volunteers, and the proposals to use money in this way is well documented, so I won't repeat them here. [0] For hardware though, I think that this would indeed be legitimate expenditure - we should ensure that it's not a technical factor that's blocking the deployment of this. However, I think that there's a wider question which can be asked: is wanna-build/britney/dak the best option for the project? SteamOS for example uses OBS [1] to completely rebuild Debian. I'm not suggesting we immediately dump our tools, but it's certainly an option we should keep open in any evaluation. [0] For those who don't remember, search for DUNC tank on your favourite search engine. [1] http://openbuildservice.org/ -- signature.asc Description: Digital signature
Re: what should the DFSG apply to?
Hi Paul, Slightly re-arranging the question order, if that's ok. On Sat, Mar 22, 2014 at 03:42:43PM +0800, Paul Wise wrote: Please share your thoughts on the SC and DFSG, in particular: Which items of the DFSG should apply to which types of works? How do you currently determine which files in upstream source packages are source and which are not? I take the following principle: If I install a package, and don't like either how it works, or how it looks, can I change it myself? In the case of a minified .js file for example, without other source, I technically *can*, but it would make my brain leak out of my ears to do so. Thus for me personally, it's not the preferred form of modification. However, we should also consider if there's an alternative. If the preferred form of modification has been lost in the mists of time, then it's quite possible to describe the resultant file as now the defacto form of modification. How do you currently apply the DFSG wrt your Debian packaging work? How do you currently deal with upstream source packages that include generated files instead of creating them at build time? Speaking in general, as I've managed to give away or remove all my packages that I directly maintain myself, I would remove them from the source package. Would you initiate or support a GR to replace uses of the words program and software in the DFSG with work where appropriate? I probably wouldn't initiate one, I don't think that this is currently the biggest blocking issue facing the project, and would rather avoid another lengthy debate on the topic. However, I would probably support it if one was proposed, at least so that we can get closure on the issue. Neil -- signature.asc Description: Digital signature
Re: To Neil: 2IC
Hi Lucas, On Mon, Mar 24, 2014 at 08:27:52PM +0100, Lucas Nussbaum wrote: In your rebuttal, you are quite critical of the idea of a board. You raise concerns about the risk of creating a cabal, and about transparency and democratic accountability. I fully agree that those concerns are valid ones, and actually even mentioned them in my platform (Of course, there is the risk of creating a cabal, and of reducing transparency. I am absolutely committed to avoiding that. [...]). Indeed, but you seem to have missed out how you'll avoid it. The board concept doesn't seem to have any details on who would serve on it at what time, except essentially by appointment of the DPL when the DPL decides that someone has done some things that the DPL wants done. Saying that you're committed to avoiding that is fine, but the question remains *how* you'd do so which is absent from the platform. On the other hand, you defer the decision about a 2IC until after the election. Apologies for not making myself clearer for you on this, but I'm afraid you're putting words into my mouth here. It's a concept that I find interesting, and would put more thought into it when elected, but I do not intend on appointing a 2IC. Neil -- signature.asc Description: Digital signature
Re: All DPL candidates: Debian assets
Hi Neil, On Thu, Mar 27, 2014 at 06:44:24PM +, Neil McGovern wrote: On Fri, Mar 21, 2014 at 04:02:57PM +, Lars Wirzenius wrote: On Thu, Mar 20, 2014 at 10:44:07PM +0100, Neil McGovern wrote: At the moment, in just SPI, we have 100k USD awaiting being spent. As an indication, that’s enough for a DebConf without any sponsors! Our donations should be spent. Be that better porter boxes, or a better backup service, or simply making sure our core machines are replaced regularly. Lucas and Neil, what are your opinions on spending some of that money on frequent springs, e.g., for bug fixing? I'm a lot more relaxed than Lucas about spending our excess money in this way. If there's an organised BSP or event, then applying to Debian through the DPL is very useful. However, I'd expect the organisers of the BSP/sprint/whatever to seek local sponsorship as well if possible. Do you think it's appropriate for these organizers to use Debian's name in seeking local sponsorship without consulting the DPL? I ask because in many cases, our local sponsors are the same as our global sponsors. From a Debian fundraising POV, I am concerned about the idea of individual DDs soliciting contributions to Debian in an uncoordinated manner, that could jeopardize our future ability to secure sponsorship from them at the global level. There have indeed been several events in the past year organized at the local/regional level that were sponsored by companies that are regular sponsors of DebConf, and while there is no evidence that this has negatively impacted DebConf fundraising (it's possible that these sponsors have increased their overall sponsorship because of the local angle, rather than it taking away from money they would've given to Debian globally), I think DDs soliciting sponsorship in Debian's name is something that should only be done with central approval. What are your thoughts on how this should be handled? -- 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
All DPL candidates: DPL Term lengths and limits?
I know this has been raised in elections past, but any thoughts on the current one-year DPL terms, and unlimited terms allowed? If thoughts are geared toward change do you have any plans to actively try to change the status quo? I ask because it seems that a lot of energy is devoted to the election every year that might be directed towards other parts of the project. One idea that I thought showed promise was the idea of two year terms, but at the ~10.5 month mark the standing DPL had to confirm they were serving the second half of their term, or an election would automatically be triggered. Obviously any changes discussed/proposed would not impact this election. -Brian -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACFaiRxE+xfWjzhR2ART_8iSOZgyfJeYAL4BBXjV=esxnwz...@mail.gmail.com
Re: ``Disclaimer'' field to document non-free-ness reasons [ Was: non-free? ]
Le Thu, Mar 27, 2014 at 10:48:48PM +0900, Stefano Zacchiroli a écrit : Questions for my -policy friends: can I conclude from the above that the Disclaimer field is to be used _only_ for contrib/non-free packages, and only to explain the reason of their (transitive) non-free-ness? Or is there a risk of overloading it for other reasons? (The current text implies it is not, but the name is a bit generic, and I prefer safe over sorry.) Hi Stefano, this use was my intent in 2008 when I added this field, following the release of version 3.8.0.0 of our Policy, that closed bug #65577 asking that “copyright should include notice if a package is not a part of Debian distribution”. https://wiki.debian.org/Proposals/CopyrightFormat?action=diffrev1=183rev2=184 I do not remember if I wanted the Disclaimer field to be exclusively used for statements that packages are not part of the Debian distribution. In any case, a quick inspection of the Debian copyright files in the “packages-metadata” repository show that the field is also being used for other purposes. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328001251.ga21...@falafel.plessy.net
