Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Release][Packaging] Linux packages fail on ARM due to wrong KEYS file with non US-ASCII character #39074

Closed
raulcd opened this issue Dec 5, 2023 · 1 comment · Fixed by #39082
Closed

[Release][Packaging] Linux packages fail on ARM due to wrong KEYS file with non US-ASCII character #39074

raulcd opened this issue Dec 5, 2023 · 1 comment · Fixed by #39082
Assignees
@kou
Labels
Component: Continuous Integration Component: Release Priority: Blocker Marks a blocker for the release Type: bug
Milestone
14.0.2

Comments

@raulcd
Copy link
Member

raulcd commented Dec 5, 2023

Describe the bug, including details regarding any error messages, version, and platform.

The Linux packages for ARM are currently failing due to:

 cd apache-arrow-release
cd /runner/_work/crossbow/crossbow/arrow/dev/tasks/linux-packages/../../..
Downloading... https://www.apache.org/dyn/closer.lua?action=download&filename=arrow/KEYS
rake aborted!
ArgumentError: invalid byte sequence in US-ASCII

This is reproducible on the 14.0.2 RC 0 branch, see: #39070 (comment)
and main:

I did add my GPG key to the release svn repo:
https://dist.apache.org/repos/dist/release/arrow/KEYS
and it contains non US-ASCII characters due to my name:
uid [ultimate] Raúl Cumplido Domínguez (CODE SIGNING KEY) <raulcd@apache.org>
This is how it looks on the browser:
uid [ultimate] Raúl Cumplido Domínguez (CODE SIGNING KEY) <raulcd@apache.org>

Component(s)

Continuous Integration, Release
@raulcd
Copy link
Member Author

raulcd commented Dec 5, 2023

@kou Should there be a problem with those characters? Should those characters not be used?

@raulcd raulcd changed the title [Release][Packaging] Linx packages fail on ARM due to wrong KEYS file with non US-ASCII character [Release][Packaging] Linux packages fail on ARM due to wrong KEYS file with non US-ASCII character Dec 5, 2023
@raulcd raulcd added the Priority: Blocker Marks a blocker for the release label Dec 5, 2023
kou added a commit to kou/arrow that referenced this issue Dec 5, 2023
@kou
apacheGH-39074: [Release][Packaging] Use UTF-8 explicitly for KEYS
834a72f
@github-actions github-actions bot mentioned this issue Dec 5, 2023
Merged
@kou kou closed this as completed in #39082 Dec 5, 2023
kou added a commit that referenced this issue Dec 5, 2023
@kou
GH-39074: [Release][Packaging] Use UTF-8 explicitly for KEYS (#39082)
50e54b8 
### Rationale for this change

`KEYS` may have UTF-8 (non ASCII) characters. Ruby chooses the default encoding based on `LANG`. If `LANG=C`, Ruby uses the `US-ASCII` encoding as the default encoding. If Ruby uses the `US-ASCII` encoding, we can't process `KEYS` because it has non ASCII characters.

### What changes are included in this PR?

Use the `UTF-8` encoding explicitly for `KEYS`. If we specify the `UTF-8` encoding explicitly, our `KEYS` processing don't depend on `LANG`.

### Are these changes tested?

Yes.

### Are there any user-facing changes?

No.
* Closes: #39074

Authored-by: Sutou Kouhei <kou@clear-code.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
@kou kou added this to the 15.0.0 milestone Dec 5, 2023
@raulcd raulcd modified the milestones: 15.0.0, 14.0.2 Dec 9, 2023
raulcd pushed a commit that referenced this issue Dec 9, 2023
@kou @raulcd
GH-39074: [Release][Packaging] Use UTF-8 explicitly for KEYS (#39082)
7a54881 
### Rationale for this change

`KEYS` may have UTF-8 (non ASCII) characters. Ruby chooses the default encoding based on `LANG`. If `LANG=C`, Ruby uses the `US-ASCII` encoding as the default encoding. If Ruby uses the `US-ASCII` encoding, we can't process `KEYS` because it has non ASCII characters.

### What changes are included in this PR?

Use the `UTF-8` encoding explicitly for `KEYS`. If we specify the `UTF-8` encoding explicitly, our `KEYS` processing don't depend on `LANG`.

### Are these changes tested?

Yes.

### Are there any user-facing changes?

No.
* Closes: #39074

Authored-by: Sutou Kouhei <kou@clear-code.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
dgreiss pushed a commit to dgreiss/arrow that referenced this issue Feb 19, 2024
@kou @dgreiss
apacheGH-39074: [Release][Packaging] Use UTF-8 explicitly for KEYS (a…
4748061 
…pache#39082)

### Rationale for this change

`KEYS` may have UTF-8 (non ASCII) characters. Ruby chooses the default encoding based on `LANG`. If `LANG=C`, Ruby uses the `US-ASCII` encoding as the default encoding. If Ruby uses the `US-ASCII` encoding, we can't process `KEYS` because it has non ASCII characters.

### What changes are included in this PR?

Use the `UTF-8` encoding explicitly for `KEYS`. If we specify the `UTF-8` encoding explicitly, our `KEYS` processing don't depend on `LANG`.

### Are these changes tested?

Yes.

### Are there any user-facing changes?

No.
* Closes: apache#39074

Authored-by: Sutou Kouhei <kou@clear-code.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kou kou

Labels
Component: Continuous Integration Component: Release Priority: Blocker Marks a blocker for the release Type: bug
Projects
None yet
Milestone
14.0.2
Development

Successfully merging a pull request may close this issue.

GH-39074: [Release][Packaging] Use UTF-8 explicitly for KEYS kou/arrow
2 participants
@kou @raulcd