for Bug 652926 - net-print/hplip-3.18.6 stable request Please, c.f. info provided in comments 14 / 15 / 16.
Daniel, could you take care of this? Bug 652926 - net-print/hplip-3.18.6 should not have been stabilized before dependant packages have been cared for in concordance ... THANKS a lot! WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: net-print/hplip:0 (net-print/hplip-3.18.6:0/0::gentoo, ebuild scheduled for merge) conflicts with ~net-print/hplip-3.18.5 required by (net-print/hplip-plugin-3.18.5:0/0::gentoo, installed) ^ ^^^^^^
(In reply to Manfred Knick from comment #1) > Daniel, could you take care of this? > > Bug 652926 - net-print/hplip-3.18.6 > should not have been stabilized > before dependant packages have been cared for in concordance ... > > THANKS a lot! > hplip does not depend on hplip-plugin, hplip-plugin depends on hplip. If you take a closer look at the location [1] where hplip-plugin is currently downloaded from you will find that there is no hplip-plugin-3.18.6 as of now. I am not the maintainer of hplip-plugin. Please don't mess with assignees and CC people at will. [1] https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/
(In reply to Daniel Pielmeier from comment #2) > hplip does not depend on hplip-plugin, hplip-plugin depends on hplip. Correct. > If you > take a closer look at the location [1] where hplip-plugin is currently > downloaded from you will find that there is no hplip-plugin-3.18.6 as of now. Correct. That is exactly the reason why hplip should never have been stabilized to 3.18.6. That was not responsible at all: Stabilization to 3.18.5 would have been completely sufficient in order to solve the original problem! Cite: "We don't break ..." ( Linus Torvalds, ... ) > I am not the maintainer of hplip-plugin. ===================== But _you_ "broke" it - unnecessarily. ===================== Now users do have to place entries into package.mask etc. in order to get a clean emerge unitl net-print/hplip-plugin-3.18.6 version bump arrives in tree. > Please don't mess with assignees > and CC people at will. Originally, in accordance with earlier bugs concerning this package, I assigned my OP to "Printing Team": c.f. "History" [https://bugs.gentoo.org/show_activity.cgi?id=658480] It was _your_ lonely hurry in Bug 652926, stabilizing net-print/hplip-3.18.6 without caring for the consequences, which made me ask you very politely: > Daniel, could you take care of this? > > Bug 652926 - net-print/hplip-3.18.6 > should not have been stabilized > before dependant packages have been cared for in concordance ... > > THANKS a lot! Moreover, I have provided all necessary background information. Sorry - but who is the one playing "at will" ? So I do ask you to take over your responsibility - and yes, I do request you being CC'ed until this issue created by you has been solved. My proposal: - redraw stabilization of hplip to 3.18.5 and - stabilize net-print/hplip-3.18.5 in due accordance - until net-print/hplip-3.18.6 arrives in Main Portage Tree - then stabilize both to 3.18.6 in due accordance. Just my 2 cents of thought ... Kind regards Yours respectfully Manfred P.S.: I don't depend neither on hplip nor on hplip-plugin any more - just my courtesy for all those many people who bitterly do.
The needed version has been released upstream: [ ] hplip-3.18.6-plugin.run 25-Jun-2018 14:21 [TXT] hplip-3.18.6-plugin.run.asc 25-Jun-2018 14:21 [ https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ ] CONFIRMATION: WORKSFORME Copy-rename to hplip-plugin-3.18.6.ebuild into my local overlay was sufficient, as expected. Digest succeeds, emerge builds both without any error: >>> Installing (1 of 2) net-print/hplip-3.18.6::gentoo >>> Installing (2 of 2) net-print/hplip-plugin-3.18.6::mkn_local_overlay PROPOSAL: Please, stabilize both to 3.18.6 in due accordance. Thanks.
(In reply to Manfred Knick from comment #3) Manfred, normally I try to stay calm but this is getting annoying. Please stop this nonsense. I do not owe you anything. Every minute I spend on Gentoo I do as volunteer the same as everybody else here. > (In reply to Daniel Pielmeier from comment #2) > > > hplip does not depend on hplip-plugin, hplip-plugin depends on hplip. > Correct. > > > If you > > take a closer look at the location [1] where hplip-plugin is currently > > downloaded from you will find that there is no hplip-plugin-3.18.6 as of now. > Correct. > > That is exactly the reason why hplip should never have been stabilized to > 3.18.6. That was not responsible at all: > > Stabilization to 3.18.5 would have been completely sufficient > in order to solve the original problem! > > Cite: "We don't break ..." ( Linus Torvalds, ... ) > > > I am not the maintainer of hplip-plugin. > ===================== > But _you_ "broke" it - unnecessarily. > ===================== > > Now users do have to place entries into package.mask etc. > in order to get a clean emerge > unitl net-print/hplip-plugin-3.18.6 version bump arrives in tree. hplip-plugin is not a stable package. So I don't think it should be a problem for users requiring it to add hplip to package.mask in addition to the entry they already need in package.accept_keywords. > > Please don't mess with assignees > > and CC people at will. > Originally, in accordance with earlier bugs concerning this package, > I assigned my OP to "Printing Team": > > c.f. "History" [https://bugs.gentoo.org/show_activity.cgi?id=658480] > > It was _your_ lonely hurry in Bug 652926, > stabilizing net-print/hplip-3.18.6 without caring for the consequences, > which made me ask you very politely: > > > Daniel, could you take care of this? > > > > Bug 652926 - net-print/hplip-3.18.6 > > should not have been stabilized > > before dependant packages have been cared for in concordance ... > > > > THANKS a lot! I did not break anything! If you take a look at bug 652926 you will find that Pacho Ramos converted the compile error into a stable request. I however would have done the same as the plugin is a testing package and probably will remain like this. hplip does not need to take care of hplip-plugin. This is the concept of stable vs. testing. > Moreover, I have provided all necessary background information. > > Sorry - but who is the one playing "at will" ? > > So I do ask you to take over your responsibility - > and yes, I do request you being CC'ed > until this issue created by you has been solved. No, I will not take responsibility because I don't have to for various reasons. I never wanted the plugin in the tree because it only causes trouble for which this is one perfect example. If anybody is responsible than it is the printing team (which I am not a member of) or especially Manuel Rüger (hope you don't get anything wrong here) who added the package. However in such cases only if hplip-plugin should become stable he needs to take care that there is a fitting stable version of hplip. For a testing version of hplip-plugin he only needs a testing version of hplip. The only thing I need to take care of and this is something I sometimes forget is that I should not remove versions of hplip without removing also the plugin or removing the latest version of hplip which is required by the plugin. I think I have improved on that though. Maybe you have to much power at this bug tracker and you're rights need to be restricted because in opinion your behavior is not appropriate. > My proposal: > > - redraw stabilization of hplip to 3.18.5 and > > - stabilize net-print/hplip-3.18.5 in due accordance > > - until net-print/hplip-3.18.6 arrives in Main Portage Tree I do not think this will happen! > - then stabilize both to 3.18.6 in due accordance. The plugin is not stable, was never stable and if it were me never should be! > Just my 2 cents of thought ... > > > Kind regards > Yours respectfully > Manfred Sorry but I somehow do not believe you. > > P.S.: > I don't depend neither on hplip nor on hplip-plugin any more - > just my courtesy for all those many people who bitterly do. But then why are you the only one making such a fuss about this? There was a little chance that I will take care of this but it is now gone. This is my last comment on this bug. I shouldn't have spent so much time on this anyway but some things need to be said.
(In reply to Daniel Pielmeier from comment #5) > Every minute I spend on > Gentoo I do as volunteer the same as everybody else here. So do I (~15y). > that Pacho Ramos converted the compile error into a stable request. for 3.18._4_ <---! > Sorry but I somehow do not believe you. Sad. > This is my last comment on this bug. I shouldn't have spent so much time on > this anyway ... Same. This superfluous exaggeration was never intended - c.f. contributions in - comments 9, 11, 14, 15 of Bug 652926 - and comment 4. All the best
(In reply to Daniel Pielmeier from comment #5) > But then why are you the only one making such a fuss about this? A) Because it is no fun at all to get dozens of complaints of customers early in the morning because of irritating warnings B) During the last years, HP buried more and more functionality: "Some HP printers require proprietary software technologies to allow full access to printer features and performance. Unfortunately, these technologies cannot be open sourced, but to resolve this HP uses a binary plug-in for these printers." This started with scanning / faxing support; recently e.g. _the_ mainstream SME line "HP LaserJet Pro MFP" requires it even for *printing* [1] ! This nowadays makes a timely version update of hplip-plugin and a co-coordinated version treatment important. > I never wanted the plugin in the tree @ Printing Team: Users don't get any warning about this disagreement behind the curtains. I still cannot comprehend what should prohibit - early provisioning of "~" hplip version bumps, but - postponing stabilization for those few days until the corresponding hplip-plugin is available. [1] "What is the HPLIP Binary Plug-In ..." https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html [2] Manuel's clarification in Bug 631198 - net-print/hplip-plugin-3.17.6 should not depend on a specific version of net-print/hplip? "No it should. Otherwise hplip will try to fetch the correct version." https://bugs.gentoo.org/631198#c2
Created attachment 537542 [details] copy-rename from 3.18.5 to 3.18.6 was sufficient and WORKSFORME
*** Bug 678050 has been marked as a duplicate of this bug. ***
Can we tie version bump of net-print/hplip-plugin to net-print/hplip. It will save effort and time of everybody.
(In reply to email200202 from comment #10) > Can we tie version bump of net-print/hplip-plugin to net-print/hplip. It > will save effort and time of everybody. Unfortunately, as you can read above and in [ https://bugs.gentoo.org/652926#c20 ] , Daniel strictly refuses to acknowledge the reasoning behind "THE #1 KERNEL RULE" : [ https://lkml.org/lkml/2018/8/3/621 ] [ https://www.lkml.org/lkml/2018/12/22/232 ] I have given up upon this.
In the time being, this is my update command: #!/bin/bash if emerge --sync; then cp -i /usr/portage/net-print/hplip-plugin/hplip-plugin-3.18.12.ebuild /usr/portage/net-print/hplip-plugin/hplip-plugin-3.19.1.ebuild ebuild /usr/portage/net-print/hplip-plugin/hplip-plugin-3.19.1.ebuild digest emerge -auvDN world fi
(In reply to email200202 from comment #12) Are you familiar with Gentoo's concept of a Custom repository? https://wiki.gentoo.org/wiki/Custom_repository esp. https://wiki.gentoo.org/wiki/Custom_repository#Simple_version_bump_of_an_ebuild_in_the_local_repository E.g., create yourself /usr/local/portage/local-overlay/, copy net-print/hplip-plugin into it, copy-rename as proposed by yourself, generate Manifest - and be fine :-)
Yes, I used it for my own packages and out of portage package as permanent solution. I hope this version will be added to portage today. We collectively wasted more time than the time required to fix and close this bug.
I was wrong to assume it will be fixed quickly. I gave up and moved the ebuild to /usr/local/portage/.
okay, just saw that bump has been done already (https://github.com/gentoo/gentoo/commits/d64acf53dbaea549f68daa42913b71babe95af2a) by Manuel Rüger <mrueg@gentoo.org> ~1 week ago, ignoring completely this bug and the PR (https://github.com/gentoo/gentoo/pull/12187)… community driven? bug tracker ? what's the use of it?
upps - sorry, last comment was concering https://bugs.gentoo.org/684428 anyway i think we can close this ?
