Created attachment 468610 [details] New ebuild Facebook block old versions of protocol. Caused outage on facebook protocol. Changed MQTT user agent solved issue. Ticket #306 https://github.com/dequis/purple-facebook/issues/306 Version release notes: https://github.com/dequis/purple-facebook/releases/tag/v0.9.2-c9b74a765767 Changelog in ebuild: Changed Homepage Facebook protocol plugin for libpurple (moved from jgeboski/purple-facebook) Changed SRC_URI
Not a new package, but I can confirm that updating the version (while keeping the rest of the ebuild the same as in the tree) works for me
Created attachment 468612 [details] purple-facebook-20170329.ebuild Change name of attachment and modify header to: # Copyright 1999-2017 Gentoo Foundation
Just wondering, is there some reason to stick with date versioning when upstream appears to have started actually publishing real version numbers? Your most recent attachment is named 20170329, but upstream has a tarball called 0.9.2.
Vojtech, thank you for your contribution to Gentoo Linux :) This is in the tree now. Christopher, because the upstream versioning still includes a git tag (random alphanumeric digits) we cannot express it with standard ebuild versions.
(In reply to Tony Vroon from comment #4) > Vojtech, thank you for your contribution to Gentoo Linux :) > This is in the tree now. > > Christopher, because the upstream versioning still includes a git tag > (random alphanumeric digits) we cannot express it with standard ebuild > versions. Sorry, I’m not sure I understand that logic. The ebuild already strips the Git commit ID out in SRC_URI, leaving only ${P}.tar.gz as the distfile name. So since upstream claims to call this 0.9.2, why shouldn’t we? I guess it doesn’t really matter. Just curious really.
(In reply to Christopher Head from comment #5) > (In reply to Tony Vroon from comment #4) > > Vojtech, thank you for your contribution to Gentoo Linux :) > > This is in the tree now. > > > > Christopher, because the upstream versioning still includes a git tag > > (random alphanumeric digits) we cannot express it with standard ebuild > > versions. > > Sorry, I’m not sure I understand that logic. The ebuild already strips the > Git commit ID out in SRC_URI, leaving only ${P}.tar.gz as the distfile name. > So since upstream claims to call this 0.9.2, why shouldn’t we? I guess it > doesn’t really matter. Just curious really. Or is is that you expect them to release a whole bunch of different things called 0.9.2, simply because they happened to leave the commit ID in there as part of the filename?
(In reply to Christopher Head from comment #6) > (In reply to Christopher Head from comment #5) > > (In reply to Tony Vroon from comment #4) > > > Vojtech, thank you for your contribution to Gentoo Linux :) > > > This is in the tree now. > > > > > > Christopher, because the upstream versioning still includes a git tag > > > (random alphanumeric digits) we cannot express it with standard ebuild > > > versions. > > > > Sorry, I’m not sure I understand that logic. The ebuild already strips the > > Git commit ID out in SRC_URI, leaving only ${P}.tar.gz as the distfile name. > > So since upstream claims to call this 0.9.2, why shouldn’t we? I guess it > > doesn’t really matter. Just curious really. > > Or is is that you expect them to release a whole bunch of different things > called 0.9.2, simply because they happened to leave the commit ID in there > as part of the filename? When i was testing this build like version 0.9.2 emerge consider it like downgrade. I apologize but i didn't know what change to get it worked.
Yes, that is an unfortunate side effect with projects that change their version numbering scheme. Also 0.9.3 is now out which seems to fix failing to download offline messages for me. I guess a new bug, since this one is closed?
(In reply to Christopher Head from comment #8) > Yes, that is an unfortunate side effect with projects that change their > version numbering scheme. Also 0.9.3 is now out which seems to fix failing > to download offline messages for me. I guess a new bug, since this one is > closed? This is new bug caused with this change. I already release ebuild version 0.9.3 https://bugs.gentoo.org/show_bug.cgi?id=614516
Moved again by the looks of it to https://github.com/dequis/purple-facebook . Appearance of issue https://github.com/dequis/purple-facebook/issues/306 has been plaguing me recently. Have left a note with willikins on IRC for @Tony regarding the possibility of a live [-9999] ebuild to keep up with changes faster :]
(In reply to Michael Everitt (IRC: veremit) from comment #10) > Moved again by the looks of it to https://github.com/dequis/purple-facebook . > > Appearance of issue https://github.com/dequis/purple-facebook/issues/306 has > been plaguing me recently. > > Have left a note with willikins on IRC for @Tony regarding the possibility > of a live [-9999] ebuild to keep up with changes faster :] Apologies - scratch that, just found bug 614516 !
