Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On Fri, 8 Feb 2013, Tomáš Chvátal wrote: 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Ulrich
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On 09/02/13 11:06, Ulrich Mueller wrote: On Fri, 8 Feb 2013, Tomáš Chvátal wrote: 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Ulrich Maybe you don't understand how linux-firmware package works. It only installs what you want -- it uses the savedconfig eclass to handle a list of wanted firmwares. I admit I never bothered to trim down my install of it, but the point is YOU CAN do it. - Samuli
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
Ulrich Mueller u...@gentoo.org wrote: On Fri, 8 Feb 2013, Tomáš Chvátal wrote: 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Ulrich Why not specify which firmwares are to be installed using a 'FIRMWARE' variable. Similar to VIDEOCARDS? -- Joost Roeleveld -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On 09/02/13 11:11, J. Roeleveld wrote: Ulrich Mueller u...@gentoo.org wrote: On Fri, 8 Feb 2013, Tomáš Chvátal wrote: 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Ulrich Why not specify which firmwares are to be installed using a 'FIRMWARE' variable. Similar to VIDEOCARDS? Read my last reply. It's already supported through savedconfig.eclass. You only get what you want.
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On Sat, 09 Feb 2013, Samuli Suominen wrote: I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Maybe you don't understand how linux-firmware package works. It only installs what you want -- it uses the savedconfig eclass to handle a list of wanted firmwares. I admit I never bothered to trim down my install of it, but the point is YOU CAN do it. I stand corrected. Ulrich
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
Samuli Suominen ssuomi...@gentoo.org wrote: On 09/02/13 11:11, J. Roeleveld wrote: Ulrich Mueller u...@gentoo.org wrote: On Fri, 8 Feb 2013, Tomáš Chvátal wrote: 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Ulrich Why not specify which firmwares are to be installed using a 'FIRMWARE' variable. Similar to VIDEOCARDS? Read my last reply. It's already supported through savedconfig.eclass. You only get what you want. I read it. Came after I sent my reply. Not familiar with that class myself. Will take your word it allows limiting the firmware. I, as a user, prefer not to have to hunt for firmware for devices supported vy the kernel. I would either install all of them or filter out the firmwares for devices I am unlikely to get. -- Joost Roeleveld -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On Sat, 09 Feb 2013 11:09:15 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: On 09/02/13 11:06, Ulrich Mueller wrote: On Fri, 8 Feb 2013, Tomáš Chvátal wrote: 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu: I would say that we might want to review linux-firmware, and if the newest firmware _is_ there, just get rid of the split one. That should be probably the best approach, to actually kill of the lone ones and keep the linux-firmware only. I disagree. Why should we force users to install lots of crap (some of it being non-free) that they will never need because they don't have the hardware? Ulrich Maybe you don't understand how linux-firmware package works. It only installs what you want -- it uses the savedconfig eclass to handle a list of wanted firmwares. I admit I never bothered to trim down my install of it, but the point is YOU CAN do it. I don't think that solves the license problem properly. Say, if user doesn't want non-free software, he's going to have the whole package masked. He'd have to work-around license + savedconfig. Now that I look at it, it seems that the ebuild doesn't even put all necessary licenses into LICENSE. I may be wrong but the git repo seems to have a lot of non-standard licenses. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory
On Sat, 9 Feb 2013, Michał Górny wrote: I don't think that solves the license problem properly. Say, if user doesn't want non-free software, he's going to have the whole package masked. He'd have to work-around license + savedconfig. Now that I look at it, it seems that the ebuild doesn't even put all necessary licenses into LICENSE. I may be wrong but the git repo seems to have a lot of non-standard licenses. Yes, it is a mess and it changes often. You can find an attempt to disentangle it in bug 318841. Ulrich
Re: [gentoo-dev] SRC
On 02/09/2013 12:26 AM, Alec Warner wrote: On Fri, Feb 8, 2013 at 3:18 PM, Stefan Ehret eh...@planetpurple.net wrote: * * * PLEACE SAFE THE SOURCE * * * Annnd banned. -A at __second__ incident, slacker! ;-) -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
[gentoo-dev] On the good usage of subslots
Dear fellow developers, I hope this will be trivial to most of you but after seeing bug #455900 and the vast majority of developers not even thinking twice before sedding their dep strings, I believe this needs some attention. What do subslots do: You set a subslot to a package and every time said package subslot changes (e.g. with an update), others packages depending on it with a := dep will be rebuilt. Nothing more, nothing less. Now, this solves a real problem: haskell, perl and ocaml packages need to be rebuilt after updating their respective compiler/interpreter and, in some cases, even after updating the libraries they use. Subslots would make haskell-updater, perl-cleaner and ocaml-rebuild not needed in the future. You can also use subslots to notify an ABI change in a shared library, in order to avoid having to use preserve-libs or run revdep-rebuild. However, this week I had to rebuild webkit-gtk three or four times and libreoffice twice... If you want to notify ABI changes, then you should set subslot to something representing the ABI, $PV as subslot is most certainly wrong in that case. Subslot is *not* a substitute to checking your library ABI, checking if its reverse dependencies work fine after the update, and notifying upstream if something went wrong so they can make a quick release fixing their mistake. Subslot is also *not* a substitute to soname and ensuring ABI compatibility (at least forward) between libraries with the same major. Using subslot only to be on the safe side and forcing a rebuild of all the dependent packages because it is too much work to check the ABI and work with upstream is, IMHO, a serious QA issue. Thank you for your attention, Alexis.
[gentoo-dev] Re: On the good usage of subslots
Hi, On 9/02/2013 23:15, Alexis Ballier wrote: Dear fellow developers, I hope this will be trivial to most of you but after seeing bug #455900 and the vast majority of developers not even thinking twice before sedding their dep strings, I believe this needs some attention. What is wrong with maintainers just updating their dependencies in this fashion? Surely the onus in this case is on package maintainers setting sensible subslots (which is indeed what you appear to be saying below)? I even noticed some maintainers adding subslots dependencies on libraries that do not yet define subslots. This too seems reasonable, given that there would be no impact until the library defines a (sensible) subslot in the future. What do subslots do: You set a subslot to a package and every time said package subslot changes (e.g. with an update), others packages depending on it with a := dep will be rebuilt. Nothing more, nothing less. Now, this solves a real problem: haskell, perl and ocaml packages need to be rebuilt after updating their respective compiler/interpreter and, in some cases, even after updating the libraries they use. Subslots would make haskell-updater, perl-cleaner and ocaml-rebuild not needed in the future. You can also use subslots to notify an ABI change in a shared library, in order to avoid having to use preserve-libs or run revdep-rebuild. However, this week I had to rebuild webkit-gtk three or four times and libreoffice twice... If you want to notify ABI changes, then you should set subslot to something representing the ABI, $PV as subslot is most certainly wrong in that case. Subslot is *not* a substitute to checking your library ABI, checking if its reverse dependencies work fine after the update, and notifying upstream if something went wrong so they can make a quick release fixing their mistake. Subslot is also *not* a substitute to soname and ensuring ABI compatibility (at least forward) between libraries with the same major. Using subslot only to be on the safe side and forcing a rebuild of all the dependent packages because it is too much work to check the ABI and work with upstream is, IMHO, a serious QA issue. Thank you for your attention, Alexis. Best regards, Michael
Re: [gentoo-dev] Re: On the good usage of subslots
On Sat, 09 Feb 2013 23:38:35 +1100
Michael Palimaka kensing...@gentoo.org wrote:
Hi,
On 9/02/2013 23:15, Alexis Ballier wrote:
Dear fellow developers,
I hope this will be trivial to most of you but after seeing bug
#455900 and the vast majority of developers not even thinking twice
before sedding their dep strings, I believe this needs some
attention.
What is wrong with maintainers just updating their dependencies in
this fashion? Surely the onus in this case is on package maintainers
setting sensible subslots (which is indeed what you appear to be
saying below)?
If subslot does not represent ABI then it's wrong to set such := deps:
By setting them you are forcing your users to needlessly rebuild your
package.
Think about glib: gobject-introspection needs to be rebuilt after each
glib update. glib maintainers will likely want glib to have ${PV} as
subslot and let gobject-introspection := depend on it. Packages that do
not break with minor updates of glib (ie 99% of them) should not :=
depend on glib, even if it has a subslot.
What I wanted to say could be summarized as: Please define what your
subslot means when you define one and please check if that is the
meaning you want to give it when you set := deps.
Alexis.
Re: [gentoo-dev] Re: On the good usage of subslots
On Sat, 09 Feb 2013 23:38:35 +1100 Michael Palimaka kensing...@gentoo.org wrote: I even noticed some maintainers adding subslots dependencies on libraries that do not yet define subslots. This too seems reasonable, given that there would be no impact until the library defines a (sensible) subslot in the future. By the way, this could also be discussed: I did not check, but as far as I understand it subslot is equal to slot if not defined. When said library defines a subslot, the subslot will change and thus triggers a (likely useless) rebuild of your package setting a := dep. Alexis.
Re: [gentoo-dev] On the good usage of subslots
On 09/02/13 14:15, Alexis Ballier wrote: Dear fellow developers, I didn't find anything to reply directly here, so sorry for stealing this message. I just wanted to point out that people have lately been adding deps like: media-libs/libpng:= dev-libs/openssl:= That is wrong as it completely ignores the SLOTting of these packages. They need to be: media-libs/libpng:0= dev-libs/openssl:0= As in, before you add any subslotting to any library, you need to check for it's binary-only SLOTs! Thanks, Samuli
[gentoo-dev] Re: On the good usage of subslots
On 10/02/2013 00:47, Samuli Suominen wrote: On 09/02/13 14:15, Alexis Ballier wrote: Dear fellow developers, I didn't find anything to reply directly here, so sorry for stealing this message. I just wanted to point out that people have lately been adding deps like: media-libs/libpng:= dev-libs/openssl:= That is wrong as it completely ignores the SLOTting of these packages. They need to be: media-libs/libpng:0= dev-libs/openssl:0= As in, before you add any subslotting to any library, you need to check for it's binary-only SLOTs! Thanks, Samuli Is there a difference in behaviour between 'media-libs/libpng:=' and 'media-libs/libpng' with no slot information at all?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On 08/02/13 22:46, Alexis Ballier wrote: On Fri, 08 Feb 2013 22:41:04 +0100 Maciej Mrozowski reave...@gmail.com wrote: On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. Not really. I was promised a discussion that hasn't happened yet. I'm available for discussion anytime, I got a little busy in the past days and I will busy the next 3 days, but I should be available today evening or now. I stated already what I think about the whole discussion in a blog post. To summarize it my take is quite simple, Libav leads the way regarding the main API, it offers a more compact surface for attacks if you are really concerned about security and usually it is a little more compact and a bit more tested over a wider range of architectures. I'm not for removing ffmpeg overnight since there are features that might be of use and I'm not so hypocrite to value diversity only when it is in favor of my interests. That said as long the two project are compatible having one or another as default is just a matter of making our life easier. I'm upstream for Libav and a good number of Libav developers are Gentoo users, including Gentoo on special platforms (e.g. aarch64). Few large projects such as VLC and Gstreamer switched to Libav as their default. Since Libav is the no-frills variant, notwithstanding the interesting campaign of we have more security11ein! less stuff should break since it is usually more tested and once we gather the samples triggering a crash usually we do not stop preventing that single crash but the whole class of possible defect (see my work on mov as an example). I cannot and will not say that Libav is perfect or that no bugs are introduced on our side and other outlandish statements, but within my biased point of view I would expect a better experience for the user not caring about which library to use. If you want to discuss on #gentoo-media ping me within 30 min or in 2 hours. I hope somebody not Libav nor FFmpeg committer could come up with a pros-cons list. lu
[gentoo-dev] Re: On the good usage of subslots
On 9/02/2013 23:52, Alexis Ballier wrote: On Sat, 09 Feb 2013 23:38:35 +1100 Michael Palimaka kensing...@gentoo.org wrote: I even noticed some maintainers adding subslots dependencies on libraries that do not yet define subslots. This too seems reasonable, given that there would be no impact until the library defines a (sensible) subslot in the future. By the way, this could also be discussed: I did not check, but as far as I understand it subslot is equal to slot if not defined. When said library defines a subslot, the subslot will change and thus triggers a (likely useless) rebuild of your package setting a := dep. Alexis. Yeah. This behaviour can be avoided by introducing the explicit subslot only when the subslot would otherwise need bumping.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Sat, Feb 9, 2013 at 9:12 AM, Luca Barbato lu_z...@gentoo.org wrote: I hope somebody not Libav nor FFmpeg committer could come up with a pros-cons list. ++, but frankly the committers are probably in the best place to do any evaluation even if they likely have some bias. If you wanted to delve into the merits of portage vs paludis you'd be far more informed by a discussion between the respective devs (even if flames are involved) than listening to some Ubuntu users go on about which ones were the ricers. Keeping things civil of course is desirable all the same. A wiki page might be a good place for this. Perhaps we should have some category for point-in-time analyses/evaluations/etc when things like this come up. A page like this might be something that gets attention from the linux community in general. If we want it to be anything other than a raging flamewar it might require moderation, and a lot of sticking to the facts and looking at it pragmatically from a what makes sense for a distro standpoint rather than which is the better project standpoint. Rich
Re: [gentoo-dev] Re: On the good usage of subslots
On 02/09/2013 06:05 AM, Michael Palimaka wrote: Is there a difference in behaviour between 'media-libs/libpng:=' and 'media-libs/libpng' with no slot information at all? I don't know if you phrased your question as intended. Anyway, yes, the difference is that one with the slot-operator will trigger rebuilds when the SLOT or sub-slot changes. -- Thanks, Zac
[gentoo-dev] Re: On the good usage of subslots
On 10/02/2013 03:06, Zac Medico wrote: On 02/09/2013 06:05 AM, Michael Palimaka wrote: Is there a difference in behaviour between 'media-libs/libpng:=' and 'media-libs/libpng' with no slot information at all? I don't know if you phrased your question as intended. Anyway, yes, the difference is that one with the slot-operator will trigger rebuilds when the SLOT or sub-slot changes. You are right, I was not very clear, sorry about that. Samuli talked about not forgetting to add the primary slot when adding a subslot dependency. Does the behaviour there differ compared to omitting the slot when there is no subslot dependency? Eg. He wrote we should use 'media-libs/libpng:0=', but pre-subslots, the :0 was often (incorrectly?) omitted.
Re: [gentoo-dev] Re: On the good usage of subslots
On 09/02/13 18:36, Michael Palimaka wrote: Eg. He wrote we should use 'media-libs/libpng:0=', but pre-subslots, the :0 was often (incorrectly?) omitted. I've at least been adding :0 to many packages, openssl, tiff, libpng ... ... pretty much ever since the libpng 1.4 upgrade problem in the past that reminded me that if something is possible, users will do it people masked =media-libs/libpng-1.4 and they only got the :1.2 binary-only SLOT installed and ended up with no headers so having :0 forces the headers be there, and people don't get confused (at least if you read portage's output correctly)
Re: [gentoo-dev] Re: On the good usage of subslots
El sáb, 09-02-2013 a las 18:39 +0200, Samuli Suominen escribió: On 09/02/13 18:36, Michael Palimaka wrote: Eg. He wrote we should use 'media-libs/libpng:0=', but pre-subslots, the :0 was often (incorrectly?) omitted. I've at least been adding :0 to many packages, openssl, tiff, libpng ... ... pretty much ever since the libpng 1.4 upgrade problem in the past that reminded me that if something is possible, users will do it people masked =media-libs/libpng-1.4 and they only got the :1.2 binary-only SLOT installed and ended up with no headers so having :0 forces the headers be there, and people don't get confused (at least if you read portage's output correctly) Wouldn't be better to force (via repoman) people to set exact slot (or :* if packages work for all slots) to prevent problems like this and future breakages could appear when SLOT if bumped and rdeps are not fixes to depend on needed slot? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] On the good usage of subslots
On Sat, 9 Feb 2013 09:15:03 -0300 Alexis Ballier aball...@gentoo.org wrote: I hope this will be trivial to most of you but after seeing bug #455900 and the vast majority of developers not even thinking twice before sedding their dep strings, I believe this needs some attention. As a note for those who get irritated with those webkit-gtk: --ignore-built-slot-operator-deps y | n Ignore the slot/sub-slot := operator parts of dependencies that have been recorded when packages where built. This option is intended only for debugging purposes, and it only affects built packages that specify slot/sub-slot := operator dependencies which are supported beginning with EAPI 5. Sadly, there's probably no way to ignore them only for cases when they are completely useless, leaving the meaningful uses alone. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
For your information, in the default/linux tree
* all 13.0 profiles have been created and are marked stable the same way as
10.0 was
* all 10.0 profiles have been removed from profiles.desc
* all 10.0 profiles have been deprecated
IMHO the waiting time of 1 year decided by Council starts now before we can
remove the 10.0 trees.
Maintainers of profiles outside default/linux (e.g. hardened and prefix),
please take care of the migration to EAPI=5 on your own.
Everyone else, have fun! :)
Am Samstag, 12. Januar 2013, 21:47:18 schrieb Andreas K. Huettel:
Hi everyone,
since Council has approved the creation of a fresh set of EAPI=5 13.0
profiles, I would like to volunteer for creating them. The proposed
procedure is outlined below in detail, and I'd be happy for comments.
[If anything below deviates from Council decision, please tell me- not my
intention.]
One general question comes first, though: Right now, the releases/10.0
profile directory does the following things:
* mask too-old portage
* set eapi
* add USE=bzip2
Is there anything unrelated to EAPI=5 that absolutely must be added to the
new releases/13.0 directory in addition in your opinion? (Whether this is
the right place and was the right place in the beginning for USE=bzip2 is
another question.)
###
The procedure (all paths relative to profiles):
1) create directory eapi-5-files, with eapi (containing 5), skeletons for
package.stable.mask etc and a readme
2) copy releases/10.0 to releases/13.0, in releases/13.0:
* increase required portage version
* additionally inherit ../../eapi-5-files
* other changes as per question above?
3) for each arch in default/linux,
* announce on arch alias (to prevent overlapping commits)
* copy default/linux/${arch}/10.0 to default/linux/${arch}/13.0 and
* change inheritance in the new copy to inherit ../../../../releases/13.0
instead of ../../../../releases/10.0
* announce on arch alias (so future changes go into 13.0 tree)
[This describes the simple case. I realize that there are differences in
the directory structure, e.g. powerpc/ppc64/10.0, which is why this step
needs extra care.]
4) edit profiles.desc and copy all 10.0 lines to 13.0 lines, with an
initial setting dev (if dev or stable before) or exp (if exp before)
This makes repoman check against the new profiles when using developer
profiles.
5) announce the state on the dev list, urging devs to update their symlink
manually and !test!
6) wait one / two weeks
7) in profiles.desc, mark all 13.0 profiles stable that were stable in
10.0, and remove the lines for the 10.0 profiles. This makes eselect
profile now only offer the new ones, and repoman test by default against
13.0 profiles.
8) mark all 10.0 profiles as deprecated by creating a deprecated file
(containing the replacement suggestion) in the directory. This makes
portage warn users to upgrade (suggesting a new profile for them), and
repoman ignore the 10.0 profiles.
9) long waiting time as decided by Council
###
Everything that does NOT use/inherit 10.0 will remain unaffected, and
whoever responsible may have to take care of that some time before (in
step 10) the main profile directory becomes EAPI=5. This means e.g.
hardened, ulibc, prefix or bsd.
Cheers,
Andreas
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
* all 13.0 profiles have been created and are marked stable the same way as 10.0 was * all 10.0 profiles have been removed from profiles.desc * all 10.0 profiles have been deprecated Suggestion: perhaps a news item should be created for the migration to the new profiles? As a Gentoo user who just got a giant red warning from portage that his active profile was deprecated, I feel like many people are going to be confused about this. -Doug
[gentoo-dev] Re: New, shiny EAPI=5 profiles: volunteer, procedure, preparations
Andreas K. Huettel posted on Sat, 09 Feb 2013 23:29:45 +0100 as excerpted: For your information, in the default/linux tree * all 13.0 profiles have been created and are marked stable the same way as 10.0 was * all 10.0 profiles have been removed from profiles.desc * all 10.0 profiles have been deprecated Just because it sometimes doesn't get said enough and I don't see anyone else posted it yet... Thank you. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: !!! ERROR !!!
On Fri, 8 Feb 2013 10:40:00 + Markos Chandras hwoar...@gentoo.org wrote: Live a little. Send a funny email to a list once. I think you are on the wrong list then. Has anyone seen my stick? I left it right here... -- gcc-porting toolchain, wxwidgetslearn a language baby, it's that kind of place @ gentoo.org where low card is hunger and high card is taste signature.asc Description: PGP signature
