Re: Releases

[Ivan Vučica]

On Tue 10 Jan 2023 at 19:43, Frederik Seiffert 
wrote:

>
> Am 10.01.2023 um 14:27 schrieb Ivan Vučica :
>
> I really would like to minimise the number of steps we have to go through
>> by automating as much as possible.
>
> I did. :-)
>
> Please see my release jottings on Google Docs. They’re not formal
> documentation, but can be interpreted as a playbook with some reading.
>
>
> I’m not familiar with what needs to be done for releases (can you share a
> link to that Google Doc maybe?), but I’m wondering if released could be
> mostly automated on the GitHub Actions CI.
>

Mainly because it is a mess and it’s mainly my notes on what I did + to
share with maintainers, I am not keen on making it publicly visible. If it
were to be a playbook, I’d put it up somewhere in repos as proper
documentation.

However, I’ve added your corporate email address to the ACL for the doc for
2.9.0/1.28.0/0.29.0 release of ~March 2021:

https://docs.google.com/document/d/1DGumTDgxGwsaamnFvJ5WI1puVHHKk2f1t7GNrwLHfi0/edit?usp=sharing

I can add other interested maintainers to these docs, but again, there’s no
point in making this more visible if it’s just notes and not proper
documentation.

I’ll see if I can turn this into something more widely shareable (maybe
once I finally upgrade the wiki schema on the new gnustep.org machine…).


> For the Android and Windows MSVC toolchains, every build on the master
> branch creates a pre-release on GitHub (overwriting the previous one), and
> then if I want to do a release I test the latest build and then simply
> add/edit the change log and check a box to turn it into a release (which
> also creates a corresponding git tag). Here’s the required Actions code:
>
>
> https://github.com/gnustep/tools-android/blob/d71de40e60f71988b40610e39b5df926e6df1687/.github/workflows/ci.yml#L57-L84
>
> In this case, the "prerelease" step will wait for the two builds (macOS
> and Linux) to complete, and then create a "Latest Build" pre-release on
> GitHub with the artifacts for the two platforms.
>

I think it makes sense if you’re doing binaries, but less so if most of the
tedious process is actually getting documentation (release notes…) in
shape, and invoking the correct commands to create the tag in the first
place (using the release notes in the tag).
-- 
Sent from Gmail Mobile

Re: Releases

[Ivan Vučica]

On Wed 11 Jan 2023 at 10:25, David Chisnall 
wrote:

>
> This is on my to-do list for the runtime.  It's something that we're
> doing with other projects and it means that the release process is just
> creating a tag.  This then builds releases for any targets that we want
> to ship binaries for, creates the GitHub release, pushes the built
> artefacts to the release, and adds a new commit on the main branch
> rolling over versions and so on.
>
> David


There’s the GPG signing part that makes Github Actions less useful. That
is: whether you want to use Github actions depends on where you want to
store this rather secret key. (We should rotate the GPG key anyway, by the
way; the one we use for gnustep make/base/gui/back is still a 1024 bit key,
with no delegation to subkeys and no expiration dates set.)

Besides, making the tarballs themselves is the easiest part.

For the make/base/gui/back stuff, the hardest for me was going through the
history, trying to make sense of everyone’s rather cryptic commit messages
and rather lacking ChangeLog updates, identifying and summarizing the
changes into something that might be useful to a reader, putting the
changes into 2 different places, then generating the new release notes file.

If I recall correctly, I touched up gnustep-make so invoking the magic git
release commands will produce the correct annotated tag containing the
release notes file as the tag’s commit message (meaning I have no need to
do anything on Github releases page to make this text show up).

But at that point, building the tarballs and signing them is easy.
Uploading them to Github is just a drag and drop. Uploading them to FTP
(…and I really need to sit down and bring it up on the ‘new’ DigitalOcean
machine, but in a more secure way than using a password over unencrypted
FTP) is easy. Writing release notes and dealing with GPG’s rejections of
the passphrase on the key is difficult.

I never fully completed the work on our own Debian packages so there’s no
point in having Github Actions for that particular purpose. Besides, Debian
‘source’ packages also need to be GPG signed. (Note, I am not talking about
the code we want to upstream into Debian proper; this would be ‘our’
packages, built with libobjc2 and clang, and preferring ‘steppiness’ over
FHS. It was not to be about making them better than Debian-built packages,
but about providing a different experience. And maybe adding a ‘defaults’
package that configures a different theme and such.)

What about win32? I never built win32 releases with NSIS, either. There
have been improvements on building .msi packages on free platforms (GNOME’s
msitools have gotten some GUI support!), but last time I checked, it was
still not sufficiently similar to WiX Tools on Windows.

-- 
Sent from Gmail Mobile

Re: Releases

[David Chisnall]

On 11/01/2023 10:40, Ivan Vučica wrote:
There’s the GPG signing part that makes Github Actions less useful. That 
is: whether you want to use Github actions depends on where you want to 
store this rather secret key. (We should rotate the GPG key anyway, by 
the way; the one we use for gnustep make/base/gui/back is still a 1024 
bit key, with no delegation to subkeys and no expiration dates set.)


This should be stored in a GitHub Secret and not stored on anyone's 
machine.  It is then exposed only to the release pipeline and 
compromising your dev VM does not leak it.



Besides, making the tarballs themselves is the easiest part.


It's not easy, it's free.  Every GitHub commit is automatically exposed 
as a tarball via a special URL, you don't need to do anything with it.




For the make/base/gui/back stuff, the hardest for me was going through 
the history, trying to make sense of everyone’s rather cryptic commit 
messages and rather lacking ChangeLog updates, identifying and 
summarizing the changes into something that might be useful to a reader, 
putting the changes into 2 different places, then generating the new 
release notes file.


For the runtime, I have an `ANNOUNCE` file containing markdown that is 
updated with things that will go in the release announcement as they're 
added.  I then just copy it to the release text.


What about win32? I never built win32 releases with NSIS, either. There 
have been improvements on building .msi packages on free platforms 
(GNOME’s msitools have gotten some GUI support!), but last time I 
checked, it was still not sufficiently similar to WiX Tools on Windows.


For the runtime, I use CMake's CPack support, which produces a zip file 
that can just be extracted on Windows and used.  It can also produce 
NuGet packages if you want to manage dependencies like that.  GNUstep 
Make makes all of this much harder (running GNUstep Make on Windows at 
all is sufficiently painful that I've never managed it successfully).


David

Re: Releases

[David Chisnall]

On 10/01/2023 19:42, Frederik Seiffert wrote:
I’m not familiar with what needs to be done for releases (can you share 
a link to that Google Doc maybe?), but I’m wondering if released could 
be mostly automated on the GitHub Actions CI.


This is on my to-do list for the runtime.  It's something that we're 
doing with other projects and it means that the release process is just 
creating a tag.  This then builds releases for any targets that we want 
to ship binaries for, creates the GitHub release, pushes the built 
artefacts to the release, and adds a new commit on the main branch 
rolling over versions and so on.


David

Re: Releases

[Frederik Seiffert]

> Am 10.01.2023 um 14:27 schrieb Ivan Vučica :
> 
>> I really would like to minimise the number of steps we have to go through by 
>> automating as much as possible.
> 
> I did. :-)
> 
> Please see my release jottings on Google Docs. They’re not formal 
> documentation, but can be interpreted as a playbook with some reading. 

I’m not familiar with what needs to be done for releases (can you share a link 
to that Google Doc maybe?), but I’m wondering if released could be mostly 
automated on the GitHub Actions CI.

For the Android and Windows MSVC toolchains, every build on the master branch 
creates a pre-release on GitHub (overwriting the previous one), and then if I 
want to do a release I test the latest build and then simply add/edit the 
change log and check a box to turn it into a release (which also creates a 
corresponding git tag). Here’s the required Actions code:

https://github.com/gnustep/tools-android/blob/d71de40e60f71988b40610e39b5df926e6df1687/.github/workflows/ci.yml#L57-L84

In this case, the "prerelease" step will wait for the two builds (macOS and 
Linux) to complete, and then create a "Latest Build" pre-release on GitHub with 
the artifacts for the two platforms.

Frederik

Re: Releases

[Ivan Vučica]

On Sun 8 Jan 2023 at 12:53, Richard Frith-Macdonald <
richardfrithmacdon...@gmail.com> wrote:

>
>
> > On 3 Jan 2023, at 10:16, Ivan Vučica  wrote:
> >
> > Lest I forget, please also try to follow the process of adding the
> annotated tag (preferably GPG signed, but at least annotated tag) so any
> release notes displayed on Github release are also in the repo itself.
> >
> > I shared the Google doc with what I did for the last few releases. Happy
> to demo over video to any maintainer that wants to see how I was doing the
> releases. Please let me know if interested in a demo; I am available
> weekdays at GMT evenings.
>
> I'm not sure what the point of the annotated tag actually is (I guess it's
> something that people who use git a lot are familiar with).


There is an author and date and a message associated with the release.
There can be a GPG signature associated. Typical tags have no metadata:
they’re just files*  containing hash of the commit they point to. When were
they themselves created? By whom? No clarity there.

With annotated tags, we can embed release notes themselves into the history
in case we move off of Github.


> If we want to make that a standard part of a release, can we add it to
> gnustep-make so that the 'make git-tag' target produces the annotated tag
> as well as tagging the release?
> I really would like to minimise the number of steps we have to go through
> by automating as much as possible.

I did. :-)

Please see my release jottings on Google Docs. They’re not formal
documentation, but can be interpreted as a playbook with some reading.

I am also happy to give a guided tour over video of how I do a release.
Maintainers who are interested, please let me know. I am available on
weekends or weekday evenings.

-- 
Sent from Gmail Mobile

Re: Releases

[Richard Frith-Macdonald]

> On 3 Jan 2023, at 10:16, Ivan Vučica  wrote:
> 
> Lest I forget, please also try to follow the process of adding the annotated 
> tag (preferably GPG signed, but at least annotated tag) so any release notes 
> displayed on Github release are also in the repo itself.
> 
> I shared the Google doc with what I did for the last few releases. Happy to 
> demo over video to any maintainer that wants to see how I was doing the 
> releases. Please let me know if interested in a demo; I am available weekdays 
> at GMT evenings.

I'm not sure what the point of the annotated tag actually is (I guess it's 
something that people who use git a lot are familiar with).
If we want to make that a standard part of a release, can we add it to 
gnustep-make so that the 'make git-tag' target produces the annotated tag as 
well as tagging the release?
I really would like to minimise the number of steps we have to go through by 
automating as much as possible.

Re: Releases

[Ivan Vučica]

Lest I forget, please also try to follow the process of adding the annotated 
tag (preferably GPG signed, but at least annotated tag) so any release notes 
displayed on Github release are also in the repo itself.

I shared the Google doc with what I did for the last few releases. Happy to 
demo over video to any maintainer that wants to see how I was doing the 
releases. Please let me know if interested in a demo; I am available weekdays 
at GMT evenings.

On 3 Jan 2023, at 10:13, Ivan Vučica  wrote:
> 
> I can get FTP set up very. I’ll try to do it over the next few days.
> 
> Wiki upgrade is why I procrastinated: I just know something will go wrong and 
> this demotivates me.
> 
> Then there’s the whole web issue with PHP7.x and MySQL modules.
> 
> I’ll try to sort FTP out and then try to keep going. FTP is easy. (Famous 
> last words.)
> 
>> On 28 Dec 2022, at 10:46, Richard Frith-Macdonald  wrote:
>> 
>> Happy Christmas.
>> 
>> We don't have a gnustep.org machine to put releases on, but I have just made 
>> a gnustep-make release, tagged as gnustep-make-2.9.1in the git repository.
>> 
>> I intend to make a gnustep-base release shortly too.
>> 
>> 
>> 

Re: Releases

[Ivan Vučica]

I can get FTP set up very. I’ll try to do it over the next few days.

Wiki upgrade is why I procrastinated: I just know something will go wrong and 
this demotivates me.

Then there’s the whole web issue with PHP7.x and MySQL modules.

I’ll try to sort FTP out and then try to keep going. FTP is easy. (Famous last 
words.)

> On 28 Dec 2022, at 10:46, Richard Frith-Macdonald  wrote:
> 
> Happy Christmas.
> 
> We don't have a gnustep.org machine to put releases on, but I have just made 
> a gnustep-make release, tagged as gnustep-make-2.9.1in the git repository.
> 
> I intend to make a gnustep-base release shortly too.
> 
> 
> 

Re: Releases

[Fred Kiefer]

Sorry, this will take a bit longer. My OpenSuse Linux is no longer starting up 
and I failed to repair it up to now. This happens when switching into graphics 
mode after the login and is accompanied by blinking keyboard lights, I already 
tried a manual update from the command prompt.

If I won’t get this fixed within the next few hours, I will just mail you the 
changes to the news files.

Sorry for the delay,
Fred

