jedarden/pdftract
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(bf-3e0vl): document diagnostic output files in build directories

Browse source
This commit is contained in:
jedarden 2026-07-06 17:31:37 -04:00
parent 8ea1ea69fb
commit 010a1fc6f5
2 changed files with 178 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

78
notes/bf-3e0vl.md Normal file
View file

@ -0,0 +1,78 @@
# Diagnostic Output Files in pdftract Build Directories
## Summary
Located and documented diagnostic output files stored in the project build and test output directories.
## Build Diagnostic Files (target/ directory)
### Location: `/home/coding/pdftract/target/debug/build/*/stderr`
Build stderr files are stored in build-specific subdirectories within `target/debug/build/`. These contain compiler warnings and build diagnostic information.
**Example file:** `/home/coding/pdftract/target/debug/build/pdftract-core-0d428a00850f9797/stderr`
- **File size:** 760 bytes
- **Last modified:** July 6, 2026 17:23
- **Contents:** Cargo compiler warnings about missing optional checksum files and unused code
**Sample content:**
```
cargo:warning=Checksum file not found (optional): std14-metrics.json
cargo:warning=Checksum file not found (optional): ../../../build/glyph-shapes.json
cargo:warning=Checksum file not found (optional): named-encodings.json
cargo:warning=Checksum file not found (optional): predefined-cmaps/adobe-japan1.json
```
**Pattern:** Each build crate has its own subdirectory with a `stderr` file (e.g., `pdftract-core-HASH/stderr`, `pdftract-cli-HASH/stderr`).
### File Count
- **Total stderr files found:** ~150+ (one per build crate dependency)
- **Non-empty stderr files:** ~10-15 (containing actual compiler warnings)
- **Most recent:** July 6, 2026 17:30
## Test Output Files (notes/ directory)
### Location: `/home/coding/pdftract/notes/`
The `notes/` directory contains diagnostic output files from test runs and CLI invocations. These are more comprehensive and user-readable than the build stderr files.
**Most recent diagnostic file:** `/home/coding/pdftract/notes/bf-677eo-output.txt`
- **File size:** 104K (104,000+ bytes)
- **Last modified:** July 6, 2026 16:36
- **Contents:** Full compiler output with warnings, dead code analysis, and cfg condition checks
**Other diagnostic files found:**
- `bf-5ucbr-pdftract-debug-output.json` - JSON debug output from pdftract CLI
- `bf-694ie-extract.log` - Extraction operation log
- `bf-694ie-help.log` - CLI help output log
- `bf-3j4ec-*.txt` - Multiple output format test files (text, ndjson, json)
## Key Findings
1. **Build stderr files** are small (usually 0 bytes, 760 bytes when non-empty) and contain compiler warnings
2. **Test output files** in `notes/` are much larger (up to 104K) and contain comprehensive diagnostic information
3. **File naming pattern:** Build stderr uses crate-HASH directory, test outputs use bead-ID prefix
4. **Most recent diagnostic:** `bf-677eo-output.txt` (104K, July 6, 2026 16:36)
## Access Patterns
### For build diagnostics:
```bash
# Find most recent non-empty stderr files
find /home/coding/pdftract/target/debug/build -name "stderr" -size +0c -exec ls -lth {} \; | head -10
```
### For test outputs:
```bash
# Find most recent diagnostic files
ls -lht /home/coding/pdftract/notes/*.log /home/coding/pdftract/notes/*output* 2>/dev/null | head -10
```
## Recommendations
1. The `notes/` directory appears to be the primary location for comprehensive test diagnostic outputs
2. Build stderr files are useful for tracking compiler warnings across build iterations
3. Test output files in `notes/` are substantially larger and more detailed than build diagnostics

100
notes/bf-igsqf.md Normal file
View file

