Re: Unmaintained packages in base package set
On 03/01/2024 08:49, Marco Atzeri wrote: +librsvg2 Marco Atzeri just discovered that librsvg2 requires Rust by long time ** The librsvg 2.40.x series is the last "C only" version of the library; it was deprecated in 2017.** https://viruta.org/do-not-use-librsvg-2.40.x.html https://viruta.org/docs/fmq-porting-c-to-rust.pdf So until we have a Rust compiler no new release is possible Regards Marco
Re: Unmaintained packages in base package set
Takashi Yano via Cygwin-apps writes: > I found the cause. DISTCLEANFILES in original cygport file removes them. > Now I can successfully build libatk1.0-doc. Thanks! No, that means the tarball includes files that should get re-built, but apparently you somehow failed to do that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Unmaintained packages in base package set
On Sun, 7 Jan 2024 22:35:02 +0900 Takashi Yano via wrote: > In the source file, docs/xml directory should have document contents, > however, it is empty. So, I thought document cannot be built in this > version. I'll check again. I found the cause. DISTCLEANFILES in original cygport file removes them. Now I can successfully build libatk1.0-doc. Thanks! -- Takashi Yano
Re: Unmaintained packages in base package set
On Sun, 7 Jan 2024 12:54:35 +
Jon Turney wrote:
> > ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends:
> > 'girepository(GLib-2.0)', but nothing satisfies that
> > ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends:
> > 'pkgconfig(glib-2.0)', but nothing satisfies that
> > ERROR: package 'libatk1.0-doc' version '2.38.0-1' has empty install tar
> > file, but it's not in ['_obsolete'] category
>
> I guess I should ask about these errors and how you fixed them:
>
> * This documented but unimplemented style of dependency atom was dropped
> [1], because we don't have a good way of supporting it.
>
> But rather than just removing them, they should probably have been
> replaced with the appropriate package names (those containing
> GLib-2.0.gir and glib-2.0.pc, i.e. girepository-GLib2.0 and
> libglib2.0-devel)
The previous cygport file uses DEPEND and cygport warned to use
BUILD_REQUIRES instead. Then the above error occured. So, I just
remove them because I was not sure how to fix that.
Thanks for letting me know that!
> * Are you sure that libatk1.0-doc should be empty now (and not that it
> requires some tool to build the documentation which isn't installed)?
In the source file, docs/xml directory should have document contents,
however, it is empty. So, I thought document cannot be built in this
version. I'll check again.
> If it is the case that the documentation doesn't exist any more, I think
> you should perhaps make some arrangement for obsoleting the package,
> rather than simply stopping generating it, allowing the previous version
> to linger indefinitely in places where it is already installed.
Now the cygport file has the line:
libatk1_0_0_OBSOLETES="lib${NAME}-doc"
> (e.g. obsoleting it by the devel package, or marking the package as
> self-destruct)
Is this as you suggested?
--
Takashi Yano
Re: Unmaintained packages in base package set
On 03/01/2024 07:49, Marco Atzeri via Cygwin-apps wrote: On 03/01/2024 05:59, Takashi Yano via Cygwin-apps wrote: On Sat, 23 Dec 2023 04:51:22 +0100 Marco Atzeri wrote: On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: I suggest to start with the smaller beasts one by one or small groups I suspect GTK3 needs a lot of effort Thanks for the advice. Now, GTK3 package of 3.24.39 has been successfully built and packaged in my environment with updating some other related packages. So, firstly, I would like to take over following packages that are related to GTK3. fribidi 0.19.7 -> 1.0.13 libdatrie 0.28 -> 0.2.13 libthai 0.1.26 -> 0.1.29 pango1.0 1.40.14 -> 1.51.0 atk1.0 2.26.1 -> 2.38.0 gtk3 3.22.28 -> 3.24.39 Firstly, thanks for taking over these. ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends: 'girepository(GLib-2.0)', but nothing satisfies that ERROR: package 'atk1.0-src' version '2.38.0-1' build-depends: 'pkgconfig(glib-2.0)', but nothing satisfies that ERROR: package 'libatk1.0-doc' version '2.38.0-1' has empty install tar file, but it's not in ['_obsolete'] category I guess I should ask about these errors and how you fixed them: * This documented but unimplemented style of dependency atom was dropped [1], because we don't have a good way of supporting it. But rather than just removing them, they should probably have been replaced with the appropriate package names (those containing GLib-2.0.gir and glib-2.0.pc, i.e. girepository-GLib2.0 and libglib2.0-devel) * Are you sure that libatk1.0-doc should be empty now (and not that it requires some tool to build the documentation which isn't installed)? If it is the case that the documentation doesn't exist any more, I think you should perhaps make some arrangement for obsoleting the package, rather than simply stopping generating it, allowing the previous version to linger indefinitely in places where it is already installed. (e.g. obsoleting it by the devel package, or marking the package as self-destruct) [1] https://cygwin.com/cgit/cygwin-apps/cygport/commit/?id=c8cb44a50377fb87c579280a490fc127562ced40
Re: Unmaintained packages in base package set
StopSent from my T-Mobile 5G Device Original message From: Takashi Yano via Cygwin-apps Date: 1/2/24 9:00 PM (GMT-08:00) To: cygwin-apps@cygwin.com Subject: Re: Unmaintained packages in base package set On Sat, 23 Dec 2023 04:51:22 +0100Marco Atzeri wrote:> On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote:> > On Wed, 20 Dec 2023 12:16:05 +> > Jon Turney via Cygwin-apps wrote:> >> I tweaked the unmaintained packages report [1] a bit so it identifies> >> 'base' and 'direct or indirect base dependencies'.> >>> >> (But you're quite right to point out that the build requirements for a> >> native Cygwin build are also important)> >>> >> [1] https://cygwin.com/packages/reports/unmaintained.html> > > > I would like to take over:> > libass> > fontconfig> > fribidi> > gnutls> > openjpeg> > librsvg2> > snappy> > libssh> > dbus> > gtk3> > orc> > tdb> > db> > libid3tag> > libmad> > taglib> > if no one like to do that, because the packages> > I maintain use them.> > all in one shot ?> I suggest to start with the smaller beasts one by one or small groups> I suspect GTK3 needs a lot of effortThanks for the advice.Now, GTK3 package of 3.24.39 has been successfully built and packagedin my environment with updating some other related packages.So, firstly, I would like to take over following packages that are relatedto GTK3.fribidi 0.19.7 -> 1.0.13libdatrie 0.28 -> 0.2.13libthai 0.1.26 -> 0.1.29pango1.0 1.40.14 -> 1.51.0atk1.0 2.26.1 -> 2.38.0gtk3 3.22.28 -> 3.24.39> > libass> > fontconfig> > gnutls> > openjpeg> > snappy> > libssh> > dbus> > orc> > tdb> > db> > libid3tag> > libmad> > taglibwill be next steps. I will try them one by one.> I could be interested in librsvg2 for the same reason of youPlease feel free to take it over. I'd withdraw from librsvg2.-- Takashi Yano
Re: Unmaintained packages in base package set
On 03/01/2024 05:59, Takashi Yano via Cygwin-apps wrote: On Sat, 23 Dec 2023 04:51:22 +0100 Marco Atzeri wrote: On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: I suggest to start with the smaller beasts one by one or small groups I suspect GTK3 needs a lot of effort Thanks for the advice. Now, GTK3 package of 3.24.39 has been successfully built and packaged in my environment with updating some other related packages. So, firstly, I would like to take over following packages that are related to GTK3. fribidi 0.19.7 -> 1.0.13 libdatrie 0.28 -> 0.2.13 libthai 0.1.26 -> 0.1.29 pango1.0 1.40.14 -> 1.51.0 atk1.0 2.26.1 -> 2.38.0 gtk3 3.22.28 -> 3.24.39 $ git diff |grep "^+" +++ b/cygwin-pkg-maint +atk1.0 Takashi Yano +fribidi Takashi Yano +gtk3 Takashi Yano +libdatrieTakashi Yano +libthai Takashi Yano +pango1.0 Please feel free to take it over. I'd withdraw from librsvg2. +librsvg2 Marco Atzeri Thanks for taking over so many packages Marco
Re: Unmaintained packages in base package set
On Sat, 23 Dec 2023 04:51:22 +0100 Marco Atzeri wrote: > On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: > > On Wed, 20 Dec 2023 12:16:05 + > > Jon Turney via Cygwin-apps wrote: > >> I tweaked the unmaintained packages report [1] a bit so it identifies > >> 'base' and 'direct or indirect base dependencies'. > >> > >> (But you're quite right to point out that the build requirements for a > >> native Cygwin build are also important) > >> > >> [1] https://cygwin.com/packages/reports/unmaintained.html > > > > I would like to take over: > > libass > > fontconfig > > fribidi > > gnutls > > openjpeg > > librsvg2 > > snappy > > libssh > > dbus > > gtk3 > > orc > > tdb > > db > > libid3tag > > libmad > > taglib > > if no one like to do that, because the packages > > I maintain use them. > > all in one shot ? > I suggest to start with the smaller beasts one by one or small groups > I suspect GTK3 needs a lot of effort Thanks for the advice. Now, GTK3 package of 3.24.39 has been successfully built and packaged in my environment with updating some other related packages. So, firstly, I would like to take over following packages that are related to GTK3. fribidi 0.19.7 -> 1.0.13 libdatrie 0.28 -> 0.2.13 libthai 0.1.26 -> 0.1.29 pango1.0 1.40.14 -> 1.51.0 atk1.0 2.26.1 -> 2.38.0 gtk3 3.22.28 -> 3.24.39 > > libass > > fontconfig > > gnutls > > openjpeg > > snappy > > libssh > > dbus > > orc > > tdb > > db > > libid3tag > > libmad > > taglib will be next steps. I will try them one by one. > I could be interested in librsvg2 for the same reason of you Please feel free to take it over. I'd withdraw from librsvg2. -- Takashi Yano
Re: Unmaintained packages in base package set
On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote: On Wed, 20 Dec 2023 12:16:05 + Jon Turney via Cygwin-apps wrote: I tweaked the unmaintained packages report [1] a bit so it identifies 'base' and 'direct or indirect base dependencies'. (But you're quite right to point out that the build requirements for a native Cygwin build are also important) [1] https://cygwin.com/packages/reports/unmaintained.html I would like to take over: libass fontconfig fribidi gnutls openjpeg librsvg2 snappy libssh dbus gtk3 orc tdb db libid3tag libmad taglib if no one like to do that, because the packages I maintain use them. all in one shot ? I suggest to start with the smaller beasts one by one or small groups I suspect GTK3 needs a lot of effort I could be interested in librsvg2 for the same reason of you I also wonder what should we do for unchanged packaegs such as: libbs2b libmodplug lame libasyncns avahi musepack if unchanged, are for the time being less urgent and i they do not see critical anyway
Re: Unmaintained packages in base package set
On Wed, 20 Dec 2023 12:16:05 + Jon Turney via Cygwin-apps wrote: > I tweaked the unmaintained packages report [1] a bit so it identifies > 'base' and 'direct or indirect base dependencies'. > > (But you're quite right to point out that the build requirements for a > native Cygwin build are also important) > > [1] https://cygwin.com/packages/reports/unmaintained.html I would like to take over: libass fontconfig fribidi gnutls openjpeg librsvg2 snappy libssh dbus gtk3 orc tdb db libid3tag libmad taglib if no one like to do that, because the packages I maintain use them. I also wonder what should we do for unchanged packaegs such as: libbs2b libmodplug lame libasyncns avahi musepack -- Takashi Yano
Re: Unmaintained packages in base package set
On 21/12/2023 04:27, Marco Atzeri via Cygwin-apps wrote: On 20/12/2023 13:16, Jon Turney via Cygwin-apps wrote: On 06/12/2023 17:19, Brian Inglis via Cygwin-apps wrote: On 2023-12-05 06:07, Jon Turney wrote: [...] I tweaked the unmaintained packages report [1] a bit so it identifies 'base' and 'direct or indirect base dependencies'. (But you're quite right to point out that the build requirements for a native Cygwin build are also important) [1] https://cygwin.com/packages/reports/unmaintained.html I could take over alternatives and bzip2. It seems our alternatives is a subset of upstream https://github.com/fedora-sysv/chkconfig I will need to look on the details of the implementation. I think to remember that upstream went for a road not feasible for us, but last I looked was long time ago, and I could remember totally wrong. Yeah, repology seems to think there are a couple of alternative implementations, so the upstream version number in that report (which is retrieved from repology) might not be accurate. Nice to have for alternatives is to manage in some ways also DLLs so for me to remove the Lapack PATH hack. I think the issue there is that we are dependent on the Windows loader to find DLLs when creating a process, and that doesn't understand Cygwin symlinks. Perhaps avoidable if we were to use native symlinks, but I think those are still not widely available enough to make that possible...
Re: Unmaintained packages in base package set
Marco Atzeri via Cygwin-apps wrote: Is anyone looking at QT5 and QT6 ? I've "looked at" Qt5 in the past, though not to the point of being able to take it over. I have a patch for the qterminal issue that I'd like to contribute. There's issues I've had building this I haven't had the time to resolve or even ask about. Not sure I've tried since Achim last did some work on it. I haven't looked at Qt6 at all. Marco, if you've got an itch to see either/both of these through, be my guest as far as I'm concerned. Meanwhile, I'm looking over the Unmaintained list too with some interest. Regards, ..mark
Re: Unmaintained packages in base package set
On 20/12/2023 13:16, Jon Turney via Cygwin-apps wrote: On 06/12/2023 17:19, Brian Inglis via Cygwin-apps wrote: On 2023-12-05 06:07, Jon Turney wrote: [...] I tweaked the unmaintained packages report [1] a bit so it identifies 'base' and 'direct or indirect base dependencies'. (But you're quite right to point out that the build requirements for a native Cygwin build are also important) [1] https://cygwin.com/packages/reports/unmaintained.html I could take over alternatives and bzip2. It seems our alternatives is a subset of upstream https://github.com/fedora-sysv/chkconfig I will need to look on the details of the implementation. I think to remember that upstream went for a road not feasible for us, but last I looked was long time ago, and I could remember totally wrong. Nice to have for alternatives is to manage in some ways also DLLs so for me to remove the Lapack PATH hack. Is anyone looking at QT5 and QT6 ?
Unmaintained packages in base package set
On 06/12/2023 17:19, Brian Inglis via Cygwin-apps wrote: On 2023-12-05 06:07, Jon Turney wrote: [...] I was kind of hoping that base packages (and "dependencies of packages in base which aren't in base themselves") aren't unmaintained, but obviously that was being optimistic... I thought I should take a peek in hopes too, but just in case, not being paranoid /much/, but like to have a bigger fan ready just in case! ;^> Maybe we should work on publishing package adoption priority lists e.g. 1 Base 1.1 crypto-policies 1.2 alternatives 2 Build 1.1 cocom (now dino) 1.2 git-archive-all 1.3 robodoc 1.4 bzip2 1.5 docbook... [lots of Unmaintained pkgs and deps] 3 Base direct deps 4 Build direct deps 5 Base indirect deps 6 Build indirect deps I stopped once I looked at docbook...sob...! ;^> I tweaked the unmaintained packages report [1] a bit so it identifies 'base' and 'direct or indirect base dependencies'. (But you're quite right to point out that the build requirements for a native Cygwin build are also important) [1] https://cygwin.com/packages/reports/unmaintained.html