> Am 28.12.2022 um 14:35 schrieb Fred Kiefer :
> 
> Merry Christmas to you too Richard!
> 
> Great that you started to build releases of make and base. If it isn’t too 
> much trouble for you, could you please release guidance and back as well? The 
> last release there was almost two years ago. I am willing to update the 
> news.texi file for these two projects. I could do this later today with the 
> hope of an upcoming release.
> 
> Cheers,
> Fred
> 
>> Am 28.12.2022 um 11:46 schrieb Richard Frith-Macdonald :
>> 
>> Happy Christmas.
>> 
>> We don't have a gnustep.org machine to put releases on, but I have just made 
>> a gnustep-make release, tagged as gnustep-make-2.9.1in the git repository.
>> 
>> I intend to make a gnustep-base release shortly too.
>> 
>> 
>> 
> 
> 

Re: Releases

[Richard Frith-Macdonald]

> On 28 Dec 2022, at 14:39, Gregory Casamento  wrote:
> 
> Hey Guys,
> 
> I will be doing a corresponding release of Gorm since there have also been 
> improvements and bug fixes to it in the last year or so.
> 
> Another thing I will be doing in the next couple of weeks is looking at FTP 
> hosting so that we can look into both restoring access to our historical 
> files as well as storing new files.  I will be contacting the FSF to see if 
> they can set aside some space for us on their servers.   As you know we used 
> to host our own at OXMIUM, but that is no longer the case (of course).   Now 
> that we have a release and we also are anticipating the Debian release 
> deadline in January we really need the FTP site back.

I discovered how to make the releases available on GitHub (turned out to be 
very easy), so there *is* somewhere people can download the tarballs from.
Having am FSF site would be much better though.


 

Reply encrypted using 
http://keys.gnupg.net:11371/pks/lookup?op=get=0x8fc6fd54cf3da610

Re: Releases

[Gregory Casamento]

Hey Guys,

I will be doing a corresponding release of Gorm since there have also been
improvements and bug fixes to it in the last year or so.

Another thing I will be doing in the next couple of weeks is looking at FTP
hosting so that we can look into both restoring access to our historical
files as well as storing new files.  I will be contacting the FSF to see if
they can set aside some space for us on their servers.   As you know we
used to host our own at OXMIUM, but that is no longer the case (of
course).   Now that we have a release and we also are anticipating the
Debian release deadline in January we really need the FTP site back.

Yours, GC

On Wed, Dec 28, 2022 at 8:37 AM Fred Kiefer  wrote:

> Merry Christmas to you too Richard!
>
> Great that you started to build releases of make and base. If it isn’t too
> much trouble for you, could you please release guidance and back as well?
> The last release there was almost two years ago. I am willing to update the
> news.texi file for these two projects. I could do this later today with the
> hope of an upcoming release.
>
> Cheers,
> Fred
>
> > Am 28.12.2022 um 11:46 schrieb Richard Frith-Macdonald :
> >
> > Happy Christmas.
> >
> > We don't have a gnustep.org machine to put releases on, but I have just
> made a gnustep-make release, tagged as gnustep-make-2.9.1in the git
> repository.
> >
> > I intend to make a gnustep-base release shortly too.
> >
> >
> >
>
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron
https://gf.me/u/x8m3sx - My GNUstep GoFundMe
https://teespring.com/stores/gnustep - Store

Re: Releases

[Fred Kiefer]

Merry Christmas to you too Richard!

Great that you started to build releases of make and base. If it isn’t too much 
trouble for you, could you please release guidance and back as well? The last 
release there was almost two years ago. I am willing to update the news.texi 
file for these two projects. I could do this later today with the hope of an 
upcoming release.

Cheers,
Fred

> Am 28.12.2022 um 11:46 schrieb Richard Frith-Macdonald :
> 
> Happy Christmas.
> 
> We don't have a gnustep.org machine to put releases on, but I have just made 
> a gnustep-make release, tagged as gnustep-make-2.9.1in the git repository.
> 
> I intend to make a gnustep-base release shortly too.
> 
> 
> 

Releases

[Richard Frith-Macdonald]

Happy Christmas.

We don't have a gnustep.org machine to put releases on, but I have just made a 
gnustep-make release, tagged as gnustep-make-2.9.1in the git repository.

I intend to make a gnustep-base release shortly too.

Re: GNUstep releases this month?

[Ivan Vučica]

I'll take these tarballs, upload to usual places and make an announcement
likely tomorrow. Consider the tarballs final, even if I didn't upload them
into usual places yet. Git tags are already pushed.

sent from phone

On Sun 2 May 2021, 15:23 Gregory Casamento, 
wrote:

