[NMU] inkscape 0.92.3-2 (Test)

[NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert]

I've uploaded a non-maintainer re-build of the existing inkscape 0.92.3. 
This attempts to work around a problem with the current inkscape reported 
to exit with 127 error code (missing DLL).  This build was produced with 
gcc-g++ 7.4 while the current build was produced with gcc-g++ 6.4.  Newer 
gcc-g++ releases fail to build inkscape due to C++ include file evolution.

The only changes in this test build were to the cygport file:
- include python3 rather than 'python'
- supply a BUILD_REQUIRES containing most if not all requirements

Not sure of the logistical process for doing a non-maintainer update.  If 
I've missed something please let me know.  I might consider doing an ITA 
if I have luck with this... we'll see.
Thanks,

..mark

Re: [NMU] inkscape 0.92.3-2 (Test)

[Jon Turney]

On 30/11/2023 00:38, Mark Geisert via Cygwin-apps wrote:
> I've uploaded a non-maintainer re-build of the existing inkscape 0.92.3. 
> This attempts to work around a problem with the current inkscape 
> reported to exit with 127 error code (missing DLL).  This build was 
> produced with gcc-g++ 7.4 while the current build was produced with 
> gcc-g++ 6.4.  Newer gcc-g++ releases fail to build inkscape due to C++ 
> include file evolution.
> 
> The only changes in this test build were to the cygport file:
> - include python3 rather than 'python'
> - supply a BUILD_REQUIRES containing most if not all requirements
> 
> Not sure of the logistical process for doing a non-maintainer update.  
> If I've missed something please let me know.  I might consider doing an 
> ITA if I have luck with this... we'll see.
> Thanks,

Thanks very much for looking into this.

So, this is all a bit ad-hoc at the moment, but only certain ("trusted") 
  maintainers are currently allowed to do NMUs.

If you have ideas about how to make things work better, I'm all ears.

For the moment, I tweaked things to let your upload through.

Re: [NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert]

Hi Jon,

Jon Turney via Cygwin-apps wrote:
> On 30/11/2023 00:38, Mark Geisert via Cygwin-apps wrote:
>> Not sure of the logistical process for doing a non-maintainer update. If I've 
>> missed something please let me know.
 >
> Thanks very much for looking into this.

You're welcome.  It was a curious report on the main list and I got hooked.

> So, this is all a bit ad-hoc at the moment, but only certain ("trusted") 
>   maintainers are currently allowed to do NMUs.

Oops.

> If you have ideas about how to make things work better, I'm all ears.
> 
> For the moment, I tweaked things to let your upload through.

Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur to me 
that those doing them were explicitly allowed to.

ISTM the process works fine as it is.  If I happen to have a future itch to do an 
NMU should I handle it as I did this one?  Or say something on cygwin-apps 
beforehand?  I don't expect it will be often.  I'm totally fine not being on the 
"trusted" list for this type of thing.
Thanks,

..mark

Re: [NMU] inkscape 0.92.3-2 (Test)

[Jon Turney]

On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:
> 
>> If you have ideas about how to make things work better, I'm all ears.
>>
>> For the moment, I tweaked things to let your upload through.
> 
> Thanks Jon.  I have only seen a handful of NMUs go by and it didn't 
> occur to me that those doing them were explicitly allowed to.
> 
> ISTM the process works fine as it is.  If I happen to have a future itch 
> to do an NMU should I handle it as I did this one?  Or say something on 
> cygwin-apps beforehand?  I don't expect it will be often.  I'm totally 
> fine not being on the "trusted" list for this type of thing.

If you ask in advance, that's possibly slightly less work for me, but 
either is fine really.

Maybe I should make things so that all maintainers can NMU orphaned 
packages. That seems reasonable I guess?

> Thanks,

No problem.

Re: [NMU] inkscape 0.92.3-2 (Test)

[Brian Inglis]

On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:
> On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:
>>
>>> If you have ideas about how to make things work better, I'm all ears.
>>>
>>> For the moment, I tweaked things to let your upload through.
>>
>> Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur to 
>> me that those doing them were explicitly allowed to.
>>
>> ISTM the process works fine as it is.  If I happen to have a future itch to do 
>> an NMU should I handle it as I did this one?  Or say something on cygwin-apps 
>> beforehand?  I don't expect it will be often.  I'm totally fine not being on 
>> the "trusted" list for this type of thing.
> 
> If you ask in advance, that's possibly slightly less work for me, but either is 
> fine really.
> 
> Maybe I should make things so that all maintainers can NMU orphaned packages. 
> That seems reasonable I guess?

Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
"toolchain" defined as cygport and cygwin deps and build deps (i.e. bzip2 cocom 
docbook git-archive-all robodoc); maybe also all their deps and build deps, even 
Devel and Libs?

