| Summary: | net-misc/cgminer-3.8.1 version bump | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | kuzetsa CatSwarm (kuza for short) <kuzetsa> |
| Component: | Current packages | Assignee: | Regna <ki> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | blueness, proxy-maint |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | cgminer-3.8.1.ebuild | ||
Technically, there has been initial support since 3.7.x for: $(use_enable knc), but this driver is intended to be used for the embedded linux device (non-x86) built into the unit. Similar use case for the new cgminer 3.8.1 support for the bab (blackarrow) hardware, and the upcoming hashfast hardware... I thought it'd be best I ask, just to be sure: Would it even be appropriate to add any of these since the current ebuild only supports x86 and amd64? (In reply to Sarah White from comment #1) > Technically, there has been initial support since 3.7.x for: $(use_enable > knc), but this driver is intended to be used for the embedded linux device > (non-x86) built into the unit. Similar use case for the new cgminer 3.8.1 > support for the bab (blackarrow) hardware, and the upcoming hashfast > hardware... > > I thought it'd be best I ask, just to be sure: > > Would it even be appropriate to add any of these since the current ebuild > only supports x86 and amd64? This ebuild also tested with and supports arm (at least raspberry pi with bitfury ASICs). Can't say anything about knc/klondike/avalon, since I don't have any. I probably should update the keywords. (In reply to Regna from comment #2) > This ebuild http://bakka.su/git/baka-bakka/tree/net-misc/cgminer/cgminer-3.7.2.ebuild (In reply to Sarah White from comment #1) > Technically, there has been initial support since 3.7.x for: $(use_enable > knc), but this driver is intended to be used for the embedded linux device > (non-x86) built into the unit. Similar use case for the new cgminer 3.8.1 > support for the bab (blackarrow) hardware, and the upcoming hashfast > hardware... > > I thought it'd be best I ask, just to be sure: > > Would it even be appropriate to add any of these since the current ebuild > only supports x86 and amd64? Ask conman in #cgminer/freenode. Upstream told me that not to include the new embedded drivers yet. If anyone has the embedded hardware and tests it, I'll be happy to add the drivers and the keywording for the corresponding arch. I'll test your ebuild in a bit and push it to the tree if its okay. Thanks! (In reply to Anthony Basile from comment #4) > (In reply to Sarah White from comment #1) > > Technically, there has been initial support since 3.7.x for: $(use_enable > > knc), but this driver is intended to be used for the embedded linux device > > (non-x86) built into the unit. Similar use case for the new cgminer 3.8.1 > > support for the bab (blackarrow) hardware, and the upcoming hashfast > > hardware... > > > > I thought it'd be best I ask, just to be sure: > > > > Would it even be appropriate to add any of these since the current ebuild > > only supports x86 and amd64? > > Ask conman in #cgminer/freenode. Upstream told me that not to include the > new embedded drivers yet. If anyone has the embedded hardware and tests it, > I'll be happy to add the drivers and the keywording for the corresponding > arch. > > I'll test your ebuild in a bit and push it to the tree if its okay. Thanks! Thanks Anthony, it's confirmed: [14:55:04] <conman> kuzetsa, knc and bab are for embedded hardware only Okay its in the tree. Only difference between yours and what's in the tree is that I added bitfury since I had it in version 3.7.2. (In reply to Regna from comment #2) > (In reply to Sarah White from comment #1) > > Technically, there has been initial support since 3.7.x for: $(use_enable > > knc), but this driver is intended to be used for the embedded linux device > > (non-x86) built into the unit. Similar use case for the new cgminer 3.8.1 > > support for the bab (blackarrow) hardware, and the upcoming hashfast > > hardware... > > > > I thought it'd be best I ask, just to be sure: > > > > Would it even be appropriate to add any of these since the current ebuild > > only supports x86 and amd64? > > This ebuild also tested with and supports arm (at least raspberry pi with > bitfury ASICs). Can't say anything about knc/klondike/avalon, since I don't > have any. > > I probably should update the keywords. Okay I'm adding arm. despite this bug report & the ebuild I submitted, somebody appears to have erroneously commited a different ebuild to the portage tree with the line: ln -s /usr/include/ADL/* ADL_SDK/ inside the function src_prepare, even though cgminer no longer supports ADL (as this feature is related to GPU monitoring, and no longer included in the upstream autotools configure scripts or the USE flags for this ebuild) When I created this bug, I wasn't so much concerned with version bump, but explicitly used the subject: "net-misc/cgminer upstream support removal for GPUs (incl. scrypt)" (In reply to Sarah White from comment #9) > despite this bug report & the ebuild I submitted, somebody appears to have > erroneously commited a different ebuild to the portage tree with the line: > > ln -s /usr/include/ADL/* ADL_SDK/ > > inside the function src_prepare, even though cgminer no longer supports ADL > (as this feature is related to GPU monitoring, and no longer included in the > upstream autotools configure scripts or the USE flags for this ebuild) > > When I created this bug, I wasn't so much concerned with version bump, but > explicitly used the subject: > > "net-misc/cgminer upstream support removal for GPUs (incl. scrypt)" The ChangeLog show that I committed the ebuild. The bug summary was changed before I saw the bug. The issue is fixed in the tree. |
Created attachment 363072 [details] cgminer-3.8.1.ebuild This updated ebuild is the one from my local overlay with support for building the 3.8.x branches of cgminer without GPU / scrypt support. The upstream developers have removed this functionality in the past 72 hours, so versions after 3.7.x will need to be based on this type of ebuild.