[gentoo-dev] Last rites: net-wireless/gr-iio
# Thomas Beierlein (2023-05-17) # Functionality got integrated into >=net-wireless/gnuradio-3.10 # itself. See # https://wiki.analog.com/resources/tools-software/linux-software/gnuradio # Removal on 2023-06-17. Bug #897168. net-wireless/gr-iio
[gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula
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
--
Title: Changing USE flags for >=app-backup/bacula-9.0.3
Author: Thomas Beierlein <tom...@gentoo.org>
Content-Type: text/plain
Posted: 2017-08-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed:
Re: [gentoo-dev] January stabilization candidates
On Sat, 12 Jan 2013 14:49:52 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Please review attached automatically generated stabilization candidates for January. # tomjbe media-libs/hamlib-1.2.15.3 media-radio/tlf-1.1.5 media-radio/xastir-2.0.4 are good to go. I put stable requests in bugzi already. Thanks for reminding Paweł. Thomas --
Re: [gentoo-dev] New herd: radio
On Thu, 05 Jul 2012 23:58:02 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Hello all, The new radio herd will maintain packages related to sending and receiving of radio transmissions. Currently, these are GNU Radio and some packages from the Osmocom/SDR project. The initial members are zerochaos, creffett and me, but anybody is free to join. Very well. Please count me in. Just added myself to the mail alias. Regards, Thomas.
Re: [gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 01 Mar 2012 22:17:12 + Markos Chandras hwoar...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Due to lack of time and motivation, the following packages are up for grabs: sci-electronics/gresistor Put it to herd sci-electronics. We will care. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk9UZ0oACgkQQe4uqXYgU9XGqgCfSlCCJevf5IfBNiMVjWeNtC5b hegAoJ/L2u7NZ5llphs+LsR1mJ8CiSEc =79qk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-electronics/gtkwave: ChangeLog gtkwave-3.3.28.ebuild
On Sun, 8 Jan 2012 13:55:17 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Sun, 8 Jan 2012 16:22:24 + (UTC) Thomas Beierlein (tomjbe) tom...@gentoo.org wrote: tomjbe 12/01/08 16:22:24 Modified: ChangeLog Added:gtkwave-3.3.28.ebuild Log: Strip flags (bug #377935). Version bump. Drop old unstable versions Please avoid doing this unless your package fails with basic (supported) flags, or flags that are common enough that a lot of people are hitting it. -floop-parallelize-all is neither of these and in this case is causing an ICE (internal compiler error) that needs to be fixed, not wallpapered over. Sorry, my fault! You are right. I was looking for sci-electronics bugs to fix and did not recognize that it was assigned to toolchain. Thanks for catching it. Thomas. --
Re: [gentoo-dev] Lastrite: media-radio/fldigi (unless patched for fltk-1.3)
On Fri, 23 Dec 2011 01:59:54 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (23 Dec 2011) # Missing fltk-1.3 support and forced downgrade of fltk # in the same stabilization level which makes this gentoo-x86 # incompatible package. Bug 395747. Removal in 30 days. media-radio/fldigi Dropped the mask as fldigi-3.21.35_pre1 (in tree) supports fltk-1.3 as well as fltk-1.1 Thomas --
Re: [gentoo-dev] rfc: news item for app-backup/bacula
On Sat, 31 Dec 2011 08:56:03 -0600 William Hubbs willi...@gentoo.org wrote: On Fri, Dec 30, 2011 at 10:11:58AM +0100, Michał Górny wrote: On Fri, 30 Dec 2011 09:56:33 +0100 Thomas Beierlein tom...@gentoo.org wrote: The 5.2.x release series of Bacula uses a new database catalog format. ^^^ use (singular) No, uses is correct here. OK. Thanks for the hint. I will change it back to 'uses'. Thomas William -- signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: news item for app-backup/bacula
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 30 Dec 2011 12:02:09 -0500 Jonathan Callen a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/30/2011 06:09 AM, Thomas Beierlein wrote: On Fri, 30 Dec 2011 11:44:23 +0100 Michał Górny mgo...@gentoo.org wrote: On Fri, 30 Dec 2011 10:43:31 +0100 Thomas Beierlein tom...@gentoo.org wrote: 4. Run the appropriate upgrade script from /usr/libexec/bacula/updatedb/. 7. Start the new Bacula. You still miss steps 5 and 6 ;P. Oh, oh. Now I read your last line from former mail right. Corrected, thanks again. Thomas Title: Bacula-5.2.3 Upgrade Author: Thomas Beierlein tom...@gentoo.org Content-Type: text/plain Posted: 2011-12-30 Revision: 3 This should remain as Revision: 1 until actually committed to svn. Ok, thanks. It was not so clear from reading the GLEP. News-Item-Format: 1.0 Display-If-Installed: app-backup/bacula-5.2.0 You need to drop the quotes here. Done. Regards, Thomas The 5.2.x release series of Bacula use a new database catalog format. If you're upgrading from a 3.x.x or 5.0.x release, you must upgrade your bacula catalog database. Please read the manual chapter for how to upgrade your database (see http://www.bacula.org/5.2.x-manuals/en/main/main/Installing_Bacula.html). You can find database upgrade scripts in /usr/libexec/bacula/(updatedb/). It is strongly recommended that you save a copy of your existing database before upgrading. For details how to do it please look into your database documentation. The simplest way to upgrade the database: 1. Stop Bacula from running (at least the director and storage daemons). 2. Save a copy of your existing database. 3. Emerge the new version of Bacula. 4. Run the appropriate upgrade script from /usr/libexec/bacula/updatedb/. 5. Start the new Bacula. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJO/e6RAAoJELHSF2kinlg4b/IP/jrMPdNAz0eqQDi4jPtQoef5 prG0NwfpnSfKq0vTCf+CS+tSezGgrn2GsnfAp+GFngEPAed8zZlylGsViusQjR5w uOPkLlaYwGiKzlUjoronqm83GLbGRw2IZJuxr96t6wsk2PWMSIs4SLLDRRoA8Lis /yZ6YtuWpkaxqdtR7GIwpW2uTK7b0L7LSR1UyIe7YO5bTQ3wlLVneysxfcNadNAh JrT1Hi1oGR/SRtWP/J43M26mpTSibqaJjE9vU+4/UVUApquKUB/Cw8x6lPgh/hZz 1JemFwHWeozIr6zUu0OOoqI3oN4nkO7cFyqVcZYezx5WEuaEK+NFLiNIrqFQFyyQ uPYgKCXFmW32rhWXKVeIYNjTiX9RYrFsEUnyTOKltD5s2sGMYd0xiplYAPZDml3n ZUTU/swMp469N5qaYq1XNrpM0GE1QztG0/Le6lvngkSIo59j330d4VsvYT410jdl +AmFaVuTFVfvRl3A7f1B9iZ2v9HKQvguFcraC2Vp6o4QQ/TbHJqbzn9PpXjCXhjL 5msQM/UvlaxWlK87BqXFzwUMb9lC5kRu6qqPfmevDtrkT5jaCPNAubcdz8Gnlo89 w8grtnCNVWNbfMBVxIzOsSR1ESKAQqkm6jkgkPJnPrcrvtIi6QQhek6r59r3FIon uSmV/1RoedqyGGsdxVyD =urxy -END PGP SIGNATURE- - -- -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7+6TQACgkQQe4uqXYgU9Us9wCgx+PHKgs75PQquqtS3heZzsdI rWUAn1CaXMoLAFm4QO4mmdgzGb+CSp0z =trfu -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: news item for app-backup/bacula
On Fri, 30 Dec 2011 11:44:23 +0100 Michał Górny mgo...@gentoo.org wrote: On Fri, 30 Dec 2011 10:43:31 +0100 Thomas Beierlein tom...@gentoo.org wrote: 4. Run the appropriate upgrade script from /usr/libexec/bacula/updatedb/. 7. Start the new Bacula. You still miss steps 5 and 6 ;P. Oh, oh. Now I read your last line from former mail right. Corrected, thanks again. Thomas -- Title: Bacula-5.2.3 Upgrade Author: Thomas Beierlein tom...@gentoo.org Content-Type: text/plain Posted: 2011-12-30 Revision: 3 News-Item-Format: 1.0 Display-If-Installed: app-backup/bacula-5.2.0 The 5.2.x release series of Bacula use a new database catalog format. If you're upgrading from a 3.x.x or 5.0.x release, you must upgrade your bacula catalog database. Please read the manual chapter for how to upgrade your database (see http://www.bacula.org/5.2.x-manuals/en/main/main/Installing_Bacula.html). You can find database upgrade scripts in /usr/libexec/bacula/(updatedb/). It is strongly recommended that you save a copy of your existing database before upgrading. For details how to do it please look into your database documentation. The simplest way to upgrade the database: 1. Stop Bacula from running (at least the director and storage daemons). 2. Save a copy of your existing database. 3. Emerge the new version of Bacula. 4. Run the appropriate upgrade script from /usr/libexec/bacula/updatedb/. 5. Start the new Bacula. signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite: media-radio/fldigi (unless patched for fltk-1.3)
On Fri, 23 Dec 2011 01:59:54 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (23 Dec 2011) # Missing fltk-1.3 support and forced downgrade of fltk # in the same stabilization level which makes this gentoo-x86 # incompatible package. Bug 395747. Removal in 30 days. media-radio/fldigi Well I have seen better christmas surprises, but there are 30 days left... It would be a pitty to loos a strongly developed application with a large user community from gentoo. I will talk to upstream again. they are aware of the problem (as can be seen from bug #359629 comment #4). Thomas --
Re: [gentoo-dev] Packages up for grabs due bangert retirement
On Wed, 20 Jul 2011 19:39:53 +0200 Pacho Ramos pa...@gentoo.org wrote: Due bangert retirement the following packages need a new maintainer: app-misc/nullmodem That will be mine :-). Thomas -- signature.asc Description: PGP signature
Re: [gentoo-dev] openrc portage news item
On Thu, 14 Apr 2011 12:51:55 +0200 Tomá? Chvátal scarab...@gentoo.org wrote: On Thursday 14 of April 2011 13:32:04 Kfir Lavi wrote: When i run world update, I usually don't really check all the written stuff. If I do this, I'm sure a lot more Gentoo users do the same. So do expect people rebooting the machine without checking what your have wrote. This can be a major headache if you have few systems that are doing auto updates. I would solve this issue by stopping the emerge and getting the attention of the user. If I don't get the attention of the user, no openrc will be installed. It should be something like emerge -C ... 1 .2 3 4 5... To conclude, you can't issue such a change without proper confirmation from the user. This was discussed multiple times, news items are to be read. Users ignore elog informations/web announcements/... so it was agreed that news item is agressive enough to user so they must read it. If they don't do so it is just their fault. And no runtime changing for portage where it expect some input is seriously stupid idea, most of us script updates in batch and noone would actualy read it. Never the less as I said we expect user to read that stuff and if he does not he is on his own due to his dumb approach. Maybe we should underline our intention by having that policy documented in the installation handbook. A good place may be section 2 Working with Gentoo (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2). At least all newbies will stumble upon it once. Regards, Thomas. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc portage news item
On Wed, 13 Apr 2011 13:15:38 -0500 William Hubbs willi...@gentoo.org wrote: All, this is the portage news item I am planning on committing to the tree. This is based on an earlier version written by Christian Fallhammer. If there are no suggestions for additions or corrections, this will be committed on 5/1. s/flexable/flexible/ Thomas Thanks, William -- signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Wed, 16 Mar 2011 17:18:52 + Christoph Mende ange...@gentoo.org wrote: app-editors/hexedit I will care for it. Thomas --
[gentoo-dev] Lastrite sci-libs/libgeda
# Thomas Beierlein tom...@gentoo.org (25 Mar 2011) # Masked for removal. # No longer required by sci-electronics/geda. # Removal in 30 days. sci-libs/libgeda --
Re: [gentoo-dev] Re: Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 31 Oct 2010 15:52:51 +0100 Diego Elio Pettenò flamee...@gmail.com wrote: For example, I have just seen in my system that packages like dev-python/pyorbit and dev-libs/libgamin are installing these .la files that should not be needed, but I am sure lots of other python packages are also affected :-/. snip.. media-libs/hamlib (tomjbe) snip.. Above package provides around 38 .la files. I am not quite sure yet about hamlibtcl.la, libhamlib++.la, libhamlib.la and _Hamlib.la. Maybe they can go -- will look into that in next days. But the other ones are plugins (or backends in hamlib terms) which get loaded via libltdl according to the radio tranceiver family in question. See as an example the following strace for calling the simple frontend (rigctl) for the Kenwood TS-570 tranceiver (Model 204). strace -e open rigctl -m 204 open(/etc/ld.so.cache, O_RDONLY) = 3 open(/usr/lib64/hamlib/libhamlib.so.2, O_RDONLY) = 3 open(/lib/libpthread.so.0, O_RDONLY) = 3 open(/lib/libc.so.6, O_RDONLY)= 3 open(/usr/lib/libltdl.so.7, O_RDONLY) = 3 open(/lib/libm.so.6, O_RDONLY)= 3 open(/lib/libusb-0.1.so.4, O_RDONLY) = 3 open(/lib/libdl.so.2, O_RDONLY) = 3 open(/usr/lib64/hamlib/hamlib-kenwood.la, O_RDONLY) = 3 open(/usr/lib64/hamlib/hamlib-kenwood.so, O_RDONLY) = 3 open(/dev/ttyS0, O_RDWR|O_NOCTTY|O_NONBLOCK) = 3 If I read the discussion correctly we will still need to keep these .la files around. Regards, Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzNvuQACgkQQe4uqXYgU9XQOACfdh6Y0K4tEaNfxZWuLQ4IKY9z COcAniZAbl1YcvRLrGQE6k2Jph2jNOkN =u989 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Re: Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 31 Oct 2010 20:15:17 +0100 Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno dom, 31/10/2010 alle 20.09 +0100, Thomas Beierlein ha scritto: If I read the discussion correctly we will still need to keep these .la files around. Most likely, yes… you can go a bit deeper about them (for instance PulseAudio can load its plugins with libltdl even if the .la files are not around, and the author _always_ recommended removing them), but that's probably something we don't have to care about so much as it is. Anyway, I will look into it and try it out. For what concerns the list I provided, that's just the output of the tinderbox in the case of hamlib, it was _Hamlib.la that triggered it, it is installed in the Python tree and Python does not use .la files. Ok. Thnaks for the info. Another one will be libhamlib.la as it works with pkg-config - so no need for it. Regards, Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkzN3JcACgkQQe4uqXYgU9WejwCdFbv1YtXLgunYF0FVXyZWJUmA 2igAn2XloPLjVitP0n0Sh3f9oDi3LOue =asZZ -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jorge, On Thu, 22 Jul 2010 18:04:59 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: If you want to use sqlite3 as default and assuming your prefer postgres over mysql, you can use the following and drop the die from pkg_setup. DEPEND= ... snip ... !bacula-clientonly? ( sqlite3? ( app-backup/bacula[-mysql.-postgres] dev-db/sqlite:3 ) !sqlite3? ( postgres? ( mysql? ( app-backup/bacula[-mysql] ) dev-db/postgresql-base[threads] ) !postgres? ( mysql? ( virtual/mysql ) !mysql? ( app-backup/bacula[sqlite3] ) ) !bacula-nodir? ( virtual/mta ) ) ... snip ... interesting. I did not know that an ebuild can use-depend on itself. Good to know. I had implemented a simpler solution in meantime. But I will test your solution. It would shorten the ebuild by a good amount (It is already much to big and complicated). Furthermore it catches the problems very early (before merging the wrong dependencies). Only downside I see is that the user has to find out why she gets the messages about the wrong USE flag requirements. Say, you want to build it with mysql and have 'sqlite' in make.conf your USE=mysql emerge bacula resultes in a emerge: there are no ebuilds built with USE flags to satisfy app-backup/bacula[-mysql,-postgres]. And than you have to think. Anyway I will think over it. Regards, Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJP2wACgkQQe4uqXYgU9XomwCfeFkb780NSjA0Q7eUCMDmGF0U 1kAAn2pJwIFXbBF0t6gN0eosBxv5c3f4 =jy0D -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 11:31:30 +0200 Tiziano Müller dev-z...@gentoo.org wrote: Am Freitag, den 23.07.2010, 09:06 +0200 schrieb Thomas Beierlein: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jorge, On Thu, 22 Jul 2010 18:04:59 + Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: If you want to use sqlite3 as default and assuming your prefer postgres over mysql, you can use the following and drop the die from pkg_setup. DEPEND= ... snip ... !bacula-clientonly? ( sqlite3? ( app-backup/bacula[-mysql.-postgres] dev-db/sqlite:3 ) !sqlite3? ( postgres? ( mysql? ( app-backup/bacula[-mysql] ) dev-db/postgresql-base[threads] ) !postgres? ( mysql? ( virtual/mysql ) !mysql? ( app-backup/bacula[sqlite3] ) ) !bacula-nodir? ( virtual/mta ) ) ... snip ... interesting. I did not know that an ebuild can use-depend on itself. Good to know. No, not good. It doesn't make any sense. Can you give some reasoning for that? We will have a solution for such cases somewhere in the future, but at the moment you should just display a warning that even though the user specified more than one db only is going to be used. That is what I am doing at the moment. If 0 or more than one backends are selected I fall back to sqlite3 as default and give an according warning message. Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJfUkACgkQQe4uqXYgU9WW7QCbBYthd11EnPrtVJf4RXTqUMVT q9UAoJ//DyXGQmlFLmU4EM3knn6wv98W =CsP/ -END PGP SIGNATURE-
Re: [gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Jul 2010 10:38:56 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: So I will help with my 2c :P I reworked the bacula for the purposes at my company: http://git.overlays.gentoo.org/gitweb/?p=dev/scarabeus.git;a=blob;f=app-backup/bacula/bacula-3.0.3.ebuild I implemented most things people complain here, so might be really really smart to just copy the parts. Cheers Tom Thanks for the link Tomáš. I am sure I will do some cherry pickings :). I agree with you that we need a better set of use flags, as you did in your in-house solution. The actual set is quite a pain. Let us see how we can switch to such a new set (like yours or similar). I was thinking about an accompanying news item, but not before the next release of a new bacula version. That gives some time for preparation and a chance for thorough tests. I am still not sure why some of the old features gets dropped starting with bacula-5.0.1. I asked the former maintainer, but got no response at all. So any ideas are welcome. Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxJhqoACgkQQe4uqXYgU9WdMwCgq20FoE1FqjlPaMYF7QmXEmHX BKoAnRH5QAzkvIzln6Mylj4Xyh8nLJp9 =5aGB -END PGP SIGNATURE-
[gentoo-dev] Fw: [gentoo-commits] gentoo-x86 commit in app-backup/bacula: bacula-5.0.2-r2.ebuild ChangeLog
Did not see the mail here and replied only with p.m. to darkside.
So please find here teh attached copy to keep the discussion on the
right list.
Thomas.
Begin forwarded message:
Date: Thu, 22 Jul 2010 18:07:40 +0200
From: Thomas Beierlein tom...@gentoo.org
To: Jeremy Olexa darks...@gentoo.org
Subject: Re: [gentoo-commits] gentoo-x86 commit in app-backup/bacula:
bacula-5.0.2-r2.ebuild ChangeLog
On Thu, 22 Jul 2010 10:57:32 -0500
Jeremy Olexa darks...@gentoo.org wrote:
On Thu, 22 Jul 2010 15:48:51 + (UTC), Thomas Beierlein (tomjbe)
tom...@gentoo.org wrote:
snip
elif [[ ${dbnum} -gt 1 ]]; then
eerror
eerror You have set ${P} to use multiple
database types. eerror I don't know which to set as the default!
eerror You can
use /etc/portage/package.use to set per-package USE flags eerror
Set it so only one database type, mysql, postgres, sqlite3 eerror
die Multiple database types selected.
Hello Thomas,
I've just noticed this code snippet. Please don't die here, instead
pick a default if there are conflicting choices in USE.
For reference, please see Conflicting USE Flags section on this
page,
http://devmanual.gentoo.org/general-concepts/use-flags/index.html
Thanks,
Jeremy
Hi Jeremy,
thanks for pointing it out.
That is old heritage from former maintainer. I tried to fix the ebuild
step by step and that was atm not on my 'urgent' list :).
So maybe as sqlite3 use flag is default now. I should also default to
that database here.
Regards,
Thomas.
Re: [gentoo-dev] Re: rfc: amateur radio applications should not be in media-radio
On Wed, 14 Jul 2010 19:27:16 -0400 Paul Arthur floweryson...@yahoo.com wrote: On 2010-07-14, William Hubbs willi...@gentoo.org wrote: ... I am an amateur radio operator as well, and that is why putting the ham radio apps inmedia-radio bothers me. Ham radio is not part of the media. But it is a medium. media-* has nothing to do with the media; I really don't see any point to this proposed change.. At least the metadata.xml for media-radio seems inconsistent as far as I can read the different languages: The English language speaks about media applications: The media-radio category contains radio-related media applications The German translation one speaks definitely about applications around amateur radio: Die Kategorie media-radio enthält Applikationen zum Thema Amateur Radio And finally in Polish translation (as far as I can tell) speaks about radio-related multimedia applications. Kategoria media-radio zawiera oprogramowanie multimedialne związane z radiem So maybe a clarification is in urgent need here. Thomas.
Re: [gentoo-dev] rfc: amateur radio applications should not be in media-radio
On Wed, 14 Jul 2010 14:16:54 -0500 William Hubbs willi...@gentoo.org wrote: On Wed, Jul 14, 2010 at 08:48:25PM +0200, Thomas Beierlein wrote: On Wed, 14 Jul 2010 12:27:47 -0500 William Hubbs willi...@gentoo.org wrote: All, I have recently noticed that our amateur radio applications are in the category media-radio. Amateur Radio is not considered part of the media, so I would like to propose renaming this category to app-hamradio, or possibly moving the amateur radio applications to app-hamradio if there are things in media-radio which are not amateur radio related. I like the idea very much. But I am an radio amateur and therefore I am a little bit biased :). I was always confused to find them in media-radio. If we do the move please count on me. I am an amateur radio operator as well, and that is why putting the ham radio apps inmedia-radio bothers me. Ham radio is not part of the media. But to be honest there are some amateur (ham) radio related packages in other categories too (e.g. app-misc/aldo - a cw morse trainer, app-text/7plus - a packet radio text encoder, ..). So maybe a general cleanup would be good. A quick count in media-radio gives 12 packages for amateur radio and 2 others (the second one coming in just today). In sunrise there are 11 amateur radio related packages and 0 others. That means a move to app-hamradio would leave media-radio nearly empty. I would say that if the sunrise packages eventually get moved into portage, they should go in app-hamradio instead of media-radio, then maybe we could move the other ham radio packages over there, but then what would be the best choice for whatever is left in media-radio? I wonder if there is a formal approach to add new categories to the tree or rename existing ones? Thomas signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: amateur radio applications should not be in media-radio
On Wed, 14 Jul 2010 12:27:47 -0500 William Hubbs willi...@gentoo.org wrote: All, I have recently noticed that our amateur radio applications are in the category media-radio. Amateur Radio is not considered part of the media, so I would like to propose renaming this category to app-hamradio, or possibly moving the amateur radio applications to app-hamradio if there are things in media-radio which are not amateur radio related. I like the idea very much. But I am an radio amateur and therefore I am a little bit biased :). I was always confused to find them in media-radio. If we do the move please count on me. But to be honest there are some amateur (ham) radio related packages in other categories too (e.g. app-misc/aldo - a cw morse trainer, app-text/7plus - a packet radio text encoder, ..). So maybe a general cleanup would be good. A quick count in media-radio gives 12 packages for amateur radio and 2 others (the second one coming in just today). In sunrise there are 11 amateur radio related packages and 0 others. That means a move to app-hamradio would leave media-radio nearly empty. Regards Thomas.
