Re: gitlab migration
On Tue, Jun 12, 2018 at 01:41:55PM +0100, Daniel Stone wrote: > Hi Sylvain, > > On 12 June 2018 at 13:38, wrote: > > On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: > >> GitLab has a pretty comprehensive and well-documented API which might > >> help if you don't want to use a web browser. There are also clients > >> like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI > >> interface. > > > > Those "web APIs" usually require the use of an heavy javascript browser for > > authentification or "app authorization". > > > > That said, I could not even create an account with a noscript/xhtml basic > > browser (if you want to test that, install the famous noscript module with > > an > > empty "white list" in firefox or chromium, or use lynx or links or w3m). > > No need to test; it's guaranteed to fail since we require Recaptcha > for login due to massive spam issues. Why is this captcha not noscript/xhtml basic friendly? (You could use also netsurf browser which has some static css support) regards, -- Sylvain ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote: > Hi Sylvain, > It looks like Mutt is mangling email addresses - I've fixed Michel's. > > On 11 June 2018 at 14:30, wrote: > > On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote: > >> Adding the amd-gfx list, in cases somebody there has concerns or other > >> feedback. > > > > For feedback: > > I attempted a migration on gitlab of my repos but I was blocked because it's > > not noscript/xhtml basic browser friendly. > > > > I was successfull with launchpad.net (which has now git support). > > > > I did not test if the issue system was noscript/xhtml basic friendly though. > > GitLab has a pretty comprehensive and well-documented API which might > help if you don't want to use a web browser. There are also clients > like 'lab': https://gitlab.com/zaquestion/lab which provide a good CLI > interface. Hi, Those "web APIs" usually require the use of an heavy javascript browser for authentification or "app authorization". That said, I could not even create an account with a noscript/xhtml basic browser (if you want to test that, install the famous noscript module with an empty "white list" in firefox or chromium, or use lynx or links or w3m). regards, -- Sylvain ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-proto] Remove libdir from pc files.
Currently the pc files define libdir, however they are installed into /usr/share, which means they should be architecture agnostic. In a multilib system, xorg-proto built for each multilib abi, the value of libdir is going to be different. These should either be installed in /pkgconfig or they shouldn't define libdir, espeically since they don't actually use the definition. This specifically causes an issue when trying to install both abis at the same time, since they are not binary identical, something like rpm will complain that they conflict. Signed-off-by: Jeremy Puhlman --- applewmproto.pc.in | 1 - bigreqsproto.pc.in | 1 - compositeproto.pc.in | 1 - damageproto.pc.in | 1 - dmxproto.pc.in | 1 - dri2proto.pc.in| 1 - dri3proto.pc.in| 1 - evieproto.pc.in| 1 - fixesproto.pc.in | 1 - fontcacheproto.pc.in | 1 - fontsproto.pc.in | 1 - glproto.pc.in | 1 - inputproto.pc.in | 1 - kbproto.pc.in | 1 - lg3dproto.pc.in| 1 - presentproto.pc.in | 1 - printproto.pc.in | 1 - randrproto.pc.in | 1 - recordproto.pc.in | 1 - renderproto.pc.in | 1 - resourceproto.pc.in| 1 - scrnsaverproto.pc.in | 1 - trapproto.pc.in| 1 - videoproto.pc.in | 1 - windowswmproto.pc.in | 1 - xcalibrateproto.pc.in | 1 - xcmiscproto.pc.in | 1 - xextproto.pc.in| 1 - xf86bigfontproto.pc.in | 1 - xf86dgaproto.pc.in | 1 - xf86driproto.pc.in | 1 - xf86miscproto.pc.in| 1 - xf86rushproto.pc.in| 1 - xf86vidmodeproto.pc.in | 1 - xineramaproto.pc.in| 1 - xproto.pc.in | 1 - xproxymngproto.pc.in | 1 - 37 files changed, 37 deletions(-) diff --git a/applewmproto.pc.in b/applewmproto.pc.in index 17841ac..3227b21 100644 --- a/applewmproto.pc.in +++ b/applewmproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: AppleWMProto diff --git a/bigreqsproto.pc.in b/bigreqsproto.pc.in index 94577ed..e21bb59 100644 --- a/bigreqsproto.pc.in +++ b/bigreqsproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: BigReqsProto diff --git a/compositeproto.pc.in b/compositeproto.pc.in index da429c7..b0dada1 100644 --- a/compositeproto.pc.in +++ b/compositeproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: CompositeExt diff --git a/damageproto.pc.in b/damageproto.pc.in index 6fd9ef1..bfd5244 100644 --- a/damageproto.pc.in +++ b/damageproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: DamageProto diff --git a/dmxproto.pc.in b/dmxproto.pc.in index e82ee7d..d140e1c 100644 --- a/dmxproto.pc.in +++ b/dmxproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: DMXProto diff --git a/dri2proto.pc.in b/dri2proto.pc.in index cb5b171..fa9d24d 100644 --- a/dri2proto.pc.in +++ b/dri2proto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: DRI2Proto diff --git a/dri3proto.pc.in b/dri3proto.pc.in index e42d60e..20da358 100644 --- a/dri3proto.pc.in +++ b/dri3proto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: DRI3Proto diff --git a/evieproto.pc.in b/evieproto.pc.in index 64e0ec4..fd5442b 100644 --- a/evieproto.pc.in +++ b/evieproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: EvIEExt diff --git a/fixesproto.pc.in b/fixesproto.pc.in index f8258e2..c7fcb81 100644 --- a/fixesproto.pc.in +++ b/fixesproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: FixesProto diff --git a/fontcacheproto.pc.in b/fontcacheproto.pc.in index eb4238b..8e9 100644 --- a/fontcacheproto.pc.in +++ b/fontcacheproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: FontcacheProto diff --git a/fontsproto.pc.in b/fontsproto.pc.in index 9d22354..ebb61a4 100644 --- a/fontsproto.pc.in +++ b/fontsproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: FontsProto diff --git a/glproto.pc.in b/glproto.pc.in index b951db5..e97bfc9 100644 --- a/glproto.pc.in +++ b/glproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: GLProto diff --git a/inputproto.pc.in b/inputproto.pc.in index 1eb6619..270b95c 100644 --- a/inputproto.pc.in +++ b/inputproto.pc.in @@ -1,6 +1,5 @@ prefix=@prefix@ exec_prefix=@exec_prefix@ -libdir=@libdir@ includedir=@includedir@ Name: InputProto diff --git
Re: gitlab migration
Hi Felix, On Wed, 13 Jun 2018 at 04:17, Felix Miata wrote: > James Cloos composed on 2018-06-12 17:38 (UTC-0400): > > Two comments: > > > BZ is superior to GL (or GH or the like). > > Strongly agree, especially for returning useful search results!!! What kind of searches have you tried which returned better search results on Bugzilla than GitLab? Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, 12 Jun 2018 at 22:36, James Cloos wrote: > > "DS" == Daniel Stone writes: > DS> No need to test; it's guaranteed to fail since we require Recaptcha > DS> for login due to massive spam issues. > > Which is of course grossly unethical and malicious and should never be > used by any site, under any circumstances. > > If some sort of captcha is ever desired, it always must be something > which works with non-ecmacsipt, TUI browsers. > > A simple math question with a simple html text box for the answer is OK. > Or a technical question specific to the given project. > > But never goog's malicious crap. I assume that you're unaware of the levels of spam we've been dealing with, including the number of times we've been blacklisted by major mail providers, the extent to which search engines used to distrust us, and the amount of admin time spent dealing with it. Now you've got whatever it was out of your system, maybe you could come back with some kind of actionable feedback, or a constructive plan to address the genuine problems that we've been discussing both here and at various conferences for the last two or three years which have led to GitLab. Maybe you could venture a real suggestion for dealing with spam which also works with noscript lynx or whatever; ideally one which was better than our previous version which did genuinely cause people issues. Or maybe you could go look at the CLI client for GitLab I've already pointed to, and read the API documentation. Or just continue the useless flames trying to enforce your opinion as universal fact, every single line of which should carry '[citation needed]'. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
Hi Felix, On Wed, 13 Jun 2018 at 10:24, Felix Miata wrote: > Daniel Stone composed on 2018-06-13 09:24 (UTC+0100): > > Felix Miata wrote: > >> James Cloos composed on 2018-06-12 17:38 (UTC-0400): > >> > BZ is superior to GL (or GH or the like). > > >> Strongly agree, especially for returning useful search results!!! > > > What kind of searches have you tried which returned better search > > results on Bugzilla than GitLab? > > I gave up trying too long ago to remember. Best of my recollection is all of > them, generally getting too many to sift through, or zarro. I'm speaking of > gitlab/github (which is it anyway?) generally, not any specific project's. BZ > I > got used to over 17 years go, when learning new things had not yet become > problematic. GitLab and GitHub are two completely different services. They offer different features in different ways through different user interfaces, and have both been evolving pretty quickly. Saying emphatically!!! that GitLab's search results are useless, based on vague recollections of having used a _different service_ which was so long ago you can't even remember, isn't really a great contribution to a discussion. > Bad as yesteryear's web was, the current one is worse. Firefox ESR 60 download > is 648% the size of Firefox 1.0. All the benefit of broadband has been eaten > up > by bottlenecks, bloated browsers and gargantuan web pages. Googling 'gitlab > xorg' or 'github xorg' don't provide anything resembling an actual home page > URI > like https://bugs.freedesktop.org/. https://www.x.org/wiki/Development/ > doesn't > either. Maybe these are a good sign, one to indicate Ajax's migration hasn't > actually started. Yes. This thread is to discuss migrating to GitLab at some point in the future. Since it has not happened yet, there is no entrypoint to speak of. I can't solve your problems with web browsers, bottlenecks and people using JavaScript, but again, both Bugzilla and GitLab are web-based tools, and GitLab has a complete API with CLI-based tools you can use instead of a browser. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-proto] Remove libdir from pc files.
Jeremy Puhlman writes: > Currently the pc files define libdir, however they are installed into > /usr/share, which means they should be architecture agnostic. Makes sense to me; none of these install any libraries. Reviewed-by: Keith Packard -- -keith signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-proto] Remove libdir from pc files.
On Wed, 2018-06-13 at 06:58 -0700, Keith Packard wrote: > Jeremy Puhlman writes: > > > Currently the pc files define libdir, however they are installed into > > /usr/share, which means they should be architecture agnostic. > > Makes sense to me; none of these install any libraries. > > Reviewed-by: Keith Packard Merged, thanks: remote: I: patch #229208 updated using rev 91c1c8e1490c970379efb16784003426faec806e. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/proto/xorgproto 95570b0..91c1c8e master -> master - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Problems in editres.1, libinput.4, s3.4, xlogo.1, Xserver.1, xterm.1
On 06/12/18 12:16 PM, e...@thyrsus.com wrote: This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond Problems with xterm.1: X.Org does not maintain xterm. You'll need to report this to Thomas Dickey: http://invisible-island.net/xterm/ Problems with editres.1: Already fixed in editres 1.0.7, please upgrade: https://cgit.freedesktop.org/xorg/app/editres/commit/?id=57e1f1c4aa60136ab22e3faf75832c728beee4aa Problems with s3.4: Already fixed in git - no one has bothered doing a new release since 2012 for this driver for ancient hardware: https://cgit.freedesktop.org/xorg/driver/xf86-video-s3/commit/?id=92d10d5d6882c3db6695a8fff83c88fbaaa27a33 Problems with xlogo.1: Already fixed in git - no one has bothered doing a new release since 2012 though as there really isn't much change in the X Logo display code: https://cgit.freedesktop.org/xorg/app/xlogo/commit/?id=84c0386d7c3db6307566219cbe7fe58d9587585a Problems with Xserver.1: Use of low-level troff hackery to set special indents or breaks can't be translated. The page will have rendering faults in HTML, and probably also under third-party man page browsers such as Xman, Rosetta, and the KDE help browser. This patch eliminates .br, .ta, .ti, .ce, .in, and \h in favor of requests like .RS/.RE that have structural translations. That description does not match the patch you provided: --- Xserver.1-unpatched 2018-05-18 14:15:55.627764185 -0400 +++ Xserver.1 2018-05-18 14:15:55.423765571 -0400 @@ -416,7 +416,7 @@ Yet another XDMCP specific value, this one allows the display manager to identify each display so that it can locate the shared key. .SH XKEYBOARD OPTIONS -X servers that support the XKEYBOARD (a.k.a. \*qXKB\*q) extension accept the +X servers that support the XKEYBOARD (a.k.a. XKB) extension accept the following options. All layout files specified on the command line must be located in the XKB base directory or a subdirectory, and specified as the relative path from the XKB base directory. The default XKB base directory is @@ -566,7 +566,7 @@ .fi This will add /usr/share/X11/fonts/misc as the first FPE with the attribute -\N'39'unscaled', second FPE will be /usr/share/X11/fonts/75dpi, also with +\&'unscaled', second FPE will be /usr/share/X11/fonts/75dpi, also with the attribute 'unscaled' etc. This is functionally equivalent to setting the following font path: -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/2] xwayland: mandatory EGL backend API
Reviewed-by: Lyude Paul
On Mon, 2018-06-11 at 10:22 +0200, Olivier Fourdan wrote:
> The API init_wl_registry() and has_wl_interfaces() are marked as being
> optional, but both GBM And EGLStream backends implement them so there is
> point in keeping those optional.
>
> Suggested-by: Emil Velikov
> Signed-off-by: Olivier Fourdan
> ---
> hw/xwayland/xwayland-glamor.c | 8 +---
> hw/xwayland/xwayland.h| 6 ++
> 2 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
> index 61418e707..f17914344 100644
> --- a/hw/xwayland/xwayland-glamor.c
> +++ b/hw/xwayland/xwayland-glamor.c
> @@ -72,14 +72,12 @@ xwl_glamor_init_wl_registry(struct xwl_screen *xwl_screen,
> uint32_t version)
> {
> if (xwl_screen->gbm_backend.is_available &&
> -xwl_screen->gbm_backend.init_wl_registry &&
> xwl_screen->gbm_backend.init_wl_registry(xwl_screen,
> registry,
> id,
> interface,
> version)); /* no-op */
> else if (xwl_screen->eglstream_backend.is_available &&
> - xwl_screen->eglstream_backend.init_wl_registry &&
> xwl_screen->eglstream_backend.init_wl_registry(xwl_screen,
> registry,
> id,
> @@ -91,11 +89,7 @@ Bool
> xwl_glamor_has_wl_interfaces(struct xwl_screen *xwl_screen,
> struct xwl_egl_backend *xwl_egl_backend)
> {
> -if (xwl_egl_backend->has_wl_interfaces)
> -return xwl_egl_backend->has_wl_interfaces(xwl_screen);
> -
> -/* If the backend has no requirement wrt WL interfaces, we're fine */
> -return TRUE;
> +return xwl_egl_backend->has_wl_interfaces(xwl_screen);
> }
>
> struct wl_buffer *
> diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> index dc01c747c..d70ad54bf 100644
> --- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -64,16 +64,14 @@ struct xwl_egl_backend {
> Bool is_available;
>
> /* Called once for each interface in the global registry. Backends
> - * should use this to bind to any wayland interfaces they need. This
> - * callback is optional.
> + * should use this to bind to any wayland interfaces they need.
> */
> Bool (*init_wl_registry)(struct xwl_screen *xwl_screen,
> struct wl_registry *wl_registry,
> uint32_t id, const char *name,
> uint32_t version);
>
> -/* Check that the required Wayland interfaces are available. This
> - * callback is optional.
> +/* Check that the required Wayland interfaces are available.
> */
> Bool (*has_wl_interfaces)(struct xwl_screen *xwl_screen);
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Obtaining Xorg DDX commit privilege
Hi Connor, I personally did not realize it often takes weeks to get patches committed. I will apologize if I was somewhat rough towards you. Anyway, thank you very much for committing the patches into the repository, and I will link this e-mail as an endorsement for myself obtaining xorg device driver commit privilege. Moving forward, I will always post the patches for r128 DDX code and leave it there for 3 to 5 days in case you want to comment on it. Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com > Sent: Monday, June 11, 2018 at 7:04 AM > From: "Connor Behan" > To: "Kevin Brace" , xorg-devel@lists.x.org > Subject: Re: Obtaining Xorg DDX commit privilege > > There are some mailing lists where I would kill to have the turnaround > time only be a week. It was also not clear to me whether you wanted > these patches pushed before or after the privilege upgrade. For what > it's worth, I think it's clear that you care about this DDX. So if the > two admins who have entered the discussion here are still reading, let > this serve as my recommendation. > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