> I did a build as well and ran the tests.   Seems fine.
>
> GC
>
>
> On Fri, Apr 30, 2021 at 11:25 AM Riccardo Mottola <
> riccardo.mott...@libero.it> wrote:
>
>> Hi
>>
>> I did a build ot base/gui/back on linux/amd64 gcc and found no issues.
>> Maybe this is enough to tell that the packages are complete. Didn't test
>> for bugs on all platforms to know if you caught a good git version or not.
>>
>> Riccardo
>>
>> Ivan Vučica wrote:
>> > (This is not a release announcement)
>> >
>> > A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
>> > at http://badc0de.net/gs/2021.
>> >
>> > Actual final releases will, as always, be distributed via GNUstep FTP.
>> > Please give this test build a go.
>> >
>> > ===
>> >
>> > Psst! If you are using themes such as Rik, you might need to rebuild
>> > them, even if there were no code changes. This is usually the case, I
>> > suspect, as well; but today I was bit by it for the first time. It was
>> > curious as I only saw problems on applications I rebuilt -- which in
>> > retrospect makes sense, given the SO bump.
>> >
>> > ===
>> >
>> > Now that all four libs are prepared, I will give it a few days to
>> > receive a stop signal, or an actively-green-light from maintainers.
>> > Then I will send out announcement emails, create GitHub releases, etc.
>> >
>> > Of course, if you spot a small thing that we _can_ fix post release
>> > (i.e. not a full showstopper), I will be happy to cut a smaller
>> > point-release.
>> >
>> >
>> > On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica  wrote:
>> >> (This is not a release announcement)
>> >>
>> >> A signed build of gnustep-base 1.28.0 has been uploaded at
>> >> http://badc0de.net/gs/2021.
>> >>
>> >> Actual final releases will, as always, be distributed via GNUstep FTP.
>> >> Please give this test build a go.
>> >>
>> >> I will continue preparing gnustep-gui and gnustep-back.
>> >>
>> >> On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
>> >>> I am resuming work on releases today and hope to prepare at least
>> >>> -base tarball today.
>> >>>
>> >>> On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
>> >>>  wrote:
>> >>>>
>> >>>> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald <
>> rich...@frithmacdonald.me.uk>:
>> >>>>
>> >>>> IIRC the standard/historic behavior is that an object can retain
>> itself in the -dealloc method, to extend its own lifetime, and I guess that
>> the singletons do that (I haven't checked).
>> >>>> I think that behavior changed for ARC, so it could be that the
>> runtime is performing an ARC style deallocation when it should be calling
>> NSDeallocateObject() (or something odd is going on in the
>> NSDeallocateObject() function).
>> >>>>
>> >>>>
>> >>>> I’ve pushed a change in the following PR that fixes the test failure:
>> >>>>
>> https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
>> >>>>
>> >>>> Frederik
>> >>>>
>>
>>
>>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>

Re: GNUstep releases this month?

[Gregory Casamento]

I did a build as well and ran the tests.   Seems fine.

GC


On Fri, Apr 30, 2021 at 11:25 AM Riccardo Mottola <
riccardo.mott...@libero.it> wrote:

> Hi
>
> I did a build ot base/gui/back on linux/amd64 gcc and found no issues.
> Maybe this is enough to tell that the packages are complete. Didn't test
> for bugs on all platforms to know if you caught a good git version or not.
>
> Riccardo
>
> Ivan Vučica wrote:
> > (This is not a release announcement)
> >
> > A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
> > at http://badc0de.net/gs/2021.
> >
> > Actual final releases will, as always, be distributed via GNUstep FTP.
> > Please give this test build a go.
> >
> > ===
> >
> > Psst! If you are using themes such as Rik, you might need to rebuild
> > them, even if there were no code changes. This is usually the case, I
> > suspect, as well; but today I was bit by it for the first time. It was
> > curious as I only saw problems on applications I rebuilt -- which in
> > retrospect makes sense, given the SO bump.
> >
> > ===
> >
> > Now that all four libs are prepared, I will give it a few days to
> > receive a stop signal, or an actively-green-light from maintainers.
> > Then I will send out announcement emails, create GitHub releases, etc.
> >
> > Of course, if you spot a small thing that we _can_ fix post release
> > (i.e. not a full showstopper), I will be happy to cut a smaller
> > point-release.
> >
> >
> > On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica  wrote:
> >> (This is not a release announcement)
> >>
> >> A signed build of gnustep-base 1.28.0 has been uploaded at
> >> http://badc0de.net/gs/2021.
> >>
> >> Actual final releases will, as always, be distributed via GNUstep FTP.
> >> Please give this test build a go.
> >>
> >> I will continue preparing gnustep-gui and gnustep-back.
> >>
> >> On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
> >>> I am resuming work on releases today and hope to prepare at least
> >>> -base tarball today.
> >>>
> >>> On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
> >>>  wrote:
> >>>>
> >>>> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald <
> rich...@frithmacdonald.me.uk>:
> >>>>
> >>>> IIRC the standard/historic behavior is that an object can retain
> itself in the -dealloc method, to extend its own lifetime, and I guess that
> the singletons do that (I haven't checked).
> >>>> I think that behavior changed for ARC, so it could be that the
> runtime is performing an ARC style deallocation when it should be calling
> NSDeallocateObject() (or something odd is going on in the
> NSDeallocateObject() function).
> >>>>
> >>>>
> >>>> I’ve pushed a change in the following PR that fixes the test failure:
> >>>>
> https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
> >>>>
> >>>> Frederik
> >>>>
>
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron
https://gf.me/u/x8m3sx - My GNUstep GoFundMe
https://teespring.com/stores/gnustep - Store

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi

I did a build ot base/gui/back on linux/amd64 gcc and found no issues.
Maybe this is enough to tell that the packages are complete. Didn't test 
for bugs on all platforms to know if you caught a good git version or not.


Riccardo

Ivan Vučica wrote:

(This is not a release announcement)

A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
at http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

===

Psst! If you are using themes such as Rik, you might need to rebuild
them, even if there were no code changes. This is usually the case, I
suspect, as well; but today I was bit by it for the first time. It was
curious as I only saw problems on applications I rebuilt -- which in
retrospect makes sense, given the SO bump.

===

Now that all four libs are prepared, I will give it a few days to
receive a stop signal, or an actively-green-light from maintainers.
Then I will send out announcement emails, create GitHub releases, etc.

Of course, if you spot a small thing that we _can_ fix post release
(i.e. not a full showstopper), I will be happy to cut a smaller
point-release.


On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica  wrote:

(This is not a release announcement)

A signed build of gnustep-base 1.28.0 has been uploaded at
http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

I will continue preparing gnustep-gui and gnustep-back.

On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:

I am resuming work on releases today and hope to prepare at least
-base tarball today.

On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
 wrote:


Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
:

IIRC the standard/historic behavior is that an object can retain itself in the 
-dealloc method, to extend its own lifetime, and I guess that the singletons do 
that (I haven't checked).
I think that behavior changed for ARC, so it could be that the runtime is 
performing an ARC style deallocation when it should be calling 
NSDeallocateObject() (or something odd is going on in the NSDeallocateObject() 
function).


I’ve pushed a change in the following PR that fixes the test failure:
https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f

Frederik

Re: GNUstep releases this month?

[Ivan Vučica]

(This is not a release announcement)

A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
at http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

===

Psst! If you are using themes such as Rik, you might need to rebuild
them, even if there were no code changes. This is usually the case, I
suspect, as well; but today I was bit by it for the first time. It was
curious as I only saw problems on applications I rebuilt -- which in
retrospect makes sense, given the SO bump.

===

Now that all four libs are prepared, I will give it a few days to
receive a stop signal, or an actively-green-light from maintainers.
Then I will send out announcement emails, create GitHub releases, etc.

Of course, if you spot a small thing that we _can_ fix post release
(i.e. not a full showstopper), I will be happy to cut a smaller
point-release.


On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica  wrote:
>
> (This is not a release announcement)
>
> A signed build of gnustep-base 1.28.0 has been uploaded at
> http://badc0de.net/gs/2021.
>
> Actual final releases will, as always, be distributed via GNUstep FTP.
> Please give this test build a go.
>
> I will continue preparing gnustep-gui and gnustep-back.
>
> On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
> >
> > I am resuming work on releases today and hope to prepare at least
> > -base tarball today.
> >
> > On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
> >  wrote:
> > >
> > >
> > > Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> > > :
> > >
> > > IIRC the standard/historic behavior is that an object can retain itself 
> > > in the -dealloc method, to extend its own lifetime, and I guess that the 
> > > singletons do that (I haven't checked).
> > > I think that behavior changed for ARC, so it could be that the runtime is 
> > > performing an ARC style deallocation when it should be calling 
> > > NSDeallocateObject() (or something odd is going on in the 
> > > NSDeallocateObject() function).
> > >
> > >
> > > I’ve pushed a change in the following PR that fixes the test failure:
> > > https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
> > >
> > > Frederik
> > >

Re: GNUstep releases this month?

[Ivan Vučica]

(This is not a release announcement)

A signed build of gnustep-base 1.28.0 has been uploaded at
http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

I will continue preparing gnustep-gui and gnustep-back.

On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
>
> I am resuming work on releases today and hope to prepare at least
> -base tarball today.
>
> On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
>  wrote:
> >
> >
> > Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> > :
> >
> > IIRC the standard/historic behavior is that an object can retain itself in 
> > the -dealloc method, to extend its own lifetime, and I guess that the 
> > singletons do that (I haven't checked).
> > I think that behavior changed for ARC, so it could be that the runtime is 
> > performing an ARC style deallocation when it should be calling 
> > NSDeallocateObject() (or something odd is going on in the 
> > NSDeallocateObject() function).
> >
> >
> > I’ve pushed a change in the following PR that fixes the test failure:
> > https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
> >
> > Frederik
> >

Re: GNUstep releases this month?

[Ivan Vučica]

I am resuming work on releases today and hope to prepare at least
-base tarball today.

On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
 wrote:
>
>
> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> :
>
> IIRC the standard/historic behavior is that an object can retain itself in 
> the -dealloc method, to extend its own lifetime, and I guess that the 
> singletons do that (I haven't checked).
> I think that behavior changed for ARC, so it could be that the runtime is 
> performing an ARC style deallocation when it should be calling 
> NSDeallocateObject() (or something odd is going on in the 
> NSDeallocateObject() function).
>
>
> I’ve pushed a change in the following PR that fixes the test failure:
> https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
>
> Frederik
>

Re: GNUstep releases this month?

[Frederik Seiffert]

> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> :
> 
> IIRC the standard/historic behavior is that an object can retain itself in 
> the -dealloc method, to extend its own lifetime, and I guess that the 
> singletons do that (I haven't checked).
> I think that behavior changed for ARC, so it could be that the runtime is 
> performing an ARC style deallocation when it should be calling 
> NSDeallocateObject() (or something odd is going on in the 
> NSDeallocateObject() function).


I’ve pushed a change in the following PR that fixes the test failure:
https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
 


Frederik

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 23 Mar 2021, at 10:02, Frederik Seiffert  wrote:
> 
> 
> 
>> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald 
>> :
>> 
 Throwing 0x247a578, in flight exception: 0x244e748
 Exception caught by C++: 0
>> 
>> appears to be a libobjc bug (one that Riccardo mentioned to me).
> 
> I think this is just debug output from libobjc2 exception handling, not an 
> error:
> https://github.com/gnustep/libobjc2/blob/master/eh_personality.c#L197-L198
> 
> I’ll submit a PR to change these to DEBUG_LOG() so they are suppressed in 
> release builds.

Thanks ... good to know that it's nothing that actually breaks the code.

Re: GNUstep releases this month?

[Frederik Seiffert]

> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald 
> :
> 
>>> Throwing 0x247a578, in flight exception: 0x244e748
>>> Exception caught by C++: 0
> 
> appears to be a libobjc bug (one that Riccardo mentioned to me).

I think this is just debug output from libobjc2 exception handling, not an 
error:
https://github.com/gnustep/libobjc2/blob/master/eh_personality.c#L197-L198

I’ll submit a PR to change these to DEBUG_LOG() so they are suppressed in 
release builds.

Regarding the test failures I’ve left a comment here, maybe David will be able 
to clarify this:
https://github.com/gnustep/libobjc2/pull/200#issuecomment-804771719

Frederik

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 22 Mar 2021, at 17:41, Frederik Seiffert  wrote:
> 
> 
> 
>> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald 
>> :
>> 
>> I was just looking at that.  The tests are passing for me on debian-10 (gcc) 
>> and fedora-33 (with both gcc and clang with libobjc2 from some months ago)
> 
> That’s good at least.
> 
>> I'm guessing that the issue is a recent libobjc2 one though.
> 
> This libobjc2 change would fit timing-wise, as it was done 2 days before my 
> commits but after the previous commits in Base that were still passing:
> https://github.com/gnustep/libobjc2/commit/73132a6c9832d939f190742a326663a7dcebd339
> 
> I saw that in [GSFileHandle dealloc] we are calling -retain, which seems 
> unusual – not sure if that is supported by the runtime? If not, since we’re 
> throwing an exception anyway maybe we could just remove that call, or 
> implement the singleton differently by overriding retain/release?
> 
> Also that test seems a bit misguided, as we’re calling release on an 
> autoreleased object...

IIRC the standard/historic behavior is that an object can retain itself in the 
-dealloc method, to extend its own lifetime, and I guess that the singletons do 
that (I haven't checked).
I think that behavior changed for ARC, so it could be that the runtime is 
performing an ARC style deallocation when it should be calling 
NSDeallocateObject() (or something odd is going on in the NSDeallocateObject() 
function).

Re: GNUstep releases this month?

[Frederik Seiffert]

> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald 
> :
> 
> I was just looking at that.  The tests are passing for me on debian-10 (gcc) 
> and fedora-33 (with both gcc and clang with libobjc2 from some months ago)

That’s good at least.

> I'm guessing that the issue is a recent libobjc2 one though.

This libobjc2 change would fit timing-wise, as it was done 2 days before my 
commits but after the previous commits in Base that were still passing:
https://github.com/gnustep/libobjc2/commit/73132a6c9832d939f190742a326663a7dcebd339

I saw that in [GSFileHandle dealloc] we are calling -retain, which seems 
unusual – not sure if that is supported by the runtime? If not, since we’re 
throwing an exception anyway maybe we could just remove that call, or implement 
the singleton differently by overriding retain/release?

Also that test seems a bit misguided, as we’re calling release on an 
autoreleased object...

Frederik

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 22 Mar 2021, at 15:25, Frederik Seiffert  wrote:
> 
> 
>> Am 19.03.2021 um 16:40 schrieb Ivan Vučica :
>> 
>> I am thinking of doing it this weekend, any objection?
> 
> 
> The NSFileHandle/singleton tests in Base have been failing for the last 
> couple commits.
> 
> The test logs look like this – trying to release the singletons correctly 
> throws an exception, but then it seems that the retain count is still zero 
> for the singleton objects:
> 
>> Passed test: (2021-03-17 16:59:18.407 +) singleton.m:18 ... stdin 
>> persists
>> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:19 ... stdout 
>> persists
>> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:20 ... strerr 
>> persists
>> Throwing 0x244e538, in flight exception: (nil)
>> Exception caught by C++: 0
>> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:21 ... Cannot 
>> dealloc stdin
>> Throwing 0x244e748, in flight exception: 0x244e538
>> Exception caught by C++: 0
>> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:22 ... Cannot 
>> dealloc stdout
>> Throwing 0x247a578, in flight exception: 0x244e748
>> Exception caught by C++: 0
>> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:23 ... Cannot 
>> dealloc stderr
>> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:24 ... stdin 
>> persists
>> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:25 ... stdout 
>> persists
>> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:26 ... strerr 
>> persists
> 
> 
> The failures started with one of these two commits from myself, but I cannot 
> figure out how they could have caused the above:
> https://github.com/gnustep/libs-base/commit/54ae296b694187b0c92dfd9bb55dfea58f357e84
> https://github.com/gnustep/libs-base/commit/5fb5fb46c404601f6fe8d6bbb7ecaae0af7f0ba7
> 
> Any ideas about what might be going on here? Could any change in Make or 
> libobjc2 maybe have caused the above? I compared build logs between the last 
> successful runs and the failed runs. They were identical except for the 
> failed tests, but they also don’t show which version of the dependencies was 
> checked out so there might have been a difference there.

I was just looking at that.  The tests are passing for me on debian-10 (gcc) 
and fedora-33 (with both gcc and clang with libobjc2 from some months ago)

The text

>> Throwing 0x247a578, in flight exception: 0x244e748
>> Exception caught by C++: 0

appears to be a libobjc bug (one that Riccardo mentioned to me).

But I don't know if this spurious output is related to the test failure.
I'm guessing that the issue is a recent libobjc2 one though.

Re: GNUstep releases this month?

[Frederik Seiffert]

> Am 19.03.2021 um 16:40 schrieb Ivan Vučica :
> 
> I am thinking of doing it this weekend, any objection?


The NSFileHandle/singleton tests in Base have been failing for the last couple 
commits.

The test logs look like this – trying to release the singletons correctly 
throws an exception, but then it seems that the retain count is still zero for 
the singleton objects:

> Passed test: (2021-03-17 16:59:18.407 +) singleton.m:18 ... stdin 
> persists
> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:19 ... stdout 
> persists
> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:20 ... strerr 
> persists
> Throwing 0x244e538, in flight exception: (nil)
> Exception caught by C++: 0
> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:21 ... Cannot 
> dealloc stdin
> Throwing 0x244e748, in flight exception: 0x244e538
> Exception caught by C++: 0
> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:22 ... Cannot 
> dealloc stdout
> Throwing 0x247a578, in flight exception: 0x244e748
> Exception caught by C++: 0
> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:23 ... Cannot 
> dealloc stderr
> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:24 ... stdin 
> persists
> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:25 ... stdout 
> persists
> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:26 ... strerr 
> persists


The failures started with one of these two commits from myself, but I cannot 
figure out how they could have caused the above:
https://github.com/gnustep/libs-base/commit/54ae296b694187b0c92dfd9bb55dfea58f357e84
https://github.com/gnustep/libs-base/commit/5fb5fb46c404601f6fe8d6bbb7ecaae0af7f0ba7

Any ideas about what might be going on here? Could any change in Make or 
libobjc2 maybe have caused the above? I compared build logs between the last 
successful runs and the failed runs. They were identical except for the failed 
tests, but they also don’t show which version of the dependencies was checked 
out so there might have been a difference there.

Frederik

Re: GNUstep releases this month?

[Ivan Vučica]

On Sat, Mar 20, 2021 at 10:48 AM Richard Frith-Macdonald
 wrote:
> > On 19 Mar 2021, at 15:40, Ivan Vučica  wrote:
> >
> > I am thinking of doing it this weekend, any objection?
> >
>
> That sounds good to me.

As usual, I won't send actual announcements or upload to FTP until
we've had a chance to test the builds.

Due to problems with the maintainer key, I've managed only to cut
gnustep-make today. The problems were resolved only by creating a new
GNUPGHOME -- which only too late did I realize is the same that I've
done the last time.

gnustep-make's signed tarball is uploaded here: http://badc0de.net/gs/2021

This is not a release announcement (nor even necessarily the final
tarball for gnustep-make 2.9.0).

Re: GNUstep releases this month?

[Ivan Vučica]

I am thinking of doing it this weekend, any objection?

sent from phone

On Wed 3 Mar 2021, 20:05 Riccardo Mottola, 
wrote:

> Hi,
>
> Richard Frith-Macdonald wrote:
> > I haven't actually tested, but I did look at the diffs and read up on
> the difference between Get/SetWindowLong and Get/SetWindowLongPtr, and it
> all makes sense to me ... I was unable to reproduce the problem on my
> system simply because, thorugh chance, the windows the system was giving me
> all existed in the low part of the address space.
> > The only error is spotted in the change was in WIN32Server.m when
> styling a popup window ... here LONG (32bit) is used to hold the style
> information, where the API requires LONG_PTR (64bit).
> > This would have the catastrophic effect of losing style information for
> popup windows for all those many users of 64bit windows on a big-endian CPU
> :-)
>
> really catastrophic. Since 64bit is only supported since Windows 2000, I
> think that would restrict to  Alpha, since PPC was only supported in NT4
> if I am right :) And no mingw outside intel, AFAIK.
>
> Still, not elegant.. I think I just found the spot and addressed it in
> my last commit.
>
> I'll write some changelog and open a PR, just in time for the release!
>
> Riccardo
>

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi,

Richard Frith-Macdonald wrote:
> I haven't actually tested, but I did look at the diffs and read up on the 
> difference between Get/SetWindowLong and Get/SetWindowLongPtr, and it all 
> makes sense to me ... I was unable to reproduce the problem on my system 
> simply because, thorugh chance, the windows the system was giving me all 
> existed in the low part of the address space.
> The only error is spotted in the change was in WIN32Server.m when styling a 
> popup window ... here LONG (32bit) is used to hold the style information, 
> where the API requires LONG_PTR (64bit).
> This would have the catastrophic effect of losing style information for popup 
> windows for all those many users of 64bit windows on a big-endian CPU :-)

really catastrophic. Since 64bit is only supported since Windows 2000, I
think that would restrict to  Alpha, since PPC was only supported in NT4
if I am right :) And no mingw outside intel, AFAIK.

Still, not elegant.. I think I just found the spot and addressed it in
my last commit.

I'll write some changelog and open a PR, just in time for the release!

Riccardo

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 2 Mar 2021, at 23:57, Riccardo Mottola  wrote:
> 
> Hi all!
> 
> some important work was done the past fortnight...  Richard and I did great 
> stuff in base!
> 
> I had two concerns for a release
> 1) in back we have a strange issue which is going on since past year and 
> which affects only windowmaker: on launch the app-icon was at first black, 
> now it is totally grey. It comes from various "fixes" Sergei did, but which 
> actually caused a regression compared to the old buggy code of the past 
> release! The bug happens only with the xlib and cairo backend, the art 
> backend just works fine.
> 
> 2) mingw 64bit stopped working on several installation recently.  While the 
> latest changes where thought to be the cause, actually it was old code using 
> a mix of old and even older win32 functions. Working with Fred, I cleaned 
> them all up to the newer level.
> 
> I commited this tonight on a special "win64-fixes" branch - should be merged 
> before release.
> 
> I think this fix is very important, things just worked "by chance" for a long 
> time and possibly broke with a mingw or windows update! It absolutely should 
> get into release if it is confirmed to work (or even not to harm, since it 
> improves for me and is technically correct)
> 
> I encourage Richard and Gregory to test this branch and if it works for them, 
> thumbs up.

I haven't actually tested, but I did look at the diffs and read up on the 
difference between Get/SetWindowLong and Get/SetWindowLongPtr, and it all makes 
sense to me ... I was unable to reproduce the problem on my system simply 
because, thorugh chance, the windows the system was giving me all existed in 
the low part of the address space.
The only error is spotted in the change was in WIN32Server.m when styling a 
popup window ... here LONG (32bit) is used to hold the style information, where 
the API requires LONG_PTR (64bit).
This would have the catastrophic effect of losing style information for popup 
windows for all those many users of 64bit windows on a big-endian CPU :-)

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi!

On 2021-02-27 16:17:16 +0100 Richard Frith-Macdonald 
 wrote:


Good point ... I think gnustep-make is in a good place now:  I don't 
know of 
any outstanding issues that should prevent release.


I agree! I tested your configure fixes on mingw32-64 as well as 32bit!




I have just updated ChangeLog for gnustep-base too, so I think that's 
now up 
to date and also in a decent state to go ahead and release.


Base got a lot new cool stuff, no regressions are now to me!
Sure we can fix more things, but we want to keep some cool stuff for 
the next time?


Same goes for base!

Just let's check and merge back for windows improvement... and then it 
will be a very good release I hope!


Riccardo

--
Sent with GNUmail on GNUstep on GNU/Linux from a faithful Thinkpard R52

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi all!

some important work was done the past fortnight...  Richard and I did 
great stuff in base!


I had two concerns for a release
1) in back we have a strange issue which is going on since past year 
and which affects only windowmaker: on launch the app-icon was at 
first black, now it is totally grey. It comes from various "fixes" 
Sergei did, but which actually caused a regression compared to the old 
buggy code of the past release! The bug happens only with the xlib and 
cairo backend, the art backend just works fine.


