Re: Bug#1010304: bullseye-pu: package freetype/2.10.4+dfsg-1+deb11u1
Hi Adam, On Sun, 29 May 2022 at 05:16, Adam D. Barratt wrote: > This looks OK to me, but as freetype builds a udeb it will want a KiBi- > ack; CCed and tagging accordingly. Thanks for the ack. I've been waiting for KiBi, but just wanted to check whether I'm supposed to upload before that happens. Hugh
Re: Debian 10.2 LinuxCenter Peterburg
Hallo Lennart, On Fri, 28 Feb 2020 at 03:08, Lennart Sorensen wrote: > > On Thu, Feb 27, 2020 at 10:36:07PM +1100, Hugh McMaster wrote: > > After using the graphical installer in a virtual machine, setting the > > root and standard user passwords, and finally restarting, the root > > password is not accepted, so the user cannot login as root or use sudo > > as a normal user. > > Can you use 'su -l' as a normal user to become root? > Can you switch to tty1 (left control+left alt+F1) and login as root there? Both of these work correctly. What I was actually thinking of was an issue with `adduser sudo`. It now requires a reboot instead of just logging out and in as a normal user. > Not being able to login to the GUI as root is expected. You can log in as the root user using Cinnamon by default.
Re: Debian 10.2 LinuxCenter Peterburg
Hallo Holger, On Wed, 26 Feb 2020 at 03:01, Holger Wansing wrote: > I have just tested with an 10.3 netinst amd64 image, and it works as it > should. > So, you will need to give more information, in order to be able to help you. > - which installation image did you use exactly? > - please provide the installation logs. The behaviour described is present in the weekly Debian Testing net install image (I used amd64). After using the graphical installer in a virtual machine, setting the root and standard user passwords, and finally restarting, the root password is not accepted, so the user cannot login as root or use sudo as a normal user. Hugh
Re: Bug#932900: buster-pu: package freetype 2.9.1-4
Hi Cyril, On Sat, 27 Jul 2019 at 8:40 pm, Cyril Brulebois wrote: > Adam D. Barratt (2019-07-26): > > As freetype produces a udeb, this will need an ack from the d-i > > release manager, so CCing and tagging appropriately. > > I'll need some time to get that tested properly. How are you getting on with this? Hugh >
Re: Bug#932900: buster-pu: package freetype 2.9.1-4
Hi Adam, On Sat, 27 Jul 2019 at 05:08, Adam D. Barratt wrote: > Please either set the metadata appropriately here to indicate a stable > update, or use reportbug which will do it for you. (In this case, > someone already corrected it.) So, this is what happens when I'm in a hurry. Thanks to Paul for adding the correct tags and bug information. reportbug doesn't actually support buster-pu yet. In saying that, the next logical step would have been to check which pseudo headers were required. > -4 has already been uploaded to unstable, so this would need to be > 2.9.1-3+deb10u1. The changelog distribution is also preferred as > "buster", rather than "stable". Noted. I've updated the debdiff accordingly. Hugh
Bug#897982: tasksel: Please drop tamil-gtk2im from the task-tamil-gnome-desktop Recommends list
> On 1 Oct 2018, at 4:21 am, Holger Wansing wrote: > Hugh McMaster wrote: >> How will switching to ibus-m17n affect the user experience or installation? > > That's out of my skills, sorry. No problem. If no one else has any objections, then I’m happy for you to drop the Recommends and/or replace it.
tasksel migration to Salsa
Hi, Could someone please migrate ‘tasksel’ to Salsa? It is still on Alioth. Thank you, Hugh
Re: Mass bug filing for the removal of freetype-config and freetype.m4
Hi Simon, On Friday, 2 February 2018 11:14 PM, Simon McVittie wrote: > On Thu, 01 Feb 2018 at 11:07:42 +0000, Hugh McMaster wrote: >> Freetype-config has been considered deprecated for several years [1]. > > By us, or by upstream? Both. We considered freetype-config a deprecated legacy interface back in 2011 [1]. Upstream also recommend using pkg-config over freetype-config in freetype-config(1). In fact, freetype-config has used pkg-config as a wrapper since February 2017 [2]. > Is there a reason to prefer removing AC_CHECK_FT2, rather than patching > it to provide enough of its historical functionality for (I'd guess) 90% > of packages? Something like this should work (untested): > > AC_DEFUN([AC_CHECK_FT2], > [ >PKG_CHECK_MODULES([FT2], [freetype2 >= $1], [$2], m4_if([$3], [], [:], > [$3])) > ]) > > (This doesn't do the sanity-checks that current AC_CHECK_FT2 does, > and it respects PKG_CONFIG_PATH instead of --with-ft-prefix, > --with-ft-exec-prefix and FT_CONFIG, but this shouldn't matter most of > the time; and it seems better if simple packages still compile than if > they don't.) codesearch.debian.net shows 26 packages referencing AC_CHECK_FT2. > Does Freetype's upstream developer consider AC_CHECK_FT2 to be deprecated > too? Not as far as I can tell. That said, I'm not against patching the m4 macro to use PKG_CHECK_MODULES if you believe it will be useful. > If we ask the upstream developers of various packages to make a change > because otherwise their package won't compile on Debian, some of them > will say "well, that's Debian's fault for removing APIs provided by > Freetype's upstream developer" and do nothing. If we ask them to make a > change because Freetype upstream has officially deprecated the macro/tool > they're using, or because otherwise their package (eventually) won't > compile against newer upstream Freetype releases, it seems more likely > to happen. > > Not carrying long-term patches to the build systems of a large number of > packages seems a good goal. Good point. I'll file a bug upstream to ask them to drop freetype-config. In the meantime, I'll do the mass bug filing for Debian. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642354#10 [2] http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/builds/unix/freetype-config.in?id=1c513fbb8872bfac5631964963b6a751169a1ce6
Mass bug filing for the removal of freetype-config and freetype.m4
Hi everyone, I intend to do a mass bug filing against all packages that use freetype-config and/or freetype.m4, as these APIs will be removed from libfreetype6-dev in the next maintainer release. This is a Debian-specific change. Freetype-config has been considered deprecated for several years [1]. Although it is suitable for compiling for the native architecture (i.e. host = build), it cannot handle cross-compiling. See, for example [1], [2] and [3]. Freetype-config also acts as a wrapper for pkg-config, if that package is installed. However, as explained in [2] and [3], this does not help with cross-compiling, because "pkg-config must be qualified with the GNU triplet of the package architecture" in order to output the correct library paths. I asked for freetype-config to be removed in [4] to allow libfreetype6-dev to become Multi-Arch: same. Five months later, I compromised and patched freetype-config to remove the hard-coded libdir paths causing the multi-arch file conflict. A separate change (build-depending on pkg-config) fixed [5], but caused additional bugs when libfreetype6-dev is installed for foreign architectures only (see [2] and [3]). In these bugs, freetype-config was calling pkg-config for the native architecture. Following discussions in [3] and further investigation, the decision was made to remove freetype-config and freetype.m4 to better support multi-arch usage. With this in mind, I removed freetype-config and built all reverse build-dependencies. I have also searched codesearch.debian.net for use of AC_CHECK_FT2 in configure.ac and configure.in. (Thanks to Simon McVittie for the suggestion.) A list of affected source packages is attached. 36 packages FTBFS without freetype-config. Another 25 compile, but warn that freetype was not detected. 26 of the 61 packages already use pkg-config to detect other libraries, so updating those packages to detect freetype2 using pkg-config is straightforward. The proposed wording for the bug reports reads: Dear Maintainer, The next release of libfreetype6-dev will *not* ship freetype-config or or freetype2.m4. This is a Debian-specific change. Please use pkg-config to detect the freetype2 headers and libraries. If this bug is not resolved prior to the release of the next version of libfreetype6-dev, your package may FTBFS. Thank you I realise removing freetype-config may not be popular. However, the long-term benefits will outweigh any short-term inconvenience. -- Hugh McMaster [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642354 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871470 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886461 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870618 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885324List of packages affected by the removal of freetype-config: D Haley <my...@gmx.com> 3depict (U) Debian Science Maintainers <debian-science-maintain...@lists.alioth.debian.org> 3depict Barry deFreese <bdefre...@debian.org> adonthell (U) Debian Games Team <pkg-games-de...@lists.alioth.debian.org> adonthell Robert Luberda <rob...@debian.org> afterstep Barry deFreese <bdefre...@debian.org> asc (U) Bartosz Fenski <fe...@debian.org> asc (U) Debian Games Team <pkg-games-de...@lists.alioth.debian.org> asc Markus Koschany <a...@debian.org> asc (U) Sam Hocevar <s...@debian.org> asc (U) Barry deFreese <bddeb...@comcast.net> brutalchess (U) Debian Games Team <pkg-games-de...@lists.alioth.debian.org> brutalchess Vincent Legout <vleg...@debian.org> brutalchess (U) Debian OCaml Maintainers <debian-ocaml-ma...@lists.debian.org> camlimages Mehdi Dogguy <me...@debian.org> camlimages (U) Ralf Treinen <trei...@debian.org> camlimages (U) Debian Games Team <pkg-games-de...@lists.alioth.debian.org> cube2font Martin Erik Werner <martinerikwer...@gmail.com> cube2font (U) Debian QA Group <packa...@qa.debian.org> dia Marc Leeman <marc.lee...@gmail.com> dvdauthor OHURA Makoto <oh...@debian.org> dvi2ps Varun Hiremath <va...@debian.org> dvipng Barry deFreese <bdefre...@debian.org> fenix-plugins (U) Debian Games Team <pkg-games-de...@lists.alioth.debian.org> fenix-plugins Miriam Ruiz <little_m...@yahoo.es> fenix-plugins (U) Peter Pentchev <r...@ringlet.net> fenix-plugins (U) Michele Martone <michelemart...@users.sourceforge.net> fim Rafael Laboissiere <raf...@debian.org> fim (U) Aaron M. Ucko <u...@debian.org> fltk1.1 Debian Games Team <pkg-games-de...@lists.alioth.debian.org> foobillardplus Markus Koschany <a...@debian.org> foobillardplus (U) Sam Hocevar <s...@debian.org> ftgl Jaimos Skriletz <jaimosskril...
Re: freetype: incorrect shlibs file generation
Hi Cyril, On Thursday, 21 December 2017 11:53 PM, Cyril Brulebois wrote: > Yeah, that would look good to me, provided there's nothing added in a > x.y.z version that would make the udeb depend on x.y (in the metadata > section) while it actually depends on a feature introduced in a x.y.z > (on a shared object level). This shouldn't happen, since freetype uses x.y.z as major.minor.patch. So a release incrementing z should only fix bugs, not alter the API. > FWIW dh_makeshlibs supports being called with a -V option. Excerpt of > its manpage: > [snip] > That might be a safer approach? Yes, but it is conservative, perhaps. 'dh_makeshlibs -V' then depends on 2.8.1. Given what we know about freetype's versioning, this doesn't seem necessary IMO. On another note, I was wondering if using 'cut' is simpler than 'sed'? $(shell echo "$(ver)" | cut -f-2 -d'.') Thanks, Hugh
freetype: incorrect shlibs file generation
Hi Cyril, Assuming I understand the problem correctly, the attached patch should help. After compiling and installing, I have the following in /var/lib/dpkg/info/libfreetype6:amd64.shlibs: libfreetype 6 libfreetype6 (>= 2.8) udeb: libfreetype 6 libfreetype6-udeb (>= 2.8) Hope this helps. Hugh freetype2-shlibs.patch Description: freetype2-shlibs.patch