@ -0,0 +1,100 @@
# Bead bf-igsqf: Synchronize GitHub to match Forgejo
## Investigation Summary
### Current State
- **Forgejo main**: `fc88f570` (latest)
- **GitHub main**: `88b4f0da` (309 commits behind)
- GitHub has 0 divergent commits (Forgejo is purely ahead)
### Blocker Discovered: Large Files in Git History
The push to GitHub is **blocked by large files** in commit history:
| File | Size | Status |
|------|------|--------|
| `--1.ppm` | 235.13 MB | Removed in commit 007439e7 but exists in history |
| `test_parse_simple` | 60.74 MB | Removed in commit 007439e7 but exists in history |
GitHub's pre-receive hook rejects any push containing files >100MB in the entire history, even if those files were later deleted.
### Error Output
```
remote: error: File --1.ppm is 235.13 MB; this exceeds GitHub's file size limit of 100.00 MB
remote: error: GH001: Large files detected. You may want to try Git Large File Storage
remote: error: File test_parse_simple is 60.74 MB; larger than recommended 50.00 MB
remote: error: Trace: f338a08cfb9744b571b78169e74d313ba22fced9e24079fc169da8702d9b41b4
To https://github.com/jedarden/pdftract.git
! [remote rejected] main -> main (pre-receive hook declined)
```
### Root Cause
The files `--1.ppm` (235MB) and `test_parse_simple` (60MB) were committed to the repository (likely as test fixtures) and later removed in commit `007439e7 chore(bf-a8031): remove tracked debug/scratch artifacts and compiled binaries`. However, git history retains all objects, so GitHub still sees them when pushing.
### Parent Mirror Configuration (bf-10182)
The parent bead `bf-10182` was about configuring a Forgejo server-side push mirror to GitHub. Without API access, I cannot verify if this mirror is configured and active. If the mirror is properly configured on Forgejo, it may handle large file filtering differently than direct git push.
## Acceptance Criteria Status
| Criterion | Status | Notes |
|-----------|--------|-------|
| GitHub main equals forgejo/main | **FAIL** | Blocked by large files in git history |
| Any divergence reconciled with merge commit | N/A | No divergent commits (GitHub is purely behind, no fork) |
| No force-push performed | **PASS** | Attempted regular fast-forward push |
| Reconciliation documented | **PASS** | This note |
## Resolution Options
To complete the synchronization, one of these approaches must be taken:
### Option 1: Git History Rewrite (Recommended)
Use `git filter-repo` or BFG Repo-Cleaner to remove large files from git history:
```bash
# Install git-filter-repo
pip install git-filter-repo
# Remove the large files from history
git filter-repo --invert-paths --path --1.ppm --path test_parse_simple
# Force push to GitHub (required after history rewrite)
git push github main --force
```
**Trade-off**: This rewrites commit hashes from the rewrite point onward, which would require re-syncing Forgejo's mirror configuration.
### Option 2: Configure Git LFS Going Forward
Add large files to Git LFS and clean up history:
1. Set up `.gitattributes`:
```
*.ppm filter=lfs diff=lfs merge=lfs -text
test_parse_simple filter=lfs diff=lfs merge=lfs -text
```
2. Migrate existing large files (if any still exist)
3. Rewrite history to move LFS objects
### Option 3: Forgejo Server-Side Mirror with LFS Filtering
If the Forgejo push mirror (from bf-10182) can be configured to handle LFS or filter large files, this would be the cleanest solution. However, without API access, I cannot verify or configure this.
## WARN Items
1. **GitHub remains 309 commits behind Forgejo** due to large file blocker
2. **No force-push was performed** (per workspace convention)
3. **Git history cleanup required** before synchronization can complete
4. **Cannot verify Forgejo push mirror status** without API access token
## Recommendation
Create a follow-up bead to:
1. Rewrite git history using `git filter-repo` to remove large files
2. Update Forgejo push mirror configuration if needed
3. Re-attempt synchronization after cleanup
---
**Verification performed**: 2026-07-06
**Bead ID**: bf-igsqf
**Status**: PARTIAL (blocked by infrastructure constraint - large files in git history)