2) mingw 64bit stopped working on several installation recently.  
While the latest changes where thought to be the cause, actually it 
was old code using a mix of old and even older win32 functions. 
Working with Fred, I cleaned them all up to the newer level.


I commited this tonight on a special "win64-fixes" branch - should be 
merged before release.


I think this fix is very important, things just worked "by chance" for 
a long time and possibly broke with a mingw or windows update! It 
absolutely should get into release if it is confirmed to work (or even 
not to harm, since it improves for me and is technically correct)


I encourage Richard and Gregory to test this branch and if it works 
for them, thumbs up.


 I did a test on a couple of installs I have and it works, both 32bit 
and 64bit, Windows 7 and Windows 10.
If someone has an install of WinXP or Win2000, a test would be 
appreciated. I have, but not available right now in time for this 
week.


I'm quite satisfied for this last-minute work!

Riccardo

--
Proudly written on a ThinkPad R52 with GNUmail with GNUstep on Gentoo 
GNU/Linux

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi,


On 2021-02-28 21:45:03 +0100 Johannes Brakensiek 
 wrote:



Great.

Riccardo, may I ask you to do a release of PDFKit as well? The 
currently 
released makefile is not compatible with libobjc2. svn works.


I apparently did no changes since the past 1.2.0 version bump.
But apparenlty I did never release 1.2.0 ? Very strange... I can't 
find it.
Indeed, then it needs a release, because it contains the whole update 
of xpdf itself, quite important!


I'll kick it out then... so we make it into the big news and nobody 
can say GNUstep is dead.


Riccardo

Re: GNUstep releases this month?

[Johannes Brakensiek]

> Am 01.03.2021 um 15:01 schrieb Ivan Vučica :
> 
> 
> I haven't really done releases of core GNUstep project's software beyond core 
> libraries.
> 
> Additionally, this is not in the core project, but in GAP. +Riccardo Mottola 
> might know more.

Yes, sorry for that misunderstanding. My mail and my wish was meant to address 
Riccardo.

Johannes


> 
>> On Sun, Feb 28, 2021 at 9:12 PM Johannes Brakensiek 
>>  wrote:
>> 
>> On 28 Feb 2021, at 20:56, Ivan Vučica wrote:
>> 
>> > Good point ... I think gnustep-make is in a good place now:  I don't 
>> > know of any outstanding issues that should prevent release.
>> >>
>> >> I have just updated ChangeLog for gnustep-base too, so I think that's 
>> >> now up to date and also in a decent state to go ahead and release.
>> 
>> Great.
>> 
>> Riccardo, may I ask you to do a release of PDFKit as well? The currently 
>> released makefile is not compatible with libobjc2. svn works.
>> 
>> Thank you
>> Johannes
>> 

Re: GNUstep releases this month?

[Ivan Vučica]

I haven't really done releases of core GNUstep project's software beyond
core libraries.

Additionally, this is not in the core project, but in GAP. +Riccardo Mottola
 might know more.

On Sun, Feb 28, 2021 at 9:12 PM Johannes Brakensiek <
johan...@brakensiek.info> wrote:

>
> On 28 Feb 2021, at 20:56, Ivan Vučica wrote:
>
> > Good point ... I think gnustep-make is in a good place now:  I don't
> > know of any outstanding issues that should prevent release.
> >>
> >> I have just updated ChangeLog for gnustep-base too, so I think that's
> >> now up to date and also in a decent state to go ahead and release.
>
> Great.
>
> Riccardo, may I ask you to do a release of PDFKit as well? The currently
> released makefile is not compatible with libobjc2. svn works.
>
> Thank you
> Johannes
>
>

Re: GNUstep releases this month?

[Johannes Brakensiek]

On 28 Feb 2021, at 20:56, Ivan Vučica wrote:

Good point ... I think gnustep-make is in a good place now:  I don't 
know of any outstanding issues that should prevent release.


I have just updated ChangeLog for gnustep-base too, so I think that's 
now up to date and also in a decent state to go ahead and release.


Great.

Riccardo, may I ask you to do a release of PDFKit as well? The currently 
released makefile is not compatible with libobjc2. svn works.


Thank you
Johannes

Re: GNUstep releases this month?

[Ivan Vučica]

Noted. I'll try to make it happen during the week, unless tiredness of
work prevents me. I'll check the news.texi etc for new changes.

On Sat, Feb 27, 2021 at 3:17 PM Richard Frith-Macdonald
 wrote:
>
>
>
> > On 27 Feb 2021, at 13:36, Fred Kiefer  wrote:
> >
> > HI Ivan,
> >
> > still waiting for the thumbs up? You definitely got one from me :-)
> >
> > Riccardo and Richard fixed a few bugs in the meantime and there are surely 
> > a few more to fix, but there always will be. We really should try to get a 
> > new release out to the world. At the moment I am faced with a few bug fixes 
> > for the GNUstep OBS packages that back port some ICU changes from the 
> > current code over to the old releases. It would have been better to avoid 
> > that by getting the releases out earlier.
> >
> > As I already wrote I did update the NEWS files for make, gui and back, but 
> > by now they will be slightly outdated again. And for gui and back I already 
> > increased the version number. For base you will need to extract the NEWS 
> > from the ChangeLog file, but at least that should be updated.
> >
>
> Good point ... I think gnustep-make is in a good place now:  I don't know of 
> any outstanding issues that should prevent release.
>
> I have just updated ChangeLog for gnustep-base too, so I think that's now up 
> to date and also in a decent state to go ahead and release.

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 27 Feb 2021, at 13:36, Fred Kiefer  wrote:
> 
> HI Ivan,
> 
> still waiting for the thumbs up? You definitely got one from me :-)
> 
> Riccardo and Richard fixed a few bugs in the meantime and there are surely a 
> few more to fix, but there always will be. We really should try to get a new 
> release out to the world. At the moment I am faced with a few bug fixes for 
> the GNUstep OBS packages that back port some ICU changes from the current 
> code over to the old releases. It would have been better to avoid that by 
> getting the releases out earlier.
> 
> As I already wrote I did update the NEWS files for make, gui and back, but by 
> now they will be slightly outdated again. And for gui and back I already 
> increased the version number. For base you will need to extract the NEWS from 
> the ChangeLog file, but at least that should be updated.
> 

Good point ... I think gnustep-make is in a good place now:  I don't know of 
any outstanding issues that should prevent release.

I have just updated ChangeLog for gnustep-base too, so I think that's now up to 
date and also in a decent state to go ahead and release.

Re: GNUstep releases this month?

[Fred Kiefer]

HI Ivan,

still waiting for the thumbs up? You definitely got one from me :-)

Riccardo and Richard fixed a few bugs in the meantime and there are surely a 
few more to fix, but there always will be. We really should try to get a new 
release out to the world. At the moment I am faced with a few bug fixes for the 
GNUstep OBS packages that back port some ICU changes from the current code over 
to the old releases. It would have been better to avoid that by getting the 
releases out earlier.

As I already wrote I did update the NEWS files for make, gui and back, but by 
now they will be slightly outdated again. And for gui and back I already 
increased the version number. For base you will need to extract the NEWS from 
the ChangeLog file, but at least that should be updated.

Cheers,
Fred


> Am 21.01.2021 um 19:53 schrieb Ivan Vučica :
> 
> I'll wait for a thumbs-up.

Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Riccardo Mottola]

Hi!

Richard Frith-Macdonald wrote:
> Never mind, I found/fixed it.  Rather than waiting to find out what 
> 'something like' meant exactly, I just tried testing with 1 1 1 and with 0 0 0
> The problem was the second case ... I had placed a check in the code intended 
> to avoid assigning the result of the scan via a nul pointer, but rather than 
> checking the pointer i checked the result.
> That would mean that, in the case where the scanned value was zero, the 
> result was not returned and the memory pointed to was undefined.

oh.. I was still testing while you fixed it! You are one of the best ones!

Tests on Intel:
2021-01-21 15:17:27.353 ScannerTest[3312:3312] parsed: 1.00,
1.00, 1.00 - isAtEnd? 1
2021-01-21 15:17:27.354 ScannerTest[3312:3312] parsed: 0.00,
0.00, 0.00 - isAtEnd? 1

Tests on Sparc:
2021-01-21 16:19:47.859 ScannerTest[20968:3930190728] parsed: 1.00,
1.00, 1.00 - isAtEnd? 1
2021-01-21 16:19:47.913 ScannerTest[20968:3930190728] parsed: 0.00,
0.00, 0.00 - isAtEnd? 1

once again.. the code was general, but SPARC was more sensitive

I was proposing to add it to the test suite, but I saw you did with a
later commit. Does it make sense to have both 1 & 0 as tests?


I also confirm that now interface colors come up correctly on both
SPARC32-bit and SPARC64bit.
With Fred's fixes in GUI... SPARC64 is working fine again, I can launch
several complex applications like GWorkspace and PRICE without spotting
gross errors.


Riccardo

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi,

Riccardo Mottola wrote:
> 9236 Passed tests
>  202 Failed tests
>   46 Dashed hopes
>   14 Skipped sets
>    1 Failed file
>    1 Failed build

if the above is sparc32 on NetBSD 8.2, below we have amd64 on NetBSD 9.1
- always with GCC runtime.


7760 Passed tests
  46 Failed files
  32 Dashed hopes
   8 Failed tests
   1 Failed build

It looks different... less failures but less passes?...

I tried quite a bit to get David's libobcj2 runtime on NetBSD 9.1 IA-32
for further comparison but for now I failed in any way.

For comparison, tests on linux, x86-64 and gcc runtime:


   9465 Passed tests
 33 Dashed hopes
 12 Skipped sets

All OK!


looks good... although
Skipped set:   test01.m 82 ... library built without NSURLSession
support

?

Anyway, I see nothing blocking, I'd love to work with Richard to smooth
out some tests in base..  see if really it is correct to skip/dash all
those on Linux and then see if we can improve the situation on NetBSD,
both amd64 and SPARC.

However applications seem to work, so I think we resolved all most
blocking issues. Thumbs up for a release if it is urgent!


cheers,

Riccardo

Re: GNUstep releases this month?

[Ivan Vučica]

I'll wait for a thumbs-up.

On Thu, Jan 21, 2021 at 2:02 PM Riccardo Mottola
 wrote:
