Re: [hackers][slock] making slock set the keyboard layout to English before locking the screen
Hi Lancia. Does "setxkbmap us && slock" do what you want?
On Tue, Oct 18, 2022 at 10:23 AM Lancia Greggori
wrote:
>
> Hi gentleman, as the title suggests, I need slock to automatically set the
> keyboard layout to English because sometimes my keyboard layout is in another
> language when slock locks the screen and this causes my typed password to be
> rejected by slock as incorrect because it has been entered in foreign
> characters.
>
> What I have tried so far:
>
> 1- using setxkbmap(1) with slock(1):
>
>$ slock setxkbmap us
> Authorization required, but no authorization protocol specified
> Cannot open display ":0"
>
> $ slock env setxkbmap us
> Authorization required, but no authorization protocol specified
> Cannot open display ":0"
>
> 2- editing slock.c and using system(3) to execute setxkbmap(1):
>
> system("setxkbmap us");
>
> /* everything is now blank. Wait for the correct password */
> readpw(dpy, , locks, nscreens, hash);
>
> output of slock(1):
>
>Authorization required, but no authorization protocol specified
>Cannot open display ":0"
>Terminated ---> guess: caused by root using killall(1)
>
>
> I am not familiar with Xorg programming, but I am guessing there might be a
> function or something that will set the keyboard layout to English.
>
> Can anyone kindly give me pointers or hints?
Re: [hackers] About swapfocus dwm patch
Hi Vinicius,
I think the "patch does not apply" error may be a red herring. The
patch applies cleanly for me directly to dwm 6.2, but does not
compile.
dwm.c:2161:52: error: ‘Monitor’ {aka ‘struct Monitor’} has no
member named ‘pertag’
On the other hand, the patch conflicts you get if you apply pertag
first are caused by the swapfocus patch including parts of pertag in
its diff. I tried removing the parts of pertag that swapfocus
includes, but could not get something compilable.
I would probably check with the maintainer, but there could be a fix
I'm not seeing.
All the best,
Daniel
On Wed, Sep 30, 2020 at 6:54 AM vinícius mota wrote:
>
> Thank you very much Chris for your reply.
>
> I just tried again, from scratch, and failed again, with the same error.
> Early on today I successfully installed other suckless patches, this time for
> st, following the same procedure and everything worked flawlessly. In fact
> since I have two other patches for dwm in place, everytime dwm is reinstalled
> those two patches are reinstalled as well, and that happened several times
> today.
>
> It may be nonsense but I have looked up several patches' codes today and
> noticed that the beginning of the swapfocus patch is different, with a
> different "diff" command:
>
> diff -up a/config.def.h b/config.def.h
> --- a/config.def.h 2020-01-29 00:06:12.415681126 +0100
> +++ b/config.def.h 2020-01-29 13:25:14.167910093 +0100
> @@ -66,6 +66,7
>
> while for all others that I have looked in such as hide vacant tags the diff
> command reads
>
> diff --git a/dwm.c b/dwm.c
> index 4465af1..c4aa3de 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -416,7 +416,7 @@
>
> Other than that I have no idea of why it is failing the way it is.
>
> Anyway, thank you again very much for your reply.
>
> Vinícius.
>
>
>
>
> --
> Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE
> Long Key ID:
> 8E65EA37669D90BE
> Short Key ID:
> 669D90BE
>
>
> On Tue, Sep 29, 2020 at 10:29 PM Chris Down wrote:
>>
>> Hi Vinícius,
>>
>> The error message from patch is quite clear that it failed to apply, so
>> compilation is premature. You need to either massage it in, or find a patch
>> which roughly matches your version.
>>
Re: [hackers] Licensing status of patches
Dear Laslo, > as far as I know, there's no need for a CLA. CLAs are just a > simplification that contributors waive their rights to the code to the > legal entity behind the project so the license file is not littered > with 100s of people but only the legal entity. Which license you're > using doesn't matter here. Please correct me if I'm wrong. My argument that the GPL is simpler here is that in the "default case" where changes are simply submitted without the contributor talking about licensing, the project as a whole is not covered by the given license (only those contributions which have explicitly agreed to it). For small projects, or projects hosted on Github, this is no problem. But if, some time later, a user decides they want to fork the project, simply seeing that the project is free is not enough to guarantee they can use it. They need to see either something like a CLA (which may cede the copyright to the maintainer, or simply agree that their contributions inherit the parent license), or an explicit statement from every contributor agreeing to license their changes under a free license. So whether it's a "need" or a "simplification" is a matter of perspective - I only think it would matter for projects above a certain size. But the need to get access to downstream changes of your own project is one of the motivating factors behind the GPL - I believe Linus cites it as his motivation for choosing it for Linux. Hope that helps, Daniel On Thu, Oct 1, 2020 at 7:36 AM Laslo Hunhold wrote: > > On Wed, 30 Sep 2020 19:06:32 +0100 > Daniel Littlewood wrote: > > Dear Daniel, > > > I am wary of going too far off topic, but I think a convincing > > argument against the use of "permissive" licenses like MIT is that if > > your project grows above a certain size, it necessitates CLAs in > > addition to a license. If you do not use a platform like GitHub who > > guarantees that inbound=outbound, then you don't necessarily have a > > right to your contributors' changes, which I'm sure could be painful. > > Sure, it's an unlikely situation, but so are most pathological > > behaviours that necessitate a license. > > as far as I know, there's no need for a CLA. CLAs are just a > simplification that contributors waive their rights to the code to the > legal entity behind the project so the license file is not littered > with 100s of people but only the legal entity. Which license you're > using doesn't matter here. Please correct me if I'm wrong. > > With best regards > > Laslo >
Re: [hackers] Licensing status of patches
Hi Pedro, Thanks for those mentions, I love the qutebrowser project and am warmed to see other examples of GPL projects finding ways to monetise their work. I am wary of going too far off topic, but I think a convincing argument against the use of "permissive" licenses like MIT is that if your project grows above a certain size, it necessitates CLAs in addition to a license. If you do not use a platform like GitHub who guarantees that inbound=outbound, then you don't necessarily have a right to your contributors' changes, which I'm sure could be painful. Sure, it's an unlikely situation, but so are most pathological behaviours that necessitate a license. On Wed, Sep 30, 2020 at 3:53 PM Pedro Lucas Porcellis wrote: > > Hi, Laslo and Hiltjo, > > > You don't sell CDs with your software anymore (this > > worked maybe 20 years ago), but you can make good money with providing > > support, which is, I think, the most probable direction. > > > > I think for businesses a development-model of selling and providing > > > the full FOSS and offer paid services for the custom work done is a > > > more fair model. > > Just to shout out and promote some examples about this, this has been > the sourcehut project [1] motto and I've seen on some other minor > projects as the miniflux app [2] and qutebrowser [3] folow the same idea > (kind of). > > It has also been the subject of a long (but good!) discussion on > LibrePlanet Discuss in the last days about this subject, if any of you > people are interested [4]. > > Best regards, > Pedro Lucas > > -- > > [1]: https://sourcehut.org/blog/2019-10-23-srht-puts-users-first > [2]: https://miniflux.app > [3]: https://qutebrowser.org > [4]: > https://lists.gnu.org/archive/html/libreplanet-discuss/2020-09/msg00041.html >
Re: [hackers] Licensing status of patches
Dear Laslo, Thanks for your reply - I appreciate that this does not have much practical importance. Unfortunately the simplest way for me to version my dwm copy is by hosting it on Github, which is in some sense "publishing" it. I was hoping to be able to do this without worrying, but it seems that the MIT license offers no such guarantee. I wonder if the suckless team had considered using the GPL (which would). Of course, it's true that in practice that a patcher is unlikely to care if their patch is shared more widely (and not all of them are so small). But after all, one could probably say the same about dwm's license itself. If I choose to share the thing more widely, I will probably take the pains to contact them. After all, it's best to be sure. Warm regards, Daniel On Tue, Sep 29, 2020 at 12:16 PM Laslo Hunhold wrote: > > On Tue, 29 Sep 2020 09:54:43 +0100 > Daniel Littlewood wrote: > > Dear Daniel, > > > Hi all, apologies if this is the wrong mailing list (I couldn't tell > > exactly where to send it). > > > > Could someone please confirm for me what the licensing status of > > patches hosted on the suckless domain is? I assume that they are > > meant to inherit the MIT/X license from their parent projects, but I > > can't see anywhere this is explicitly stated. I don't think that they > > inherit the license of the parent project by default. > > patches are usually just added as-is and don't bear a license, which > practically says "all rights reserved". This, though, doesn't matter if > you just use them for your personal needs. > > If you plan to work on a patch or republish it or something and want to > go 1000% sure, it's best to e-mail the original author of the patch and > ask him if he agrees to license it under the ISC license (which is > equivalent to the MIT/X license, but stripped of useless legal > clauses) or the GPL, whichever you prefer. If he agrees, you can > modify and republish the patch, as long as you give proper attribution. > > What should be said, though, is that I don't see a big problem with > patch licensing anyway. Neither would anybody go to court over a 10 line > diff, nor would any company respect any license or give attribution, so > let's just accept that and carry on. > > With best regards > > Laslo >
[hackers] Licensing status of patches
Hi all, apologies if this is the wrong mailing list (I couldn't tell exactly where to send it). Could someone please confirm for me what the licensing status of patches hosted on the suckless domain is? I assume that they are meant to inherit the MIT/X license from their parent projects, but I can't see anywhere this is explicitly stated. I don't think that they inherit the license of the parent project by default. All the best, Dan
