Re: [gentoo-dev] Last rites: net-wireless/yatebts, net-wireless/srslte, net-wireless/nanovna-saver, net-wireless/gr-scan
On Mon, Mar 21, 2022 at 02:50:36PM +0100, Jakov Smolić wrote: > > > On 3/21/22 2:38 PM, tom...@gentoo.org wrote: > > On Sun, Mar 20, 2022 at 06:48:55PM +0100, David Seifert wrote: > >> On Sun, 2022-03-20 at 18:44 +0100, tom...@gentoo.org wrote: > >>> I would like to keep net-wireless/nanovna-saver. I pushed version > >>> 0.3.10 to > >>> the tree which should fix the problems. > >>> > >>> Shall I drop it from package mask or do you want to do it yourself > >>> Jakov. > >>> > >>> - Thomas > >>> > >>> > >>> On Wed, Mar 16, 2022 at 11:08:05PM +0100, Jakov Smolić wrote: > # Jakov Smolić (2022-03-16) > # Unmaintaned, broken packages with no revdeps. > # Bugs 822234, 809539, 809536, 832618, 731720, 713684, > # 733662, 741082, and many others. > # Removal on 2022-04-16. > net-wireless/yatebts > net-wireless/srslte > net-wireless/nanovna-saver > net-wireless/gr-scan > -- > Jakov > >>> > >> > >> Your new ebuild still doesn't support python 3.10, without which it > >> would be lagging again. > >> > > > > See the following commit: > > > > commit 725073832253187b4183b0ddaa1672451e66ae49 (HEAD -> master, > > origin/master, origin/HEAD) > > Date: Mon Mar 21 14:31:09 2022 +0100 > > net-wireless/nanovna-saver: enable py3.10, add USE deps and tests > > > > Besides the deprecation warning for setuptools in Py3.12 it Works with > > Py3.10 like a charme. > > version still suffers from the same issues mentioned previously, > could you update it or alternatively remove it (along with the old version)? > Feel free to unmask it after it's fixed. > Also, given that the package was de-facto unmaintained, I'd suggest that > you add yourself to metadata.xml if you're interested in it to prevent > something like this happening in the future. > > > -- > Jakov > Done. Thanks for help. -- Thomas signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: net-wireless/yatebts, net-wireless/srslte, net-wireless/nanovna-saver, net-wireless/gr-scan
On Sun, Mar 20, 2022 at 06:48:55PM +0100, David Seifert wrote: > On Sun, 2022-03-20 at 18:44 +0100, tom...@gentoo.org wrote: > > I would like to keep net-wireless/nanovna-saver. I pushed version > > 0.3.10 to > > the tree which should fix the problems. > > > > Shall I drop it from package mask or do you want to do it yourself > > Jakov. > > > > - Thomas > > > > > > On Wed, Mar 16, 2022 at 11:08:05PM +0100, Jakov Smolić wrote: > > > # Jakov Smolić (2022-03-16) > > > # Unmaintaned, broken packages with no revdeps. > > > # Bugs 822234, 809539, 809536, 832618, 731720, 713684, > > > # 733662, 741082, and many others. > > > # Removal on 2022-04-16. > > > net-wireless/yatebts > > > net-wireless/srslte > > > net-wireless/nanovna-saver > > > net-wireless/gr-scan > > > -- > > > Jakov > > > > Your new ebuild still doesn't support python 3.10, without which it > would be lagging again. > See the following commit: commit 725073832253187b4183b0ddaa1672451e66ae49 (HEAD -> master, origin/master, origin/HEAD) Date: Mon Mar 21 14:31:09 2022 +0100 net-wireless/nanovna-saver: enable py3.10, add USE deps and tests Besides the deprecation warning for setuptools in Py3.12 it Works with Py3.10 like a charme. -- Thomas
Re: [gentoo-dev] Last rites: net-wireless/yatebts, net-wireless/srslte, net-wireless/nanovna-saver, net-wireless/gr-scan
On Sun, Mar 20, 2022 at 06:48:55PM +0100, David Seifert wrote: > On Sun, 2022-03-20 at 18:44 +0100, tom...@gentoo.org wrote: > > I would like to keep net-wireless/nanovna-saver. I pushed version > > 0.3.10 to > > the tree which should fix the problems. > > > > Shall I drop it from package mask or do you want to do it yourself > > Jakov. > > > > - Thomas > > > > > > On Wed, Mar 16, 2022 at 11:08:05PM +0100, Jakov Smolić wrote: > > > # Jakov Smolić (2022-03-16) > > > # Unmaintaned, broken packages with no revdeps. > > > # Bugs 822234, 809539, 809536, 832618, 731720, 713684, > > > # 733662, 741082, and many others. > > > # Removal on 2022-04-16. > > > net-wireless/yatebts > > > net-wireless/srslte > > > net-wireless/nanovna-saver > > > net-wireless/gr-scan > > > -- > > > Jakov > > > > Your new ebuild still doesn't support python 3.10, without which it > would be lagging again. > I know. That was by indention. I just wanted to be sure that the other bugs are gone before starting to test with python 3.10. I think i can test it tommorow. --
Re: [gentoo-dev] Last rites: net-wireless/yatebts, net-wireless/srslte, net-wireless/nanovna-saver, net-wireless/gr-scan
I would like to keep net-wireless/nanovna-saver. I pushed version 0.3.10 to the tree which should fix the problems. Shall I drop it from package mask or do you want to do it yourself Jakov. - Thomas On Wed, Mar 16, 2022 at 11:08:05PM +0100, Jakov Smolić wrote: > # Jakov Smolić (2022-03-16) > # Unmaintaned, broken packages with no revdeps. > # Bugs 822234, 809539, 809536, 832618, 731720, 713684, > # 733662, 741082, and many others. > # Removal on 2022-04-16. > net-wireless/yatebts > net-wireless/srslte > net-wireless/nanovna-saver > net-wireless/gr-scan > -- > Jakov > --
[gentoo-dev] Last rites: sci-electronics/linsmith
# Thomas Beierlein (2020-09-09) # Depends on obsolete gnome-base/libgnomeui. # Upstream promised to have a better version # for nearly a year now, but no release in sight. # Masked for removal in 30 days. sci-electronics/linsmith Best regards, Thomas Beierlein -- signature.asc Description: PGP signature
[gentoo-dev] [RFC] UID/GID assignment for app-backup/bacula (273)
Hi, I would like to reserve UID/GID 273 for app-backup/bacula. Fedora uses 133 for it but that is occupied by rtkit here. FreeBSD recommends 1002 but that is out of question for us. According to uid-gid.txt 273 should be free. Regards, Thomas. --
[gentoo-dev] Last rites: media-radio/tucnak2
# Thomas Beierlein (22 Dec 2017) # Development moved to another naming scheme. # Use media-radio/tucnak instead. # Masked for removal in 30 days. media-radio/tucnak2
[gentoo-dev] Last rites: media-radio/wspr
# Thomas Beierlein (10 Dec 2017) # Development stopped, nasty build system. # Functionality superseded by media-radio/wsjtx. # Masked for removal in 30 days. media-radio/wspr
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
Quoting Thomas Beierlein (2017-08-14 21:58:42)
> Bacula ebuilds uses some weird USE flags with mostly negative
> logic ('do not build ..') coming from their build system.
>
> With the actual major release (bacula-9.0.3) we should try to switch to
> something more sane. I picked up the new flags from app-backup/bareos as
> both ebuilds have a common anchestry.
>
> Please comment on the proposed news item.
>
> Thanks,
> Thomas
>
First thanks to all who commented and gave wise advices.
As I see it the discussion boils down to the following new behaviour:
* There will be two USE flags 'director' and 'storage-daemon' which are on by
default and control the installation of the backup director component
and the storage daemon accordingly.
* If both flags are unset neither component gets installed. Only the set of
files for the file daemon (Client) gets installed - mimicking the
former 'clientonly' behaviour. The old 'bacula-clientonly' flag gets dropped
completely.
It will require quite some changes to the ebuild and due to its complexity
also some tests. As I have only three days left to holiday I will suspend the
switch to the new USE flag settings for now.
To let users no longer wait for the actual 9.0.3 version (which is out for
already 2 weeks now) I would like to bring it into the tree with the old USE
flag settings. The switch to the new one will then be made after returning
from my holiday vacation.
Comments?
Best regards,
Thomas.
Re: [gentoo-dev] Re: [FRC] News item: Changing USE flags for >=app-backup/bacula
Quoting Duncan (2017-08-16 03:45:35) > tomjbe posted on Tue, 15 Aug 2017 19:49:33 +0200 as excerpted: > > > think we can find a proper formulation for the use flag description in > > metadata.xml, e.g.: > > > > director - Installs the backup director additional to the default file > > daemon. > > storage-daemon - Installs the storage daemon additional to the default > > file daemon > > FWIW, "additional to" is understandable, but AFAIK nonstandard (sounds > like ESL/English-as-a-second-language, using grammar from the first). > > The phrase "in addition to" works much better to my eye/ear. > Thanks for the hint. I was not sure which one is better. Thomas.
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
Quoting Rich Freeman (2017-08-15 14:16:14) > On Tue, Aug 15, 2017 at 5:19 AM, wrote: > > Quoting Michał Górny (2017-08-15 08:43:07) > >> On wto, 2017-08-15 at 06:55 +0200, tom...@gentoo.org wrote: > >> > Quoting Rich Freeman (2017-08-15 00:29:19) > >> > > > >> > > I guess to make it a bit more explicit, would it make sense to have 3 > >> > > flags: > >> > > > >> > > client - install the client (or consider calling it file-daemon > >> > > instead) > >> > > director - install the director > >> > > storage-daemon - install the storage daemon > >> > > > >> > > >> > That would be best, but it is not supported by their (autoconf based) > >> > build > >> > system (and would require a complete rewrite of it). The actual USE flags > >> > mostly mirrors the switches from the configure script. You can not set > >> > them as > >> > you like, they are not orthogonal E.g. the file deamon (client) will be > >> > installed unconditionally. > >> > > >> > The configure script itself is very brittle atm and needs an urgent > >> > overhaul. > >> > Discussion with upstream goes a long way, but they do not want to change > >> > it > >> > because of the need to retest it on very different systems. No good > >> > situation. > >> > > >> > A possible idea may be to drop the 'no/client' flag completely. If > >> > neither > >> > 'director' nor 'storage-daemon' is active all that is left would be the > >> > file daemon. > >> > What do you think? > >> > >> WFM. If the flag doesn't do anything except for disabling the two other > >> flags, then there's no place for such a flag. > >> > > And here comes the problem. USE="bacula-nodir bacula-nosd" does not produce > > the same set of files as USE="bacula-clientonly". But I will recheck if the > > difference is of relevance for normal gentoo user. > > It is probably worth understanding the difference. However, if the > user sets both -director and -storage-daemon you could also enable > bacula-clientonly, unless there is some reason somebody might want two > of those and not the third. > I just tested the different use flags settings as well as directly the different configure switches. Here is what happens for configure: * Deactivation of storage-daemon drops the related files. * Deactivation of director ist ignored by the build system, the director is build anyway (One more bug in their build system). * Activation of clientonly drops both the related files for director and for storage daemon. The ebuild does fix some of the differences: * +bacula-nodir and +bacula+nosd drops most of the files for these functionality, but keeps some more (mostly irrelevant) files over +bacula-clientonly. So from gentoos point of view having nodir and nosd is nearly the same as having clientonly. That would allow to drop the clientonly flag and keep only the controling flags for director and storage-daemon. > > > >> > > >> > The downside of that idea is that we diverge from baculas documentation > >> > which > >> > explicitly state that there is a 'clientonly' install. > >> > > >> > >> Upstream install documentation is not relevant to Gentoo. The flag > >> descriptions in metadata.xml are. > >> > > Right. But if we drop a "clientonly" than there is no hint in metadata.xml > > how > > to get only the file daemon alone. Some einfo output or similar come to > > mind. > > > > You could use einfo. However, if the docs say what the other two > flags do then it seems pretty obvious that if you turn them both off > you end up with only the file daemon. > I think we can find a proper formulation for the use flag description in metadata.xml, e.g.: director - Installs the backup director additional to the default file daemon. storage-daemon - Installs the storage daemon additional to the default file daemon. Thomas
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
Quoting Kristian Fiskerstrand (2017-08-15 10:37:39) > On 08/15/2017 12:29 AM, Rich Freeman wrote: > > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny wrote: > >> On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote: > >>> * 'bacula-clientonly' becomes 'clientonly' > >> This is still negative logic in disguise. clientonly = noserver. > > Can the "minimum"-use flag be utilized here? > Sounds reasonable and is worth thinking about. At least we could define the meaning of "minimum" here in metadata.xml. But, looking through portage there seems to be no "minimum" use flag anymore. Seems it got dropped for some reasons. Regards, Thomas
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
Quoting Michał Górny (2017-08-15 08:43:07) > On wto, 2017-08-15 at 06:55 +0200, tom...@gentoo.org wrote: > > Quoting Rich Freeman (2017-08-15 00:29:19) > > > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny wrote: > > > > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote: > > > > > > > > > > * 'bacula-clientonly' becomes 'clientonly' > > > > > > > > This is still negative logic in disguise. clientonly = noserver. > > > > True. See below for discussion. > > > > > > > > > * 'bacula-nodir' will be replaced by 'director' but with inverted > > > > > logic > > > > > * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted). > > > > > > > > > > 'director' and 'storage-daemon' will be active by default resulting > > > > > in an > > > > > installation with backup director and storage daemon enabled. > > > > > > > > > > > ++ > > > > > > I guess to make it a bit more explicit, would it make sense to have 3 > > > flags: > > > > > > client - install the client (or consider calling it file-daemon instead) > > > director - install the director > > > storage-daemon - install the storage daemon > > > > > > > That would be best, but it is not supported by their (autoconf based) build > > system (and would require a complete rewrite of it). The actual USE flags > > mostly mirrors the switches from the configure script. You can not set them > > as > > you like, they are not orthogonal E.g. the file deamon (client) will be > > installed unconditionally. > > > > The configure script itself is very brittle atm and needs an urgent > > overhaul. > > Discussion with upstream goes a long way, but they do not want to change it > > because of the need to retest it on very different systems. No good > > situation. > > > > A possible idea may be to drop the 'no/client' flag completely. If neither > > 'director' nor 'storage-daemon' is active all that is left would be the > > file daemon. > > What do you think? > > WFM. If the flag doesn't do anything except for disabling the two other > flags, then there's no place for such a flag. > And here comes the problem. USE="bacula-nodir bacula-nosd" does not produce the same set of files as USE="bacula-clientonly". But I will recheck if the difference is of relevance for normal gentoo user. > > > > The downside of that idea is that we diverge from baculas documentation > > which > > explicitly state that there is a 'clientonly' install. > > > > Upstream install documentation is not relevant to Gentoo. The flag > descriptions in metadata.xml are. > Right. But if we drop a "clientonly" than there is no hint in metadata.xml how to get only the file daemon alone. Some einfo output or similar come to mind. Regards, Thomas
Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
Quoting Rich Freeman (2017-08-15 00:29:19) > On Mon, Aug 14, 2017 at 5:55 PM, Michał Górny wrote: > > On pon, 2017-08-14 at 21:58 +0200, Thomas Beierlein wrote: > >> > >> * 'bacula-clientonly' becomes 'clientonly' > > > > This is still negative logic in disguise. clientonly = noserver. True. See below for discussion. > > > >> * 'bacula-nodir' will be replaced by 'director' but with inverted logic > >> * 'bacula-nosd' will be replaced by 'storage-daemon' (also inverted). > >> > >> 'director' and 'storage-daemon' will be active by default resulting in an > >> installation with backup director and storage daemon enabled. > >> > > ++ > > I guess to make it a bit more explicit, would it make sense to have 3 flags: > > client - install the client (or consider calling it file-daemon instead) > director - install the director > storage-daemon - install the storage daemon > That would be best, but it is not supported by their (autoconf based) build system (and would require a complete rewrite of it). The actual USE flags mostly mirrors the switches from the configure script. You can not set them as you like, they are not orthogonal E.g. the file deamon (client) will be installed unconditionally. The configure script itself is very brittle atm and needs an urgent overhaul. Discussion with upstream goes a long way, but they do not want to change it because of the need to retest it on very different systems. No good situation. A possible idea may be to drop the 'no/client' flag completely. If neither 'director' nor 'storage-daemon' is active all that is left would be the file daemon. What do you think? The downside of that idea is that we diverge from baculas documentation which explicitly state that there is a 'clientonly' install. Thomas.
Re: [gentoo-dev] Package up for grabs
Quoting Daniel Campbell (2017-08-07 22:38:53) > On 08/06/2017 02:27 AM, tom...@gentoo.org wrote: > > Quoting Daniel Campbell (2017-07-31 04:16:30) > >> On 07/19/2017 02:33 AM, Amy Liffey wrote: ... > >> > > Ok, as I have done some quite Forth programming in the past, let me step in. > > > > Thomas > > > > > > > Sounds great. Would you like me to do the honors of updating > metadata.xml later tonight? Yes, please do as suggested. Be aware that I am just to start my holidays in next days. I will be back in mid of september. Then I will be glad to help. Thomas > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 >
Re: [gentoo-dev] Package up for grabs
Quoting Daniel Campbell (2017-07-31 04:16:30) > On 07/19/2017 02:33 AM, Amy Liffey wrote: > > The following package is up for grabs: > > > > dev-lang/gforth > > > > Best regards, > > Amy Liffey > > > I can take this one; I'd hate to see Forth support go missing on Gentoo. > I'm open to co-maintainers as well. > Ok, as I have done some quite Forth programming in the past, let me step in. Thomas > ~zlg > > -- > Daniel Campbell - Gentoo Developer > OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net > fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 >