>
> Hi,
>
> Fred Kiefer wrote:
> > If this is really a recent bug, not something that went unnoticed for years 
> > as nobody uses SPARC processors any more, than the only possible change 
> > would be the float parsing change that Richard just made. No idea why this 
> > would fail on something as simple as „1“ or „0“ but this is SPARC specific 
> > so you probably should start of by using the test suit of base on that 
> > machine.
>
>
> in the meanwhile, I did run the test suite:
>
> Working (before)
> 9231 Passed tests
>  207 Failed tests
>   46 Dashed hopes
>   14 Skipped sets
>1 Failed file
>1 Failed build
>
> Current:
>
> 9236 Passed tests
>  202 Failed tests
>   46 Dashed hopes
>   14 Skipped sets
>1 Failed file
>1 Failed build
>
> so actually we "fixed" some tests :) :)
>
>
> Riccardo
>
>

Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:
> In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. 
> The next step would be to write a short test program that feeds these strings 
> to the code above and outputs the values for r, g and b and of course the 
> result of isAtEnd. That should make it easy to track down the issue. But you 
> are the only one with a SPARC processor
I prepared a test containing this:

  str = @"1 1 1";
  scanner = [[NSScanner alloc] initWithString: str];
  [scanner scanDouble: ];
  [scanner scanDouble: ];
  [scanner scanDouble: ];
  isAtEnd = [scanner isAtEnd];
  NSLog(@"parsed: %lf, %lf, %lf - isAtEnd? %d", r, g, b, isAtEnd);
  [scanner release]; 

  str = @"0 0 0";
  scanner = [[NSScanner alloc] initWithString: str];
  [scanner scanDouble: ];
  [scanner scanDouble: ];
  [scanner scanDouble: ];
  isAtEnd = [scanner isAtEnd];
  NSLog(@"parsed: %lf, %lf, %lf - isAtEnd? %d", r, g, b, isAtEnd);
  [scanner release]; 

does this look reasonable? it looks to me.

On intel I get an unexpected result:
2021-01-21 14:09:20.967 ScannerTest[26541:26541] parsed: 1.00,
1.00, 1.00 - isAtEnd? 1
2021-01-21 14:09:20.968 ScannerTest[26541:26541] parsed: 1.00,
1.00, 1.00 - isAtEnd? 1

which is consistent with SPARC:
2021-01-21 16:02:32.466 ScannerTest[5278:3930190648] parsed: 1.00,
1.00, 1.00 - isAtEnd? 1
2021-01-21 16:02:32.555 ScannerTest[5278:3930190648] parsed: 1.00,
1.00, 1.00 - isAtEnd? 1


but why not 0.0  the second time?

Riccardo

Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Richard Frith-Macdonald]

> On 21 Jan 2021, at 14:10, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 20 Jan 2021, at 19:48, Fred Kiefer  wrote:
>> 
>> 
>> 
>>> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola 
>>> :
>>> 
>>> Hi,
>>> 
>>> Fred Kiefer wrote:
> I will try to bisect - but I'd liek to track this down before a release,
> especially knowing it is something done these last months.
 If this is really a recent bug, not something that went unnoticed for 
 years as nobody uses SPARC processors any more, than the only possible 
 change would be the float parsing change that Richard just made. No idea 
 why this would fail on something as simple as „1“ or „0“ but this is SPARC 
 specific so you probably should start of by using the test suit of base on 
 that machine.
>>> 
>>> 
>>> Yes... I confirm it is a recent commit and I tracked it down to this commit:
>>> 
>>> 
>>> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30
>>> Dec 2020) | 2 lines
>>> 
>>> Remove internal GSScanInt and GSScanDouble functions after moving
>>> functionality into the -scanDouble: method.  Add private class method to
>>> support scanning a string for a double without having to create a new
>>> scanner each time (use a shared lock-protected, instance with resetting
>>> of the string being scanned).
>>> 
>>> before this, all color look fine.
>>> 
>>> I'm running the tests to see if some specific failed tests can be
>>> identified ... but apparently they run sequentially on only one CPU and
>>> it takes hours
>>> 
>>> Anyway having an exact commit is also a good start.
>> 
>> 
>> OK, so it is this code in [NSColor colorFromString:] 
>> 
>> 
>> double   r, g, b;
>> NSScanner *scanner = [[NSScanner alloc] initWithString: str];
>> 
>> if ([scanner scanDouble: ] &&
>>[scanner scanDouble: ] &&
>>[scanner scanDouble: ] &&
>>[scanner isAtEnd])
>> 
>> In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. 
>> The next step would be to write a short test program that feeds these 
>> strings to the code above and outputs the values for r, g and b and of 
>> course the result of isAtEnd. That should make it easy to track down the 
>> issue. But you are the only one with a SPARC processor.
> 
> Looks interesting ... do we have the data this is failing on anywhere?
> If I can get a testcase to debug I can see what's going on.


Never mind, I found/fixed it.  Rather than waiting to find out what 'something 
like' meant exactly, I just tried testing with 1 1 1 and with 0 0 0
The problem was the second case ... I had placed a check in the code intended 
to avoid assigning the result of the scan via a nul pointer, but rather than 
checking the pointer i checked the result.
That would mean that, in the case where the scanned value was zero, the result 
was not returned and the memory pointed to was undefined.

Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Richard Frith-Macdonald]

> On 20 Jan 2021, at 19:48, Fred Kiefer  wrote:
> 
> 
> 
>> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola :
>> 
>> Hi,
>> 
>> Fred Kiefer wrote:
 I will try to bisect - but I'd liek to track this down before a release,
 especially knowing it is something done these last months.
>>> If this is really a recent bug, not something that went unnoticed for years 
>>> as nobody uses SPARC processors any more, than the only possible change 
>>> would be the float parsing change that Richard just made. No idea why this 
>>> would fail on something as simple as „1“ or „0“ but this is SPARC specific 
>>> so you probably should start of by using the test suit of base on that 
>>> machine.
>> 
>> 
>> Yes... I confirm it is a recent commit and I tracked it down to this commit:
>> 
>> 
>> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30
>> Dec 2020) | 2 lines
>> 
>> Remove internal GSScanInt and GSScanDouble functions after moving
>> functionality into the -scanDouble: method.  Add private class method to
>> support scanning a string for a double without having to create a new
>> scanner each time (use a shared lock-protected, instance with resetting
>> of the string being scanned).
>> 
>> before this, all color look fine.
>> 
>> I'm running the tests to see if some specific failed tests can be
>> identified ... but apparently they run sequentially on only one CPU and
>> it takes hours
>> 
>> Anyway having an exact commit is also a good start.
> 
> 
> OK, so it is this code in [NSColor colorFromString:] 
> 
> 
> doubler, g, b;
>  NSScanner *scanner = [[NSScanner alloc] initWithString: str];
> 
>  if ([scanner scanDouble: ] &&
> [scanner scanDouble: ] &&
> [scanner scanDouble: ] &&
> [scanner isAtEnd])
> 
> In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. 
> The next step would be to write a short test program that feeds these strings 
> to the code above and outputs the values for r, g and b and of course the 
> result of isAtEnd. That should make it easy to track down the issue. But you 
> are the only one with a SPARC processor.

Looks interesting ... do we have the data this is failing on anywhere?
If I can get a testcase to debug I can see what's going on.

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:
> If this is really a recent bug, not something that went unnoticed for years 
> as nobody uses SPARC processors any more, than the only possible change would 
> be the float parsing change that Richard just made. No idea why this would 
> fail on something as simple as „1“ or „0“ but this is SPARC specific so you 
> probably should start of by using the test suit of base on that machine.


in the meanwhile, I did run the test suite:

Working (before)
9231 Passed tests
 207 Failed tests
  46 Dashed hopes
  14 Skipped sets
   1 Failed file
   1 Failed build

Current:

9236 Passed tests
 202 Failed tests
  46 Dashed hopes
  14 Skipped sets
   1 Failed file
   1 Failed build

so actually we "fixed" some tests :) :)


Riccardo

Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Fred Kiefer]

> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola :
> 
> Hi,
> 
> Fred Kiefer wrote:
>>> I will try to bisect - but I'd liek to track this down before a release,
>>> especially knowing it is something done these last months.
>> If this is really a recent bug, not something that went unnoticed for years 
>> as nobody uses SPARC processors any more, than the only possible change 
>> would be the float parsing change that Richard just made. No idea why this 
>> would fail on something as simple as „1“ or „0“ but this is SPARC specific 
>> so you probably should start of by using the test suit of base on that 
>> machine.
> 
> 
> Yes... I confirm it is a recent commit and I tracked it down to this commit:
> 
> 
> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30
> Dec 2020) | 2 lines
> 
> Remove internal GSScanInt and GSScanDouble functions after moving
> functionality into the -scanDouble: method.  Add private class method to
> support scanning a string for a double without having to create a new
> scanner each time (use a shared lock-protected, instance with resetting
> of the string being scanned).
> 
> before this, all color look fine.
> 
> I'm running the tests to see if some specific failed tests can be
> identified ... but apparently they run sequentially on only one CPU and
> it takes hours
> 
> Anyway having an exact commit is also a good start.


OK, so it is this code in [NSColor colorFromString:] 


double  r, g, b;
  NSScanner *scanner = [[NSScanner alloc] initWithString: str];

  if ([scanner scanDouble: ] &&
  [scanner scanDouble: ] &&
  [scanner scanDouble: ] &&
  [scanner isAtEnd])

In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. 
The next step would be to write a short test program that feeds these strings 
to the code above and outputs the values for r, g and b and of course the 
result of isAtEnd. That should make it easy to track down the issue. But you 
are the only one with a SPARC processor.

Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:
>> I will try to bisect - but I'd liek to track this down before a release,
>> especially knowing it is something done these last months.
> If this is really a recent bug, not something that went unnoticed for years 
> as nobody uses SPARC processors any more, than the only possible change would 
> be the float parsing change that Richard just made. No idea why this would 
> fail on something as simple as „1“ or „0“ but this is SPARC specific so you 
> probably should start of by using the test suit of base on that machine.


Yes... I confirm it is a recent commit and I tracked it down to this commit:


r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30
Dec 2020) | 2 lines

Remove internal GSScanInt and GSScanDouble functions after moving
functionality into the -scanDouble: method.  Add private class method to
support scanning a string for a double without having to create a new
scanner each time (use a shared lock-protected, instance with resetting
of the string being scanned).

before this, all color look fine.

I'm running the tests to see if some specific failed tests can be
identified ... but apparently they run sequentially on only one CPU and
it takes hours

Anyway having an exact commit is also a good start.

Riccardo

Re: GNUstep releases this month?

[Fred Kiefer]

> Am 20.01.2021 um 17:08 schrieb Riccardo Mottola :
> 
> Hi,
> 
> Richard Frith-Macdonald wrote:
>> I think the base library is functionally OK, but I need to get ChangeLog 
>> updated from the git logs, and it turns out there is no tool that does a 
>> good job of this so it may take me a day or two.
> 
> I found a bug some days ago - on SPARC (32bit & 64bit) but only there
> (?) all GUI colors appear inverted between Black and White... so
> controls have white borders. Text may be white or even transparent, but
> only in controls.
> Using the colorpicker shows that all colors are correct.
> 
> I am in the progress of upgrading a second computer which was last
> updated Sempter 2020 and had no issue. Just updating base brought up the
> issue: this means it is not gui/back but base.
> 
> 
> Most probably, it comes down to some parsing of the color strings
> property list.
> 
> I will try to bisect - but I'd liek to track this down before a release,
> especially knowing it is something done these last months.

If this is really a recent bug, not something that went unnoticed for years as 
nobody uses SPARC processors any more, than the only possible change would be 
the float parsing change that Richard just made. No idea why this would fail on 
something as simple as „1“ or „0“ but this is SPARC specific so you probably 
should start of by using the test suit of base on that machine.

Hope this helps,
Fred

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi,

Richard Frith-Macdonald wrote:
> I think the base library is functionally OK, but I need to get ChangeLog 
> updated from the git logs, and it turns out there is no tool that does a good 
> job of this so it may take me a day or two.

I found a bug some days ago - on SPARC (32bit & 64bit) but only there
(?) all GUI colors appear inverted between Black and White... so
controls have white borders. Text may be white or even transparent, but
only in controls.
Using the colorpicker shows that all colors are correct.

I am in the progress of upgrading a second computer which was last
updated Sempter 2020 and had no issue. Just updating base brought up the
issue: this means it is not gui/back but base.


Most probably, it comes down to some parsing of the color strings
property list.

I will try to bisect - but I'd liek to track this down before a release,
especially knowing it is something done these last months.

Riccardo

Re: GNUstep releases this month?

[Sergii Stoian]

Hi,

> On Jan 19, 2021, at 19:29, Ivan Vučica  wrote:
> 
> On Tue, Jan 19, 2021 at 11:26 AM Riccardo Mottola
>  wrote:
>> my only "itch" which would be a regression is the bug of the icon, the
>> stuff Sergeii did...
> 
> Can you clarify this? What action needs to be taken before the
> release? Can you link to the bug so I can understand this better?

The issue is here https://github.com/gnustep/libs-back/issues/30 
.
I can revert changes if it's necessary.

Sergii

Re: GNUstep releases this month?

[Ivan Vučica]

On Tue, Jan 19, 2021 at 11:26 AM Riccardo Mottola
 wrote:
> my only "itch" which would be a regression is the bug of the icon, the
> stuff Sergeii did...

Can you clarify this? What action needs to be taken before the
release? Can you link to the bug so I can understand this better?