Any of us or sourceware accounts could be hacked (possibly even targeted), and 
systems used to disrupt Cygwin processes, if someone had some dispute, wanted to 
be nasty, to see if they could do it, or made a mistake.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [NMU] inkscape 0.92.3-2 (Test)

[Jon Turney]

On 03/12/2023 17:50, Brian Inglis via Cygwin-apps wrote:
> On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:
>> On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:
>>>
>>>> If you have ideas about how to make things work better, I'm all ears.
>>>>
>>>> For the moment, I tweaked things to let your upload through.
>>>
>>> Thanks Jon.  I have only seen a handful of NMUs go by and it didn't 
>>> occur to me that those doing them were explicitly allowed to.
>>>
>>> ISTM the process works fine as it is.  If I happen to have a future 
>>> itch to do an NMU should I handle it as I did this one?  Or say 
>>> something on cygwin-apps beforehand?  I don't expect it will be 
>>> often.  I'm totally fine not being on the "trusted" list for this 
>>> type of thing.
>>
>> If you ask in advance, that's possibly slightly less work for me, but 
>> either is fine really.
>>
>> Maybe I should make things so that all maintainers can NMU orphaned 
>> packages. That seems reasonable I guess?
> 
> Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
> "toolchain" defined as cygport and cygwin deps and build deps (i.e. 
> bzip2 cocom docbook git-archive-all robodoc); maybe also all their deps 
> and build deps, even Devel and Libs?

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...

Re: [NMU] inkscape 0.92.3-2 (Test)

[Brian Inglis]

On 2023-12-05 06:07, Jon Turney wrote:
> On 03/12/2023 17:50, Brian Inglis via Cygwin-apps wrote:
>> On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:
>>> On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:
>>>>> If you have ideas about how to make things work better, I'm all ears.
>>>>> For the moment, I tweaked things to let your upload through.

>>>> Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur to 
>>>> me that those doing them were explicitly allowed to.
>>>> ISTM the process works fine as it is.  If I happen to have a future itch to 
>>>> do an NMU should I handle it as I did this one?  Or say something on 
>>>> cygwin-apps beforehand?  I don't expect it will be often.  I'm totally fine 
>>>> not being on the "trusted" list for this type of thing.

>>> If you ask in advance, that's possibly slightly less work for me, but either 
>>> is fine really.
>>> Maybe I should make things so that all maintainers can NMU orphaned packages. 
>>> That seems reasonable I guess?

>> Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
>> "toolchain" defined as cygport and cygwin deps and build deps (i.e. bzip2 
>> cocom docbook git-archive-all robodoc); maybe also all their deps and build 
>> deps, even Devel and Libs?

> 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...! ;^>

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [NMU] inkscape 0.92.3-2 (Test)

[Brian Inglis]

On 2023-12-06 10:19, Brian Inglis via Cygwin-apps wrote:
> On 2023-12-05 06:07, Jon Turney wrote:
>> On 03/12/2023 17:50, Brian Inglis via Cygwin-apps wrote:
>>> On 2023-12-03 08:33, Jon Turney via Cygwin-apps wrote:
>>>> On 01/12/2023 09:17, Mark Geisert via Cygwin-apps wrote:
>>>>>> If you have ideas about how to make things work better, I'm all ears.
>>>>>> For the moment, I tweaked things to let your upload through.
> 
>>>>> Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur 
>>>>> to me that those doing them were explicitly allowed to.
>>>>> ISTM the process works fine as it is.  If I happen to have a future itch to 
>>>>> do an NMU should I handle it as I did this one?  Or say something on 
>>>>> cygwin-apps beforehand?  I don't expect it will be often.  I'm totally fine 
>>>>> not being on the "trusted" list for this type of thing.
> 
>>>> If you ask in advance, that's possibly slightly less work for me, but either 
>>>> is fine really.
>>>> Maybe I should make things so that all maintainers can NMU orphaned 
>>>> packages. That seems reasonable I guess?
> 
>>> Maybe Unmaintained except Base (i.e. alternatives crypto-policies) or 
>>> "toolchain" defined as cygport and cygwin deps and build deps (i.e. bzip2 
>>> cocom docbook git-archive-all robodoc); maybe also all their deps and build 
>>> deps, even Devel and Libs?
> 
>> 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]
   2 Build 2.1 cocom (now dino) 2.2 git-archive-all 2.3 robodoc 2.4 bzip2
        2.5 docbook... [lots of Unmaintained pkgs and deps]
