Bug#1015738: xcb-util-xrm fails to parse resources like *.foo
Feel free to just adopt this one. Thanks for taking care of it! On Wed, 20 Jul 2022 at 09:45, Jakob Haufe wrote: > On Wed, 20 Jul 2022 08:28:11 +0200 > Michael Stapelberg wrote: > > > sur5r, is updating libxcb-xrm something you’d be able to help with? > > Yes, but I will not be able to have a look for at least another week. > > > The alternative is orphaning that package and updating it via the QA > team, > > I suppose. > > Do you prefer co-/team-maintenance as with i3 or should I adopt it? > > Cheers, > sur5r > > -- > ceterum censeo microsoftem esse delendam. > -- Best regards, Michael
Bug#1015738: xcb-util-xrm fails to parse resources like *.foo
On Wed, 20 Jul 2022 08:28:11 +0200 Michael Stapelberg wrote: > sur5r, is updating libxcb-xrm something you’d be able to help with? Yes, but I will not be able to have a look for at least another week. > The alternative is orphaning that package and updating it via the QA team, > I suppose. Do you prefer co-/team-maintenance as with i3 or should I adopt it? Cheers, sur5r -- ceterum censeo microsoftem esse delendam. pgpIQn7f3X83I.pgp Description: OpenPGP digital signature
Bug#1015738: xcb-util-xrm fails to parse resources like *.foo
sur5r, is updating libxcb-xrm something you’d be able to help with? The alternative is orphaning that package and updating it via the QA team, I suppose. Thanks On Wed, 20 Jul 2022 at 04:33, Antoine Beaupre wrote: > Package: libxcb-xrm0 > Version: 1.0-3+b1 > Severity: normal > > This is a rather convoluted issue, but bear with me for a minute and > hopefully things will be a little clearer. > > I have recently changed themes to use srcery, which basically means I > loaded this Xresources file: > > > https://github.com/srcery-colors/srcery-terminal/blob/566eb23e7bbf084bb56587a08ba2df6cb65db5a8/xresources/srcery.xresources > > Notice the ... particular pattern: > > ! white > *.color7: #baa67f > *.color15: #fce8c3 > > Normally, that would be something like: > > ! white > *color7: #baa67f > *color15: #fce8c3 > > ... which was fixed in: > > > https://github.com/srcery-colors/srcery-terminal/commit/96b21803832d00fd816473fd20517d39f9245741 > > ... but, actually, *.foo *is* legal according to the X(7) > specification. The actual quote, if I may, is: > > When an application looks for the value of a resource, it specifies > a complete path in the hierarchy, with both class and instance > names. However, resource values are usually given with only > partially specified names and classes, using pattern matching > constructs. An asterisk (*) is a loose binding and is used to > represent any number of intervening components, including none. A > period (.) is a tight binding and is used to separate immediately > adjacent components. A question mark (?) is used to match any single > component name or class. A database entry cannot end in a loose > binding; the final component (which cannot be "?") must be > specified. The lookup algorithm searches the resource database for > the entry that most closely matches (is most specific for) the full > name and class being queried. When more than one database entry > matches the full name and class, precedence rules are used to select > just one. > > So this *should* work, but doesn't. This affects any package using the > libxcb-xrm0 which includes, most prominently for me, the i3 window > manager (but there are problem many others). > > This bug has been acknowledged upstream: > > https://github.com/Airblader/xcb-util-xrm/issues/79 > > ... and fixed over 4 years ago, in a release that was shipped as 1.3 > in March 2018: > > https://github.com/Airblader/xcb-util-xrm/releases/tag/v1.3 > > It seems like Debian should probably fix this bug as well, so I'm > filing this here to make sure we have that particularly hairy issue, > which sent me spinning over three different GitHub projects (i3, > xcb-util-frm, and srcery). ;) > > More details in: > > https://github.com/i3/i3/discussions/5051 > https://github.com/srcery-colors/srcery-terminal/pull/164 > > Thanks! > > -- System Information: > Debian Release: 11.3 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, > 'stable'), (1, 'unstable'), (1, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads) > Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libxcb-xrm0 depends on: > ii libc6 2.31-13+deb11u3 > ii libxcb-util1 0.4.0-1+b1 > ii libxcb1 1.14-3 > > libxcb-xrm0 recommends no packages. > > libxcb-xrm0 suggests no packages. > > -- no debconf information > -- Best regards, Michael
Bug#1015738: xcb-util-xrm fails to parse resources like *.foo
Package: libxcb-xrm0 Version: 1.0-3+b1 Severity: normal This is a rather convoluted issue, but bear with me for a minute and hopefully things will be a little clearer. I have recently changed themes to use srcery, which basically means I loaded this Xresources file: https://github.com/srcery-colors/srcery-terminal/blob/566eb23e7bbf084bb56587a08ba2df6cb65db5a8/xresources/srcery.xresources Notice the ... particular pattern: ! white *.color7: #baa67f *.color15: #fce8c3 Normally, that would be something like: ! white *color7: #baa67f *color15: #fce8c3 ... which was fixed in: https://github.com/srcery-colors/srcery-terminal/commit/96b21803832d00fd816473fd20517d39f9245741 ... but, actually, *.foo *is* legal according to the X(7) specification. The actual quote, if I may, is: When an application looks for the value of a resource, it specifies a complete path in the hierarchy, with both class and instance names. However, resource values are usually given with only partially specified names and classes, using pattern matching constructs. An asterisk (*) is a loose binding and is used to represent any number of intervening components, including none. A period (.) is a tight binding and is used to separate immediately adjacent components. A question mark (?) is used to match any single component name or class. A database entry cannot end in a loose binding; the final component (which cannot be "?") must be specified. The lookup algorithm searches the resource database for the entry that most closely matches (is most specific for) the full name and class being queried. When more than one database entry matches the full name and class, precedence rules are used to select just one. So this *should* work, but doesn't. This affects any package using the libxcb-xrm0 which includes, most prominently for me, the i3 window manager (but there are problem many others). This bug has been acknowledged upstream: https://github.com/Airblader/xcb-util-xrm/issues/79 ... and fixed over 4 years ago, in a release that was shipped as 1.3 in March 2018: https://github.com/Airblader/xcb-util-xrm/releases/tag/v1.3 It seems like Debian should probably fix this bug as well, so I'm filing this here to make sure we have that particularly hairy issue, which sent me spinning over three different GitHub projects (i3, xcb-util-frm, and srcery). ;) More details in: https://github.com/i3/i3/discussions/5051 https://github.com/srcery-colors/srcery-terminal/pull/164 Thanks! -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxcb-xrm0 depends on: ii libc6 2.31-13+deb11u3 ii libxcb-util1 0.4.0-1+b1 ii libxcb1 1.14-3 libxcb-xrm0 recommends no packages. libxcb-xrm0 suggests no packages. -- no debconf information