Re: GNUstep releases this month?

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:
> I just added the new entries for news.texi for GNUstep make. While doing so I 
> stated the upcoming release as 2.9.0 but giving it the number 2.8.1 would 
> also be fine with me. There are only minor changes for this release. If you 
> decide on a different number please remember to fix that file.

my only "itch" which would be a regression is the bug of the icon, the
stuff Sergeii did...

perhaps I should plan a ProjectCenter release too then.
maybe thematic too, Richard?

Riccardo

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 18 Jan 2021, at 23:37, Ivan Vučica  wrote:
> 
> On Mon, Jan 18, 2021 at 9:49 PM Fred Kiefer  wrote:
>> I just added the new entries for news.texi for GNUstep make. While doing so 
>> I stated the upcoming release as 2.9.0 but giving it the number 2.8.1 would 
>> also be fine with me. There are only minor changes for this release. If you 
>> decide on a different number please remember to fix that file.
>> 
>> Hope that makes your work easier,
>> Fred
> 
> Thanks. I'll wait for Richard's thumbs up and likely work on this over
> the weekend.

I just committed the merge of git log information into ChangeLog
For anyone interested, the command I used to produce output, which I then 
edited by hand, was:

git log --since=2020-04-05 --no-merges --pretty=format:"%ad %an <%ae>%n%n   
 %s" --date=short --name-status | sed -e 's/^[A-Z]\t\(.*\)/\t* \1:/' 
>/ChangeLog.tmp

I arrived at that after a lot of time wasted trying out things on the web that 
claimed to produce beautiful output or to produce standard/gnu stype ChangeLogs 
none of them did).
Maybe, we could feed that output though further processing (to move the file 
names to correct position at the start of the ChangeLog entry rather than the 
end, and to split long commit comments up properly so that they are indented 8 
spaces but not longer than 80).  On the other hand, maybe going through and 
editing by hand is worthwhile (I did fix a number of typos).

Re: GNUstep releases this month?

[Ivan Vučica]

On Mon, Jan 18, 2021 at 9:49 PM Fred Kiefer  wrote:
> I just added the new entries for news.texi for GNUstep make. While doing so I 
> stated the upcoming release as 2.9.0 but giving it the number 2.8.1 would 
> also be fine with me. There are only minor changes for this release. If you 
> decide on a different number please remember to fix that file.
>
> Hope that makes your work easier,
> Fred

Thanks. I'll wait for Richard's thumbs up and likely work on this over
the weekend.

Re: GNUstep releases this month?

[Fred Kiefer]

> Am 18.01.2021 um 16:46 schrieb Ivan Vučica :
> 
> On Mon, Jan 18, 2021 at 10:55 AM Richard Frith-Macdonald
>  wrote:
>>> On 16 Jan 2021, at 19:50, Fred Kiefer  wrote:
>>> 
>>> I updated the required files and also increased the version number in both 
>>> gui and back. I think we normally do this right after a release, but this 
>>> time I forgot about it. So for these two modules we are theoretically ready 
>>> for a release.
>> 
>> I think the base library is functionally OK, but I need to get ChangeLog 
>> updated from the git logs, and it turns out there is no tool that does a 
>> good job of this so it may take me a day or two.
> 
> Thank you, Fred and Richard. Since Yavor said we'll miss the train
> anyway, I won't rush; I'll probably do my part of the work over the
> upcoming weekend.


I just added the new entries for news.texi for GNUstep make. While doing so I 
stated the upcoming release as 2.9.0 but giving it the number 2.8.1 would also 
be fine with me. There are only minor changes for this release. If you decide 
on a different number please remember to fix that file.

Hope that makes your work easier,
Fred

Re: GNUstep releases this month?

[Ivan Vučica]

On Thu, Jan 14, 2021 at 7:51 PM Yavor Doganov  wrote:
>
> Ivan Vučica wrote:
> > Debian is soft-freezing on 2021-02-12.
>
> Debian is already in library transition freeze so please don't rush
> with the releases just for the sake of it.  We had a chat with Gürkan
> recently and decided that we won't manage for bullseye should there be
> new GNUstep releases.
>
> Sorry that again I failed to inform you in advance but life's been
> incredibly difficult in our colonized territory.

No worries, thank you for your work in general! I should also pay
closer attention.

On Mon, Jan 18, 2021 at 10:55 AM Richard Frith-Macdonald
 wrote:
> > On 16 Jan 2021, at 19:50, Fred Kiefer  wrote:
> >
> > I updated the required files and also increased the version number in both 
> > gui and back. I think we normally do this right after a release, but this 
> > time I forgot about it. So for these two modules we are theoretically ready 
> > for a release.
>
> I think the base library is functionally OK, but I need to get ChangeLog 
> updated from the git logs, and it turns out there is no tool that does a good 
> job of this so it may take me a day or two.

Thank you, Fred and Richard. Since Yavor said we'll miss the train
anyway, I won't rush; I'll probably do my part of the work over the
upcoming weekend.

Re: GNUstep releases this month?

[Richard Frith-Macdonald]

> On 16 Jan 2021, at 19:50, Fred Kiefer  wrote:
> 
> I updated the required files and also increased the version number in both 
> gui and back. I think we normally do this right after a release, but this 
> time I forgot about it. So for these two modules we are theoretically ready 
> for a release.

I think the base library is functionally OK, but I need to get ChangeLog 
updated from the git logs, and it turns out there is no tool that does a good 
job of this so it may take me a day or two.

Re: GNUstep releases this month?

[Fred Kiefer]

I updated the required files and also increased the version number in both gui 
and back. I think we normally do this right after a release, but this time I 
forgot about it. So for these two modules we are theoretically ready for a 
release.

Cheers,
Fred

> Am 14.01.2021 um 20:13 schrieb Ivan Vučica :
> 
> Hi Fred,
> 
> thanks for a quick reply!
> 
> I suspect that's where the difference between soft- and hard-freeze
> kicks in, but Yavor can maybe provide some insight in this regard.
> 
> If I get the green lights from other maintainers, I can cut releases next 
> week.
> 
> If a maintainer wishes me to release and upload anything that is not
> included in the usual batch of releases on ftp.gnu.org, let me know
> and I can try pushing that out as well.
> 
> On Thu, Jan 14, 2021 at 6:27 PM Fred Kiefer  wrote:
>> 
>> Hi Ivan,
>> 
>> great that you remind us! The problem at the moment is that there is a know 
>> problem for 64bit big endian systems in gui (actually a rather long standing 
>> issue) and even two suitable solutions for it. But we haven’t decided which 
>> solution to prefer. Either we reach a consensus quickly and deploy the 
>> chosen solution to all affected classes or we release with this know issue. 
>> This sounds worse than it is. We had the issue for a few years and releases 
>> already and nobody noticed.
>> 
>> Apart from that I promise to bring the release notes of gui and back up to 
>> date over the weekend.
>> 
>> Cheers,
>> Fred
>> 
>>> Am 14.01.2021 um 18:40 schrieb Ivan Vučica :
>>> 
>>> Hi maintainers et al!
>>> 
>>> What's the status of our individual projects? Should I plan on cutting
>>> the releases this or the next weekend?
>>> 
>>> Debian is soft-freezing on 2021-02-12. 
>>> https://wiki.debian.org/DebianBullseye
>>> 
>>> I'd like to ask maintainers who are interested in a release happening
>>> to please update the release documentation (see my commits from
>>> just-before-the-previous-release). Obviously, there's no need to
>>> update anything that's automatically generated.
>>> 
>>> The less time I need to spend on producing the release notes by
>>> reading through the commits and trying to piece together a story, the
>>> easier it is to make the release, validate it builds, sign it, upload
>>> it, prepare the signed emails for sending to GNU announcements, etc. I
>>> am happy to review maintainers' (or other volunteers') PRs updating
>>> the docs. If the docs are not updated, I am still ok writing the
>>> updates myself, it might just be messy.
>>> 
>>> The faster we can cut a release, the higher the chance that there's
>>> enough time for Debian package maintainers to get the package through
>>> the bureaucracy and into the bullseye archives.
>>> 
>> 
>> 
> 

Re: GNUstep releases this month?

[Yavor Doganov]

Ivan Vučica wrote:
> Debian is soft-freezing on 2021-02-12.

Debian is already in library transition freeze so please don't rush
with the releases just for the sake of it.  We had a chat with Gürkan
recently and decided that we won't manage for bullseye should there be
new GNUstep releases.

Sorry that again I failed to inform you in advance but life's been
incredibly difficult in our colonized territory.

Re: GNUstep releases this month?

[Ivan Vučica]

Hi Fred,

thanks for a quick reply!

I suspect that's where the difference between soft- and hard-freeze
kicks in, but Yavor can maybe provide some insight in this regard.

If I get the green lights from other maintainers, I can cut releases next week.

If a maintainer wishes me to release and upload anything that is not
included in the usual batch of releases on ftp.gnu.org, let me know
and I can try pushing that out as well.

On Thu, Jan 14, 2021 at 6:27 PM Fred Kiefer  wrote:
>
> Hi Ivan,
>
> great that you remind us! The problem at the moment is that there is a know 
> problem for 64bit big endian systems in gui (actually a rather long standing 
> issue) and even two suitable solutions for it. But we haven’t decided which 
> solution to prefer. Either we reach a consensus quickly and deploy the chosen 
> solution to all affected classes or we release with this know issue. This 
> sounds worse than it is. We had the issue for a few years and releases 
> already and nobody noticed.
>
> Apart from that I promise to bring the release notes of gui and back up to 
> date over the weekend.
>
> Cheers,
> Fred
>
> > Am 14.01.2021 um 18:40 schrieb Ivan Vučica :
> >
> > Hi maintainers et al!
> >
> > What's the status of our individual projects? Should I plan on cutting
> > the releases this or the next weekend?
> >
> > Debian is soft-freezing on 2021-02-12. 
> > https://wiki.debian.org/DebianBullseye
> >
> > I'd like to ask maintainers who are interested in a release happening
> > to please update the release documentation (see my commits from
> > just-before-the-previous-release). Obviously, there's no need to
> > update anything that's automatically generated.
> >
> > The less time I need to spend on producing the release notes by
> > reading through the commits and trying to piece together a story, the
> > easier it is to make the release, validate it builds, sign it, upload
> > it, prepare the signed emails for sending to GNU announcements, etc. I
> > am happy to review maintainers' (or other volunteers') PRs updating
> > the docs. If the docs are not updated, I am still ok writing the
> > updates myself, it might just be messy.
> >
> > The faster we can cut a release, the higher the chance that there's
> > enough time for Debian package maintainers to get the package through
> > the bureaucracy and into the bullseye archives.
> >
>
>

Re: GNUstep releases this month?

[Fred Kiefer]

Hi Ivan,

great that you remind us! The problem at the moment is that there is a know 
problem for 64bit big endian systems in gui (actually a rather long standing 
issue) and even two suitable solutions for it. But we haven’t decided which 
solution to prefer. Either we reach a consensus quickly and deploy the chosen 
solution to all affected classes or we release with this know issue. This 
sounds worse than it is. We had the issue for a few years and releases already 
and nobody noticed.

Apart from that I promise to bring the release notes of gui and back up to date 
over the weekend.

Cheers,
Fred

> Am 14.01.2021 um 18:40 schrieb Ivan Vučica :
> 
> Hi maintainers et al!
> 
> What's the status of our individual projects? Should I plan on cutting
> the releases this or the next weekend?
> 
> Debian is soft-freezing on 2021-02-12. https://wiki.debian.org/DebianBullseye
> 
> I'd like to ask maintainers who are interested in a release happening
> to please update the release documentation (see my commits from
> just-before-the-previous-release). Obviously, there's no need to
> update anything that's automatically generated.
> 
> The less time I need to spend on producing the release notes by
> reading through the commits and trying to piece together a story, the
> easier it is to make the release, validate it builds, sign it, upload
> it, prepare the signed emails for sending to GNU announcements, etc. I
> am happy to review maintainers' (or other volunteers') PRs updating
> the docs. If the docs are not updated, I am still ok writing the
> updates myself, it might just be messy.
> 
> The faster we can cut a release, the higher the chance that there's
> enough time for Debian package maintainers to get the package through
> the bureaucracy and into the bullseye archives.
> 

GNUstep releases this month?

[Ivan Vučica]

Hi maintainers et al!

What's the status of our individual projects? Should I plan on cutting
the releases this or the next weekend?

Debian is soft-freezing on 2021-02-12. https://wiki.debian.org/DebianBullseye

I'd like to ask maintainers who are interested in a release happening
to please update the release documentation (see my commits from
just-before-the-previous-release). Obviously, there's no need to
update anything that's automatically generated.

The less time I need to spend on producing the release notes by
reading through the commits and trying to piece together a story, the
easier it is to make the release, validate it builds, sign it, upload
it, prepare the signed emails for sending to GNU announcements, etc. I
am happy to review maintainers' (or other volunteers') PRs updating
the docs. If the docs are not updated, I am still ok writing the
updates myself, it might just be messy.

The faster we can cut a release, the higher the chance that there's
enough time for Debian package maintainers to get the package through
the bureaucracy and into the bullseye archives.

Are releases needed?

[Ivan Vučica]