> 3 Base direct deps
   3 Base direct deps 3.1 ...
> 4 Build direct deps
   4 Build direct deps 4.1 ...
> 5 Base indirect deps
   5 Base indirect deps 5.1 ...
> 6 Build indirect deps
   6 Build indirect deps 6.1 ...

> I stopped once I looked at docbook...sob...! ;^>

[Getting coffee now!]

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Unmaintained packages in base package set

[Jon Turney]

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

Re: Unmaintained packages in base package set

[Marco Atzeri]

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 ?

Re: Unmaintained packages in base package set

[Mark Geisert]

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

[Jon Turney]

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

[Takashi Yano]

On Wed, 20 Dec 2023 12:16:05 +0000
Jon Turney via Cygwin-apps <cygwin-apps@cygwin.com> 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 <takashi.yano@nifty.ne.jp>

Re: Unmaintained packages in base package set

[Marco Atzeri]

On 23/12/2023 04:42, Takashi Yano via Cygwin-apps wrote:
> On Wed, 20 Dec 2023 12:16:05 +0000
> Jon Turney via Cygwin-apps <cygwin-apps@cygwin.com> 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

[Takashi Yano]

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 +0000
> > Jon Turney via Cygwin-apps <cygwin-apps@cygwin.com> 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 <takashi.yano@nifty.ne.jp>

Re: Unmaintained packages in base package set

[Marco Atzeri]

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
+libdatrie                                    Takashi 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

[Jon Turney]

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

[Takashi Yano]

On Sun, 7 Jan 2024 12:54:35 +0000
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 <takashi.yano@nifty.ne.jp>

Re: Unmaintained packages in base package set

[Takashi Yano]

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 <takashi.yano@nifty.ne.jp>

Re: Unmaintained packages in base package set

[ASSI]

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

[Marco Atzeri]

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

[1dakotaxi]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

StopSent from my T-Mobile 5G Device
-------- Original message --------From: Takashi Yano via Cygwin-apps <cygwin-apps@cygwin.com> 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 +0000> > Jon Turney via Cygwin-apps <cygwin-apps@cygwin.com> 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 <takashi.yano@nifty.ne.jp>

Re: [NMU] inkscape 0.92.3-2 (Test)

[ASSI]

Mark Geisert via Cygwin-apps writes:
> I've uploaded a non-maintainer re-build of the existing inkscape
> 0.92.3. This attempts to work around a problem with the current
> inkscape reported to exit with 127 error code (missing DLL).  This
> build was produced with gcc-g++ 7.4 while the current build was
> produced with gcc-g++ 6.4.  Newer gcc-g++ releases fail to build
> inkscape due to C++ include file evolution.

Since apparently you can compile it with that compiler on an otherwise
current release of Cygwin (I assume), you should be able to request a
previous C++ or G++ standard version and have the current compiler do
the same?  The baseline for gcc-6 until gcc-10 has been C++14 and gcc-11
switched to C++17.  You should also check that the compiler is detected
correctly, there are some configure scripts that fail to take higher
version numbers (esp. double digits for the main gcc version) correctly into
account and then set bogus options.  Inkscape shouldn't have been using
C++11 until 0.93, so the appropriate standard to invoke is probably
C++98 (or thew GNU variant thereof).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert]

ASSI via Cygwin-apps wrote:
> Mark Geisert via Cygwin-apps writes:
>> I've uploaded a non-maintainer re-build of the existing inkscape
>> 0.92.3. This attempts to work around a problem with the current
>> inkscape reported to exit with 127 error code (missing DLL).  This
>> build was produced with gcc-g++ 7.4 while the current build was
>> produced with gcc-g++ 6.4.  Newer gcc-g++ releases fail to build
>> inkscape due to C++ include file evolution.
> 
> Since apparently you can compile it with that compiler on an otherwise
> current release of Cygwin (I assume), you should be able to request a
> previous C++ or G++ standard version and have the current compiler do
> the same?  The baseline for gcc-6 until gcc-10 has been C++14 and gcc-11
> switched to C++17.  You should also check that the compiler is detected
> correctly, there are some configure scripts that fail to take higher
> version numbers (esp. double digits for the main gcc version) correctly into
> account and then set bogus options.  Inkscape shouldn't have been using
> C++11 until 0.93, so the appropriate standard to invoke is probably
> C++98 (or thew GNU variant thereof).

Thanks much, Achim, for pointing out that additional dimension. That should help 
with my future builds and/or ITA.

..mark

Re: [NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert]

This test version of inkscape has been promoted to current.

Apologies to JonT who probably has to help this through again.
Next time I do this will be after I ITA the thing.
Thanks & Regards,

..mark