Debian Project Leader Election 2024 Results
The winner of the election is Andreas Tille. The details of the results are available at: https://vote.debian.org/2024/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | | 2021 | 1018 | 47.859 | 469 |455 | 89 | 44.695 | 9.50706 | | 2022 | 1023 | 47.976 | 363 |354 | 73 | 34.604 | 7.37860 | | 2023 | 996 | 47.339 | 283 |279 | 71 | 28.012 | 5.89363 | | 2024 | 1010 | 47.671 | 369 |362 | 89 | 35.841 | 7.59375 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2023 Results
Hi, The winner of the election is Jonathan Carter. The details of the results are available at: https://vote.debian.org/2023/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | | 2021 | 1018 | 47.859 | 469 |455 | 89 | 44.695 | 9.50706 | | 2022 | 1023 | 47.976 | 363 |354 | 73 | 34.604 | 7.37860 | | 2023 | 996 | 47.339 | 283 |279 | 71 | 28.012 | 5.89363 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: non-free firmware: results
Hi, The results of the General Resolution about non-free firmware: Option 5 "Change SC for non-free firmware in installer, one installer" The details of the results are available at: https://www.debian.org/vote/2022/vote_003 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2022 Results
Hi, The winner of the election is Jonathan Carter. The details of the results are available at: https://vote.debian.org/2022/vote_002 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | | 2021 | 1018 | 47.859 | 469 |455 | 89 | 44.695 | 9.50706 | | 2022 | 1023 | 47.976 | 363 |354 | 73 | 34.604 | 7.37860 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: Voting secrecy result
Hi, The result of the General Resolution is: Option 2 "Hide identities of Developers casting a particular vote and allow verification" The details of the results are available at: https://www.debian.org/vote/2022/vote_001 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: Change the resolution process: results
Hi, The winner of the General Resolution is: Choice 1: "Amend resolution process, set maximum discussion period" The details of the results are available at: https://www.debian.org/vote/2021/vote_003 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Re: DEP-16 Confidential votes
On Sun, Apr 18, 2021 at 11:58:55PM -0400, Olek Wojnar wrote: > Hi zigo, > > On Sun, Apr 18, 2021 at 6:16 PM Thomas Goirand wrote: > > > > > I'd be very much for leaving the decision of open/close to our > > secretary, with most votes open, and the possibility for him to decide > > when it should be closed. I trust Kurt to do the right thing whenever a > > vote (like the RMS GR) needs to be closed. Otherwise, I very much prefer > > if most votes were staying open. > > > > Note that the RMS GR was, in fact, open. :) > > I respect Kurt's interpretation of the constitution and the reluctance to > single-handedly interpret vague sections. I personally believe that "lists > all the votes cast" (4.2.3) should be interpreted to mean "lists by hash" > or another non-personally-identifying means. Perhaps that will need to be > clarified in the constitution, one way or the other, in the future. My > point is that Kurt's interpretation (as I understand it) is that all > non-DPL votes are open. So I don't believe that Kurt would ever make the > decision to have a confidential non-DPL vote. Kurt: please correct me if I > misunderstand you! The only real difference between a secret and non-secret vote currently is knowing who voted what. In both cases a list of voters and a list of votes is published. Changing the interpretation that we don't publish who voted what would turn our non-secret vote in the same a secret vote. I do no believe that was ever the intention. For every GR we have published who voted what. Kurt
Re: DEP-16 Confidential votes
On Sun, Apr 18, 2021 at 09:22:38PM +, Andrew M.A. Cater wrote: > > No, please don't. We already have problems enough with HTML - a structured > form would need to be fully accessible, secure, validated. A signed email > is (relatively) more straightforward and has served us well for the last > 25 years. An other option is that we have software in Debian that makes it easy to vote using email. For instance, we could have a tool that generates the data that needs to be mailed and have it in a format that that's easy to send over email. Kurt
General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Hi, The results of the General Resolution is: Option 7 "Debian will not issue a public statement on this issue" The details of the results are available at: https://www.debian.org/vote/2021/vote_002 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2021 Results
Hi, The winner of the election is Jonathan Carter. The details of the results are available at: https://vote.debian.org/2021/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | | 2021 | 1018 | 47.859 | 469 |455 | 89 | 44.695 | 9.50706 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Re: "gr_rms" rejected but "Debian Project Leader 2021 Election" worked
On Fri, Apr 16, 2021 at 08:59:24AM +0900, Osamu Aoki wrote: > Hi again, > > This is not GMAIL problem. This involves only My PC and Debian > servers. > > (I use gmail only for recieving mails. I send mail from my Debian > shell account using SSH when I use @debuian.org address to avoid mail > rejections. So Gmail has nothing to do with my problem.) > > $ date -u --iso=sec > 2021-04-15T23:44:44+00:00 > > So still in voting period as far as I am concerned. > > I think the problem is: > > >gpg: WARNING: unsafe permissions on homedir > > >'/srv/vote.debian.org/data/gr_rms' > > I think times execution of permission setting to close voting may have > kicked in too early. Hi Osamu, I've replied privately to the mail you've sent to secretary, but I'm not sure that you saw it. I see that you attempted to vote again, and that you got the same error. Your 3 messages for the RMS GR were not signed, while your mail to the DPL election was signed. The error message contained: gpg: no valid OpenPGP data found. Which is almost always that there is no signature. Please make sure that you actually sign the email. There is no permission problem, nor a problem that the vote is over. Other people are able to vote. Kurt
Re: [External] Re: ThinkPad laptops preinstalled Linux
On Fri, Jun 12, 2020 at 05:10:11PM -0400, Mark Pearson wrote: > Hi Kurt > > On 6/12/2020 2:58 PM, Kurt Roeckx wrote: > > On Wed, Jun 03, 2020 at 01:39:08PM +, Mark Pearson wrote: > > > > > > The good - Lenovo are expanding what they offer on Linux (we had another > > > big announcement yesterday about doing full config on our workstations > > > with Ubuntu and RHEL). We're asking HW vendors to have Linux support > > > upstream including firmware on LVFS which I think is important. It's not > > > perfect yet but it's getting better and better. We're starting to > > > contribute to open source projects. > > > > Hi Mark, > > > > Do you know if Lenovo plans to support Linux on all it's products? > > > > I use LVFS as in indication that it's supported. And there are > > various products I'm considering buying, most of them are > > currently not on LVFS. I'm looking at things from the > > ThinkCentre, IdeaCentre or Legion line. > > > > ThinkCentre should be supported (I'm not 100% sure all of them are - I can > check that) The only one in LVFS are M90n-1 and M625q, where the M625q doesn't seem to be for sale anymore. On the other hand, if I look at the website, it depends on what information you look at. If you just look at the comparison between models, they all only mention Windows 10, except the M75q which mentions Linux. But if you look at the details, the M75s and M75q support Linux, but neither is on LVFS. Kurt
Re: [External] Re: ThinkPad laptops preinstalled Linux
On Wed, Jun 03, 2020 at 01:39:08PM +, Mark Pearson wrote: > > The good - Lenovo are expanding what they offer on Linux (we had another big > announcement yesterday about doing full config on our workstations with > Ubuntu and RHEL). We're asking HW vendors to have Linux support upstream > including firmware on LVFS which I think is important. It's not perfect yet > but it's getting better and better. We're starting to contribute to open > source projects. Hi Mark, Do you know if Lenovo plans to support Linux on all it's products? I use LVFS as in indication that it's supported. And there are various products I'm considering buying, most of them are currently not on LVFS. I'm looking at things from the ThinkCentre, IdeaCentre or Legion line. Kurt
Debian Project Leader Election 2020 Results
Hi, The winner of the election is Jonathan Carter. The details of the results are available at: https://vote.debian.org/2020/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: init systems and systemd results:
Hi, The results of the General Resolution about init systems and systemd is: Option 2 "B: Systemd but we support exploring alternatives" The details of the results are available at: https://www.debian.org/vote/2019/vote_002 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2019 Results
Hi, The winner of the election is Sam Hartman. The details of the results are available at: https://vote.debian.org/2019/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On Sun, Mar 10, 2019 at 01:48:23PM +0100, Joerg Jaspert wrote: > On 15337 March 1977, Sam Hartman wrote: > > > In fairness, I'd recommend that the nominations period be extended for > > some explicit time. I think that we want to have a known window for new > > nominations rather than say starting the campaigning as soon as someone > > nominates themselves. > > §5.2.4 to the rescue. (Something I also missed earlier). > > --8<---cut here---start->8--- > For three weeks after that no more candidates may be nominated; > candidates should use this time for campaigning and discussion. If there > are no candidates at the end of the nomination period then the > nomination period is extended for an additional week, repeatedly if > necessary. > --8<---cut here---end--->8--- > > So basically we are now having one more nomination period week. It also means that the current DPL's term will expire before we have a new DPL. I think this will apply in that case: 6. Technical committee 6.1. Powers [...] 8. The Chair can stand in for the Leader, together with the Secretary As detailed in §7.1(2), the Chair of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. [...] 7. The Project Secretary 7.1. Powers The Secretary: [...] 2. Can stand in for the Leader, together with the Chair of the Technical Committee. If there is no Project Leader then the Chair of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. Kurt
DPL election 2019
Hi, This is the proposed timeline for the 2019 DPL election: Nomination period: Sunday 2019-03-03 - Saturday 2019-03-09 Campaigning period: Sunday 2019-03-10 - Saturday 2019-03-30 Voting period: Sunday 2019-03-31 - Saturday 2019-04-13 Kurt
Re: Appeal procedure for DAM actions
On Thu, Jan 10, 2019 at 09:43:27AM +0100, Kurt Roeckx wrote: > On Wed, Jan 09, 2019 at 11:53:38PM +0100, Karsten Merker wrote: > > > So while I agree there might be possible improvements in how the vote > > > goes, I > > > don't think just deleting that one sentence is it. > > > > I beg to differ :). I have taken a look at Ian's proposal with > > using sqrt(people allowed to vote) instead of a fixed ratio of > > 50%. That doesn't solve the general underlying problem of "not > > voting" generating a bias against the appealer, but it makes such > > a negative effect less likely, so I would consider this at least > > a lot better than a fixed 50% ratio. > > The problem with deleting the sentence is that only 1 person > voting can decide on the result. You really want to have a minimum > of people voting. And once you introduce some kind of quorum, > there is always a (small) advantage for the status quo, but it > assumes they organize themselves to try and take advantage of it. This isn't really correct. With Ian's proposal there is no way to vote tacticly, there is just a minimum amount of people that need to vote, but that's still in the advantage of the status quo. Kurt
Re: Appeal procedure for DAM actions
On Wed, Jan 09, 2019 at 11:53:38PM +0100, Karsten Merker wrote: > > So while I agree there might be possible improvements in how the vote goes, > > I > > don't think just deleting that one sentence is it. > > I beg to differ :). I have taken a look at Ian's proposal with > using sqrt(people allowed to vote) instead of a fixed ratio of > 50%. That doesn't solve the general underlying problem of "not > voting" generating a bias against the appealer, but it makes such > a negative effect less likely, so I would consider this at least > a lot better than a fixed 50% ratio. The problem with deleting the sentence is that only 1 person voting can decide on the result. You really want to have a minimum of people voting. And once you introduce some kind of quorum, there is always a (small) advantage for the status quo, but it assumes they organize themselves to try and take advantage of it. Kurt
Re: Appeal procedure for DAM actions
On Wed, Jan 09, 2019 at 07:28:34PM +0100, Luke Faraone wrote: > On Wed, 9 Jan 2019 at 19:07, Pierre-Elliott Bécue wrote: > > Le 9 janvier 2019 16:49:30 GMT+01:00, Kurt Roeckx a écrit : > > >I would try to use software that can run a vote like that, > > >where it's possible to provide proof that your vote was recorded > > >properly. I think there is such open source software, I just can't > > >remember it. > > > > French lab Loria has developped Belenios, an enhanced version of Helios. > > It was an oblique reference to devotee[1], the Debian voting software. > We already have secret ballots for DPL elections. I don't intend to use devotee for that. I don't think it can currently handle such votes, nor do I want to spend time implementing that. Kurt
Re: Appeal procedure for DAM actions
On Wed, Jan 09, 2019 at 04:28:41PM +0100, Thomas Goirand wrote: > > Would this vote be secret? In some situation, I'd rather not vote than > having my vote disclosed. I'm very much OK for the secretary to see what > I voted for though. The voting would be secret. I think the only output should be the number of yes/no/abstain. I would try to use software that can run a vote like that, where it's possible to provide proof that your vote was recorded properly. I think there is such open source software, I just can't remember it. Kurt
Re: Appeal procedure for DAM actions
On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote: > > we waive the time limit defined in §1 for the cases > from the last 6 months. Would it make sense to have them 1 week from publishing this instead? Kurt
Re: Article 13 of the EU copyright review
On Tue, Jun 05, 2018 at 07:10:05PM +0100, Chris Lamb wrote: > https://savecodeshare.eu/ There is also https://saveyourinternet.eu/ Kurt
Debian Project Leader Election 2018 Results
Hi, The winner of the election is Chris Lamb. His term will start on April 17th, 2018. The details of the results are available at: https://vote.debian.org/2018/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | | 2017 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2017 Results
Hi, The winner of the election is Chris Lamb. His term will start on April 17th, 2017. The details of the results are available at: https://vote.debian.org/2017/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: Declassifying debian-private results
Hi, The results of the General Resolution about declassifying debian-private is: "Further Discussion". The details of the results are available at: https://www.debian.org/vote/2016/vote_002 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
General Resolution: Replace Chairman with Chair
Hi, The results of the General Resolution is that the replacement of Chairman with Chair has been accepted. The details of the results are available at: https://www.debian.org/vote/2016/vote_003 Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Debian Project Leader Election 2016 Results
Hi, The winner of the election is Mehdi Dogguy. His term will start on April 17th, 2016. The details of the results are available at: https://vote.debian.org/2016/vote_001 Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Project assistent
Hi, For the avoidance of any doubt Neil McGovern is no longer the assitent of the secretary. Kurt signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Fri, Apr 17, 2015 at 10:00:56AM +0100, Jonathan McDowell wrote: the answer is 986 at present. So can you give me a list of those 986 so I can update the website? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150419120848.ga3...@roeckx.be
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 09:28:34PM -0500, Gunnar Wolf wrote: Kurt Roeckx dijo [Fri, Apr 17, 2015 at 12:45:37AM +0200]: On Thu, Apr 16, 2015 at 10:41:52PM +0100, Jonathan McDowell wrote: Sadly this list is trivially proved inaccurate So I have no source at all that is can tell me the number of DDs? You can fetch the number of active DD keys [1,2], and add to it the number of removed 1024D keys [3]. When a person who had their key removed due to being too short presents a new key, we take the old one out of the removed-1024 tree as well. People with 1024D keys cannot vote, but don't lose their DD status. As far as I know relying on the keyring and ldap has always been incorrect. The number was always off by a few. Of course, the only authoritative number should be in the hands of DAM. But we have something, uh, quite close to it. It's was my understanding that DAM says that nm.debian.org is authoritative. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150417070901.ga7...@roeckx.be
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 09:26:27AM +0100, Jonathan McDowell wrote: On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - Kurt Roeckx wrote: Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | |--+--++---++-++---| This num DDs seems a bit higher than I'd expect; it looks more like the number of DDs with active keys + emeritus DDs, rather than the number of DDs with active keys + number of non-uploading DDs with active keys + number of DDs with removed 1024 bit keys. active DD keys: 751 active DN keys:12 1024 bit removed DD keys: 220 emeritus keys:283 So I think quorum is 983. It's possible the number might be one or two higher as that won't included anyone who is entirely missing a key at present but such situations are rare. I get the numbers from nm.debian.org, both at https://nm.debian.org/api and https://nm.debian.org/public/findperson/ Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416171222.ga29...@roeckx.be
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 10:41:52PM +0100, Jonathan McDowell wrote: Sadly this list is trivially proved inaccurate So I have no source at all that is can tell me the number of DDs? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416224537.ga2...@roeckx.be
Debian Project Leader Election 2015 Results
Hi, The winner of the election is Neil McGovern His new term will start on April 17th, 2015. The details of the results shall soon be available at: https://vote.debian.org/2015/vote_001 In the mean time the results are also available at: https://vote.debian.org/~secretary/leader2015/results.txt https://vote.debian.org/~secretary/leader2015/results.png The tally sheet is at: https://vote.debian.org/~secretary/leader2015/tally.txt The list of people voting is at: https://vote.debian.org/~secretary/leader2015/voters.txt Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: Debian Project Leader Elections 2015: Call for nominations
On Sun, Mar 08, 2015 at 11:48:54AM +0100, Stefano Zacchiroli wrote: On Wed, Mar 04, 2015 at 08:06:11PM +0100, Debian Project Secretary - Kurt Roeckx wrote: | Nomination | Wednesday, March 4th, 2015 | Tuesday, March 9th, 2015 | ^ The above should rather be Tuesday, March 10th, right? Yes. The webpage seems to have it right. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150308130413.ga30...@roeckx.be
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
On Fri, Oct 17, 2014 at 03:12:35PM +0100, Jonathan Dowland wrote: Dear Kurt, On Tue, Oct 14, 2014 at 09:17:27AM +0200, Kurt Roeckx wrote: If on -vote the required amount of seconds have been reached, I will announce that the GR process has been sarted on debian-devel-announce. This is now the case for one GR and one GR amendement. There may be further amendments. Would you be prepared to post an announcement to d-d-a? As you probably saw by now, I've asked Neil to do this. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017165505.ga8...@roeckx.be
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
On Mon, Oct 13, 2014 at 10:32:35PM +0300, Lars Wirzenius wrote: On Mon, Oct 13, 2014 at 07:30:43PM +0100, Jonathan Dowland wrote: I think we should clearly indicate where GRs should be announced. (Should, I suppose I'm arguing, not must). I think we don't need to name the place in the constitution. I don't think we need a hard rule about where the announcement happens. I do, however, think it would be good to announce all proposed GRs on debian-devel-announce and debian-vote, with Reply-To to debian-vote. This would ensure all DDs hear about every proposed GR. There's not enough of them to cause a lot of d-d-a traffic. If the proposer of a GR forgets to do that, the secretary or some other DD could do it for them. If on -vote the required amount of seconds have been reached, I will announce that the GR process has been sarted on debian-devel-announce. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014071727.ga5...@roeckx.be
General Resolution: Code of conduct results
Hi, The results of the General Resolution about the code of conduct is that the code of conduct is accepted and updates to it should be done via an other General Resolution. The details of the results shall soon be available at: http://vote.debian.org/2014/vote_002 In the mean time the results are also available at: http://vote.debian.org/~secretary/codeofconduct/results.txt http://vote.debian.org/~secretary/codeofconduct/results.png The tally sheet is at: http://vote.debian.org/~secretary/codeofconduct/tally.txt The list of people voting is at: http://vote.debian.org/~secretary/codeofconduct/voters.txt Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: 20140407 keyring report
On Sat, Apr 19, 2014 at 09:41:40PM +, Clint Adams wrote: Upon request. Made with an unpackaged set of keyrings[0]. Thanks for the update. So we had in january: DDs: 623 DSA 624 1024 DMs: 54 DSA 54 1024 non-upload: 0 DSA 0 1024 In february: DDs: 611 DSA 612 1024 DMs: 54 DSA 54 1024 non-upload: 0 DSA 0 1024 And now in April: DDs: 550 DSA 551 1024 DMs: 52 DSA 52 1024 non-upload: 0 DSA 0 1024 So we seem to making some progress, and I hope the rest will follow soon. Specially the DMs don't seem to make any progress. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140419225145.ga11...@roeckx.be
Re: Following GR amendments evolution ? - Was: Re: General Resolution: Code of conduct
On Tue, Mar 11, 2014 at 11:18:10AM +0100, Olivier Berger wrote: Hi. (not subscribed to debian-vote, so please CC me, eventually). Sorry if I'm unaware of details of our constitutional corpus and procedures, but is there a way to track evolutions in a GR page like [0], if not subscribed to -vote ? Since the GR was announced on d-d-a, I think it would be great for those on d-d-a and not on d-v to be able to grasp how the amendments evolve, if we had some version tracking of the page accessible directly from it. There should be links to all relevant e-mails, the proposals, amendements, accepting them, ... Is this not providing enough information? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140311172006.ga23...@roeckx.be
Re: GR proposal: code of conduct
On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: Hi all, This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. So I've put up a vote page with my current understanding at: https://www.debian.org/vote/2014/vote_002 I've made some minor changes since the version that's there now. I intend to mail debian-devel-announce about this soon, so feedback about the current page is welcome. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307173343.ga5...@roeckx.be
Re: GR proposal: code of conduct
On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: == 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. So I've been wondering under which part of the constituion I should be putting all the options. Are they position statements? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307173741.gb5...@roeckx.be
Re: GR proposal: code of conduct
On Fri, Mar 07, 2014 at 06:33:44PM +0100, Kurt Roeckx wrote: On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: Hi all, This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. So I've put up a vote page with my current understanding at: https://www.debian.org/vote/2014/vote_002 I've made some minor changes since the version that's there now. I intend to mail debian-devel-announce about this soon, so feedback about the current page is welcome. It seems lines from the initial text with # where missing, wml removed them. I've just commited the fix for that. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307181313.ga7...@roeckx.be
Re: GR proposal: code of conduct
On Thu, Mar 06, 2014 at 05:08:10PM +, Ian Jackson wrote: Wouter Verhelst writes (GR proposal: code of conduct): This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. I second this proposal. I think that's the 4th second. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306173551.ga10...@roeckx.be
Re: GR proposal: code of conduct
On Thu, Mar 06, 2014 at 01:25:16PM -0500, Andrew Starr-Bochicchio wrote: On Thu, Mar 6, 2014 at 12:35 PM, Kurt Roeckx k...@roeckx.be wrote: On Thu, Mar 06, 2014 at 05:08:10PM +, Ian Jackson wrote: Wouter Verhelst writes (GR proposal: code of conduct): This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. I second this proposal. I think that's the 4th second. I believe we've now reached five: https://lists.debian.org/debian-vote/2014/02/msg7.html https://lists.debian.org/debian-vote/2014/03/msg00112.html https://lists.debian.org/debian-vote/2014/03/msg00115.html https://lists.debian.org/debian-vote/2014/03/msg00116.html https://lists.debian.org/debian-vote/2014/03/msg00117.html So I missed yours for some reason. I'll get started on the vote page. Wouter, are you going to accept Neil's amendment, or should I create 2 options? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306184802.ga12...@roeckx.be
Re: GR proposal: code of conduct
On Thu, Mar 06, 2014 at 05:08:10PM +, Ian Jackson wrote: Wouter Verhelst writes (GR proposal: code of conduct): This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. I second this proposal. I actually got a BAD signature on this. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306190310.ga13...@roeckx.be
Re: GR proposal: code of conduct
On Thu, Mar 06, 2014 at 07:09:49PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: GR proposal: code of conduct): On Thu, Mar 06, 2014 at 05:08:10PM +, Ian Jackson wrote: Wouter Verhelst writes (GR proposal: code of conduct): This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. I second this proposal. I actually got a BAD signature on this. I think it must have been charset-mangled. Wouter's message contained some utf-8. My signed message has utf-8 in it since my software has copied the octets verbatim. Here is a uuencoded copy of the output I got from gnupg. I can at least very the signature with that, and have to agree it's some kind of mangeling gone wrong somewhere. Hmm. Looking at my original message in my MUA it says Content-Type: text/plain; charset=iso-8859-1 which is not right. Perhaps your MUA has done a latin-1 to utf-8 encoding, meaning that your copy of the signed file is in a form of WTF-8. If so then presumably if my message _had_ been in latin-1 with codepoints above 128, it would have been mishandled in the same way ? As far as I can tell the problem is that you're not using MIME and the same problem people have when voting using non-ASCII characters. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306192616.gb13...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Mon, Mar 03, 2014 at 11:39:40AM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote: That doesn't contradict the GR. If the GR passes we have two resolutions: 11th Feb as modified by GR: sysvinit as default, loose coupling 28th Feb we choose not to pass a resolution at the current time [ie on the 28th of February] about coupling These are not contradictory. In particular, the 28th of February resolution should not be read as vacating the 11th of February resolution's GR rider, which is what you are suggesting. I'm not disagreeing that you're allowed to do it, I'm disagreeing that it's a good idea to do it. Does that mean that you are now tending towards the view that Matthew's proposal requires only a simple 1:1 majority ? Yes. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140303210532.gc15...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): This is probably going to require a 2:1 majority requirement as written. Do you agree that the intent can be achieved by something requiring a 1:1 majority ? If so, can you please say how. If you're going to say we need to replace the TC resolution is amended with something like we wish that instead the TC had decided blah, then please reconsider. That would force the GR to avoid saying what its own effect is, which is unnecessarily confusing. Also, writing that text is very cumbersome. The text currently says it's using the TC's power to decide something, and so would fall under 4.1.4. I think the intent of this GR is not to override the TC's decision about the default, so I'm currently not sure what to suggest. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302112246.ga2...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 12:26:38PM +0100, Andreas Barth wrote: * Kurt Roeckx (k...@roeckx.be) [140302 12:23]: On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): This is probably going to require a 2:1 majority requirement as written. Do you agree that the intent can be achieved by something requiring a 1:1 majority ? If so, can you please say how. If you're going to say we need to replace the TC resolution is amended with something like we wish that instead the TC had decided blah, then please reconsider. That would force the GR to avoid saying what its own effect is, which is unnecessarily confusing. Also, writing that text is very cumbersome. The text currently says it's using the TC's power to decide something, and so would fall under 4.1.4. I think the intent of this GR is not to override the TC's decision about the default, so I'm currently not sure what to suggest. I don't see why the text couldn't just say that the developers make a position statement. As per 4.1.5 this could be done with a 1:1-majority. This might have as affect that the ctte's decision about the default is replaced by the result of the GR, and since this GR doesn't want to set the default currently it might result in not having a decision about the default. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302113547.ga3...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 01:06:46PM +0100, Andreas Barth wrote: * Kurt Roeckx (k...@roeckx.be) [140302 12:36]: On Sun, Mar 02, 2014 at 12:26:38PM +0100, Andreas Barth wrote: * Kurt Roeckx (k...@roeckx.be) [140302 12:23]: On Sun, Mar 02, 2014 at 11:01:16AM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): This is probably going to require a 2:1 majority requirement as written. Do you agree that the intent can be achieved by something requiring a 1:1 majority ? If so, can you please say how. If you're going to say we need to replace the TC resolution is amended with something like we wish that instead the TC had decided blah, then please reconsider. That would force the GR to avoid saying what its own effect is, which is unnecessarily confusing. Also, writing that text is very cumbersome. The text currently says it's using the TC's power to decide something, and so would fall under 4.1.4. I think the intent of this GR is not to override the TC's decision about the default, so I'm currently not sure what to suggest. I don't see why the text couldn't just say that the developers make a position statement. As per 4.1.5 this could be done with a 1:1-majority. This might have as affect that the ctte's decision about the default is replaced by the result of the GR, and since this GR doesn't want to set the default currently it might result in not having a decision about the default. Thanks for the reference to the auto-nuke clause in the TC decision. How about adding something along the lines To avoid any doubt, this decision does not replace the TC resolution to avoid invoking that clause and keep the current decision (because that is also what this proposal wants to achive)? I think that should work. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302121000.ga3...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote: This a GR proposal is a position statement about issues of the day (as it says in the Notes and rubric.) It's on the subject of init systems. Therefore it is covered by this wording. But it also says: 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302124423.ga4...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 12:49:43PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): On Sun, Mar 02, 2014 at 12:35:15PM +, Ian Jackson wrote: This a GR proposal is a position statement about issues of the day (as it says in the Notes and rubric.) It's on the subject of init systems. Therefore it is covered by this wording. But it also says: 1. Exercise of the TC's power to set policy For jessie and later releases, the TC's power to set technical policy (Constitution 6.1.1) is exercised as follows: Yes. That is part of the text which is added to the TC decision of the 11th of February, by virtue of the GR override clause in that decision. As the rubric says, s1 and s2 of the GR text are added to that TC decision text. s1 of the GR text is not freestanding. Putting the notes and rubric section first might make this clearer for you to see, but it would make the whole GR text much less clear to read because it would start with several paragraphs of procedural palaver. I understand your point. But it feels to me like an abuse of the CTs decision because it's on a related but different subject. I would prefer that it would just make a position statement that doesn't have an effect on the CTs decision. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302130248.ga5...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 01:07:00PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): On Sun, Mar 02, 2014 at 12:49:43PM +, Ian Jackson wrote: Putting the notes and rubric section first might make this clearer for you to see, but it would make the whole GR text much less clear to read because it would start with several paragraphs of procedural palaver. I understand your point. But it feels to me like an abuse of the CTs decision because it's on a related but different subject. I would prefer that it would just make a position statement that doesn't have an effect on the CTs decision. I don't think it's an abuse. That GR override clause was written by me. I specifically drew it widely precisely so that, amongst other things, a GR could answer questions that the TC has failed to answer. Surely the question is simply whether this GR is indeed on init systems. Clearly it is. Therefore the GR rider is engaged. There is also this decision of the CTTE: The TC chooses to not pass a resolution at the current time about whether software may require specific init systems. Which doesn't have this GR rider text in it, and is on the same subject as this GR. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302133723.ga5...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): There is also this decision of the CTTE: The TC chooses to not pass a resolution at the current time about whether software may require specific init systems. Which doesn't have this GR rider text in it, and is on the same subject as this GR. That doesn't contradict the GR. If the GR passes we have two resolutions: 11th Feb as modified by GR: sysvinit as default, loose coupling 28th Feb we choose not to pass a resolution at the current time [ie on the 28th of February] about coupling These are not contradictory. In particular, the 28th of February resolution should not be read as vacating the 11th of February resolution's GR rider, which is what you are suggesting. I'm not disagreeing that you're allowed to do it, I'm disagreeing that it's a good idea to do it. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302151034.ga7...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Sun, Mar 02, 2014 at 02:50:00PM +, Ian Jackson wrote: Kurt Roeckx writes (Re: Proposal - preserve freedom of choice of init systems): There is also this decision of the CTTE: The TC chooses to not pass a resolution at the current time about whether software may require specific init systems. Which doesn't have this GR rider text in it, and is on the same subject as this GR. That doesn't contradict the GR. If the GR passes we have two resolutions: 11th Feb as modified by GR: sysvinit as default, loose coupling The result of that CT decision is that systemd is the default. The intend of this GR is not to change the default. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302183150.ga12...@roeckx.be
Re: Proposal - preserve freedom of choice of init systems
On Fri, Feb 28, 2014 at 11:45:01PM +, Matthew Vernon wrote: Hi, I wish to propose the following general resolution, and hereby call for seconds. I don't think further lengthy discussion of the issues is likely to be productive, and therefore hope we can bring this swiftly to a vote so that the project can state its mind on this important issue. The substantive text is that which was drafted for the purposes of the technical committee's vote (where they decided not to pass a resolution on the subject). This is probably going to require a 2:1 majority requirement as written. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140301105155.ga1...@roeckx.be
Re: State of the debian keyring
On Thu, Feb 27, 2014 at 11:19:23AM +0100, Marco d'Itri wrote: On Feb 27, Yves-Alexis Perez cor...@debian.org wrote: Because unless you are paranoid, then it is not. If anybody disagrees then please describe a credible threat model in which: - an entity would want to have access to the key of a DD, and - would find brute forcing a 1024 bit key more practical than stealing it or coercing a developer to disclose it. There's also the hash algorithm issue, which could lead to signature collision attacks (wether in data signing or in key signing). Please describe a credible threat model, etc. Theoretically possible also means that somebody could factor a RSA 4096 key at the first try with pen and paper so it does not matter much. I'm not concerned about the hash algorithm myself. As I understand it, it's a preimage attack. MD5 is broken for that in that it can be done in 2^123 instead of 2^128, and so should still be fine. SHA1 is still at 2^160, and so such clearly not a problem. SHA1 on the other hand is at 2^60 for a collision attack. That is, someone could generate 2 keys with the same fingerprint in a reasonable time, but can not generate a key with the same fingerprint as an existing key. The current cost estimate for such a collision attack is around 1M USD. See: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html MD5 is currently completly useless if collision resistance is important, it's around 2^18, and in the other of seconds. But as far as I know, for most cases we don't care about collision resistance, but do care about the preimage resistance. As long as you're not singing something that an attacker has control over MD5 and SHA1 should still be safe. If an attacker does have control over it, SHA-2 would be safe instead. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227192851.ga30...@roeckx.be
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 10:51:56AM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Debian tools don't care which key you use for email encryption. Except for project DPL votes, no? I think the keys are used for voting and the email interfance for db.debian.org. I'm not sure if we have any other services checking the gpg signatures of emails. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225201000.ga5...@roeckx.be
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm not sure what you're saying, but I think it's a bad idea. What I would find acceptable is that if you generate an new key you sign the same keys with the new key that you signed previously with the old key. I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. If they old key doesn't get revoked there is still a (weak) web of trust. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. I see no good reason to sign new keys without meeting the person to confirm that that is their new key. You seem to suggest that that is a good idea to keep the web of trust, but to me it seems you just create a web of trust that isn't really there. What we need is a way to confirm that you're talking to the same person you've met previously and confirm that that is his new key. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223112858.ga13...@roeckx.be
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 04:29:29PM +, Bart Martens wrote: I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. I would not find this acceptable. I'm surprised you write this. Maybe I'm misreading what you meant. So maybe this wasn't clear, but I think that should be the exception and clearly not the default. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223183736.ga23...@roeckx.be
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 10:41:48PM +, Clint Adams wrote: Redone with debian-keyring 2014.01.31, hopenpgp-tools 0.6-1, jq 1.3-1.1, and attached script: (/usr/share/keyrings/debian-keyring.gpg) [...] Primary key pubkey sizes: 612 1024 For those people who are not aware of this yet, this is really a problem. This provides less security than an 80 bit symmetric cipher. A brute force for this is possible. It's considered to have very short time protection against agencies, short time against medium organisations. That's still 61.5% that's at 1024 bit. CAs are doing better than this, with only 0.8% of the certificates that are still active being 1024 bit. Can I suggest that everyone that is still using a 1024 bit pgp key generates a new key *now*? The recommended minimum size is at least 2048 bit, but I suggest you go for 4096 bit. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014034641.ga31...@roeckx.be
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 06:35:06PM -0600, Gunnar Wolf wrote: I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? How can we incentivate them to change? I've looked at the debconf 2013 keysigning list. 13 people in it had a 1024 bit key, but all of them also had a stronger one. It's clear that the socially-connected DD already moved to a stronger key, and that the problem would then be the others. A few people have already suggested to set a timeline. You also published this policy in 2010: https://lists.debian.org/debian-devel-announce/2010/09/msg3.html Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223005132.ga1...@roeckx.be
Re: Questioning the TC's power to decide on technical policy
On Sat, Feb 08, 2014 at 06:48:25PM +, Ian Jackson wrote: I'm quite concerned at the current line of enquiry being pursued by the Secretary in #727708. Ian, People ask me questions. Should I just ignore them because you think it's not a good time to answer them? I would also like to point out that I never claimed to be wearing my secretary hat. If I were in the Secretary's position I would refuse to entertain an argument that the TC is impermissibly doing detailed design work or has failed to allow the usual maintainer of the relevant software or documentation (ie the policy maintainers) to make [the] decision initially. I would like to point out that I never took any position, or made any ruling on it. If it looks like it did, I apologize. I'm trying to understand what people are thinking and trying to see what the consensus is, and I'm actually still not sure about it. But the constitution does explictly say that you can't do detailed design work. All I can say is that I see no consensus on wheter the TC is doing that or not. And I suggest you find a way so that nobody can argue that case. I would respond that whether or not something has been sufficiently discussed or decided already, or whether the TC is impermissibly engaging in detailed design work, is a matter for the TC, not for the Secretary. Please see 6.1.1 and 6.3.5. An analogous situation arises with the DPL's powers. Should the Secretary be prepared to entertain an argument that a DPL decision was void because it wasn't consistent with the consensus of the opinions of the Developers ? Or that it was void because the DPL had failed to informally solicit the views of the Developers or the DPL had overemphasized their own point of view when making decisions in their capacity as Leader ? If someone made arguments along those lines I would advise the Secretary to say that these things are matters for the DPL, and that if a Developer feels that the DPL has overstepped the mark they should use a General Resolution to do so. I have to agree that a GR is the proper way to do that. I have no power to revoke a decision. But I can say what I think the constitution says and I hope that people than act accordingly. I think all of these things are very dangerous territory for the Secretary. The Secretary should avoid getting involved in the substance of these kind of subjective disputes about what is and is not sufficiently ripe, or what is or isn't detailed design, or what is or isn't sufficient consultation. So because I'm secretary I should not be involved in any discussion, even if people ask me, is that what you're saying? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140209045054.ga8...@roeckx.be
Re: Debian SIP feedback?
On Wed, Feb 05, 2014 at 07:29:24PM +0100, Daniel Pocock wrote: On 04/02/14 23:43, Kurt Roeckx wrote: On Tue, Feb 04, 2014 at 10:15:42PM +0100, Daniel Pocock wrote: I'm just wondering if people have further feedback about the Debian SIP service https://rtc.debian.org has just been updated to overcome some issues with local audio feedback For Firefox/Iceweasel users, there have been fixes in both the JSCommunicator code and the Asterisk instance behind http://www.sip5060.net/test-calls so this should also be stable. If there are complaints that haven't been answered, please let me know. I actually can't get those to work. That is, I can call them, they pick up, but I never hear sound from the other side. Please open the JavaScript console before starting the call to the test number This was with jitsi Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140205184539.ga4...@roeckx.be
Re: Debian SIP feedback?
On Tue, Feb 04, 2014 at 10:15:42PM +0100, Daniel Pocock wrote: I'm just wondering if people have further feedback about the Debian SIP service https://rtc.debian.org has just been updated to overcome some issues with local audio feedback For Firefox/Iceweasel users, there have been fixes in both the JSCommunicator code and the Asterisk instance behind http://www.sip5060.net/test-calls so this should also be stable. If there are complaints that haven't been answered, please let me know. I actually can't get those to work. That is, I can call them, they pick up, but I never hear sound from the other side. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204224312.ga15...@roeckx.be
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 09:21:41AM -0800, Russ Allbery wrote: Didier 'OdyX' Raboud o...@debian.org writes: Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : I agree. I think that would be quite bad. We could explicitly state in our TC resolution that the TC decision can be vacated by General Resolution on a simple majority. I don't think our constitution allows a resolution of the TC to change how §4.1.4 has to be interpreted for a GR overriding it[0]. It would certainly need to be checked with the secretary (CC'ed, just in case). Personally, I think we should amend the constitution to remove this requirement, but in the meantime, it's obviously possible for the TC to change its own decision. So, failing any other approach, the TC can simply vote to adopt the GR decision as its own decision, which only requires a simple majority in the TC (assuming this isn't a matter that involves a maintainer override). I don't see why the TC wouldn't be able to vote for something again. Assuming there was a GR about it, this will most likely only be possible if the result of the GR was FD. I'll defer to the secretary on whether it makes sense for the TC to do this in advance, or whether to be formally correct we would have to do so after the GR had passed. I guess this is most likely going to depend on how you word it. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140127201432.ga16...@roeckx.be
Re: Updating the Policy Editors delegation
On Sun, Jan 12, 2014 at 02:56:10PM +0900, Charles Plessy wrote: Le Sat, Jan 11, 2014 at 05:22:01PM +0100, Secretary - Kurt Roeckx a écrit : On Wed, Jan 08, 2014 at 12:10:08PM +, Neil McGovern wrote: As there has been no comments on the draft text I'll make that the official response. I want to thank Neil from writing this all down. Hi Kurt and Niel, thank you for the prompt in-depth analysis that you gave us. I was slow to react because I was puzzled by the discussion (why trying to change a delegation text that the delegates themselves agree with ?) and wanted to give to others the opportunity to express positive opinions first, before coming with my criticism. It think that it would have been fair to either set upfront a deadline for answering, or make a last call for comments. Also, less than a week (not even including a week-end) is quite a short delay. In my opinion we had a long discussion about this. I don't see why we should even have published a draft in the first place. * Debian policy editors are a delegatable position by the DPL, but only if the DPL wishes to delegate the power to *set* policy, rather than to simply document current practice. I do not see a difference between documenting current practice and setting the policy, because in many cases it is unclear what the current practice is, and somebody needs the final call on this, similar to the role of the Secretary for interpreting the Constitution. The key here is who is responsibile (for what). See the previous 2 points. --- The Debian Policy Editors: - Guide the work on the Debian Policy Manual and related documents as a collaborative process where developers review and second or object to proposals, usually on the debian-policy mailing list [1]. [1]: https://lists.debian.org/debian-policy/ - Count seconds and weight objections to proposals, to determine whether they have reached sufficient consensus to be included, and accept consensual proposals. - Reject or refer to the Technical Committee proposals that fail to reach consensus. - Commit changes to the version control system repository used to maintain the Debian Policy Manual and related documents. - Maintain the debian-policy package. As package maintainers, they have the last word on package content, releases, bug reports, etc. --- Here are my interpretations point by point. Disclaimer: based on material posted earlier on mailing lists and the wiki, I wrote the text of the delegation. 1) The possibility of editing the Policy out of a collaborative process is not delegated. This does not say how the Editors should decide within a collaborative process, it only says that changes decided in closed comittee are not in the scope of the delegation. The link to the mailing list might be removed, however, for newcomers I find it more useful than harmful. Delegates may make decisions as they see fit. This means that any delegate can make any decisions without the need for anybody else to be involved or to follow a process. The DPL can not say which process you should follow. But the delegates themself can of course decide which process to follow. 2) Count seconds could be removed indeed, to allow the Editors to accept a proposal that did not attract enough attention, but that they estimate consensual. The whole paragraph could also be removed, on the grounds that it is redundant with the Constitution's section 8.3 asking to the delegates to seek concensus. But on the other hand, because it is redundant, I think that it can not be anticonstitutional. This is yet again a process. 3) is indeed redundant with the section 6.3.6 of our Constitution. Maybe we should point to this section instead or even quote it. 4) and 5) may be too obvious as well, but I like the idea that, on top of making decisions, the Editors are also expected to do some more trivial work regarding formatting documents and commiting changes, therefore I think that these paragraphs, which do not restrict how decisions are taken, are useful. You can agrue that 4) and 5) fall under 3.1.1. The delegation should only cover responsibilities and decisions. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112121158.ga15...@roeckx.be
Re: Updating the Policy Editors delegation
On Wed, Jan 08, 2014 at 12:10:08PM +, Neil McGovern wrote:
All,
I think me and Kurt have now reached consensus about the issue - and as
such we'd welcome any comments on the draft, available below!
As there has been no comments on the draft text I'll make that
the official response. I want to thank Neil from writing this
all down.
Lucas,
I suggest that you read the summary carefully and review existing
delegations. I suggest that you make sure that you're delegating
a responsibility or decision.
Kurt
-- draft below --
It seems that two separate questions are being asked. Firstly, what is
the ability of the DPL to create a delegation, and how pescriptive can
this be on the day to day working of a delegate.
Secondly, on the status of the Debian Policy Editors, and if they can be
delegates.
I will deal with both in turn.
In writing this, general commentary appears { in curly brackets } -
these bit aren't official interpretations of the constitution, but a
commentay of my own :)
1) Ability of DPL to make pescriptive delegations
The Debian Constitution is quite clear:
The Leader may define an area of ongoing responsibility or a specific
decision and hand it over to another Developer [...].
Once a particular decision has been delegated and made the Project
Leader may not withdraw that delegation; however, they may withdraw an
ongoing delegation of particular area of responsibility. (5.1.1)
The Delegates are appointed by the Project Leader and may be replaced
by the Leader at the Leader's discretion. The Project Leader may not
make the position as a Delegate conditional on particular decisions by
the Delegate, nor may they override a decision made by a Delegate once
made. (8.2)
Delegates may make decisions as they see fit, but should attempt to
implement good technical decisions and/or follow consensus opinion.
(8.3)
This means that delegations should take care not to perscribe any
particular process, or method for working that a delegate should adhere
to. It is up to the delegate(s) to form a team and to produce a process
themselves. It is, of course required as above that delegates should
attempt to implement good technical decisions and/or follow consensus
opinion.
As a guide - it is the wording that ongoing responsibility or a
specific decision that should be delegated - powers to act in an area,
but not how that power should be wielded. How to organise and the
process for exercising a power is a decision in itself, and thus for the
delegate to decide.
Should a delegate make a decision, or create a process or proceedure
that the project is unhappy with, a Debian Developer is free to refer
this to a General Resolution to reverse any taken decision.
In a special case, where the decision is explicitly a matter of
technical policy, it may also be referred to the Technical Committee, to
decide the matter under 6.1.1:
This includes the contents of the technical policy manuals, developers'
reference materials, example packages and the behaviour of
non-experimental package building tools. (In each case the usual
maintainer of the relevant software or documentation makes decisions
initially [...]). This requires a simple majority.
2) The status of Debian Policy Editors, and the ability to be delegated
To answer this, a series of questions should first be addressed;
* What can the DPL delegate?
In general, this reading of the constituion is being done from a
permissive, rather than restrictive view. ie: a developer may do any
task which they have a general competence to do, rather than only being
allowed to do anything explicitly defined in the constituon. This seems
to follow the project's general favour towards do-ocracy
If a restrictive view is taken, then a number of issues arise. For
example, an individual may only make any technical or nontechnical
decision with regard to their own work, and may not affect other
people's work (3.1.1). It is likely that nothing that affects more than
one person's work would ever be completed without a prior delegation
from the DPL. Thus, a permissive view is more consistent with how
current practice in Debian has developed.
Further, the ability of the DPL to delegate is explicity not limited to
decisions that the DPL can themselves do. See 8.1.2 for example, as the
Debian Account Managers are not a function of the DPL, but are
delegates.
{ There are things that the DPL cannot delegate, for example the
secretary, and tech-ctte members/chair, these are appointments. }
However, what is key here, and covered above in the first part of the
mail, is that it is a decision, or a power must be delegated, not simply
a process. Thus a sucessful delegation should be, for example, for the
Policy Editors to be the primary decision makers on what goes in Debian
Policy. This could mean that the Policy Editors could make a policy that
no packages
Re: Updates in stable releases
On Mon, Dec 30, 2013 at 08:59:31PM +0100, Florian Weimer wrote: * Kurt Roeckx: I want to start by giving some examples of things that got updated in stable point releases that I know about: - linux was 3.2.41-2 in 7.0, 3.2.51-1 in 7.3, 3.2.53-2 in proposed-updates - iceweasel was 10.0.12esr-1 in 7.0, is now 17.0.10esr-1~deb7u1 - postgresql-9.1 was 9.1.9-1, now 9.1.11-0wheezy1 Clearly new upstream releases are acceptable under some conditions. But it's not clear to me what those conditions are. There's not a consistent set. For some packages, we end up with new upstream versions because we have not much choice and would otherwise have to remove the package. iceweasel from your list falls into this category, and there have been BIND and OpenJDK updates with similar rationale. If upstream has long-term stable versions with really limited changes (your linux and postgresql-9.1 examples), we may use them instead of rolling our own releases, based on the assumption that the released version has seen some testing upstream and elsewhere, more than our backport of a patch in isolation would receive prior to a release in a Debian update. So I have the impression that if upstream has a stable branch and really only do bug fixes with a low chance of regressions that this will most likely be accepted. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131230222400.ga...@roeckx.be
Updates in stable releases
Hi, I think in general we are either too strict in what we allow as updates to stable or people think it's not going to be allowed and so don't even try to get updates to stable. The last time I asked about this, I got this as reply: https://lists.debian.org/debian-devel/2013/09/msg00466.html I want to start by giving some examples of things that got updated in stable point releases that I know about: - linux was 3.2.41-2 in 7.0, 3.2.51-1 in 7.3, 3.2.53-2 in proposed-updates - iceweasel was 10.0.12esr-1 in 7.0, is now 17.0.10esr-1~deb7u1 - postgresql-9.1 was 9.1.9-1, now 9.1.11-0wheezy1 Clearly new upstream releases are acceptable under some conditions. But it's not clear to me what those conditions are. The rules seem to suggest that we need a priority important bug in the Debian BTS. Does that mean that if upstream makes a bugfix release we need to file bugs in the Debian BTS for each fix that we consider important and backports just those bugfixes, or would uploading such bugfix releases be allowed? How about more than just bugfixes? For instance would new features be allowed, and in what case? It seems that at least for the linux kernel support gets added for new hardware. One thing I had in mind for an update to apache is to have the version in stable support ECDHE which the version in stable currently doesn't do. And I think the general feeling from people is that this is going to be rejected and so don't even try and ask. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131229210441.ga18...@roeckx.be
Re: Moving to stronger keys than 1024D
On Sat, Oct 05, 2013 at 10:37:40AM +0200, Stefano Zacchiroli wrote: Oh mighty Debian keyring maintainers and WoT gurus, what do you suggest to do in this respect? When is the right moment to retire old keys after migration to stronger ones? I think that you clearly reached the point where more keysignings doesn't have a big inpact on your msd ranking. I would say that if your new keys has over 100 signatures it's time to revoke your old key. As such I have just revoked my old key with msd 49 while my new one only is at 1033. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131005094825.ga25...@roeckx.be
Re: Debian Maintainers Keyring changes
On Sun, Sep 08, 2013 at 02:01:43AM +, Debian FTP Masters wrote: The following changes to the debian-maintainers keyring have just been activated: sas...@girrulat.de Removed key: A33FC3A59C40F1BCC3368E88FCA5101964F970D1 Removed key: E67DF5E7FCFAB7218C6D0FAF610711E66630FEFA Removed key: DA813270E09F448D18771FBE1AB9332D9E47CF19 Added key: B7018D75BBAD63F52395B82C5E55B31A2FEDAC22 Added key: FD9F764B0B28B823E02E62EF7809DD1F83DCC74A This looks really confusing. It's DA813270E09F448D18771FBE1AB9332D9E47CF19 that gets removed, the other 2 mentioned are subkeys. And it's FD9F764B0B28B823E02E62EF7809DD1F83DCC74A that gets added with B7018D75BBAD63F52395B82C5E55B31A2FEDAC22 as subkey. Can we change the output so that it's more clear that it's about the pub or the sub key? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130908065815.ga...@roeckx.be
Re: Survey of new contributors -- results
On Wed, Aug 07, 2013 at 09:52:41PM +0200, Lucas Nussbaum wrote: | It seems that we could get better at listing possible contributions. For | example, we could have a 'apt-list-possible-contributions' tool that would | list installed packages that are orphaned or RFAed. Like wnpp-alert? Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130807195736.ga4...@roeckx.be
Debian Project Leader Election 2013 Results
Hi, The winner of the election is Lucas Nussbaum. His term will start on April 17th, 2013. The details of the results shall soon be available at: http://vote.debian.org/2013/vote_001 In the mean time the results are also available at: http://vote.debian.org/~secretary/leader2013/results.txt http://vote.debian.org/~secretary/leader2013/results.png The tally sheet is at: http://vote.debian.org/~secretary/leader2013/tally.txt The list of people voting is at: http://vote.debian.org/~secretary/leader2013/voters.txt Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: LaMont Jones, WTH are you doing?
On Wed, Feb 06, 2013 at 11:33:39AM -0700, LaMont Jones wrote: [...] binaries are built on a system that is running sid, both amd64 and i386 binaries, since at least one of those buildds has bitten me with bad binaries in the past. [...] The packages you're seeing are built on a sid amd64 box, the i386 binaries built in a sid schroot. I suppose I could just trust the i386 buildds to do the right thing and not screw up, and just upload amd64 binaries to go with the source. Can you explain what went wrong? It's really not supposed to generate broken binaries, and I don't see why you would get a different result if you build them. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206220501.ga11...@roeckx.be
Re: Position statements short of a GR - DPL statements
On Tue, Jan 08, 2013 at 04:24:16PM +, Ian Jackson wrote: A little while ago I wrote this: I think it would be useful to add a new category to this list: - Formal policy document from the DPL [...] And I would hope that a decision to publish such a statement would be a decision by the DPL and therefore subject to overturn by GR. Some people have suggested that such an action by the DPL would need a constitutional change. Can you please confirm your interpretation of the constitution ? So I think the question is on how to interprete 3.1.1: [An individual Developer may] make any technical or nontechnical decision with regard to their own work; 4.1.5: [The Developers by way of General Resolution or election may] Issue, supersede and withdraw nontechnical policy documents and statements. These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. They may also include position statements about issues of the day. And 5.1.4: [The Project Leader may] Make any decision for whom noone else has responsibility. Only 4.1.5 talks about nontechnical policy and position statements, the other 2 talk about decisions. I think the constituion is written to imply that if someone has a right to do something, that nobody else has it. So I would say that we can only make position statements of the type meant in 4.1.5 by way of General Resolution. The question then is what kind of position statement are they, and how is that different from a decision. I think the intention is that it's about the position of Debian, it talks about the goals of the project. So I think it can't be about the goal some package or group of packages. I think that would not fall under 4.1.5 and so not covered at all by the consitution. So I see no problem with such statements. If it's clear that it's not an official Debian position but the individual's position I also see no problem with it. If in your view formal statements from the DPL are not permitted, can you please comment on which of the following prospective web pages setting out position statements are permitted and which are also unconstitutional ? I think it all depends on what the statement says, and how it can be interpreted. For instance, if we end up with a policy on how to deal with incomming trademarks I think that would fall under 4.1.5 and would need a GR. But you could also interprete is as just a decision of the DPL, and I guess it all comes down on how you write it down. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130112002306.ga24...@roeckx.be
Re: General Resolution: Diversity statement results
On Wed, Jun 06, 2012 at 06:45:46PM +0200, Kurt Roeckx wrote: On Wed, Jun 06, 2012 at 05:08:52PM +0100, Ian Jackson wrote: If I could get a copy of the Secretary's running source code I could also change it so that options were lettered rather than numbered. That would be /much/ less confusing... master.debian.org:/org/vote.debian.org/ I've put all my changes in git and it's available at: http://anonscm.debian.org/gitweb/?p=users/kroeckx/devotee.git;a=summary It's about to move to a new host When that's done I'll also make it available on the vote website, and point the website to it. The running version isn't completly the same as the version in git, the files are in other directories. But all the code that's used should be in git. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120709171708.ga22...@roeckx.be
Re: devotee predictable random numbers (was: General Resolution: Diversity statement results)
On Thu, Jun 07, 2012 at 02:22:12PM +0300, Touko Korpela wrote: On Thu, Jun 07, 2012 at 12:00:19AM -0700, Manoj Srivastava wrote: Once I get my act together again, I have devotee v 2.0 that I think is generally useful enough to package, since I have moved it to a command pattern based workflow, and thus people may add modules (check gpg sigs) or remove tham (no ldap checks), and move the action noides around at will (do gpg checks _after_ ldap checks) Is predictable RNG allows recovery of secret monikers (CVE-2012-2387) fixed now in devotee? No, and it's only relevant (to Debian) to get it fixed by the next DPL election, so I'm in no hurry to fix it myself. But patches are always welcome. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120607190646.ga20...@roeckx.be
Re: General Resolution: Diversity statement results
On Wed, Jun 06, 2012 at 05:08:52PM +0100, Ian Jackson wrote: If I could get a copy of the Secretary's running source code I could also change it so that options were lettered rather than numbered. That would be /much/ less confusing... master.debian.org:/org/vote.debian.org/ It's about to move to a new host, and I'm not sure if DSA is still going to give everybody access to that host. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120606164546.ga12...@roeckx.be
General Resolution: Diversity statement results
Hi, The results of the General Resolution is that the diversity statement has been accepted. The details of the results shall soon be available at: http://vote.debian.org/2012/vote_002 In the mean time the results are also available at: http://master.debian.org/~secretary/diversity/results.txt http://master.debian.org/~secretary/diversity/results.png The tally sheet is at: http://master.debian.org/~secretary/diversity/tally.txt The list of people voting is at: http://master.debian.org/~secretary/diversity/voters.txt Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: Fool copy of a Debian web side.
On Sun, May 06, 2012 at 12:22:47PM -0400, Yaroslav Halchenko wrote: depending on what portion of the website you would like to have a copy off you might * sudo apt-get install debian-reference debian-policy developers-reference installation-guide-amd64 to get necessary documentation which is a part of the website * setup a mirror of the Debian APT repository if what you care is actual packages... There is a set of tools for that, e.g. debmirror, reprepro there are detailed manpages and bulk of information online on how to setup such mirrors Or check out the webwml repo and build it yourself. See http://www.debian.org/devel/website/ and http://www.debian.org/devel/website/using_cvs Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120506203003.ga14...@roeckx.be
Debian Project Leader Election 2012 Results
Hi, The winner of the election is Stefano Zacchiroli. His new term will start on April 17th, 2012. The details of the results shall soon be available at: http://vote.debian.org/2012/vote_001 In the mean time the results are also available at: http://master.debian.org/~secretary/leader2012/results.txt http://master.debian.org/~secretary/leader2012/results.png The tally sheet is at: http://master.debian.org/~secretary/leader2012/tally.txt The list of people voting is at: http://master.debian.org/~secretary/leader2012/voters.txt Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Debian Project Leader Election 2011 Results
Hi, The winner of the election is Stefano Zacchiroli. His new term will start on April 17th, 2011. The details of the results shall soon be available at: http://vote.debian.org/2011/vote_001 In the mean time the results are also available at: http://master.debian.org/~secretary/leader2011/results.txt http://master.debian.org/~secretary/leader2011/results.png The tally sheet is at: http://master.debian.org/~secretary/leader2011/tally.txt The list of people voting is at: http://master.debian.org/~secretary/leader2011/voters.txt Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: buildd/porter/maintainer roles again
On Wed, Jul 14, 2010 at 11:07:50PM +0900, Charles Plessy wrote: I am not asking for throwing away people's work or ignoring their motivation, but I feel demotivated that I am asked efforts with nothing in return, since--and this is what makes this mail more or less on-topic in this thread--it is usually not the porter nor the users themselves who insist on putting a high priority for distributing scientific leaf package on their favorite architecture, but a policy that I challenge, enforced through the buildd maintainers by filing RC bugs. From http://release.debian.org/squeeze/rc_policy.txt: 4. Autobuilding [...] Packages must autobuild without failure on all architectures on which they are supported. Packages must be supported on as many architectures as is reasonably possible. Packages are assumed to be supported on all architectures for which they have previously built successfully. Prior builds for unsupported architectures must be removed from the archive (contact -release or ftpmaster if this is the case). If it never build on that arch before, and looks like an arch specific issue, it's not RC. This for instance means that not all FTBFS bugs on kfreebsd-* are RC. I will file bugs as RC even when it didn't build previous when I think it's supported on that arch and needs some very easy fix, like adding proper build-depends. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714164629.ga29...@roeckx.be
Re: Squeeze, firmware and installation
On Mon, May 24, 2010 at 02:13:30PM +0100, Steve McIntyre wrote: Yup, definitely. We already have an unofficial non-free area on cdimage.debian.org which is where we've been pushing the firmware zip/tar.gz files already. I'll set up the extra images to be dropped in there. It would be nice if this could all be moved somewhere else so that it gets mirrored. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100524144323.ga17...@roeckx.be
Squeeze, firmware and installation
Hi, It seems the kernel team has moved alot of firmware to non-free, which means that more people will need to use pieces from non-free to be able to use their computer. So I was wondering what the state is of everything, and what issues people will run into, specially when installing. I'm also wondering what people think about adding some firmware to our official installation media. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505162955.ga17...@roeckx.be
Re: Squeeze, firmware and installation
On Wed, May 05, 2010 at 09:57:46PM +0300, Arto Jantunen wrote: Hmm. Is the release already so close that it's time to have this flamewar again? Shouldn't we wait a month or two for maximal effect? I think the earlier we have this discussion the better. Seriously speaking, to me it seems very clear that non-free firmware will not be present on official installer images. Then again, the installer team has made it very easy to inject firmware during installation on machines where it's needed. I've heard people complain about how the (lenny?) installer works, and I didn't have the need to install on a machine that requires firmware yet myself. I think the issues I've heard were: - You need 2 installation media. Which also makes an unattended installation harder or impossible. - It didn't find the firmware or didn't look at the usb disk that was plugged in or simular. Maybe it would be helpful if something from the installer team could describe how it's supposed to work now and what the state is. I think their clearly will be a need to create media which has the firmware on it. The current manual points to an unofficial part of cdimage.debian.org to get the latest firmware and says that some might be missing and that you'd need to get it from non-free without much instructions on what to do with it. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505194511.ga18...@roeckx.be
Debian Project Leader Election 2010 Results
Hi, The winner of the election is Stefano Zacchiroli. His term will start on April 17th, 2010. The details of the results shall soon be available at: http://vote.debian.org/2010/vote_001 In the mean time the results are also available at: http://master.debian.org/~secretary/leader2010/results.txt http://master.debian.org/~secretary/leader2010/results.png The tally sheet is at: http://master.debian.org/~secretary/leader2010/tally.txt The list of people voting is at: http://master.debian.org/~secretary/leader2010/voters.txt Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Withdrawal of GR about sponsorship requirements for GRs
Hi, I'm withdrawing the general resolution about the sponsorship requirement for general resolutions. It has 3 options that have enough seconds (under the current constitution). But it looks like people were hoping to get more seconds for the options that would change the required number of seconds. The discussion about this GR has stopped over 4 weeks ago, so I'm withdrawing this under section A.5. of the constitution. Sponsors of any of the proposals have 1 week to object. More info about this GR can be seen at: http://www.debian.org/vote/2009/vote_002 Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Debian Project Leader Election 2009 Results
Hi, The winner of the election is Steve McIntyre. His new term will start on April 17th, 2009. The details of the results shall soon be available at: http://vote.debian.org/2009/vote_001 In the mean time the results are also available at: http://master.debian.org/~secretary/leader2009/results.txt http://master.debian.org/~secretary/leader2009/results.png The tally sheet is at: http://master.debian.org/~secretary/leader2009/tally.txt The list of people voting is at: http://master.debian.org/~secretary/leader2009/voters.txt Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | | 2001 | ?? | ?? | |311 | || | | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | |--+--++---++-++---| Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
First call for votes for the Debian Project Leader Elections 2009
Hi, This is the first call for votes for the Debian Project Leader Elections 2009. Voting period starts 00:00:00 UTC on Sunday, March 29th, 2009 Votes must be received by 23:59:59 UTC on Saturday, April 11th, 2009 This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact secret...@debian.org. The details of the candidate platforms can be found at: http://www.debian.org/vote/2009/platforms/ HOW TO VOTE First, read the full text of the platforms and rebuttals. Do not erase anything between the lines below and do not change the choice names. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue till you reach your last choice. Do not enter a number smaller than 1 or larger than 3. You may skip numbers. You may rank options equally (as long as all choices X you make fall in the range 1 = X = 3). Please read the platforms in detail. To vote no, no matter what rank None Of The Above as more desirable than the unacceptable choices, or you may rank the None Of The Above choice, and leave choices you consider unacceptable blank. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Then mail the ballot to: leader2...@vote.debian.org. Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. You may, if you wish, choose to send a signed, encrypted ballot. Devotee accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- a9ccc78e-785a-4762-a24a-ca59fe9b2dfe [ ] Choice 1: Stefano Zacchiroli [ ] Choice 2: Steve McIntyre [ ] Choice 3: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEnNM0sRBACD6OeKJJPQQerENhPdQEO2pfDWyXxSUKOd0aA3u0aApAt7Pc9w v8c7d4cBprOj0M5Jj1bMlncSCYKluaD/izSbbUjXesrLhlhFfe+qxNk0BUupMXkl Zzj7M71X+x0gKKVCMqIHaFrfAwITYaINXfa1YYR/Ppy98cjGs3sKLsB6VwCgurx4 +vUhvxig27zVsbRYGmr5EJED/A4JhYLdfYj+E5hQcxs0g5HxwUVYfEEhoRS0ggh1 jy79SnFH7irxHpwFemH3ZkNPtltJj3QKTzhSsDWBeQIrM6ni8Q9R4+oFCwIhVpug wWkAi2wl4gbHnKPn1Dz72H24WLdheTZtzs30YkaBUgqQ/SnmPHzRerTDdA4dKvTz q1VaA/wPDWsM90pcMgEFlyL8hCo93R5mfEpPQx3PXn3bkiP8Moz3RIAjY14KwETI urupOiUnQfL6jjebow3wyRmexmb7Wjw9R+iVxePVTL+lRUxK3baNuO9o4t0SuFP9 GTNxQndKyzwqdRCqUJHEJTXaEA5vII3zBpB+Dc0AwOZy9xCGfrQqRFBMIFZvdGUg MjAwOSA8bGVhZGVyMjAwOUB2b3RlLmRlYmlhbi5vcmc+iGYEExECACYFAknNM0sC GwMFCQAXuwAGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBWJrUvkcuEqF/wAJ0a yAYppfddTTTjKNnuxLbbsdYtqQCgouksCxMDOgWJ62t3DJh6AkwZbQuIRgQTEQIA BgUCSc06egAKCRBB3ByQckSXC6CvAKDaNn4nS6bXPNHd54ghw14HFSyV4ACffEGD ET/Vuvc0WH63juiqb73mpVS5Ag0ESc0zSxAIAN5//g8j1sEvNz/7/0Nopi+r3HZY sRo58ewVbsnUqb6Bs1Pi3Vo/3zjliiXR3ymJzNV6sNlNwBbaYgk3AIlsTvtKqWuF UZbyTLPfDvB5OklQ699cY3gYXqalTEDo8HE2JO9Pidpw1bjzQzbFuVjHAIfrK0zu tdsWge1UnObR9venMijCTsvyoPU57c5WSP/0lzK7QmsvFtkmFCk4MbcRqumjnfXW AbSTwn8vI2Ze7DISv9KzMJWSjw9SJl4KPT9MlC9Ag3MRypsGrRyfrS6CRHf2vTlO Fjr5obeZKP6RWimJJN7eTr0j+SQnMOkxvViDOcD6z+Jf0FfPg0pCgkTm+osAAwUH /3+6UyV5bmjnno4JigM5cZ20n4vjpTTpkBAGyyApfBCVxuTJDGbYl0TRxvdmsWYV dp/ZyHsyQk3c5jNq7Il8QSCfhuRSn5trizXf1OyudS+j5UT7kj6Ad3qF6TpLvbkw Zxy4e3g0TqPWWW1G8zah/vaXt90Zx3Y9F4lpbw2vMziFN7y1mXLs0YtYGHY2sLBd Hjq1PXeG6ifzoXkSvA22f8bWQS3oqKhTZYGht7q/aE9Isk781hEJvhjV/SrM0VGh y/n/23aDdruvkv4thb4f3LQhxtAKLJ3DSIf8fGjRzfIfX9jnMhjJSPdoSpLtWScW zzS5Hj74RTRBLzFakOrasluITwQYEQIADwUCSc0zSwIbDAUJABe7AAAKCRBWJrUv kcuEqFYIAKCtVUpHkkHEm3XWnvKooxY4yzJ3DgCghtOdEUkPVR0YS02o+9Ptmact Lxs= =CFD2 -END PGP PUBLIC KEY BLOCK- Kurt Roeckx Debian Project Secretary signature.asc Description: Digital signature
Re: New Technical Committee Members
On Sun, Jan 11, 2009 at 11:57:31AM -0700, Bdale Garbee wrote: Anthony Towns recently announced his decision to step down from the Debian Technical Committee: http://lists.debian.org/debian-ctte/2009/01/msg6.html I thank him on behalf of the rest of the committee and the project for his contributions over the last three years! With this change, the remaining members of the committee are: chairman Bdale Garbee member Andreas Barth member Ian Jackson member Steve Langasek member Manoj Srivastava As per Constitution section 6.2, we discussed a number of potential additions to the committee, with the full engagement and support of Debian Project Leader Steve McIntyre. It gives me great pleasure to welcome Russ Allbery and Don Armstrong as the newest members of the Technical Committee. If I understand things right, you can add new members until the number reaches 6 and can then proposed new members to the DPL. And Steve organised the vote to add Russ (which got approved), and propose Don to the DPL. Andreas said that with 3 of the 5 votes for proposing Don the vote is over. But I think it's only 3 of 6 at that point, and the DPL still needs to approve it. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Updated Debian Maintainers Keyring
On Mon, Nov 26, 2007 at 05:32:03PM +, Anthony Towns wrote: dm:[EMAIL PROTECTED] Full name: Jelmer Vernooij Added key: B3634EEAEEF17128A64F34A716F9CB0085E26E51 Added key: F1F3A87ED983DFAD791ADAD83DAF54A21EEF5276 Added key: 9C94A3D863D34E71CFA0781E0CB425E1060F66E5 Added key: 2EE0F89E0170C3746E1EE0AB9EF8F8135404158F Why does he need to have 4 keys in the keyring? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
On Fri, Dec 29, 2006 at 11:20:30AM +0100, Josselin Mouette wrote: An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not doing his job as buildd maintainer. You can't pretend to be the one handling builds for the whole archive while not following discussions around problems specific to this architecture. I think you're confusing the buildd admin with the porters. I expect porters to read the [EMAIL PROTECTED] list, I don't expect the same from the buildd admin. The buildd admin's job is getting packages built, while the porter's is to deal with architecture specific issues. The buildd admins aren't always also porters for that arch. But I think it would be a good thing that (some) porters also see all the buildd logs. That way they know alot faster about problems the port might have. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Note to Did you already MOO today...
On Fri, Nov 10, 2006 at 08:54:56AM -0600, Manoj Srivastava wrote: Hi, On Fri, 10 Nov 2006 09:51:35 +0100, Jakob Johannes Blaette [EMAIL PROTECTED] said: Hello, Debain, first of all thank you for the Distribution of DEBIAN that I appreciate. Thanks. I am Computer Scientist and have roman catholic believe so I'm also thankful f.ex. that Debian offers a Web Browser called Epiphany Browser. I doubt that the naming had something to do with religion, really. But I could also find a program that can produce the comment Did you already MOO today...?. Now I found that MOO can mean a text based online virtual system but as well MOOism that is a joke religion (please see f.ex. wikipedia.org). Or is the meaning only harmess in the meaning of cows? Hard to say, I don't think this has much to do with the text based game, and something to do with cows is also unlikely. However, that is not to say that the only explanation left is MOOism, though that can't be ruled out. Perhaps there is some humour here that I am missing. Where does the Did you already MOO today... come from? I can't find anything related to it. Something that seem to be related to it in Debian is: $ apt-get moo (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... Which seems to be a cow to me. An other I can think of is distributed.net who has a logo of a cow (or bovine), and the button to get the client says Moo. You'll find lots of references to moo and bovine on their site. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[AMENDMENT] Re: seconds searched for override of resolution 007 needed.
I want to amendment the following proposal: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 0. This resolution overrides the resolution just voted (http://www.debian.org/vote/2006/vote_007). 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue, both upstream and in the debian packaging; however, it is not yet finally sorted out. 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL And replace the text with: BEGIN OF PROPOSAL We, the Debian project, find freeness that we want for firmware used by the kernel is an important question, and that we will have to deal with this. However, we think that we as a project need more time to deal with it, and having more general resolutions isn't going to solve this. Therefor we will not have another general resolution about firmware until after the release of etch and atleast 6 moths have passed since this general resolution. This does not mean we will not discuss this issue, or work on getting things better. END OF PROPOSAL I'm open for suggestions on how to better word this. Kurt signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Mon, Sep 18, 2006 at 10:07:18PM -0700, Don Armstrong wrote: D. Requests that vendors of hardware, even those whose firmware is not loaded by the operating system, provide the prefered form for modification so that purchasers of their hardware can exercise their freedom to modify the functioning of their hardware. What I also find important is that hardware comes with good technical documentation, so that we can either write the software ourself, or modify what the hardware vendor provides. But I'm not really sure if this belongs in a GR, and how it should be put into it. We might want to do things with the hardware that the vendor did not design it for. For instance, most GPUs would be very useful doing vector math. It can do alot more FP operation than a normal CPU, and things like that. I need to look at what the other current proposols look like, but I think a combination of this with the apoligy might be a good proposol. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Server restored after Compromise
On Thu, Jul 13, 2006 at 10:49:04PM +0200, Andreas Tille wrote: On Thu, 13 Jul 2006, Bas Zoetekouw wrote: Or maybe only allow pubkey ssh authentication? I'd vote for it and I use it since the last break in exclusively. The only drawback is that the mail interface to db.d.o is somewhat broken but if more people use it the pressure to fix it might increase. When I wanted to mail my ssh key, I had to first log in on master (with my password) to be able to send the mail from there. The script doesn't handle mime, and my ssh key is longer then 1024 chars so you can't really send it over smtp as 1 line. I think exim allows it or something, making it work if you send it from master. But I guess you're talking about setting other things you can do thru the website, for which the password is required too. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