I'm not sure when I'll have time to do anything immediately, but if
maintainers estimate there's been enough work done to warrant
releases, and my assistance is requested this year, please let me
know. Something should be doable during a weekend.

If you'd like me to do a release, please bring it to a releasable
state and let me know.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New core releases are out

[Alessandro Sangiuliano]

Thanks to all for the work done for this new release!
I hope to update to this new release as soon as I can.

 Il giorno 17/mag/2015, alle ore 22:26, Fred Kiefer fredkie...@gmx.de ha 
 scritto:
 
 As you will have seen from the previous announcement mails, Richard has
 done another shared release of GNUstep make (2.6.7), base (1.24.8), gui
 (0.24.1) and back (0.24.1). I would like to thank Richard for this.
 Having releases is one important step to keep this project visible.
 
 To support this attempt I have updated the GNUstep core packages at the
 OBS (https://build.opensuse.org/project/show/X11:GNUstep). There you may
 download prebuild RPMs for OpenSuse and Fedora (Warning, all untested!).
 I hope that packages for other distributions will be available soon.
 
 Fred
 
 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 https://lists.gnu.org/mailman/listinfo/gnustep-dev
 


Alex

-
A: Hey dude, where are you from?
B: “I’m from Uros”
A: “What?”
B: “Uros, the Uranos' world capital”
A: “Hey dude, you look so strange and white. You should eat some meat!”
B: “We don’t need to eat”
A: “Hey man, that dude looks so strange, He doesn’t need to eat”
C: “OMG! So strange, he also is so white!”
D: “Why do I have to hunt to eat and survive and he doesn’t need to eat to 
survive? I hate him!”
…

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

New core releases are out

[Fred Kiefer]

As you will have seen from the previous announcement mails, Richard has
done another shared release of GNUstep make (2.6.7), base (1.24.8), gui
(0.24.1) and back (0.24.1). I would like to thank Richard for this.
Having releases is one important step to keep this project visible.

To support this attempt I have updated the GNUstep core packages at the
OBS (https://build.opensuse.org/project/show/X11:GNUstep). There you may
download prebuild RPMs for OpenSuse and Fedora (Warning, all untested!).
I hope that packages for other distributions will be available soon.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New GNUstep releases for base and gui?

[Fred Kiefer]

Am 21.03.2015 um 12:14 schrieb David Chisnall:
 On 20 Mar 2015, at 22:29, Gregory Casamento
 greg.casame...@gmail.com wrote:
 
 BTW, one thing I've been thinking of doing lately is creating
 rpm and deb repositories so that we can distribute our own
 packages in a fashion similar to how the mono project does.
 
 It's been a while since I ran Linux, but I found this kind of thing
 from upstream to be highly counter-productive.  The dependencies are
 always subtly wrong in the third-party repos (because different
 distros name things slightly differently, even between forks from the
 same base) and it reduces the incentive for distros to create their
 own packages.

I tend to agree with David here. Abstract packages are of no use. We
will need packages for specific distributions and we already have those
for a few systems. If we really need more it would be rather easy to
extend, for example, the Open Build Service setup for GNustep
(https://build.opensuse.org/project/show?project=X11%3AGNUstep) to
include more repositories, as they call distributions. Of course this is
only useful if somebody takes over the responsibility for these new
distributions. As David already pointed out there are always some subtle
changes that need to be taken care of for each distribution.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New GNUstep releases for base and gui?

[Gregory Casamento]

On Thu, Mar 19, 2015 at 6:04 PM, Fred Kiefer fredkie...@gmx.de wrote:
 Am 18.03.2015 um 09:12 schrieb Richard Frith-Macdonald:
 On 14 Mar 2015, at 22:03, Fred Kiefer fredkie...@gmx.de wrote:
 I just noticed that openSuse will be switching to the GIFlib 5.1
 release. Which means that we should get Riccardo's changes from last
 summer out as fast as possible. There hasn't been a gui (nad back)
 release in over a year and even the last base bug fix release is half a
 year old.
 There are plenty of other fixes and extensions in both libraries as well.

 I have no problem making a new release of base .,.. do you want it done 
 before gui or in sync with gui?

 A shared base/gui/back release would be great. Maybe even a make
 release? There have been a lot of smallish changes over the last year
 that should justify a release.
 We could set the next two weeks as a code freeze/testing period and have
 the releases at the beginning of April.

 Fred

I concur.  I will release Gorm alongside these releases.

BTW, one thing I've been thinking of doing lately is creating rpm
and deb repositories so that we can distribute our own packages in a
fashion similar to how the mono project does.

GC
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New GNUstep releases for base and gui?

[Fred Kiefer]

Am 18.03.2015 um 08:39 schrieb Germán Arias:
 El sáb, 14-03-2015 a las 23:03 +0100, Fred Kiefer escribió:
 I just noticed that openSuse will be switching to the GIFlib 5.1
 release. Which means that we should get Riccardo's changes from last
 summer out as fast as possible. There hasn't been a gui (nad back)
 release in over a year and even the last base bug fix release is half a
 year old.
 There are plenty of other fixes and extensions in both libraries as well.
 
 Would be nice have this bug:
 
 https://savannah.gnu.org/bugs/?43454
 
 fixed on GUI in this new release.

Fixing that big would indeed be great, but I haven't made any progress
there.

Sorry,
Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New GNUstep releases for base and gui?

[Fred Kiefer]

Am 18.03.2015 um 09:12 schrieb Richard Frith-Macdonald:
 On 14 Mar 2015, at 22:03, Fred Kiefer fredkie...@gmx.de wrote:
 I just noticed that openSuse will be switching to the GIFlib 5.1
 release. Which means that we should get Riccardo's changes from last
 summer out as fast as possible. There hasn't been a gui (nad back)
 release in over a year and even the last base bug fix release is half a
 year old.
 There are plenty of other fixes and extensions in both libraries as well.
 
 I have no problem making a new release of base .,.. do you want it done 
 before gui or in sync with gui?

A shared base/gui/back release would be great. Maybe even a make
release? There have been a lot of smallish changes over the last year
that should justify a release.
We could set the next two weeks as a code freeze/testing period and have
the releases at the beginning of April.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New GNUstep releases for base and gui?

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:

I just noticed that openSuse will be switching to the GIFlib 5.1
release. Which means that we should get Riccardo's changes from last
summer out as fast as possible. There hasn't been a gui (nad back)
release in over a year and even the last base bug fix release is half a
year old.
There are plenty of other fixes and extensions in both libraries as well.

True, I don't know about base, but GUI has improved.

First thing: do we have regressions? Not that I am aware of, but other 
should check


Are there some bugs that can be fixed in this release? Often a lot of 
time passes before a new release and this time perhaps even more. Small 
fix preferred or very serious blocking problems.


Printing stuff for example is just too big and we can procrastinate.

I'd like, if possible that a certain bug with sheets can be fixed in 
this release, I hope it is something small.
I haven't got around formalizing it yet, but sheets essentially come out 
with the wrong color and with no window decorations. It is quite strange.



Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New GNUstep releases for base and gui?

[Germán Arias]

El sáb, 14-03-2015 a las 23:03 +0100, Fred Kiefer escribió:
 I just noticed that openSuse will be switching to the GIFlib 5.1
 release. Which means that we should get Riccardo's changes from last
 summer out as fast as possible. There hasn't been a gui (nad back)
 release in over a year and even the last base bug fix release is half a
 year old.
 There are plenty of other fixes and extensions in both libraries as well.
 
 Fred
 

Would be nice have this bug:

https://savannah.gnu.org/bugs/?43454

fixed on GUI in this new release.

Germán



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

New GNUstep releases for base and gui?

[Fred Kiefer]

I just noticed that openSuse will be switching to the GIFlib 5.1
release. Which means that we should get Riccardo's changes from last
summer out as fast as possible. There hasn't been a gui (nad back)
release in over a year and even the last base bug fix release is half a
year old.
There are plenty of other fixes and extensions in both libraries as well.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Pending releases for Gorm and GnomeTheme this weekend...

[Ivan Vučica]

Currently, I primarily had minor problems with GnomeTheme in the outline
view and in the menu. Menu isn't as important as the outline view. In Zcode,
I'm using an Apple-provided cell for the outline view called
ImageAndTextCell that works great with GNUstep main theme (with a few
#ifdefs). However, background isn't rendered with GnomeTheme in the outline
view, which looks really ugly when I scroll.

If the bug is already fixed, sorry.

On Mon, May 16, 2011 at 19:43, Gregory Casamento
greg.casame...@gmail.comwrote:

 I am planning a Gorm release this weekend.  If anyone has any
 outstanding issues with Gorm it would be nice to hear about them.
 Please file bugs or change requests via the bug system and I will try
 to close them by this weekend.  Currently, the top ones I'm working on
 are:

 * Standalone views - Currently standalone views only work partially,
 which is frustrating for many users
 * Outline view for objects - This has been requested by a lot of
 people since it would simplify navigation.
 * XIB file support - I am leveraging the code written by Fred in GUI
 to do this.   Currently, there is some work in both GUI and Gorm
 needed to complete this, so it may not be done for this weekend's
 release.
 * Better selection of views - When selecting a view in IB, the view
 directly under the mouse cursor is selected, no matter if the
 superview is selected.
 * Specifying sorting of data in table column in Gorm.

 I am also working on fixing some bugs that are present in the current
 release.

 I am also planning on a 0.1 release of the GnomeTheme.   It is
 currently stable enough to release so that people can play with it.
 I plan to fix a few small bugs with it before release.

 Please provide any feedback you feel is appropriate.

 Thanks, GC
 --
 Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
 yahoo/skype: greg_casamento, aol: gjcasa
 (240)274-9630 (Cell)

 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 https://lists.gnu.org/mailman/listinfo/gnustep-dev




-- 
Ivan Vučica
i...@vucica.net
Coming soon for iPhone, Zombie Ball - http://j.mp/zombieball
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep releases

[David Chisnall]

At FOSDEM, Fred also suggested re-running the clang static analyser and fixing 
the bugs that it finds before the next release.  I've got some new results for 
-base, but I haven't finished setting up the dependencies for -gui on the 
machine that's fast enough to run the analyser in a timely fashion.  I hope to 
do this later in the week.

David

On 9 Feb 2011, at 17:44, Gregory Casamento wrote:

 I agree with this list.   Can anyone think of anything else?
 
 I'm cross posting this, since it started on the gnustep-discuss list.
 
 GC
 
 On Wed, Feb 9, 2011 at 1:55 AM, Riccardo Mottola mul...@ngi.it wrote:
 Hi,
 
 perhaps we should make a list of things to do before the release of each
 core component. Maybe on the wiki?
 
 Something on the line:
 
 For base:
* finalize FHS decision (or not)
* test working with/without ICU
 For gui:
* fix bug 32166 (theme switching)
* finalize Gnome-theming
* correct theming for Thematic in the definitive way (32056)
* veryfiy bug 27782
 For back:
* 
 
 For all core:
* do compilation test on most platforms
* verify libobjc1/libobcj2/gcc/clang...
 
 Generally, we could add on this list both tasks as well a certain bugs to be
 checked (or discarded) for the release.
 
 Riccardo
 
 Gregory Casamento wrote:
 
 Before we do any release we should give some time for current efforts
 to complete and stabilize.
 
 I would like to complete the work on the GNOME theme prior to the
 release to make sure that there's no additional changes which must be
 made in gnustep-GUI in order to support it fully.
 
 GC
 
 On Tue, Feb 8, 2011 at 3:46 PM, Ivan Vučicaivuc...@gmail.com  wrote:
 
 
 On Wed, Feb 2, 2011 at 11:43, Nicola
 Peronicola.p...@meta-innovation.com
 wrote:
 
 
 gnustep-make needs a bit of work before release too; trunk
 contains a migration to the unix filesystem layout as default
 
 
 
 
 
 
 
 
 
 
 -- 
 Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
 yahoo/skype: greg_casamento, aol: gjcasa
 (240)274-9630 (Cell)
 
 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev


-- Sent from my PDP-11


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep releases

[Gregory Casamento]

I agree with this list.   Can anyone think of anything else?

I'm cross posting this, since it started on the gnustep-discuss list.

GC

On Wed, Feb 9, 2011 at 1:55 AM, Riccardo Mottola mul...@ngi.it wrote:
 Hi,

 perhaps we should make a list of things to do before the release of each
 core component. Maybe on the wiki?

 Something on the line:

 For base:
    * finalize FHS decision (or not)
    * test working with/without ICU
 For gui:
    * fix bug 32166 (theme switching)
    * finalize Gnome-theming
    * correct theming for Thematic in the definitive way (32056)
    * veryfiy bug 27782
 For back:
    * 

 For all core:
    * do compilation test on most platforms
    * verify libobjc1/libobcj2/gcc/clang...

 Generally, we could add on this list both tasks as well a certain bugs to be
 checked (or discarded) for the release.

 Riccardo

 Gregory Casamento wrote:

 Before we do any release we should give some time for current efforts
 to complete and stabilize.

 I would like to complete the work on the GNOME theme prior to the
 release to make sure that there's no additional changes which must be
 made in gnustep-GUI in order to support it fully.

 GC

 On Tue, Feb 8, 2011 at 3:46 PM, Ivan Vučicaivuc...@gmail.com  wrote:


 On Wed, Feb 2, 2011 at 11:43, Nicola
 Peronicola.p...@meta-innovation.com
 wrote:


 gnustep-make needs a bit of work before release too; trunk
 contains a migration to the unix filesystem layout as default










-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Riccardo Mottola]

Hi,


Stef Bidi wrote:

Thanks... I'll try it out as soon as I can.  Saw that you updated the bug
report, as well, and will report back there.  Build GWorkspace just a few
weeks back on Slackware 13.1 (latest release) and it was giving me the same
problems... sqlite3.h is found but it can't link against the function it's
looking for (it's a bit weird).
   


I never understood that error. It might be a slackware oddity, I got 
GWorkspace compile with sqlite on all my systems, including Windows!

On that note, when can we expect a new release of GW?  It's been a while.

   
Yes, but I admit I worked on it sparingly. I'd love to do a release 
soon, given this release wave and the fixes that are in.

I'd like a confirm about this build system change.

GWorkspace has an odd display bug I notice sometimes on certain systems, 
but I have no reliable way of reproducing it (some icons in the browsers 
show clipped). Anyway, with the logic that I don't think I broke any new 
stuff, a release can be done soon.


Riccardo



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Riccardo Mottola]

Hi

Well, since that's you I'd like to see some of the bugs in GWorkspace.
Specifically that sqlite configure bug (24995).  GWorkspace has a bunch of
annoying bugs here and there that make it a pain to use day-in-day-out


I tried to amend that, the problem was actually both a bug and a feature 
request.


REmoval of the dependency I consider a feature request, the real bug was 
that even if selected, the GWMetadata subproject did not build.


Now I made both configuring and building dependent on the configure 
option, which by default is turned off.


Give it a spin.

Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Stef Bidi]

Thanks... I'll try it out as soon as I can.  Saw that you updated the bug
report, as well, and will report back there.  Build GWorkspace just a few
weeks back on Slackware 13.1 (latest release) and it was giving me the same
problems... sqlite3.h is found but it can't link against the function it's
looking for (it's a bit weird).

On that note, when can we expect a new release of GW?  It's been a while.

Stefan
On Thu, Jun 10, 2010 at 7:23 PM, Riccardo Mottola mul...@ngi.it wrote:

 Hi

 Well, since that's you I'd like to see some of the bugs in GWorkspace.
 Specifically that sqlite configure bug (24995).  GWorkspace has a bunch of
 annoying bugs here and there that make it a pain to use day-in-day-out


 I tried to amend that, the problem was actually both a bug and a feature
 request.

 REmoval of the dependency I consider a feature request, the real bug was
 that even if selected, the GWMetadata subproject did not build.

 Now I made both configuring and building dependent on the configure option,
 which by default is turned off.

 Give it a spin.

 Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Nicola Pero]

All,

Since we just did a major release of core


Was there an announcement of the actual release somewhere? I am  
only aware about the discussion relating to an *upcoming* release.




I made an announcement on the info-gnustep list.  It's also on the  
GNUstep wiki.



It may be worth posting the announcement to discuss-gnustep too ? :-)

I wasn't subscribed to info-gnustep myself and was confused myself  
about whether we had released the core libraries or not. ;-)


