Re: [RFC] General Resolution to deploy tag2upload
On Wed, Jun 12, 2024 at 10:43:04PM +0100, Luca Boccassi wrote: > On Wed, 12 Jun 2024 at 22:35, Joerg Jaspert wrote: > > > > On 17258 March 1977, Luca Boccassi wrote: > > > > >> Whatever end goals some individuals may have is *NOT* a good base to > > >> decide on how a technical implementation for Debian should be. > > > > >> If it turns out that this new thingie makes Salsa entirely > > >> unneccessary, > > >> then so be it. Good for us. > > > > >> I highly doubt this will happen. The dgit stuff only implements a > > >> small > > >> subset of features. The BTS does *not* provide what Salsa issues do. > > >> There isn't anything even near to do what MRs do. CI integration? > > >> Even > > >> less so. No idea why anyone should fear this dgit thing will lead to > > >> Salsa getting turned off, at this point. > > > > >> But really, if we end up getting something that makes an installation > > >> of > > >> gitlab unneccessary, then yay, party. It is not something to be > > >> feared. > > > > > So in other words, I am 100% right to worry about this being the thin > > > end of the wedge that some will use to try and kill Salsa. Sounds like > > > below NoTA if it goes to GR for anybody who, like me, doesn't want > > > Salsa to be jeopardised, then. > > > > WTF is up with you? Honest question. I just explained, in a load of > > words, that this thing is *really* unlikely to provide whatever it needs > > to replace Salsa, as there is basically nothing actually providing the > > features Salsa provides. And your conclusion is more "trying to kill > > Salsa"? > > You _literally_ just wrote: > > > If it turns out that this new thingie makes Salsa entirely unneccessary, > then so be it. Good for us. > > > But really, if we end up getting something that makes an installation of > gitlab unneccessary, then yay, party. It is not something to be feared. > > Not even an hour ago. How can you expect someone to reach any _other_ > conclusion? WTF right back at you. Speaking as listmaster: please calm down everyone. Alex signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Fri, 13 Dec 2019, Steve Langasek wrote: > On Fri, Dec 13, 2019 at 08:46:35PM +0100, Alexander Wirt wrote: > > On Wed, 11 Dec 2019, Sam Hartman wrote: > > > > TL;DR: Treating people with respect is hard and very contextual. > > > Choosing to change how you talk about something to make people more > > > comfortable doesn't always mean you were obligated to make that change. > > > Sometimes you're just promoting connection. > > *snip* > > > today I had to write a bunch of mails in my role as one of the listmasters. > > To be honest, I had better things to than doing that.. I want to remember > > *everyone* on list (and of course on all other lists to) to follow our Coc > > [1] > > and the l.d.o additions [2]. Beside of those formal things, I ask you all to > > come down. Please remember, in the end we are just doing some stupid thing > > like a linux distribution here. There are so many more important things > > like > > a technical discussion. > > I don't know if this is what you intended, but it reads to me like you are > saying here that a technical discussion is more important than Martina's > concerns about transphobia in our community and trans people having their > identity denied. > > I disagree and would consider that an unacceptable position for a Debian > listmaster to take. In fact it does not point into *any* of those directions. It means we are doing a technical thing here and *no* discussion should be that emotional. And it also is meaned in the other direction - no technical discussion is that important that it should hurt any feelings. There are hundreds of things that are more important than Debian. Don't let a discussion over stupid initsystems escalate in a way that people get hurt. Thats what I wanted to say. Alex - Not speaking as listmaster signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Wed, 11 Dec 2019, Sam Hartman wrote: > TL;DR: Treating people with respect is hard and very contextual. > Choosing to change how you talk about something to make people more > comfortable doesn't always mean you were obligated to make that change. > Sometimes you're just promoting connection. *snip* today I had to write a bunch of mails in my role as one of the listmasters. To be honest, I had better things to than doing that.. I want to remember *everyone* on list (and of course on all other lists to) to follow our Coc [1] and the l.d.o additions [2]. Beside of those formal things, I ask you all to come down. Please remember, in the end we are just doing some stupid thing like a linux distribution here. There are so many more important things like a technical discussion. So, next time when you think you would have a write an angry mail, step backwards, go outside, do something you like. Talk with someone you like or love or do whatever you like to do. And after a few hours, try to write a mail that will not hurt someone or heats up the discussion. Thanks for your attention and please forgive me any usage of bad wording or typos. Alex - still on of the Debian Listmasters [1] https://www.debian.org/code_of_conduct [2] https://www.debian.org/MailingLists/#codeofconduct signature.asc Description: PGP signature
Re: Debian presence on newer platforms
On Wed, 27 Mar 2019, Jonas Meurer wrote: > Hi Alex, > > Alexander Wirt: > > On Tue, 26 Mar 2019, Jonas Meurer wrote: > >> Alexander Wirt: > >>> In my experience as a former mailman admin and listadmin mailman is a > >>> no-go. > >>> Getting our feature set even nearly into mailman is impossible, takes > >>> years > >>> and will just get us an unmaintainable thing. I don't want to ever run a > >>> bigger mailman setup again. > >> > >> Can you give an example, what from "our feature set" is missing in > >> mailman? Also, you probably mean mailman2, right? Have you taken a look > >> at mailman3 recently? > > > > Sure, just a few coming into mind: > > > > All those gpg related features we use, our spam removal tools, our special > > archiving hacks, we way we support blacklist through several lists, our > > second line of spamfiltering, crossassassin, the way we can do management on > > several lists and probably a lot more I forgot. It may take man years to do > > a > > migration (in fact we talked about that a few days ago in our internal IRC > > channel and this is more or less consense about the needed effort). > > Thanks for elaborating on that. At least some of them might be > interesting to submit as mailman3 feature requests as they probably > would be of help for other projects that use mailman3 as well. > > I fully understand that you as the listmasters don't consider to switch > right now though. > > > And I tested hyperkitty some time ago with our archive and it was > > unusable slow. > > Interesting. I wonder how Fedora deals with this. I haven't used their > archives extensively, but from quick tests it appeared to be quite > responsive. One question that came into mind: which problems with our lists do you think mailman would solve? If its list archives: provide (or let someone do so) a hyperkitty plugin for reading our mboxes (bonus points if its able to also remove mails from it afterwards (gpdr, spam). Alex signature.asc Description: PGP signature
Re: Debian presence on newer platforms
On Tue, 26 Mar 2019, Jonas Meurer wrote: > Hi Alex, > > Alexander Wirt: > >> While I agree that some "more modern" going way would be nice for lists, > >> I don't think that is an easy task. Nor one where DPL can do much > >> (unless listmasters need some resources that DPL can approve for such a > >> change). Its up to the listmasters, though as far as i know, our current > >> setup is anything but easily converted. > >> In my experience as a former mailman admin and listadmin mailman is a > no-go. > > Getting our feature set even nearly into mailman is impossible, takes years > > and will just get us an unmaintainable thing. I don't want to ever run a > > bigger mailman setup again. > > Can you give an example, what from "our feature set" is missing in > mailman? Also, you probably mean mailman2, right? Have you taken a look > at mailman3 recently? Sure, just a few coming into mind: All those gpg related features we use, our spam removal tools, our special archiving hacks, we way we support blacklist through several lists, our second line of spamfiltering, crossassassin, the way we can do management on several lists and probably a lot more I forgot. It may take man years to do a migration (in fact we talked about that a few days ago in our internal IRC channel and this is more or less consense about the needed effort). And I tested hyperkitty some time ago with our archive and it was unusable slow. Alex signature.asc Description: PGP signature
Re: Debian presence on newer platforms
On Mon, 25 Mar 2019, Joerg Jaspert wrote: > On 15352 March 1977, ans...@debian.org wrote: > > > Do you think Debian should be more active to establish (official) > > presence on newer platforms? > > For those that are free, sure. > > > In particular I also wonder if Debian should look at Matrix[1]: it is a > > free and decentralized platform, and the UI (of Riot[2]) seems more > > friendly than IRC clients. > > I think that doesn't need a DPL. Anyone who wants can do it. And setup > (to speeak in irc terms) channels for the users to get in. And then it > can go the usual way of "the more people use it, the more important it > becomes". > > > Similar things also apply to mailing lists; there are solutions that > > might be more accessible to some users (e.g. mailman3's web interface > > which for example Fedora uses). Though I can't say much about those as > > I haven't used them so far. > > While I agree that some "more modern" going way would be nice for lists, > I don't think that is an easy task. Nor one where DPL can do much > (unless listmasters need some resources that DPL can approve for such a > change). Its up to the listmasters, though as far as i know, our current > setup is anything but easily converted. In my experience as a former mailman admin and listadmin mailman is a no-go. Getting our feature set even nearly into mailman is impossible, takes years and will just get us an unmaintainable thing. I don't want to ever run a bigger mailman setup again. Just my 2 cent Alex - Debian Listmaster
Re: GR proposal: code of conduct
On Wed, 26 Feb 2014, Wouter Verhelst wrote: Hi, *snip* - the CoC, can only be an extension to our (lists.d.o) Coc [1], as there are missing the mail/list specific parts. Hm. The whole point of this exercise was to replace that code of conduct with a more generic and up-to-date one, so if you feel that this isn't good enough, then that's a bug. Can you be more specific about the bits that you think should not be removed from the current mailinglist coc? Your goals are honorable, but I am not sure if this possible. Let me see: I have some example that I don't want to lose, but most are for example not suitable for IRC: - Do not send spam; see the advertising policy below. (the advertising policy is the interesting part) - Send all of your e-mails in English. Only use other languages on mailing lists where that is explicitly allowed (e.g. French on debian-user-french). - Make sure that you are using the proper list. In particular, don't send user-related questions to developer-related mailing lists. - Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l). - Do not send automated out-of-office or vacation messages. - Do not send test messages to determine whether your mail client is working. - Do not send subscription or unsubscription requests to the list address itself; use the respective -request address instead. - Never send your messages in HTML; use plain text instead. - Avoid sending large attachments. - Do not quote messages that were sent to you by other people in private mail, unless agreed beforehand. - When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. - If you want to complain to someone who sent you a carbon copy when you did not ask for it, do it privately. - If you send messages to lists to which you are not subscribed, always note that fact in the body of your message. This are a lot of points, and most of them don't fit to other mediums. I am also not that happy with having several documents with the name 'Code of Conduct', maybe we can find a solution somehow. Yes, that would seem to be obvious; I don't think we need several codes of conduct. I think that there are always medium specific rules that don't apply to other medium. One classic point specific to IRC would be not to use an CTCP VERSION to all clients. *snip* Are _all_ other administrators of 'Debian communication forums' aware of that change? If we go that way, we should probably move away from announcing them on -private and move to something else. Like an mbox on master, or something else (and in my eyes - non-public). I don't think it's necessary to move that. While the code of conduct says that bans should be made public to Debian Developers, it does not say how, where, in what manner, or even if bans should be made public _only_ to Debian Developers (although we might be somewhat more explicit about that). This is intentional; I think review of bans is a good thing, and I do think we should have it, but I don't want a document like this to impose any workflow on anyone. As such, personally I don't expect this to result in a major increase (other than has already happened) of such announcements to -private. OK Alex pgpb3zqlJ52jx.pgp Description: PGP signature
Re: GR proposal: code of conduct
On Tue, 25 Feb 2014, Ean Schuessler wrote: - Steve McIntyre st...@einval.com wrote: I'm not sure how wiki.d.o bans would fit. We *could* list banned users on a specific page, I guess. But the vast majority of the bans we ever enact are for spamming. I feel like spamming and trolling should be considered a different phenomena than bans brought for other reasons. Agreed, I (and I guess other listmasters too) don't plan to publish our antispam measures on -private. And I am pretty sure, no one really wants that. Alex -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225075050.ga27...@lisa.snow-crash.org
Re: GR proposal: code of conduct
On Thu, 20 Feb 2014, Wouter Verhelst wrote: Hi, Op donderdag 13 februari 2014 14:13:40 schreef Alexander Wirt: On Thu, 13 Feb 2014, Wouter Verhelst wrote: If indeed listmasters do object (which I don't think will be the case, but of course I can't read their minds), then obviously we'll need to work with them to fix that. Indeed, if what we propose is in line with what listmasters believe should be done, then this issue would be moot, anyway. in my case it is more the lack of time to dive into that process. I still think we should comment it. Can you give me a reasonable time estimate? I want to push this forward, but I also do value your input. If there's no reply forthcoming from you, however, then these two goals are conflicting... Sorry for being late. That morning I found the time to read the CoC in detail. In that mail I speak primary for myself and not all listmasters. But I collected some opinions from the others forehand, therefore I hope that what I write is in line with the other listmasters. I am quite happy with the CoC as it is, I just have a few supplementary notes. - the CoC, can only be an extension to our (lists.d.o) Coc [1], as there are missing the mail/list specific parts. I am also not that happy with having several documents with the name 'Code of Conduct', maybe we can find a solution somehow. - I always found the netiquette [2] a very useful source, maybe we can add a link to it to the document. - The administrators will divulge any bans to all Debian Developers for review. I know that this is the case for lists.d.o now, but I never saw other anything from other services. Are _all_ other administrators of 'Debian communication forums' aware of that change? If we go that way, we should probably move away from announcing them on -private and move to something else. Like an mbox on master, or something else (and in my eyes - non-public). That's it from my side, I hope it was useful. Thanks for your work Alex - Debian Listmaster [1] https://www.debian.org/MailingLists/index.en.html#codeofconduct [2] http://www.albion.com/netiquette/corerules.html pgpdKn4_Fe9OD.pgp Description: PGP signature
Re: GR proposal: code of conduct
On Thu, 13 Feb 2014, Wouter Verhelst wrote: On Wed, Feb 12, 2014 at 10:49:51PM +, Ian Jackson wrote: Wouter Verhelst writes (Re: GR proposal: code of conduct): 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct Is this overriding the listmasters then? I'll leave it up to the secretary to decide whether this is, indeed, overriding listmasters, but I don't think it is, or should be. I think it would be better to get an opinion from the listmasters. If the listmasters are happy with the GR then clearly it's not overruling them. If they are unhappy with it then given that they're mostly going to be implementing it we should hear about it and take their comments on board! I would be happy to second this GR provided that the listmasters approve, or at least don't object. I don't want to CC the listmasters in this thread on -vote because they probably don't want a zillion crossposts. As the proponent and editor, would you send them a mail asking their opinion ? I did actually already do that (by mail to listmaster@, on 2013-11-27, with Message-ID: 5295bda8.80...@debian.org), but never got a reply. Whether that is because the mail was forgotten, or because they just agreed with it and didn't think it therefore required a reply or something else entirely, I cannot say. But given the level of consensus I had already achieved on -project, and given the fact that I do think it is mostly in line with their current policies, means I thought it better to move this forward. If indeed listmasters do object (which I don't think will be the case, but of course I can't read their minds), then obviously we'll need to work with them to fix that. Indeed, if what we propose is in line with what listmasters believe should be done, then this issue would be moot, anyway. in my case it is more the lack of time to dive into that process. I still think we should comment it. Alex -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140213131340.gb3...@smithers.cadcae.loc
Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Martin Wuertele schrieb am Mittwoch, den 25. Oktober 2006: I second the quoted proposal I disagree with the Policy delegation decision of our DPL [1] and therefore propose a resolution as defined in section 4.2.2 of the Debian constitution to delay the decision of the Debian Project Leader keeping the Package Policy Committee as defined[2] in place until the Debian Project Leader has found at least three people who'll be active in maintaining policy according to the policy process[3] and delegates them. Consequently the REJECT for uploads of debian-policy must be removed. My reason for this proposal is the impression the revocation of the delegation is based on the disagreement of the interpretation of the policy between the chair of the Package Policy Committee and the Debian Project Leader. [1] http://lists.debian.org/debian-project/2006/10/msg00233.html [2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html [3] http://lists.debian.org/debian-project/2006/10/msg00238.html yours Martin Alex signature.asc Description: Digital signature
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don Armstrong schrieb am Montag, den 18. September 2006: I also second this clarified proposal. == BEGIN PROPOSAL = The Free Software movement is about enabling users to modify the works that they use on their computer; about giving users the same information that copyright holders and upstream developers have. As such, a critical part of the Free Software movement is the availability of source (that is, the form of the work that a copyright holder or developer would use to actually modify the work) to users. This makes sure that users are not held hostage by the whims (or lack of interest or financial incentive) of upstreams and copyright holders. Different types of works have different forms of source. For some works, the preferred form for modification may not actually be digitally transferable.[1] For others, the form that originally was preferred may have been destroyed at some point in time, and is no longer available to anyone. However, to the greatest extent possible,[2] the availability of source code to users is a critical aspect of having the freedom to modify the software that is running upon ones computer. Recognizing this, the Debian Project: A. Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution. That is, works must include the form that the copyright holder or upstream developer would actually use for modification. B. Strongly recommends that all non-programmatic works distribute the form that the copyright holder or upstream developer would actually use for modification. Such forms need not be distributed in the orig.tar.gz (unless required by license) but should be made available on upstream websites and/or using Debian project resources. C. Reaffirms its continued support of users whose hardware (or software) requires works which are not freely licensed or whose source is not available by making such works available in non-free and providing project resources to the extent that Debian is capable of doing so. D. Requests that vendors of hardware, even those whose firmware is not loaded by the operating system, provide the prefered form for modification so that purchasers of their hardware can exercise their freedom to modify the functioning of their hardware. 1: Consider film negatives, or magnetic tape in the case of audio recordings. 2: Here it must be emphasized that we refer to technically possible or possible for some party as opposed to legally possible for Debian. We also assume digital distribution, and do not attempt to require the distribution of physical objects. = END PROPOSAL === If necessary, consider this an amendment under A.1.2; seconders, you may object to the changes under A.1.5. (If you decide to re-second this proposal, please only second the part between the === lines.) I've also attached the suggested content for the v.d.o webpages for this option in the interest of completeness. Don Armstrong 1: http://cvs.debian.org/webwml/english/vote/2006/vote_004.wml?root=webwmlr1=1.3r2=1.4 2: http://lists.debian.org/debian-vote/2006/09/msg00228.html 3: http://lists.debian.org/debian-vote/2006/09/msg00235.html -- CNN/Reuters: News reports have filtered out early this morning that US forces have swooped on an Iraqi Primary School and detained 6th Grade teacher Mohammed Al-Hazar. Sources indicate that, when arrested, Al-Hazar was in possession of a ruler, a protractor, a set square and a calculator. US President George W Bush argued that this was clear and overwhelming evidence that Iraq indeed possessed weapons of maths instruction. http://www.donarmstrong.com http://rzlab.ucr.edu vproposer / p Don Armstrong [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /p vseconds / ol li René van Bevern [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /li li Frank Küster [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /li li Pierre Habouzit [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /li li Alexander Wirt [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /li li Kari Pahula [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /li li Anibal Monsalve Salazar [a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a] /li /ol vtext / p Choice 1. The actual text of the resolution is as follows: /p h2DFSG #2 applies to all programmatic works
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Don Armstrong schrieb am Donnerstag, den 24. August 2006: I'd like to propose the following option to the current GR process. I second this proposal. As I will (starting late sunday PDT) be away for a week and a few days at Burning Man,[i] I will be unable to appropriately respond to corrections and suggested amendments during that time. However, I will do so immediately at my return. == The Free Software movement is about enabling users to modify the works that they use on their computer; about giving users the same information that copyright holders and upstream developers have. As such, a critical part of the Free Software movement is the availability of source (that is, the form of the work that a copyright holder or developer would use to actually modify the work) to users. This makes sure that users are not held hostage by the whims (or lack of interest or financial incentive) of upstreams and copyright holders. Different types of works have different forms of source. For some works, the preferred form for modification may not actually be digitally transferable.[1] For others, the form that originally was preferred may have been destroyed at some point in time, and is no longer available to anyone. However, to the greatest extent possible,[2] the availability of source code to users is a critical aspect of having the freedom to modify the software that is running upon ones computer. Recognizing this, the Debian Project: A. Reaffirms that programmatic works distributed in the Debian system (IE, in main) must be 100% Free Software, regardless of whether the work is designed to run on the CPU, a subsidiary processing unit, or by some other form of execution. That is, works must include the form that the copyright holder or upstream developer would actually use for modification. B. Strongly recommends that all non-programmatic works distribute the form that the copyright holder or upstream developer would actually use for modification. Such forms need not be distributed in the orig.tar.gz (unless required by license) but should be made available on upstream websites and/or using Debian project resources. C. Reaffirms its continued support of users whose hardware (or software) requires works which are not freely licensed or whose source is not available by making such works available in non-free and providing project resources to the extent that Debian is capable of doing so. D. Requests that vendors of hardware, even those whose firmware is not loaded by the operating system, provide the prefered form for modification so that purchasers of their hardware are can exercise their freedom to modify the functioning of their hardware. 1: Consider film negatives, or magnetic tape in the case of audio recordings. 2: Here it must be emphasized that we refer to technically possible or possible for some party as opposed to legally possible for Debian. We also assume digital distribution, and do not attempt to require the distribution of physical objects. === Obvious points for discussion: 1. I would really like to be able to commit to some form of installation support for users who need to be able to use non-free firmware to install their system; some more work is needed in d-i land, though to make sure that this is separated out and that it's trivial to have a Free system, and know that what you're installing/using/distributing is Free Software. 2. Distributing the huge source forms for non-programmatic works is going to be a problem. I don't think they're needed in the orig.tar.gz, because that would needlessly bloat the archive, and it's probably not required unless the works are copylefted. However, we should make an effort to encourage upstreams to make them available and likewise make them available to our users. [Even if it's just in people.debian.org/~you/ or similar and mentioned in the copyright file, it'd be a good step.] 3. If there is substantial objection to D, I will probably remove it; however firmware, whether we happen to distribute it or not, is a hazard to user's freedom to modify the functioning of their computers. 4. Finally, if in the context of the release of etch, we need to compromise our ideals and accept programmatic works without source, we should do so by specifically exempting them from DFSG 2 for the purpose of releasing etch by a GR which needs to meet the 3:1 requirement instead of attempting to define ourselves into such a position, especially when source code is clearly a desirable thing to have from our users and our perspective. Don Armstrong i:
Re: Proposal: Source code is important for all works in Debian, and required for programmatic ones
Alexander Wirt schrieb am Freitag, den 25. August 2006: Don Armstrong schrieb am Donnerstag, den 24. August 2006: I'd like to propose the following option to the current GR process. I second this proposal. I have to say a few mores word to it. It would be fully ok for me if we release etch with this non-free firmware, but this problem should be adressed with etch+1. Alex signature.asc Description: Digital signature
Questions about kroogers platform
Hi, I have just one question, how do you explain the differences about your platform and your statements posted in this thread: http://lists.debian.org/debian-women/2004/07/msg00217.html Alex -- Alexander formorer Wirt KeyID: BC7D020A EMail: [EMAIL PROTECTED]ICQ: 28651245 signature.asc Description: OpenPGP digital signature
