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 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
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: Bug#1068045: libssl3: breaks YAPET
There might be a related change that doesn't allow restarting the operation with the same context without setting things up again.
Bug#1068045: [Pkg-openssl-devel] Bug#1068045: Bug#1068045: libssl3: breaks YAPET
There might be a related change that doesn't allow restarting the operation with the same context without setting things up again.
Debian Project Leader election 2024: First call for votes
Hi,
This is the fist call for votes for the DPL election of 2024.
Voting period starts 2024-04-06 00:00:00 UTC
Votes must be received by 2024-04-19 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2024/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2024".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 3 choices in the form, which you may rank with numbers between
1 and 3. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 3.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
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. (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).
Finally, mail the filled out 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: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
9c605edd-40a5-469c-9489-cbf80ac05970
[ ] Choice 1: Andreas Tille
[ ] Choice 2: Sruthi Chandran
[ ] 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-
mQINBGYPJG0BEADDE7JDmXCIKi05UqF/OMIdHu/5RvDPc5TwtGofnF9ov9bsXIll
dA+lRLz58tvkuibfF2xFi4ZXMmmmSaZkQ/KlZC9tk+fs7J4+WemGS19srzVWF3Hk
3Vcad0VoV5kJtpatgL7iR2xRvzgvMgDs5baRnehSJ+pTtp9fCLQDXl9tmI48a8cF
HNyTiXPUpY+0mR69HsuywuCmiU6bgH9kksJNbstbzCVewp9bqHOSWavU4loi9TCp
jk0EjfisrJNBopXF/m0gxozZD2V+2JrxRDnn8e2vHZ3ljq34t7YRy9yTD8ey74ym
HutRq2EOwWVjRlc8vVpmbvX7F7FzPdrgw0wLFBCxwMUxcHOX+m9IvM2aYl2oeyM8
YE0yAX0FqUO75ujCYr4y9x5RIKKVxjdzv5Paiy4YBPiWWHxt+5JhrV+l6Vlrj3oT
s+RGp8NyeVd+jZmnY2FJsr20ZMovPSD8xcTvOrv8LPRlZpqSP2R93gMX6txZGiNa
/vvqY4d7xb9VUSxDN/3scb8ihBLEGnvkvk2h6hcDRxbX7cTjiWtmqDy8vn/e/fRQ
Z3QJToaiCfhcJNApBD5KPKjch+di8RlOfhrSb+1UMJrV2RjWRPQaXskGyIrRhXiy
Tpaq895OX6b0jDeFH7cbQuZh2XTVJKZ7FUDw8pqgmrq2S0BuW2gLb1zxQQARAQAB
tCpEUEwgdm90ZSAyMDI0IDxsZWFkZXIyMDI0QHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmYPJG0CGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
ENK7zila6Q4lujIP/39ZmDz3vgx7s2tO5NqSP5U+HPNYTs1sO+kicqTyHeKsNRJY
Yfp6Crjx++rREATOaE0lfPWvjtYCx5qYedgxkdSJNMk8F7VWgF3Rf4Ze2WaDRpdF
aJSePI/TrSqU2mCrR9/G+GSeuZiIQIRRmPVOTqZaJzpd9OYcXQXO99mrlcZPNgTS
R0dd8aZg49qHUNtVuRuHeK+b9b0t1+xzwb8d5OiNPc092SfO5b6b+IoJw3vsbrYb
byJPRIse7JF+zZntblCJOeaA87AnicOF/ilQNA8msRRo7CvtRrxEK9zyef6KB7eB
Ir71Qu3RYrfE4AyWkWeWAmtYGmcyH5SIVnahoq2XZ3Rf7UbN/4j4dmHNymtkv5GR
WCg0ixj8S4HvLdyJusoRs/F4IbcJlJjJzq7arDw/WXWbWz0oomm8W7wtP1lU5icL
Draft ballot
Here is the draft ballot:
Voting period starts 2024-04-06 00:00:00 UTC
Votes must be received by 2024-04-19 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2024/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2024".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 3 choices in the form, which you may rank with numbers between
1 and 3. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 3.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
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. (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).
Finally, mail the filled out 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: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
9c605edd-40a5-469c-9489-cbf80ac05970
[ ] Choice 1: Andreas Tille
[ ] Choice 2: Sruthi Chandran
[ ] 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-
mQINBGYPJG0BEADDE7JDmXCIKi05UqF/OMIdHu/5RvDPc5TwtGofnF9ov9bsXIll
dA+lRLz58tvkuibfF2xFi4ZXMmmmSaZkQ/KlZC9tk+fs7J4+WemGS19srzVWF3Hk
3Vcad0VoV5kJtpatgL7iR2xRvzgvMgDs5baRnehSJ+pTtp9fCLQDXl9tmI48a8cF
HNyTiXPUpY+0mR69HsuywuCmiU6bgH9kksJNbstbzCVewp9bqHOSWavU4loi9TCp
jk0EjfisrJNBopXF/m0gxozZD2V+2JrxRDnn8e2vHZ3ljq34t7YRy9yTD8ey74ym
HutRq2EOwWVjRlc8vVpmbvX7F7FzPdrgw0wLFBCxwMUxcHOX+m9IvM2aYl2oeyM8
YE0yAX0FqUO75ujCYr4y9x5RIKKVxjdzv5Paiy4YBPiWWHxt+5JhrV+l6Vlrj3oT
s+RGp8NyeVd+jZmnY2FJsr20ZMovPSD8xcTvOrv8LPRlZpqSP2R93gMX6txZGiNa
/vvqY4d7xb9VUSxDN/3scb8ihBLEGnvkvk2h6hcDRxbX7cTjiWtmqDy8vn/e/fRQ
Z3QJToaiCfhcJNApBD5KPKjch+di8RlOfhrSb+1UMJrV2RjWRPQaXskGyIrRhXiy
Tpaq895OX6b0jDeFH7cbQuZh2XTVJKZ7FUDw8pqgmrq2S0BuW2gLb1zxQQARAQAB
tCpEUEwgdm90ZSAyMDI0IDxsZWFkZXIyMDI0QHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmYPJG0CGwMFCQAaXgAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
ENK7zila6Q4lujIP/39ZmDz3vgx7s2tO5NqSP5U+HPNYTs1sO+kicqTyHeKsNRJY
Yfp6Crjx++rREATOaE0lfPWvjtYCx5qYedgxkdSJNMk8F7VWgF3Rf4Ze2WaDRpdF
aJSePI/TrSqU2mCrR9/G+GSeuZiIQIRRmPVOTqZaJzpd9OYcXQXO99mrlcZPNgTS
R0dd8aZg49qHUNtVuRuHeK+b9b0t1+xzwb8d5OiNPc092SfO5b6b+IoJw3vsbrYb
byJPRIse7JF+zZntblCJOeaA87AnicOF/ilQNA8msRRo7CvtRrxEK9zyef6KB7eB
Ir71Qu3RYrfE4AyWkWeWAmtYGmcyH5SIVnahoq2XZ3Rf7UbN/4j4dmHNymtkv5GR
WCg0ixj8S4HvLdyJusoRs/F4IbcJlJjJzq7arDw/WXWbWz0oomm8W7wtP1lU5icL
14hTUYuuvc0MeWSVpnSNeX794x22WYj9duSFTUxn2xcyZXbWxhNWTzD+8ZlQKd+H
Debian Project Leader Elections 2024: Candidates
We're now into the campaigning period. We have 2 candidates this year: - Andreas Tille - Sruthi Chandran I will make the platforms available when I have received them at: https://www.debian.org/vote/2024/platforms/ Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Bug#1067087: GCC frame pointers
Source: gcc-14 Severity: wishlist Please consider enabling frame pointers on 64 bit arches. See: https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html Kurt
Bug#1067087: GCC frame pointers
Source: gcc-14 Severity: wishlist Please consider enabling frame pointers on 64 bit arches. See: https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html Kurt
Debian Project Leader Elections 2024: Call for nominations
Hi, According to the constitution (5.2. Appointment), project leader elections should begin "six weeks before the leadership post becomes vacant, or (if it is too late already) immediately." The new project leader term starts on 2024-04-21. The time line looks like: | Period | Start | End | |+-+---| | Nomination | Saturday 2024-03-09 | Friday 2024-03-15 | | Campaign | Saturday 2024-03-16 | Friday 2024-04-05 | | Vote | Saturday 2024-04-06 | Friday 2024-04-19 | Prospective leaders should be familiar with the constitution, but just to review: there's a one week period when interested developers can nominate themselves and announce their platform, followed by a three week period intended for campaigning, followed by two weeks for the election itself. I intend to collect platform statements from the candidates, and publish them at http://www.debian.org/vote/2024/platforms/ at the end of the nomination period, which means around 2024-03-16. I suggest that the candidates send the platform, preferably in wml or HTML, to the secretary at least a day before the publication date. The format of the web page is open to discussion, but I suggest there be at least three sections: - Introduction / Biography - Major Goal / Meat of the platform - Rebuttal. The candidates can make a rebuttal. I would like to receive them in the first week of the campaign period, so I can publish them around 2024-03-23. Details and results for the vote will be published at: http://www.debian.org/vote/2024/vote_001 Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Can't connect to Active Directory with openssl
Hi, It's unclear to me what you're reporting as error. The connection seems to be working. The verification of the certificate seems to fail. It seems you have your own CA, but the CA is not trusted because it's not in the certificate store. Kurt
DPL 2024
Hi, This is the schedule for the DPL election: Nomination period: Saturday 2024-03-09 Friday 2024-03-15 Campaigning period: Saturday 2024-03-16 Friday 2024-04-05 Voting period: Saturday 2024-04-06 Friday 2024-04-19 Kurt
General Resolution: Statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Hi,
This is the first call for votes abouti:
Statement about the EU Legislation "Cyber Resilience Act and Product Liability
Directive"
Voting period starts 2023-12-09 00:00:00 UTC
Votes must be received by 2023-12-22 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the general resolution can be found at:
https://www.debian.org/vote/2023/vote_002
Also, note that you can get a fresh ballot any time before the end of the
vote by sending a signed mail to
bal...@vote.debian.org
with the subject "gr_non_free_firmware".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the options.
You might also want to read discussions at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below. The
dedicated email address this ballot should be sent to is:
gr_non_free_firmw...@vote.debian.org
The form you need to fill out is contained bellow in this message, marked
with two lines containing the characters '-=-=-=-=-=-'. Do not erase
anything between those lines, and do not change the choice names.
There are 4 choices in the form, which you may rank with numbers between 1
and 4. In the brackets next to your preferred choice, place a 1. Place a 2
in the brackets next to your next choice. Continue until you reach your
last choice. Do not enter a number smaller than 1 or larger than 4.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
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. (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).
Finally, mail the filled out ballot to:
gr_cra_...@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: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list. This secret is sent in an encrypted
mail.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
52bbd34b-1e8e-45ad-bd32-e517dbf2958c
[ ] Choice 1: CRA and PLD proposals include regulations detrimental to FOSS
[ ] Choice 2: CRA and PLD proposals should only apply to commercial ventures
[ ] Choice 3: The EU should not overrule DFSG 6 and FOSS licenses
[ ] Choice 4: 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.
BALLOT OPTIONS
Choice 1: CRA and PLD proposals include regulations detrimental to FOSS
===
Debian Public Statement about the EU Cyber Resilience Act and the
Product Liability Directive
The European Union is currently preparing a regulation "on horizontal
cybersecurity requirements for products with digital elements" known as
the Cyber Resilience Act (CRA). It is currently in the final "trilogue"
phase of the legislative process. The act includes a set of essential
cybersecurity and vulnerability handling requirements for manufacturers.
It will require products to be accompanied by information and
instructions to the user. Manufacturers will need to perform risk
assessments and produce technical documentation and, for critical
components, have third-party audits conducted. Discovered security
issues will have to be reported to European authorities within 24 hours
(1). The CRA will be followed up by the Product Liability Directive
(PLD) which will introduce compulsory
Re: CRA and PLD vote status
On Wed, Nov 29, 2023 at 10:39:38PM +0100, Kurt Roeckx wrote:
> Hi,
>
> I've updated the page at https://www.debian.org/vote/2023/vote_002 which
> the current status.
Here is the draft ballot:
Voting period starts 2023-12-09 00:00:00 UTC
Votes must be received by 2023-12-22 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the general resolution can be found at:
https://www.debian.org/vote/2023/vote_002
Also, note that you can get a fresh ballot any time before the end of the
vote by sending a signed mail to
bal...@vote.debian.org
with the subject "gr_non_free_firmware".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the options.
You might also want to read discussions at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below. The
dedicated email address this ballot should be sent to is:
gr_non_free_firmw...@vote.debian.org
The form you need to fill out is contained bellow in this message, marked
with two lines containing the characters '-=-=-=-=-=-'. Do not erase
anything between those lines, and do not change the choice names.
There are 4 choices in the form, which you may rank with numbers between 1
and 4. In the brackets next to your preferred choice, place a 1. Place a 2
in the brackets next to your next choice. Continue until you reach your
last choice. Do not enter a number smaller than 1 or larger than 4.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
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. (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).
Finally, mail the filled out ballot to:
gr_cra_...@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: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list. This secret is sent in an encrypted
mail.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
52bbd34b-1e8e-45ad-bd32-e517dbf2958c
[ ] Choice 1: CRA and PLD proposals include regulations detrimental to FOSS
[ ] Choice 2: The EU should clarify that non-commercial FOSS is exempted
[ ] Choice 3: The EU should not overrule DFSG 6 and FOSS licenses
[ ] Choice 4: 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.
BALLOT OPTIONS
Choice 1: CRA and PLD proposals include regulations detrimental to FOSS
===
Debian Public Statement about the EU Cyber Resilience Act and the
Product Liability Directive
The European Union is currently preparing a regulation "on horizontal
cybersecurity requirements for products with digital elements" known as
the Cyber Resilience Act (CRA). It is currently in the final "trilogue"
phase of the legislative process. The act includes a set of essential
cybersecurity and vulnerability handling requirements for manufacturers.
It will require products to be accompanied by information and
instructions to the user. Manufacturers will need to perform risk
assessments and produce technical documentation and, for critical
components, have third-party audits conducted. Discovered security
issues will have to be repor
Re: CRA and PLD vote status
On Fri, Dec 08, 2023 at 08:43:33PM +0100, Ilu wrote: > The CRA and PLD proposals include regulations, that will be detrimental > to free and open source software We've never had such a long option, and I'm worried this will break for some people trying to vote when it gets wrapped to the next line. But it might also just be fine. There is at least some code that only checks the first few words or something like that. Kurt > Am 08.12.23 um 20:40 schrieb Kurt Roeckx: > > The CRA and PLD will be detrimental to open source software >
Re: CRA and PLD vote status
Since the vote will start in a few hours, I need options for the other 2 options. My best attempts so far: A: The CRA and PLD will be detrimental to open source software B: The EU should clarify that non-commercial open source is exempted C: The EU should not overrule DFSG 6 and FOSS licenses Kurt On Thu, Dec 07, 2023 at 04:43:09PM +0100, Bart Martens wrote: > May I suggest for proposal C: > "The EU should not overrule DFSG 6 and FOSS licenses" > > > On Thu, Dec 07, 2023 at 07:19:44AM +0300, Kurt Roeckx wrote: > > Can people make suggestions for the ballot options text? > > > > Kurt > > > > On November 30, 2023 12:39:38 AM GMT+03:00, Kurt Roeckx > > wrote: > > >Hi, > > > > > >I've updated the page at https://www.debian.org/vote/2023/vote_002 which > > >the current status. > > > > > >We're at the maximum discussion period of 3 weeks, so the vote will > > >probably start the 10th of December. > > > > > > > > >Kurt > > > > > -- >
Re: CRA and PLD vote status
Can people make suggestions for the ballot options text? Kurt On November 30, 2023 12:39:38 AM GMT+03:00, Kurt Roeckx wrote: >Hi, > >I've updated the page at https://www.debian.org/vote/2023/vote_002 which >the current status. > >We're at the maximum discussion period of 3 weeks, so the vote will >probably start the 10th of December. > > >Kurt >
CRA and PLD vote status
Hi, I've updated the page at https://www.debian.org/vote/2023/vote_002 which the current status. We're at the maximum discussion period of 3 weeks, so the vote will probably start the 10th of December. Kurt
Re: call for seconds - separate proposal text for 2023/vote_002
On Wed, Nov 22, 2023 at 07:16:48PM +0100, Bart Martens wrote: > Hello, I hereby welcome seconds for adding this text to 2023/vote_002 > as a separate proposal. I'm currently counting 3 seconds for this. Kurt
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, Nov 19, 2023 at 11:21:47PM +, Luca Boccassi wrote: > Second version, taking into account feedback. Looking for seconds at > this point: So I'm still only counting 4 seconds at this point. Kurt
Re: This does not have to be a GR
On Tue, Nov 21, 2023 at 10:26:09PM +0100, Bill Allombert wrote: > Dear Debian voters, > > While Debian has stakes in the CRA, and should issue a statement if > only to show we exists, I am quite sure that a GR is not necessary for Debian > to issue such statement, and I am quite unconvinced the GR process is the best > option for the purpose of drafting such statement. > > I note that this is not the first law proposal that impact Debian and we never > did used the GR process for issuing a position statement. > > The DPL could delegate to a group of people knowledgeable in EU law to draft > a statement that is congruent with the interest of Debian. I'm not sure that the DPL has such authority, since it's a power giving to the developers by way of GR. I would also like to point out that, in the current state, on Saturday the discussion period is over and a vote is automatically called. Kurt
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, Nov 20, 2023 at 12:40:58AM +0100, Aigars Mahinovs wrote: > I second adding this version to the vote I'm getting a bad signature on this. > On Mon, 20 Nov 2023 at 00:22, Luca Boccassi wrote: > Second version, taking into account feedback. Looking for seconds at > this point: Maybe Santiago wants to adopt this text, rather than having 2 options? Kurt
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, Nov 12, 2023 at 01:03:38PM -0600, Simon Quigley wrote: > Just for good measure, seconded. This is the 5th second. Kurt
Bug#1007669: lice: please consider upgrading to 3.0 source format
You seem to have moved the config file for some reason. Are you sure you wanted to do that?
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
Can I suggest that if you file a few bugs and add some information in it so that maybe someone can look at it? If it only affects one architecture, send a mail to that list asking for help. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On Tue, Jun 20, 2023 at 05:52:44AM +0200, Rene Engelhard wrote: > Hi, > > Am 19.06.23 um 23:29 schrieb Rene Engelhard: > > > The pragmatic option would be to run only a smoketest for build success > > > on architectures not tested by upstream. > > > > And have Format->Character in Impress crash with Bus error like on > > mipsel? That doesn't sound too good for basic quality. > > > > There is a "smoketest" but it does just basic start. open, close stuff. > > Not even basic usage. > > That said, that is the smoketest on mipsel: The problem with a mail like this is that it really doesn't help anybody in understanding the problem. As porter, it will probably take a lot of time to get to the point where you can start looking at what the problem might be. It contains lots of information, but it's not clear what the problem is and what needs to be looked at. > (process:8700): dconf-CRITICAL **: 02:36:13.575: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8708): dconf-CRITICAL **: 02:36:19.328: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. > > (process:8815): dconf-CRITICAL **: 02:36:52.467: unable to create directory > '/run/user/2952/dconf': Permission denied. dconf will not work properly. Is this something the porter should look at? Is is relevant? > Fatal exception: Signal 11 It's a segfault, this should normally be trivial for you to debug, but is probably complicated for a porter to find out how to do things like attaching a debugger to the relevant process. > Stack: > /<>/instdir/program/libuno_sal.so.3(+0x49b18)[0x77d69b18] > /<>/instdir/program/libuno_sal.so.3(+0x49d48)[0x77d69d48] > /usr/lib/jvm/java-17-openjdk-mipsel/lib/server/libjvm.so(+0x537b8c)[0x62417b8c] Is this some openjdk problem, not a problem in libreoffice problem? > ./smoketest/smoketest.cxx:187:(anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() So the (TCP?) connection is not alive? Why not? That doesn't seem to be platform specific. Is that a problem in the test suite, and not libreoffice itself? > unknown:0:(anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException > - Binary URP bridge already disposed at ./binaryurp/source/bridge.cxx:1048 > > (anonymous namespace)::Test::test finished in: 76764ms > smoketest.cxx:187:Assertion > Test name: (anonymous namespace)::Test::test > assertion failed > - Expression: connection_.isStillAlive() > > ##Failure Location unknown## : Error > Test name: (anonymous namespace)::Test::test > tearDown() failed > - An uncaught exception of type com.sun.star.lang.DisposedException And then the test suite crashes because it can't actually deal with the previous the assertion failure, and the segfault above is not relevant at all? The most likely thing is that this is not a platform specific issue, but a either a general issue that just shows up on some platforms for whatever reason, or some problem in an other piece of software that libreoffice is using that does have a pratform specific issue. Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
Re: unbreaking LibreOffices tests on at least release architectures
On June 18, 2023 11:37:55 PM GMT+02:00, Rob Landley wrote: >On 6/18/23 14:58, Rene Engelhard wrote: >>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 >>> and >>> the AGPL have been rejected soundly by most developers" and talked about >>> how he >>> regretted the move and the damage it had done to the project, >>> https://archive.org/details/copyleftconf2020-allison >> >> Can we please talk about the actual issue at and - that is not the license. > >The issue is the number of developers engaging with this package have declined >to the point problems have gone unnoticed and unfixed for a long time. > >>> How long has the problem you're treating as a crisis been brewing? >> >> Far too long, as I said it was swept under I have a hard time understanding what you're trying to say. Do you think Debian doesn't have any developers/porters anymore? Or maybe that they're not actually using it for a desktop, and so the package isn't actually useful to anybody? Kurt
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
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
Bug#1034004: afl++: afl-clang(-fast) does not support -m32 due to missing afl-compiler-rt-32.o
This seems to be caused by a missing build-depends. If I build it locally, I do get support for 32 bit builds.
Re: voting problems
On Sat, Apr 01, 2023 at 02:38:06AM +0200, Kurt Roeckx wrote: > Hi, > > It seems something broke devotee, as usual. I've stopped the > processing of the mails, it will not send any reply. But you > can send your vote and it will be processed later. The ACKs should all be sent out now. Kurt
voting problems
Hi, It seems something broke devotee, as usual. I've stopped the processing of the mails, it will not send any reply. But you can send your vote and it will be processed later. Kurt
Debian Project Leader election 2023: First call for votes
Hi,
This is the first call for votes on the DPL election of 2023.
Voting period starts 2023-04-01 00:00:00 UTC
Votes must be received by 2023-04-14 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2023/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2023".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 2 choices in the form, which you may rank with numbers between
1 and 2. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 2.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
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. (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).
Finally, mail the filled out 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: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
593b4a1a-56be-45f6-b74e-db404069c55b
[ ] Choice 1: Jonathan Carter
[ ] Choice 2: 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-
mQINBGQnI+4BEADf0NtW+/v4B/4P3wkv4TdO5D9ExfdVpnzZ6Sy5Vg2hwhl0knBO
ioIXwhEq/UpMYcwprRGhR9gsOwAMkRlkQAhR0NF4w5oD0QqpEQpkEfNdyZnRrgRi
oPWvpIBBs7jaDNsAkf5TgP/6Cesm4hBPTNcA4vGmemVyesTehpY/JUxnl5NLyB/X
p82Gax/GwccE2OBQ7nAo1xEzEbPqa8+O76inDS7Rf/oRzjbkyrjeCmYlkzQrrNwW
TASnjjOWzJBrQAcd9OwKj7T0FHxV/hA1wP3XCwm1OpKrtxM6fZOmHK78fOBPUN6l
5udBZwAi/jvl+84VHq6HAm7e98JxEsvawm5GUnwqotntxgCtq1B0b4ytl66ZvfSs
biAEXKXkXsl4FvgmWvHR8R498fogKGMjcJdm/ZqGO8jubE6HJpeViDK5jlKe58F7
0pLc0H+iHa+XzZE3Cfwvurd7AIkLG0kRiHxJnSwDotGo1tcjoNnaykiGnNlYAoKi
8u2MvcE+xfIuPyW2bfVZbFAoFFRgdcP9VweAWWIM69d69y3vb5dxIiSsxE52Fv8J
K5lWAtPKYCGP2JpkZY6ABujKu53wZ2ikn+lumdQ8FDUnls5qow7md9S7EoEvHMj8
L/PhIJU3JQwJsZ/W2sHEEZYthtewh3n++lQoIgPA7JqTJcIxRY8BFmGTjwARAQAB
tCpEUEwgdm90ZSAyMDIzIDxsZWFkZXIyMDIzQHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmQnI+4CGwMFCQAbr4AGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
EGEYoeoM1XQxuh8QAIMPU5nrpPe6050tfDdQ9k6rOP/vhy/gg3KBqkWeDMvvPjPA
Draft ballot
Here is the draft ballot.
Voting period starts 2023-04-01 00:00:00 UTC
Votes must be received by 2023-04-14 23:59:59 UTC
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at https://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate's platform can be found at:
https://www.debian.org/vote/2023/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2023".
To vote you need to be a Debian Developer.
HOW TO VOTE
First, read the full text of the platform.
You might also want to read discussions with the candidates at
https://lists.debian.org/debian-vote/
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 2 choices in the form, which you may rank with numbers between
1 and 2. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 2.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
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. (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).
Finally, mail the filled out 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: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
VOTING SECRECY
This is a secret vote. After the voting period there will be a record
of all the votes without the name of the voter. It will instead contain
a cryptographic hash. You will receive a secret after you have voted
that can be used to calculate that hash. This allows you to verify
that your vote is in the list.
VOTING FORM
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
593b4a1a-56be-45f6-b74e-db404069c55b
[ ] Choice 1: Jonathan Carter
[ ] Choice 2: 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-
mQINBGQnI+4BEADf0NtW+/v4B/4P3wkv4TdO5D9ExfdVpnzZ6Sy5Vg2hwhl0knBO
ioIXwhEq/UpMYcwprRGhR9gsOwAMkRlkQAhR0NF4w5oD0QqpEQpkEfNdyZnRrgRi
oPWvpIBBs7jaDNsAkf5TgP/6Cesm4hBPTNcA4vGmemVyesTehpY/JUxnl5NLyB/X
p82Gax/GwccE2OBQ7nAo1xEzEbPqa8+O76inDS7Rf/oRzjbkyrjeCmYlkzQrrNwW
TASnjjOWzJBrQAcd9OwKj7T0FHxV/hA1wP3XCwm1OpKrtxM6fZOmHK78fOBPUN6l
5udBZwAi/jvl+84VHq6HAm7e98JxEsvawm5GUnwqotntxgCtq1B0b4ytl66ZvfSs
biAEXKXkXsl4FvgmWvHR8R498fogKGMjcJdm/ZqGO8jubE6HJpeViDK5jlKe58F7
0pLc0H+iHa+XzZE3Cfwvurd7AIkLG0kRiHxJnSwDotGo1tcjoNnaykiGnNlYAoKi
8u2MvcE+xfIuPyW2bfVZbFAoFFRgdcP9VweAWWIM69d69y3vb5dxIiSsxE52Fv8J
K5lWAtPKYCGP2JpkZY6ABujKu53wZ2ikn+lumdQ8FDUnls5qow7md9S7EoEvHMj8
L/PhIJU3JQwJsZ/W2sHEEZYthtewh3n++lQoIgPA7JqTJcIxRY8BFmGTjwARAQAB
tCpEUEwgdm90ZSAyMDIzIDxsZWFkZXIyMDIzQHZvdGUuZGViaWFuLm9yZz6JAj4E
EwEIACgFAmQnI+4CGwMFCQAbr4AGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJ
EGEYoeoM1XQxuh8QAIMPU5nrpPe6050tfDdQ9k6rOP/vhy/gg3KBqkWeDMvvPjPA
QEDCCpUydnC4H/Ygyk7BTiUrQMJ6/tSKI8dqjyNBlb73BicbUnNcyrPeG/zK+ng+
AhWyssjBbAzxgunilGqd847dAMIBJ8Ks9AG+e78pe2Xa003FXIDc5qLXkTZRMUh5
FeoAvtPkwrkGZM1ihJMJ9+CYoC9kdozzUPmTJh9bV1+Tk2o42iGWlQVpcdY7pp02
KWVqxZfhNsLYmM/dx63rz/QyuH9mbZgUbdK/R6P/3ZXpoMKngACKQUxKUEsFYWc/
YOU7+i2duVVrUwdpx7JF05n3cJd+KCRdnUomsmle2Pk1N8ZumNIuCPr8TxvaIcz9
WNHUZziaySPOKwTUnaNwHhJ1ZlY3BZFbI8t4G7X5cFWojEdleCf9PiWd2cUdCH5T
Y7CUk/nbk2s4QbxiavY2kjTjYs4RFvacbbo5EOX7jzoID4XrPMl+TZroSDOELRRi
Debian Project Leader Elections 2022: Candidates
We're now into the campaigning period. We have 1 candidate this year: - Jonathan Carter The platform is available at: https://www.debian.org/vote/2023/platforms/ Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hi, Is the issue that with older glibc versions, it was silently casted to a 32 bit value, but now that glibc supports 64 bit, it knows it can't represent it, and gives an error? Maybe for bookworm, we should just ignore the test error? Kurt
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hi, Is the issue that with older glibc versions, it was silently casted to a 32 bit value, but now that glibc supports 64 bit, it knows it can't represent it, and gives an error? Maybe for bookworm, we should just ignore the test error? Kurt
Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'
Hi, Are you waiting for something before uploading this fix? Kurt
Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'
Hi, Are you waiting for something before uploading this fix? Kurt
Debian Project Leader Elections 2023: Call for nominations
Hi, According to the constitution (5.2. Appointment), project leader elections should begin "six weeks before the leadership post becomes vacant, or (if it is too late already) immediately." The new project leader term starts on 2023-04-21. The time line looks like: | Period | Start | End | |+-+---| | Nomination | Saturday 2023-03-04 | Friday 2023-03-10 | | Campaign | Saturday 2023-03-11 | Friday 2023-03-31 | | Vote | Saturday 2023-04-01 | Friday 2023-04-14 | Prospective leaders should be familiar with the constitution, but just to review: there's a one week period when interested developers can nominate themselves and announce their platform, followed by a three week period intended for campaigning, followed by two weeks for the election itself. I intend to collect platform statements from the candidates, and publish them at http://www.debian.org/vote/2023/platforms/ at the end of the nomination period, which means around 2023-03-12. I suggest that the candidates send the platform, preferably in wml or HTML, to the secretary at least a day before the publication date. The format of the web page is open to discussion, but I suggest there be at least three sections: - Introduction / Biography - Major Goal / Meat of the platform - Rebuttal. The candidates can make a rebuttal. I would like to receive them in the first week of the campaign period, so I can publish them around 2023-03-19. Details and results for the vote will be published at: http://www.debian.org/vote/2023/vote_001 Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. Kurt Roeckx Debian Project Secretary signature.asc Description: PGP signature
Bug#1023284: libevent: FTBFS with glibc 2.36
Hi, It seems a fix for this is sitting git, but hasn't been uploaded. Is there a reason it's not been uploaded yet? Kurt
Bug#1023284: libevent: FTBFS with glibc 2.36
Hi, It seems a fix for this is sitting git, but hasn't been uploaded. Is there a reason it's not been uploaded yet? Kurt
DPL 2023
Hi, This is the schedule for the DPL election: Nomination period: Saturday 2023-03-04 Friday 2023-03-10 Campaigning period: Saturday 2023-03-11 Friday 2023-03-31 Voting period: Saturday 2023-04-01 Friday 2023-04-14 Kurt
Re: Differences between the zani and zandonai build hosts?
On Fri, Dec 30, 2022 at 09:42:43AM +0200, Peter Pentchev wrote: > Hi, > > First of all, thanks a lot for all your work on porting Debian to > the IBM z* systems! > > Are there any differences in the hardware or software configuration of > the zandonai and zani Debian buildd hosts? There is a build-time test for > the libzstd package that failed the only time when a 1.5.0 version of > the package was built on the zani host, but it built successfully on > the zandonai one. There were no significant differences between > the four uploads of libzstd-1.5.0 - the changes that were made should have > prevented a full-on FTBFS if they were applicable to the compiler/libc > at all. > > https://buildd.debian.org/status/logs.php?pkg=libzstd=s390x According to: https://db.debian.org/machines.cgi?host=zandonai https://db.debian.org/machines.cgi?host=zani They both run on a z15. Kurt
Bug#1026103: aflplusplus: FTBFS on s390x
Source: aflplusplus Version: 4.04c-2 Severity: serious Hi, Your package is failing to build on s390x: [*] Compiling afl++ for OS Linux on ARCH s390x ./test/unittests/unit_maybe_alloc [==] Running 6 test(s). [ RUN ] test_pow2 [ OK ] test_pow2 [ RUN ] test_null_allocs [ OK ] test_null_allocs [ RUN ] test_nonpow2_size [ OK ] test_nonpow2_size [ RUN ] test_zero_size [ OK ] test_zero_size [ RUN ] test_unchanged_size [ OK ] test_unchanged_size [ RUN ] test_grow_multiple [ OK ] test_grow_multiple [==] 6 test(s) run. [ PASSED ] 6 test(s). ./test/unittests/unit_preallocable [==] Running 2 test(s). [ RUN ] test_alloc_free [ OK ] test_alloc_free [ RUN ] test_prealloc_overflow [ OK ] test_prealloc_overflow [==] 2 test(s) run. [ PASSED ] 2 test(s). ./test/unittests/unit_list [==] Running 3 test(s). [ RUN ] test_contains [ OK ] test_contains [ RUN ] test_foreach [ OK ] test_foreach [ RUN ] test_long_list [ OK ] test_long_list [==] 3 test(s) run. [ PASSED ] 3 test(s). ./test/unittests/unit_rand [==] Running 2 test(s). [ RUN ] test_rand_0 [ OK ] test_rand_0 [ RUN ] test_rand_below [ OK ] test_rand_below [==] 2 test(s) run. [ PASSED ] 2 test(s). ./test/unittests/unit_hash [==] Running 1 test(s). [ RUN ] test_hash [ OK ] test_hash [==] 1 test(s) run. [ PASSED ] 1 test(s). make[3]: Leaving directory '/<>' ␛[1;90m[*] 10 test cases completed.␛[0m ␛[1;93m[-] not all test cases were executed ␛[0;31m[!] failure in tests :-(␛[0m make[2]: *** [GNUmakefile:343: tests] Error 1 It's not at all clear why it says: "failure in tests". All the test seem to pass. Other architectures also have the "not all test cases were executed" message. I've tried to build it again on the buildds, but it failed the same way. Kurt
Bug#1026103: aflplusplus: FTBFS on s390x
Source: aflplusplus Version: 4.04c-2 Severity: serious Hi, Your package is failing to build on s390x: [*] Compiling afl++ for OS Linux on ARCH s390x ./test/unittests/unit_maybe_alloc [==] Running 6 test(s). [ RUN ] test_pow2 [ OK ] test_pow2 [ RUN ] test_null_allocs [ OK ] test_null_allocs [ RUN ] test_nonpow2_size [ OK ] test_nonpow2_size [ RUN ] test_zero_size [ OK ] test_zero_size [ RUN ] test_unchanged_size [ OK ] test_unchanged_size [ RUN ] test_grow_multiple [ OK ] test_grow_multiple [==] 6 test(s) run. [ PASSED ] 6 test(s). ./test/unittests/unit_preallocable [==] Running 2 test(s). [ RUN ] test_alloc_free [ OK ] test_alloc_free [ RUN ] test_prealloc_overflow [ OK ] test_prealloc_overflow [==] 2 test(s) run. [ PASSED ] 2 test(s). ./test/unittests/unit_list [==] Running 3 test(s). [ RUN ] test_contains [ OK ] test_contains [ RUN ] test_foreach [ OK ] test_foreach [ RUN ] test_long_list [ OK ] test_long_list [==] 3 test(s) run. [ PASSED ] 3 test(s). ./test/unittests/unit_rand [==] Running 2 test(s). [ RUN ] test_rand_0 [ OK ] test_rand_0 [ RUN ] test_rand_below [ OK ] test_rand_below [==] 2 test(s) run. [ PASSED ] 2 test(s). ./test/unittests/unit_hash [==] Running 1 test(s). [ RUN ] test_hash [ OK ] test_hash [==] 1 test(s) run. [ PASSED ] 1 test(s). make[3]: Leaving directory '/<>' ␛[1;90m[*] 10 test cases completed.␛[0m ␛[1;93m[-] not all test cases were executed ␛[0;31m[!] failure in tests :-(␛[0m make[2]: *** [GNUmakefile:343: tests] Error 1 It's not at all clear why it says: "failure in tests". All the test seem to pass. Other architectures also have the "not all test cases were executed" message. I've tried to build it again on the buildds, but it failed the same way. Kurt
Bug#1025454: afl: Downloads software during build
Source: aflplusplus Version: 4.04c-1 Severity: serious Hi, On the buildds, we get: # -/usr/bin/make -C utils/plot_ui /usr/bin/make -C frida_mode make[3]: Entering directory '/<>/frida_mode' mkdir -p /<>/frida_mode/build/ mkdir -p /<>/frida_mode/build/frida/ wget -qO /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz "https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz; || curl -L -o /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz "https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz; /bin/sh: 1: wget: not found /bin/sh: 1: curl: not found make[3]: *** [GNUmakefile:313: /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz] Error 127 make[3]: Leaving directory '/<>/frida_mode' make[2]: [GNUmakefile:636: distrib] Error 2 (ignored) cd nyx_mode && ./build_nyx_support.sh = Nyx build script = [*] Performing basic sanity checks... [*] Making sure all Nyx is checked out ./build_nyx_support.sh: line 41: git: command not found make[2]: [GNUmakefile:637: distrib] Error 127 (ignored) cd qemu_mode && sh ./build_qemu_support.sh = QemuAFL build script = [*] Performing basic sanity checks... [+] All checks passed! [*] Making sure qemuafl is checked out [*] cloning qemuafl Trying to clone qemuafl (attempt 1/3) ./build_qemu_support.sh: 84: git: not found Trying to clone qemuafl (attempt 2/3) ./build_qemu_support.sh: 84: git: not found Trying to clone qemuafl (attempt 3/3) ./build_qemu_support.sh: 84: git: not found [-] Not checked out, please install git or check your internet connection. make[2]: [GNUmakefile:638: distrib] Error 1 (ignored) cd unicorn_mode && unset CFLAGS && sh ./build_unicorn_support.sh = UnicornAFL build script = [...] On machines that have more software installed, it will download various things and build them. It makes at least use of software like wget, curl, git, cargo. Packages in Debian should be build only from the source and not download more sources from internet. Kurt
Bug#1025454: afl: Downloads software during build
Source: aflplusplus Version: 4.04c-1 Severity: serious Hi, On the buildds, we get: # -/usr/bin/make -C utils/plot_ui /usr/bin/make -C frida_mode make[3]: Entering directory '/<>/frida_mode' mkdir -p /<>/frida_mode/build/ mkdir -p /<>/frida_mode/build/frida/ wget -qO /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz "https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz; || curl -L -o /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz "https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz; /bin/sh: 1: wget: not found /bin/sh: 1: curl: not found make[3]: *** [GNUmakefile:313: /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz] Error 127 make[3]: Leaving directory '/<>/frida_mode' make[2]: [GNUmakefile:636: distrib] Error 2 (ignored) cd nyx_mode && ./build_nyx_support.sh = Nyx build script = [*] Performing basic sanity checks... [*] Making sure all Nyx is checked out ./build_nyx_support.sh: line 41: git: command not found make[2]: [GNUmakefile:637: distrib] Error 127 (ignored) cd qemu_mode && sh ./build_qemu_support.sh = QemuAFL build script = [*] Performing basic sanity checks... [+] All checks passed! [*] Making sure qemuafl is checked out [*] cloning qemuafl Trying to clone qemuafl (attempt 1/3) ./build_qemu_support.sh: 84: git: not found Trying to clone qemuafl (attempt 2/3) ./build_qemu_support.sh: 84: git: not found Trying to clone qemuafl (attempt 3/3) ./build_qemu_support.sh: 84: git: not found [-] Not checked out, please install git or check your internet connection. make[2]: [GNUmakefile:638: distrib] Error 1 (ignored) cd unicorn_mode && unset CFLAGS && sh ./build_unicorn_support.sh = UnicornAFL build script = [...] On machines that have more software installed, it will download various things and build them. It makes at least use of software like wget, curl, git, cargo. Packages in Debian should be build only from the source and not download more sources from internet. Kurt
Bug#1025443: aflplusplus: Missing lld-14 Build-Depends
Source: aflplusplus Version: 4.04c-1 Hi, The LTO mode is not build at runtime, the log shows: [+] llvm_mode detected llvm 10+, enabling neverZero implementation and c++14 [+] llvm_mode detected llvm 11+, enabling afl-lto LTO implementation GNUmakefile.llvm:229: ld.lld not found, cannot enable LTO mode This is because there is a missing Build-Depends on lld-14. The LTO mode is the recommended mode. Kurt
Bug#1024631: gitlab: preinst: invalid number 9.1
On Tue, Nov 22, 2022 at 06:13:30PM +0100, Kurt Roeckx wrote: > In any case, the default cluster points to 14, it's just not on port 5432. That doesn't seem to be true. Commands like createdb, psql default to port 5432 if there is nothing overriding it, like PGPORT env variable. Kurt
[DRE-maint] Bug#1024631: gitlab: preinst: invalid number 9.1
On Tue, Nov 22, 2022 at 06:13:30PM +0100, Kurt Roeckx wrote: > In any case, the default cluster points to 14, it's just not on port 5432. That doesn't seem to be true. Commands like createdb, psql default to port 5432 if there is nothing overriding it, like PGPORT env variable. Kurt ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
Bug#1024631: gitlab: preinst: invalid number 9.1
On Tue, Nov 22, 2022 at 10:20:06PM +0530, Pirate Praveen wrote: > > > On Tue, Nov 22 2022 at 02:27:05 PM +01:00:00 +01:00:00, Kurt Roeckx > wrote: > > Package: gitlab > > Version: 15.4.2+ds1-1~fto11+3 > > > > On install I get: > > /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1 > > > > I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them > > are used. 9.1 is using port 5432. > > > > Do you have another recommendation on how to make sure we use at least > postgresql 12? > > Does adding a configuration option to skip this check > "gitlab_pg_version_check" which can be set to "false" in > /etc/gitlab/gitlab-debian.conf suffice? Note that it just continues the installation because it ignores the error. To be able to install things, I had to edit the database.yml to set the port number. I also had to manually create the user and database. I think it asks for a hostname, but not for a port number. I at least assume it supports a remote database. The check should be for that combination, which is probably harder. In any case, the default cluster points to 14, it's just not on port 5432. Kurt
[DRE-maint] Bug#1024631: gitlab: preinst: invalid number 9.1
On Tue, Nov 22, 2022 at 10:20:06PM +0530, Pirate Praveen wrote: > > > On Tue, Nov 22 2022 at 02:27:05 PM +01:00:00 +01:00:00, Kurt Roeckx > wrote: > > Package: gitlab > > Version: 15.4.2+ds1-1~fto11+3 > > > > On install I get: > > /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1 > > > > I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them > > are used. 9.1 is using port 5432. > > > > Do you have another recommendation on how to make sure we use at least > postgresql 12? > > Does adding a configuration option to skip this check > "gitlab_pg_version_check" which can be set to "false" in > /etc/gitlab/gitlab-debian.conf suffice? Note that it just continues the installation because it ignores the error. To be able to install things, I had to edit the database.yml to set the port number. I also had to manually create the user and database. I think it asks for a hostname, but not for a port number. I at least assume it supports a remote database. The check should be for that combination, which is probably harder. In any case, the default cluster points to 14, it's just not on port 5432. Kurt ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
Bug#1024627: Acknowledgement (gitlab: Fails to install)
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 version from backports is too new it seems, and it what gets installed when you just do: apt install gitlab
Bug#1024627: Acknowledgement (gitlab: Fails to install)
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 version from backports is too new it seems, and it what gets installed when you just do: apt install gitlab
[DRE-maint] Bug#1024627: Acknowledgement (gitlab: Fails to install)
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 version from backports is too new it seems, and it what gets installed when you just do: apt install gitlab ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
Bug#1024631: gitlab: preinst: invalid number 9.1
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 On install I get: /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1 I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them are used. 9.1 is using port 5432. Kurt
[DRE-maint] Bug#1024631: gitlab: preinst: invalid number 9.1
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 On install I get: /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1 I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them are used. 9.1 is using port 5432. Kurt ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
Bug#1024627: gitlab: Fails to install
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 Severity: serious Setting up gitlab (15.4.2+ds1-1~fto11+3) ... Bundler could not find compatible versions for gem "omniauth-oauth2": In Gemfile: omniauth-auth0 (~> 2.0) was resolved to 2.0.0, which depends on omniauth-oauth2 (~> 1.4) x86_64-linux omniauth-authentiq (~> 0.3.3) was resolved to 0.3.3, which depends on omniauth-oauth2 (>= 1.5) x86_64-linux omniauth-azure-activedirectory-v2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7) x86_64-linux omniauth-dingtalk-oauth2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7.1) x86_64-linux omniauth-facebook (~> 4.0) was resolved to 4.0.0, which depends on omniauth-oauth2 (~> 1.2) x86_64-linux omniauth-oauth2-generic (~> 0.2.2) was resolved to 0.2.2, which depends on omniauth-oauth2 (~> 1.0) x86_64-linux Could not find gem 'omniauth-oauth2 (~> 1.7.1)', which is required by gem 'omniauth-auth0 (~> 2.0)', in any of the sources. Kurt
Bug#1024627: gitlab: Fails to install
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 Severity: serious Setting up gitlab (15.4.2+ds1-1~fto11+3) ... Bundler could not find compatible versions for gem "omniauth-oauth2": In Gemfile: omniauth-auth0 (~> 2.0) was resolved to 2.0.0, which depends on omniauth-oauth2 (~> 1.4) x86_64-linux omniauth-authentiq (~> 0.3.3) was resolved to 0.3.3, which depends on omniauth-oauth2 (>= 1.5) x86_64-linux omniauth-azure-activedirectory-v2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7) x86_64-linux omniauth-dingtalk-oauth2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7.1) x86_64-linux omniauth-facebook (~> 4.0) was resolved to 4.0.0, which depends on omniauth-oauth2 (~> 1.2) x86_64-linux omniauth-oauth2-generic (~> 0.2.2) was resolved to 0.2.2, which depends on omniauth-oauth2 (~> 1.0) x86_64-linux Could not find gem 'omniauth-oauth2 (~> 1.7.1)', which is required by gem 'omniauth-auth0 (~> 2.0)', in any of the sources. Kurt
[DRE-maint] Bug#1024627: gitlab: Fails to install
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 Severity: serious Setting up gitlab (15.4.2+ds1-1~fto11+3) ... Bundler could not find compatible versions for gem "omniauth-oauth2": In Gemfile: omniauth-auth0 (~> 2.0) was resolved to 2.0.0, which depends on omniauth-oauth2 (~> 1.4) x86_64-linux omniauth-authentiq (~> 0.3.3) was resolved to 0.3.3, which depends on omniauth-oauth2 (>= 1.5) x86_64-linux omniauth-azure-activedirectory-v2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7) x86_64-linux omniauth-dingtalk-oauth2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7.1) x86_64-linux omniauth-facebook (~> 4.0) was resolved to 4.0.0, which depends on omniauth-oauth2 (~> 1.2) x86_64-linux omniauth-oauth2-generic (~> 0.2.2) was resolved to 0.2.2, which depends on omniauth-oauth2 (~> 1.0) x86_64-linux Could not find gem 'omniauth-oauth2 (~> 1.7.1)', which is required by gem 'omniauth-auth0 (~> 2.0)', in any of the sources. Kurt ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
Bug#1021997: cargo: New upstream version
Source: cargo Version: 0.57.0-7 Severity: wishlist Hi, Would it be possible to upload a newer version of cargo? The current version is preventing me from building things. I think the 0.62 version matches the 1.61 version of rustc that's currently in testing/unstable. Kurt
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
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
Re: cv25519 key support on devotee
On Wed, Sep 28, 2022 at 07:22:38AM +0200, Kurt Roeckx wrote: > > As far as I understand of what is going wrong is that gnupg tries to > write to the status fd, but libgnupg-interface-perl is trying to read > gnupg's stdout and they just deadlock. So I applied this patch and things seem to work now: --- dvt-ack 2019-07-28 21:02:14.142145228 + +++ dvt-ack 2022-09-28 18:42:04.128218420 + @@ -231,9 +231,9 @@ close $input; # now we read the output + my @status = <$status_fh>;# read the status info my @output = <$output>; # reading the output my @errors = <$error>;# reading the error - my @status = <$status_fh>;# read the status info # clean up... close $output; Kurt
Re: cv25519 key support on devotee
On Wed, Sep 28, 2022 at 04:27:56PM +0800, Shengjing Zhu wrote: > On Wed, Sep 28, 2022 at 07:22:38AM +0200, Kurt Roeckx wrote: > > On Mon, Sep 26, 2022 at 12:51:48AM +0800, Shengjing Zhu wrote: > > > Hi, > > > > > > Is there any plan to support cv25519 key on devotee? > > > > > > Or could devotee send unencrypted ack to the voter? I really don't > > > mind the vote secrecy... But I want to see my vote hash. I see dvt-ack > > > has something like Encrypted_Ack option, but I'm not sure if it can be > > > run manually to send individual ack (I'm not good at reading perl > > > scripts). > > > > > > Please CC me as I don't subscribe -vote. > > > > I've been unable to get encrypting using libgnupg-interface-perl to > > work with gnupg 2. In bullseye it at least claims the support both > > 1.4 and 2.2, but I can't get it to work with either. So I'm > > currently stuck with the libgnupg-interface-perl version from buster > > and gnupg 1.4. > > > > As far as I understand of what is going wrong is that gnupg tries to > > write to the status fd, but libgnupg-interface-perl is trying to read > > gnupg's stdout and they just deadlock. > > > > After a quick checking the changelog of libgnupg-interface-perl, > I think it is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016125 > > It has been fixed in bullseye-backports(1.02-2~bpo11+1). > Could you try with that? That doesn't fix anything. Kurt
Re: cv25519 key support on devotee
On Mon, Sep 26, 2022 at 12:51:48AM +0800, Shengjing Zhu wrote: > Hi, > > Is there any plan to support cv25519 key on devotee? > > Or could devotee send unencrypted ack to the voter? I really don't > mind the vote secrecy... But I want to see my vote hash. I see dvt-ack > has something like Encrypted_Ack option, but I'm not sure if it can be > run manually to send individual ack (I'm not good at reading perl > scripts). > > Please CC me as I don't subscribe -vote. I've been unable to get encrypting using libgnupg-interface-perl to work with gnupg 2. In bullseye it at least claims the support both 1.4 and 2.2, but I can't get it to work with either. So I'm currently stuck with the libgnupg-interface-perl version from buster and gnupg 1.4. As far as I understand of what is going wrong is that gnupg tries to write to the status fd, but libgnupg-interface-perl is trying to read gnupg's stdout and they just deadlock. Kurt