Just a suggestion - I think a reasonable policy would be to have  
announcements posted to both discuss-gnustep and info-gnustep;
discuss-gnustep is then for people who want to receive everything  
(announcements, discussions, chats, etc), while info-gnustep is for  
people

who want to receive only the official announcements (lower traffic). :-)

I just can't imagine why someone would want to receive all the discuss- 
gnustep posts discussing details and situations that may or may not  
affect them,
and *not* receive the official announcements of new releases, which  
affect everyone. ;-)


But, it is only a suggestion.  Otherwise, I guess I need to subscribe  
to info-gnustep. :-)


Thanks

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Application releases...

[Gregory Casamento]

All,

Since we just did a major release of core it seems like a good idea to
me to release all of our major applications within the next week so
that packagers will have a decent set of applications to bundle with
the current release.

I'm planning on doing a Gorm release by the end of the week (Saturday
or Sunday).

I'd like to know what the release readiness of each of the major
applications is at the moment.

GC
-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Riccardo Mottola]

Hi,

testers and feedbacks are welcome.

I have somehow unofficially taken over GWorkspace and SystemPreferences. 
They are both in a reasonable state, although tests and possible patches 
are welcome. I don't even know if SP needs a new release at all.


What concerns me is ProjectCenter. The release is sorely needed since, 
the last release was 0.5.0. I have no t really big problems with the 
current 0.6.0 so I'd release it except for a problem with filesaving and 
Undo which needs a better test. The planned features of 0.6.0 should be 
posponed to 0.6.1. (as I wrote more than a month ago!)



I have no special complaints about Gorm that are not in the bugtracker, 
so give a bit of fixes I think it is releasable too.


I don't know if Richard plans a Thematic release, but the fact is that 
the last tame I worked on didn't work and I needed to tweak it manually, 
so maybe it is not ready.


I have PRICE essentially ready, the fixes in Gorm allowed me to port all 
the new stuff from Mac to GNUstep. It needs testing however, since most 
of the controllers saw updating and I could have broken things. This 
will be the 1.0 release!


Several applications in GAP need some minor adjustments too but are 
almost ready.


Riccardo

Gregory Casamento wrote:

All,

Since we just did a major release of core it seems like a good idea to
me to release all of our major applications within the next week so
that packagers will have a decent set of applications to bundle with
the current release.

I'm planning on doing a Gorm release by the end of the week (Saturday
or Sunday).

I'd like to know what the release readiness of each of the major
applications is at the moment.

GC
   



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Stef Bidi]

On Thu, May 13, 2010 at 4:30 PM, Riccardo Mottola mul...@ngi.it wrote:

 Hi,

 testers and feedbacks are welcome.

 I have somehow unofficially taken over GWorkspace and SystemPreferences.
 They are both in a reasonable state, although tests and possible patches are
 welcome. I don't even know if SP needs a new release at all.


Well, since that's you I'd like to see some of the bugs in GWorkspace.
Specifically that sqlite configure bug (24995).  GWorkspace has a bunch of
annoying bugs here and there that make it a pain to use day-in-day-out.

One thing that really annoys me about it is that it's a session manager but
it's not a session manager.  In this case I have to start WindowMaker (for
example) in the background and then GWorkspace, but since whenever GW logs
out it doesn't close WM correctly, none of the dock icons get saved.  But I
can't start GW before WM or else the Log Out doesn't actually log you out,
it only closes GS apps and quits.

Also, I'd really like to see a release of pbxbuild (and integration with PC,
I know that's a long shot request).  Releases of GAP and Etoile
apps/libraries would be nice, too.

That's it for me... I'll get off the soap box now.

Stefan
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application releases...

[Lars Sonchocky-Helldorf]

Am 13.05.2010 um 18:47 schrieb Gregory Casamento:


All,

Since we just did a major release of core


Was there an announcement of the actual release somewhere? I am only  
aware about the discussion relating to an *upcoming* release.


thanks,

Lars

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Gorm issues and next GNUstep core releases

[Quentin Mathé]

Le 30 oct. 07 à 00:48, Gregory John Casamento a écrit :


I'm aware of this problem and I'm planning on looking into it tonight.


ok :-)

From: Quentin Mathé [EMAIL PROTECTED]:


The issues I discuss are:
- https://savannah.gnu.org/bugs/?21402
- view control points (knots) are invisible most of time, this means
problems for selecting container subviews and resizing views
For this last issue, I have a detailed bug report on the way, I still
need to test and write down the expected behavior for each kind of
control.


I just posted a detailed bug report for this last issue: https:// 
savannah.gnu.org/bugs/index.php?21478


Thanks,
Quentin.

--
Quentin Mathé
[EMAIL PROTECTED]



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Gorm issues and next GNUstep core releases

[Gregory John Casamento]

I'm aware of this problem and I'm planning on looking into it tonight.

GJC
 
--
Gregory Casamento -- OLC, Inc 
# GNUstep Chief Maintainer

- Original Message 
From: Quentin Mathé [EMAIL PROTECTED]
To: GNUStep Developers gnustep-dev@gnu.org
Sent: Monday, October 29, 2007 7:42:27 PM
Subject: Gorm issues and next GNUstep core releases


Hi,

 From recent Fred's commits, I just saw that the next gnustep-gui  
release is on the way. That's great :-)
However previous Gorm release crashes with -gui trunk, and Gorm trunk  
although it doesn't crash anymore has several issues that makes it  
difficult to use. These issues weren't present in Gorm 2.1, so I  
think they result from recent gnustep-gui changes and fixing them in  
a clean manner might involve modifying gnustep-gui. That's why I  
would like to suggest delaying next core releases until they are  
fixed. May be all these issues can be fixed directly in Gorm though?…
  
in this case my suggestion is pointless.

The issues I discuss are:
- https://savannah.gnu.org/bugs/?21402
- view control points (knots) are invisible most of time, this means  
problems for selecting container subviews and resizing views
For this last issue, I have a detailed bug report on the way, I still  
need to test and write down the expected behavior for each kind of  
control.

Cheers,
Quentin.

--
Quentin Mathé
[EMAIL PROTECTED]



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Proposal: Mandatory periodic releases

[Helge Hess]

Hi,

On 1. Mrz 2006, at 15:15 Uhr, Gregory John Casamento wrote:
One of the ways I've noticed that other projects act is that they,  
under normal circumstances, try to make regular releases of the  
code at predictable intervals.  This helps to reassure people that  
the project is active and it also helps to focus developers on  
impending releases.


I'm wondering if this might not be a good thing to start in this  
project, since our releases tend to be occasional.  Just a thought. :)


personally I would like to see a split between stable releases and  
development releases. I talked about that with Nicola at FOSDEM and  
the impression is that GNUstep lacks both, more frequent AND less  
frequent releases.


More frequent because it will be easier to try out new features (and  
have a less moving target even for developers) and less frequent  
because the GNUstep API is too instable for distribution inclusion  
and to base binary software packages upon. (and ABI change in the  
core library every 6 months or so is FAR to much, 12 months might be  
OK, 24 considered stable).



In SOPE/OGo we do this by using the Linux version numbering, that is,  
we have stable releases which are even numbered and NEVER change the  
API (no additional methods, no additional classes, only fixes). And  
we have odd numbers which are alpha releases and are allowed to break  
the ABI.
Eg SOPE 4.4.0 is a stable release and 4.4 will never change the ABI  
while 4.5.1, 4.5.2, ... 4.5.6 are unstable releases and have no  
soname ABI guarantee.


How do we do that in Subversion? If we release a stable version, we  
copy the trunk tree to a branch, eg:

  svn cp /trunk /branches/4.4
The trunk then becames the next unstable. Trunk always has an odd  
numbers and you never have an odd number in (release) branches. To  
make a stable release, we copy the branch to a release, eg:

  svn cp /branches/4.4 /releases/4.4.0
To make an unstable release we just copy the trunk, eg
  svn cp /trunk /releases/4.5.7

BTW: beta releases are also supposed to be ABI stable to the final  
release. So the first branch is actually a beta, not a final release.



I would like to suggest something similiar for GNUstep (at least  
base ;-). With Subversion this is reasonably easy to do. Keeping ABI  
stability of course requires A LOT of discipline.


Greets,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Proposal: Mandatory periodic releases

[Helge Hess]

On 7. Mrz 2006, at 16:41 Uhr, Adam Fedor wrote:
Well, I try to do something like this, only I aim for binary  
compatibility, rather than API stability. That's way too hard for  
me to track - something that all the developers would have to sign  
up to do, not just me. The last binary incompatible release was  
September, last year (7 months).


I'm not entirely sure what you mean by that. Ensuring ABI/API  
stability just implies that every once in a while a new version is  
branched. This branch then is only allowed to add fixes, no new API/ 
ABI stuff.
Development of course will continue as usual (with breaking  
things ;-) in the trunk and with alpha releases.


Technically patches (aka bugfixes) to the branch could/should only be  
allowed for a release manager, could be you or someone else. A patch  
would need to ensure that nothing ABI/API is changed, this should be  
reasonably easy.


Since a stable release should happen max every 12 months this should  
be no big burden. And interest to provide fixes when necessary should  
be high because only stable versions (and API/ABI compatible fixes)  
are usually allowed in distributions.


Summary: IMHO this should be easy with Subversion. Just do a copy of  
trunk every 12/18/24 months and mark that the stable release and  
disallow changes.
This might imply that this only makes sense for core components like  
gstep-make and gstep-base since maybe gstep-gui has so many bugs that  
it doesn't make sense to tag a stable. Can't decide that.


Greets,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Proposal: Mandatory periodic releases

[Gregory John Casamento]

All,One of the ways I've noticed that other projects act is that they, under normal circumstances, try to make regular releases of the code at predictable intervals. This helps to reassure people that the project is active and it also helps to focus developers on impending releases.I'm wondering if this might not be a good thing to start in this project, since our releases tend to be occasional. Just a thought. :)Later,Gregory John Casamento-- Principal Consultant, Open Logic Corp. (A MD Corp.)## Maintainer of Gorm(IB)  GUI(AppKit) for GNUstep.___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev