devs/cproof
1
2
Fork 1
Code Issues 43 Pull Requests 6 Actions Packages Projects 1 Releases Wiki Activity

[CI] Detect flag collisions caused by Pikaur's configuration logic #55

New Issue
Closed
opened 2025-11-10 12:04:42 +00:00 by jabber.developer · 1 comment
jabber.developer commented 2025-11-10 12:04:42 +00:00
Owner
Copy Link

Problem

We are seeing reports of build failures on Arch Linux for users running pikaur. These failures occur during the compilation stage, often appearing as "variable redefined" errors or conflicting compiler options.

Root Cause

The issue stems from how pikaur handles makepkg configurations. Specifically, its makepkg_config.py logic causes flags from the system-wide /etc/makepkg.conf to be merged into the build environment.

When these system flags collide with flags explicitly defined in our project's Makefile.am (for example, different versions of -D_FORTIFY_SOURCE), the compiler encounters duplicate or conflicting definitions and aborts the build.

Impact

Our current CI environment is "too clean." Because the CI uses a standard Arch Linux container without the cascading configuration logic used by pikaur, our automated tests are failing to catch these collisions.

This creates a "silent killer" scenario: a developer can push a change that works perfectly in CI but breaks the build for all Arch users using pikaur.

Goal

We need to improve our Arch Linux CI pipeline to achieve parity with the pikaur environment. The CI should be able to detect when a code change introduces a flag collision by simulating the injection of system-level flags into the build environment.

Acceptance Criteria

  • The Arch Linux CI runner simulates the presence of flags from /etc/makepkg.conf.
  • The simulation is scoped strictly to the Arch Linux environment (does not affect Debian/Ubuntu runs).
  • The simulation correctly handles multi-line configuration files.
  • A change that introduces a flag collision in Makefile.am successfully triggers a failure in the Arch CI matrix.
## Problem We are seeing reports of build failures on Arch Linux for users running `pikaur`. These failures occur during the compilation stage, often appearing as "variable redefined" errors or conflicting compiler options. ## Root Cause The issue stems from how `pikaur` handles `makepkg` configurations. Specifically, its `makepkg_config.py` logic causes flags from the system-wide `/etc/makepkg.conf` to be merged into the build environment. When these system flags collide with flags explicitly defined in our project's `Makefile.am` (for example, different versions of `-D_FORTIFY_SOURCE`), the compiler encounters duplicate or conflicting definitions and aborts the build. ## Impact Our current CI environment is "too clean." Because the CI uses a standard Arch Linux container without the cascading configuration logic used by `pikaur`, our automated tests are failing to catch these collisions. This creates a "silent killer" scenario: a developer can push a change that works perfectly in CI but breaks the build for all Arch users using `pikaur`. ## Goal We need to improve our Arch Linux CI pipeline to achieve parity with the `pikaur` environment. The CI should be able to detect when a code change introduces a flag collision by simulating the injection of system-level flags into the build environment. ### Acceptance Criteria - [x] The Arch Linux CI runner simulates the presence of flags from `/etc/makepkg.conf`. - [x] The simulation is scoped strictly to the Arch Linux environment (does not affect Debian/Ubuntu runs). - [x] The simulation correctly handles multi-line configuration files. - [x] A change that introduces a flag collision in `Makefile.am` successfully triggers a failure in the Arch CI matrix.
jabber.developer added this to the Plans (2025-2026) project 2025-11-10 12:25:47 +00:00
jabber.developer added the
Kind/Testing
Priority
Medium
3
Reviewed
Confirmed
1
 labels 2026-01-21 16:51:26 +00:00
jabber.developer changed title from Add autotests with pikaur-like build flags to [CI] Detect flag collisions caused by Pikaur's configuration logic 2026-04-18 16:11:45 +00:00
jabber.developer moved this to Verification in Plans (2025-2026) on 2026-04-18 16:49:37 +00:00
jabber.developer commented 2026-04-25 18:13:11 +00:00
Author
Owner
Copy Link

Resolved by #108

Resolved by #108
jabber.developer moved this to Done in Plans (2025-2026) on 2026-04-25 18:13:21 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
Kind/Bug
Something is not working
Kind/Documentation
Documentation changes
Kind/Enhancement
Improve existing functionality
Kind/Feature
New functionality
Kind/Security
This is security issue
Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label
Kind/Testing
Priority
Medium
3
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No project Plans (2025-2026)
Assignees
Clear assignees
admin jabber.developer jabber.developer2
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: devs/cproof#55
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?