gimp-print-devel

Re: [Gimp-print-devel] MacOS 10.6

[Robert K. <rl...@al...>]

On 2/4/21 12:38 PM, Matt Broughton wrote:
> 
> 
>> On Feb 3, 2021, at 9:29 PM, Robert Krawitz <rl...@al... <mailto:rl...@al...>> wrote:
>>
>> On 2/3/21 9:35 AM, Matt Broughton wrote:
>>>> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh... <mailto:pi...@sh...>> wrote:
>>>>
>>>> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>>>>> Other than a couple of Mac mini systems that lived on through August 
>>>>> 2007, these were all short-lived laptops that were discontinued at 
>>>>> various times in 2006, so close to 15 years ago.
>>>>
>>>> 10.6 was also the final release to support running PPC binaries (via 
>>>> Rosetta) so there might be folks with newer hardware that are legitimately
>>>> stuck on it. 
>>>
>>> The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to
>>> update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on
>>> the internet.>
>>>> I like the sound of Matt's proposal of two installer packages, one for 
>>>> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
>>>> support burdens for us, especially for platforms that Apple ceased 
>>>> supporting over a decade ago.
>>>
>>> I suggested that because I think it takes a lot more time and resources to build a one off for
>>> 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he
>>> may not be able to support anything lower than 10.13.  With more systems that could use an
>>> unsigned installer, it  *might* be justified to offer a package that wasn't signed.
>>
>> You and Steve have a much better understanding of the Apple market than I do, certainly.  When
>> you've determined what you're going to do, I'll cut a new release build.
> 
> 
> Most of my previous comments were to show how we could meet your general feeling that we should
> support the lowest system we can.  That would mean to support 10.6, we either have to do a singular
> build for 10.6 each release or make it more universal and support 10.6 thru 10.12 with one installer
> and later versions with a second installer.  Either option means two installers.
> 
> A more pragmatic view would be to consider what printers users of 10.6 are using.  If there is a
> reason they haven't upgraded to a more recent version of macos, I don't think many of them have
> upgraded their printers.  I think we have a pretty good record of supporting older printers.  We
> still support an HP DeskJet 870c and an Epson Stylus Color 800.  I used both of them back in System
> 7.1. They can still use a parallel to USB connector. That's a pretty good track record.
> 
> What about any new printers they may try to use.  I'm guessing here!!.  I think most of the new HP
> printers use some flavor of PCL GUI which we don't support.  I think most of the Epson printers are
> 300 dpi rather than 360 dpi.  We don't support them either.  The Ricoh family has gone mostly to PDF
> to PDF.  I'm not sure about the Canon printers.
> 
> What's the old business adage.  You spend 90 percent of your time and effort to support 99 percent
> of your clients.  It takes the remaining 10 percent of your time and effort to support the other 1
> percent.  It essentially boils down to make two installers for each release to include 10.6 or one
> installer to support macos 7 Lion through macos 11 Big Sur.  I'm not doing the work on the
> installers, I will let you and Steve decide which way to go.
> 
> As always, I should mention that my writing style is often a bit strong and lengthy.  It is not
> meant to be such.

I'd like to support as much as we reasonably can.  But I'm also not the one doing the work, and
we're all volunteers.  If continuing to support 10.6 is going to require a lot of extra work, I'd
say punt.  As you said, people running older versions of OS X are probably likely not to be running
the newest printers.

Bottom line, if you and Steve think it's not worthwhile to support 10.6 (or nobody has the time to
do it), I'm fine with dropping it.  It sounds like continuing to support 10.6 is going to require
one of two ugly workarounds.

Re: [Gimp-print-devel] Selphy 800 avec Big Sur

[Solomon P. <pi...@sh...>]

On Sat, Jan 30, 2021 at 12:42:53PM +0100, Anne-Marie wrote:
> I’ve an old Selphy CP800 that I would like to use with my Mac book pro 
> but it will not print. It adds the printer alright with your driver 
> but then it hangs there. I’ve read this is was a common problem years 
> ago but was ressolved then. Do you know how to ressolve this?

Anne-Marie,

The most likely explanation is that the printer was added with the wrong 
backend.  Please remove the printer and re-add it -- you will most 
likely see the printer listed twice; you will need to make sure you 
select the printer with the "gutenprint53+usb" connection instead of 
"usb"

That should get you to the point where you can print successfully.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

Re: [Gimp-print-devel] MacOS 10.6

[Matt B. <wal...@ma...>]

> On Feb 3, 2021, at 9:29 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On 2/3/21 9:35 AM, Matt Broughton wrote:
>>> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh...> wrote:
>>> 
>>> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>>>> Other than a couple of Mac mini systems that lived on through August 
>>>> 2007, these were all short-lived laptops that were discontinued at 
>>>> various times in 2006, so close to 15 years ago.
>>> 
>>> 10.6 was also the final release to support running PPC binaries (via 
>>> Rosetta) so there might be folks with newer hardware that are legitimately
>>> stuck on it. 
>> 
>> The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on the internet.>
>>> I like the sound of Matt's proposal of two installer packages, one for 
>>> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
>>> support burdens for us, especially for platforms that Apple ceased 
>>> supporting over a decade ago.
>> 
>> I suggested that because I think it takes a lot more time and resources to build a one off for 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he may not be able to support anything lower than 10.13.  With more systems that could use an unsigned installer, it  *might* be justified to offer a package that wasn't signed.
> 
> You and Steve have a much better understanding of the Apple market than I do, certainly.  When
> you've determined what you're going to do, I'll cut a new release build.


Most of my previous comments were to show how we could meet your general feeling that we should support the lowest system we can.  That would mean to support 10.6, we either have to do a singular build for 10.6 each release or make it more universal and support 10.6 thru 10.12 with one installer and later versions with a second installer.  Either option means two installers.

A more pragmatic view would be to consider what printers users of 10.6 are using.  If there is a reason they haven't upgraded to a more recent version of macos, I don't think many of them have upgraded their printers.  I think we have a pretty good record of supporting older printers.  We still support an HP DeskJet 870c and an Epson Stylus Color 800.  I used both of them back in System 7.1. They can still use a parallel to USB connector. That's a pretty good track record.

What about any new printers they may try to use.  I'm guessing here!!.  I think most of the new HP printers use some flavor of PCL GUI which we don't support.  I think most of the Epson printers are 300 dpi rather than 360 dpi.  We don't support them either.  The Ricoh family has gone mostly to PDF to PDF.  I'm not sure about the Canon printers.

What's the old business adage.  You spend 90 percent of your time and effort to support 99 percent of your clients.  It takes the remaining 10 percent of your time and effort to support the other 1 percent.  It essentially boils down to make two installers for each release to include 10.6 or one installer to support macos 7 Lion through macos 11 Big Sur.  I'm not doing the work on the installers, I will let you and Steve decide which way to go.

As always, I should mention that my writing style is often a bit strong and lengthy.  It is not meant to be such.

Matt

[Gimp-print-devel] Samsung m2070

[Onofrio L. <ono...@gm...>]

Hello,
Any chances to get the driver of the above printer to use wireless with Fritz.box?
Thank you
The printer only partially works with OS 11 Big Sur 
Onofrio

Re: [Gimp-print-devel] MacOS 10.6

[Robert K. <rl...@al...>]

On 2/3/21 9:35 AM, Matt Broughton wrote:
>> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh...> wrote:
>>
>> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>>> Other than a couple of Mac mini systems that lived on through August 
>>> 2007, these were all short-lived laptops that were discontinued at 
>>> various times in 2006, so close to 15 years ago.
>>
>> 10.6 was also the final release to support running PPC binaries (via 
>> Rosetta) so there might be folks with newer hardware that are legitimately
>> stuck on it. 
> 
> The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on the internet.>
>> I like the sound of Matt's proposal of two installer packages, one for 
>> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
>> support burdens for us, especially for platforms that Apple ceased 
>> supporting over a decade ago.
> 
> I suggested that because I think it takes a lot more time and resources to build a one off for 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he may not be able to support anything lower than 10.13.  With more systems that could use an unsigned installer, it  *might* be justified to offer a package that wasn't signed.

You and Steve have a much better understanding of the Apple market than I do, certainly.  When
you've determined what you're going to do, I'll cut a new release build.

Re: [Gimp-print-devel] MacOS 10.6

[Steve L. <sle...@ya...>]

> On Feb 3, 2021, at 2:50 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>>> On Feb 3, 2021, at 12:57 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>>> 
>>> 
>>>> On Feb 3, 2021, at 9:36 AM, Matt Broughton <wal...@ma...> wrote:
>>> 
>>> 
>>> 
>>>> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh...> wrote:
>>>> 
>>>>> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>>>>> Other than a couple of Mac mini systems that lived on through August 
>>>>> 2007, these were all short-lived laptops that were discontinued at 
>>>>> various times in 2006, so close to 15 years ago.
>>>> 
>>>> 10.6 was also the final release to support running PPC binaries (via 
>>>> Rosetta) so there might be folks with newer hardware that are legitimately
>>>> stuck on it. 
>>> 
>>> The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on the internet.
>>> 
>>> 
>>>> I like the sound of Matt's proposal of two installer packages, one for 
>>>> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
>>>> support burdens for us, especially for platforms that Apple ceased 
>>>> supporting over a decade ago.
>>> 
>>> I suggested that because I think it takes a lot more time and resources to build a one off for 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he may not be able to support anything lower than 10.13.  With more systems that could use an unsigned installer, it  *might* be justified to offer a package that wasn't signed.
>>> 
>>> 
>>>> 
>>>>> I would naively expect that there are more people running 10.12 (say) 
>>>>> for whom signed packages are a plus than people still running 
>>>>> specifically 10.6, but maybe I'm wrong.
>>>> 
>>>> I would agree with that, and there are some numbers to back this up:
>>>> 
>>>> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide/#monthly-201805-202101
>>>> 
>>>> Those numbers show that 10.13 combined is under 9% and <10.10 is under 
>>>> 2%.  Granted, this is taken via web analytics, so it might be skewed a tad.
>>>> 
>>>> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
>>>> 
>>>> This shows 10.6 as having a mere 0.14% of the install base now:
>>>> 
>>>> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
>>>> 
>>>> And this data shows as of mid-2016, <10.8 was under 6%.  It's surely fallen since.
>>>> 
>>>> https://update.omnigroup.com/
>>>> 
>>>> But I digress.. if we can support 10.7+ on a single installer, I think 
>>>> it's time to stick a fork in 10.6.
>>> 
>>> The current build Steve put in Snapshots does work with OS X 10.7.5.  I have tested it.
>>> 
>>> Matt
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Gimp-print-devel mailing list
>>> Gim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>> 
>> One caveat that probably makes building a 10.6 version less important, I’m not sure I have a setup to build PPC fat binaries. I had even forgotten about them until Solomon mentioned it. 
>> 
>> Anyone know off the top of their head when Xcode command line tools stopped supporting PPC builds?  I’ll need to get it. 
> 
> You don't build a PPC binary for 10.6.  It was 10.5 that was the first macos to need Intel.  You could run PPC apps using Rosetta. OS X 10.4 could boot either PPC or Intel.  10.4 was the last OS X to be able to do that.  I have a PPC mac mini and the first generation of the Intel mac mini.  Both machines can use 10.4. After that, you needed to have an Intel machine and you booted into an i386 environment. OS X 10.6 was 32 bit, but it could run Gutenprint in 64 bit mode.  I would need a 64 bit package to make sure.  It was some later version that required you to boot into 64 bit -- 10.8 or 10.9 come to mind.  As this is a one off release for 10.6 only, the easiest and most compatible would be to just build i386 if possible.
> Matt
> 

Thanks Matt. My brain is in the middle of rewriting Diffie Hellman in one of our libraries so it will pass government audit for the foreseeable future. 

Re: [Gimp-print-devel] MacOS 10.6

[Matt B. <wal...@ma...>]

> On Feb 3, 2021, at 12:57 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> 
>> On Feb 3, 2021, at 9:36 AM, Matt Broughton <wal...@ma...> wrote:
>> 
>> 
>> 
>>> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh...> wrote:
>>> 
>>>> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>>>> Other than a couple of Mac mini systems that lived on through August 
>>>> 2007, these were all short-lived laptops that were discontinued at 
>>>> various times in 2006, so close to 15 years ago.
>>> 
>>> 10.6 was also the final release to support running PPC binaries (via 
>>> Rosetta) so there might be folks with newer hardware that are legitimately
>>> stuck on it. 
>> 
>> The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on the internet.
>> 
>> 
>>> I like the sound of Matt's proposal of two installer packages, one for 
>>> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
>>> support burdens for us, especially for platforms that Apple ceased 
>>> supporting over a decade ago.
>> 
>> I suggested that because I think it takes a lot more time and resources to build a one off for 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he may not be able to support anything lower than 10.13.  With more systems that could use an unsigned installer, it  *might* be justified to offer a package that wasn't signed.
>> 
>> 
>>> 
>>>> I would naively expect that there are more people running 10.12 (say) 
>>>> for whom signed packages are a plus than people still running 
>>>> specifically 10.6, but maybe I'm wrong.
>>> 
>>> I would agree with that, and there are some numbers to back this up:
>>> 
>>> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide/#monthly-201805-202101
>>> 
>>> Those numbers show that 10.13 combined is under 9% and <10.10 is under 
>>> 2%.  Granted, this is taken via web analytics, so it might be skewed a tad.
>>> 
>>> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
>>> 
>>> This shows 10.6 as having a mere 0.14% of the install base now:
>>> 
>>> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
>>> 
>>> And this data shows as of mid-2016, <10.8 was under 6%.  It's surely fallen since.
>>> 
>>> https://update.omnigroup.com/
>>> 
>>> But I digress.. if we can support 10.7+ on a single installer, I think 
>>> it's time to stick a fork in 10.6.
>> 
>> The current build Steve put in Snapshots does work with OS X 10.7.5.  I have tested it.
>> 
>> Matt
>> 
>> 
>> 
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
> One caveat that probably makes building a 10.6 version less important, I’m not sure I have a setup to build PPC fat binaries. I had even forgotten about them until Solomon mentioned it. 
> 
> Anyone know off the top of their head when Xcode command line tools stopped supporting PPC builds?  I’ll need to get it. 

You don't build a PPC binary for 10.6.  It was 10.5 that was the first macos to need Intel.  You could run PPC apps using Rosetta. OS X 10.4 could boot either PPC or Intel.  10.4 was the last OS X to be able to do that.  I have a PPC mac mini and the first generation of the Intel mac mini.  Both machines can use 10.4. After that, you needed to have an Intel machine and you booted into an i386 environment. OS X 10.6 was 32 bit, but it could run Gutenprint in 64 bit mode.  I would need a 64 bit package to make sure.  It was some later version that required you to boot into 64 bit -- 10.8 or 10.9 come to mind.  As this is a one off release for 10.6 only, the easiest and most compatible would be to just build i386 if possible.
Matt

Re: [Gimp-print-devel] MacOS 10.6

[Steve L. <sle...@ya...>]

> On Feb 3, 2021, at 9:36 AM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh...> wrote:
>> 
>>> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>>> Other than a couple of Mac mini systems that lived on through August 
>>> 2007, these were all short-lived laptops that were discontinued at 
>>> various times in 2006, so close to 15 years ago.
>> 
>> 10.6 was also the final release to support running PPC binaries (via 
>> Rosetta) so there might be folks with newer hardware that are legitimately
>> stuck on it. 
> 
> The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on the internet.
> 
> 
>> I like the sound of Matt's proposal of two installer packages, one for 
>> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
>> support burdens for us, especially for platforms that Apple ceased 
>> supporting over a decade ago.
> 
> I suggested that because I think it takes a lot more time and resources to build a one off for 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he may not be able to support anything lower than 10.13.  With more systems that could use an unsigned installer, it  *might* be justified to offer a package that wasn't signed.
> 
> 
>> 
>>> I would naively expect that there are more people running 10.12 (say) 
>>> for whom signed packages are a plus than people still running 
>>> specifically 10.6, but maybe I'm wrong.
>> 
>> I would agree with that, and there are some numbers to back this up:
>> 
>> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide/#monthly-201805-202101
>> 
>> Those numbers show that 10.13 combined is under 9% and <10.10 is under 
>> 2%.  Granted, this is taken via web analytics, so it might be skewed a tad.
>> 
>> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
>> 
>> This shows 10.6 as having a mere 0.14% of the install base now:
>> 
>> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
>> 
>> And this data shows as of mid-2016, <10.8 was under 6%.  It's surely fallen since.
>> 
>> https://update.omnigroup.com/
>> 
>> But I digress.. if we can support 10.7+ on a single installer, I think 
>> it's time to stick a fork in 10.6.
> 
> The current build Steve put in Snapshots does work with OS X 10.7.5.  I have tested it.
> 
> Matt
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

One caveat that probably makes building a 10.6 version less important, I’m not sure I have a setup to build PPC fat binaries. I had even forgotten about them until Solomon mentioned it. 

Anyone know off the top of their head when Xcode command line tools stopped supporting PPC builds?  I’ll need to get it. 

Re: [Gimp-print-devel] MacOS 10.6

[Matt B. <wal...@ma...>]

> On Feb 2, 2021, at 6:29 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>> Other than a couple of Mac mini systems that lived on through August 
>> 2007, these were all short-lived laptops that were discontinued at 
>> various times in 2006, so close to 15 years ago.
> 
> 10.6 was also the final release to support running PPC binaries (via 
> Rosetta) so there might be folks with newer hardware that are legitimately
> stuck on it. 

The ones "stuck" on 10.6 may be the enterprise people.  How long did it take for businesses to update from Windows 98.  I'm not so sure about the home user.  You can't do much if anything on the internet.


> I like the sound of Matt's proposal of two installer packages, one for 
> 10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
> support burdens for us, especially for platforms that Apple ceased 
> supporting over a decade ago.

I suggested that because I think it takes a lot more time and resources to build a one off for 10.6.  Also, if I remember correctly, when Michael Sweet offered to help us, he indicated that he may not be able to support anything lower than 10.13.  With more systems that could use an unsigned installer, it  *might* be justified to offer a package that wasn't signed.


> 
>> I would naively expect that there are more people running 10.12 (say) 
>> for whom signed packages are a plus than people still running 
>> specifically 10.6, but maybe I'm wrong.
> 
> I would agree with that, and there are some numbers to back this up:
> 
> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide/#monthly-201805-202101
> 
> Those numbers show that 10.13 combined is under 9% and <10.10 is under 
> 2%.  Granted, this is taken via web analytics, so it might be skewed a tad.
> 
> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
> 
> This shows 10.6 as having a mere 0.14% of the install base now:
> 
> https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/
> 
> And this data shows as of mid-2016, <10.8 was under 6%.  It's surely fallen since.
> 
> https://update.omnigroup.com/
> 
> But I digress.. if we can support 10.7+ on a single installer, I think 
> it's time to stick a fork in 10.6.

The current build Steve put in Snapshots does work with OS X 10.7.5.  I have tested it.

Matt

Re: [Gimp-print-devel] MacOS 10.6

[Solomon P. <pi...@sh...>]

On Tue, Feb 02, 2021 at 06:15:51PM -0500, Robert Krawitz wrote:
>  Other than a couple of Mac mini systems that lived on through August 
> 2007, these were all short-lived laptops that were discontinued at 
> various times in 2006, so close to 15 years ago.

10.6 was also the final release to support running PPC binaries (via 
Rosetta) so there might be folks with newer hardware that are legitimately
stuck on it. 

I like the sound of Matt's proposal of two installer packages, one for 
10.6->10.12, and another for 10.13+, but that obviously carries ongoing 
support burdens for us, especially for platforms that Apple ceased 
supporting over a decade ago.

> I would naively expect that there are more people running 10.12 (say) 
> for whom signed packages are a plus than people still running 
> specifically 10.6, but maybe I'm wrong.

I would agree with that, and there are some numbers to back this up:

 https://gs.statcounter.com/macos-version-market-share/desktop/worldwide/#monthly-201805-202101

Those numbers show that 10.13 combined is under 9% and <10.10 is under 
2%.  Granted, this is taken via web analytics, so it might be skewed a tad.

 https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/

This shows 10.6 as having a mere 0.14% of the install base now:

 https://www.statista.com/statistics/944559/worldwide-macos-version-market-share/

And this data shows as of mid-2016, <10.8 was under 6%.  It's surely fallen since.

 https://update.omnigroup.com/

But I digress.. if we can support 10.7+ on a single installer, I think 
it's time to stick a fork in 10.6.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

Re: [Gimp-print-devel] MacOS 10.6

[Matt B. <wal...@ma...>]

> On Feb 2, 2021, at 8:00 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> Let me verify I can build a version that installs and runs on 10.6.  If I can, let me build a last build for 10.6.  I can add documentation stating it is the last build to support Snow Leopard.  I will wait for Robert to prepare a release version and build both the fat version and the final 10.6 version.  Agreed?
> 
> Steve Letter

Works for me. Let them know that is a one off build for them and that there will be no future releases for Snow Leopard. 
Matt
Sent frothy iPhone


> 
>>> On Feb 2, 2021, at 6:16 PM, Robert Krawitz <rl...@al...> wrote:
>>> 
>> On 2/2/21 3:39 PM, Matt Broughton wrote:
>>> 
>>> 
>>>> On Feb 2, 2021, at 1:23 PM, Steve Letter via Gimp-print-devel
>>>> <gim...@li... <mailto:gim...@li...>> wrote:
>>>> 
>>>> The only easily implemented option to continue support for Snow Leopard is to build a second
>>>> version without signing.  I haven't tested this but I think it would work.  Is this something we
>>>> really want though?
>>>> 
>>>> Steve Letter You're never to old to learn something stupid.  -- unknown
>>> 
>>> Just thinking out loud here.  Would it make more sense to build an unsigned package for Snow Leopard
>>> 10.6 through Sierra 10.12?  I'm thinking that may may provide a longer term solution.  We would then
>>> have a fat binary with x86_64 and arm64 with a signed package for later versions of macos.
>> 
>> If I'm reading it correctly, 10.6 is the last release that supported 32-bit platforms.  It looks
>> like very few systems were orphaned by 10.7, basically the Core Solo and Core Duo (not Core 2 Duo).
>> Other than a couple of Mac mini systems that lived on through August 2007, these were all
>> short-lived laptops that were discontinued at various times in 2006, so close to 15 years ago.  It
>> looks like a fair number more systems were orphaned by 10.8 (the Core 2 Duo ones, including some Mac
>> Pros that might have a longer lifespan), but after that, nothing was orphaned until 10.12, and then
>> only a few MacBook Air laptops.  However, 10.13 orphaned a lot of systems.
>> 
>> I would naively expect that there are more people running 10.12 (say) for whom signed packages are a
>> plus than people still running specifically 10.6, but maybe I'm wrong.  With the switch to a new
>> minor version, this seems like a convenient point to drop support for 10.6.  But again, I'm not a
>> Mac expert so I want to be a bit careful what I say.
>> 
>> 
>> 
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] MacOS 10.6

[Steve L. <sle...@ya...>]

Let me verify I can build a version that installs and runs on 10.6.  If I can, let me build a last build for 10.6.  I can add documentation stating it is the last build to support Snow Leopard.  I will wait for Robert to prepare a release version and build both the fat version and the final 10.6 version.  Agreed?

Steve Letter

> On Feb 2, 2021, at 6:16 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On 2/2/21 3:39 PM, Matt Broughton wrote:
>> 
>> 
>>> On Feb 2, 2021, at 1:23 PM, Steve Letter via Gimp-print-devel
>>> <gim...@li... <mailto:gim...@li...>> wrote:
>>> 
>>> The only easily implemented option to continue support for Snow Leopard is to build a second
>>> version without signing.  I haven't tested this but I think it would work.  Is this something we
>>> really want though?
>>> 
>>> Steve Letter You're never to old to learn something stupid.  -- unknown
>> 
>> Just thinking out loud here.  Would it make more sense to build an unsigned package for Snow Leopard
>> 10.6 through Sierra 10.12?  I'm thinking that may may provide a longer term solution.  We would then
>> have a fat binary with x86_64 and arm64 with a signed package for later versions of macos.
> 
> If I'm reading it correctly, 10.6 is the last release that supported 32-bit platforms.  It looks
> like very few systems were orphaned by 10.7, basically the Core Solo and Core Duo (not Core 2 Duo).
> Other than a couple of Mac mini systems that lived on through August 2007, these were all
> short-lived laptops that were discontinued at various times in 2006, so close to 15 years ago.  It
> looks like a fair number more systems were orphaned by 10.8 (the Core 2 Duo ones, including some Mac
> Pros that might have a longer lifespan), but after that, nothing was orphaned until 10.12, and then
> only a few MacBook Air laptops.  However, 10.13 orphaned a lot of systems.
> 
> I would naively expect that there are more people running 10.12 (say) for whom signed packages are a
> plus than people still running specifically 10.6, but maybe I'm wrong.  With the switch to a new
> minor version, this seems like a convenient point to drop support for 10.6.  But again, I'm not a
> Mac expert so I want to be a bit careful what I say.
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] MacOS 10.6

[Robert K. <rl...@al...>]

On 2/2/21 3:39 PM, Matt Broughton wrote:
> 
> 
>> On Feb 2, 2021, at 1:23 PM, Steve Letter via Gimp-print-devel
>> <gim...@li... <mailto:gim...@li...>> wrote:
>>
>> The only easily implemented option to continue support for Snow Leopard is to build a second
>> version without signing.  I haven't tested this but I think it would work.  Is this something we
>> really want though?
>>
>> Steve Letter You're never to old to learn something stupid.  -- unknown
> 
> Just thinking out loud here.  Would it make more sense to build an unsigned package for Snow Leopard
> 10.6 through Sierra 10.12?  I'm thinking that may may provide a longer term solution.  We would then
> have a fat binary with x86_64 and arm64 with a signed package for later versions of macos.

If I'm reading it correctly, 10.6 is the last release that supported 32-bit platforms.  It looks
like very few systems were orphaned by 10.7, basically the Core Solo and Core Duo (not Core 2 Duo).
 Other than a couple of Mac mini systems that lived on through August 2007, these were all
short-lived laptops that were discontinued at various times in 2006, so close to 15 years ago.  It
looks like a fair number more systems were orphaned by 10.8 (the Core 2 Duo ones, including some Mac
Pros that might have a longer lifespan), but after that, nothing was orphaned until 10.12, and then
only a few MacBook Air laptops.  However, 10.13 orphaned a lot of systems.

I would naively expect that there are more people running 10.12 (say) for whom signed packages are a
plus than people still running specifically 10.6, but maybe I'm wrong.  With the switch to a new
minor version, this seems like a convenient point to drop support for 10.6.  But again, I'm not a
Mac expert so I want to be a bit careful what I say.

Re: [Gimp-print-devel] MacOS 10.6

[Matt B. <wal...@ma...>]

> On Feb 2, 2021, at 1:23 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> The only easily implemented option to continue support for Snow Leopard is to build a second version without signing.  I haven't tested this but I think it would work.  Is this something we really want though?
> 
> Steve Letter You're never to old to learn something stupid.  -- unknown

Just thinking out loud here.  Would it make more sense to build an unsigned package for Snow Leopard 10.6 through Sierra 10.12?  I'm thinking that may may provide a longer term solution.  We would then have a fat binary with x86_64 and arm64 with a signed package for later versions of macos.

Matt

[Gimp-print-devel] MacOS 10.6

[Steve L. <sle...@ya...>]

The only easily implemented option to continue support for Snow Leopard is to build a second version without signing.  I haven't tested this but I think it would work.  Is this something we really want though?

Steve Letter You're never to old to learn something stupid.  -- unknown

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Matt B. <wal...@ma...>]

> On Feb 2, 2021, at 10:05 AM, Steve Letter <sle...@ya...> wrote:
> 
>> 
>> On Feb 1, 2021, at 9:33 PM, Matt Broughton <wal...@ma...> wrote:
>> 
>> 
>> 
>>> On Feb 1, 2021, at 11:53 AM, Steve Letter <sle...@ya... <mailto:sle...@ya...>> wrote:
>>> 
>>> On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma... <mailto:wal...@ma...>> wrote:
>>> 
>>> 
>>> 
>>> 
>>> > On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya... <mailto:sle...@ya...>> wrote:
>>> > 
>>> > 
>>> >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma... <mailto:wal...@ma...>> wrote:
>>> >> 
>>> >> Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.
>>> >> 
>>> >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
>>> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
>>> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):    Mach-O 64-bit executable x86_64
>>> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):    Mach-O 64-bit executable arm64
>>> >> 
>>> >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.
>>> >> 
>>> >> Matt
>>> >> 
>>> > 
>>> > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. 
>>> 
>>> I do want to test it on 10.7 Lion to make sure there are no install errors.  It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand.
>>> 
>>> Matt
>>> 
>>> Sent from my iPad
>>> 
>>> 
>>> Of course!  I was just adding additional information.  The more testing the better!
>> 
>> Installs fine on Lion 10.7.5.  Both x86_64 and arm64 get installed.  Prints fine to my Epson WorkForce 1100.
>> 
>> Matt
>> 
> 
> So now I need to get more familiar with autotools to make some changes in configuring, a few changes in my build script, get the changes into git and I will be ready to do an official build. 
> 
> I haven’t gotten any other feedback from the other 30 something downloads, I guess that’s good news. 
> 
> If we want to do an official build before I finish the above, I can easily reproduce the hacked build. 
> 
> And by the way, there are bugs in the M1 tool chain so I am currently building on x86 (10.15) with the latest Xcode command line tools. 

Just to add another data point.  As expected Mac OS X 10.6 cannot install the package.

Feb  2 10:24:35 SL Installer[383]: Failed to verify data against certificate.
Feb  2 10:24:35 SL Installer[383]: Invalid Distribution File/Package

We may well want to drop 10.6.  It can't connect to https:// website either.

Matt

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Steve L. <sle...@ya...>]

> On Feb 1, 2021, at 9:33 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Feb 1, 2021, at 11:53 AM, Steve Letter <sle...@ya...> wrote:
>> 
>> On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma...> wrote:
>> 
>> 
>> 
>> 
>> > On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya...> wrote:
>> > 
>> > 
>> >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote:
>> >> 
>> >> Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.
>> >> 
>> >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
>> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
>> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):    Mach-O 64-bit executable x86_64
>> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):    Mach-O 64-bit executable arm64
>> >> 
>> >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.
>> >> 
>> >> Matt
>> >> 
>> > 
>> > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. 
>> 
>> I do want to test it on 10.7 Lion to make sure there are no install errors.  It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand.
>> 
>> Matt
>> 
>> Sent from my iPad
>> 
>> 
>> Of course!  I was just adding additional information.  The more testing the better!
> 
> Installs fine on Lion 10.7.5.  Both x86_64 and arm64 get installed.  Prints fine to my Epson WorkForce 1100.
> 
> Matt
> 

So now I need to get more familiar with autotools to make some changes in configuring, a few changes in my build script, get the changes into git and I will be ready to do an official build. 

I haven’t gotten any other feedback from the other 30 something downloads, I guess that’s good news. 

If we want to do an official build before I finish the above, I can easily reproduce the hacked build. 

And by the way, there are bugs in the M1 tool chain so I am currently building on x86 (10.15) with the latest Xcode command line tools. 

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Matt B. <wal...@ma...>]

> On Feb 1, 2021, at 11:53 AM, Steve Letter <sle...@ya...> wrote:
> 
> On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma... <mailto:wal...@ma...>> wrote:
> 
> 
> 
> 
> > On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya... <mailto:sle...@ya...>> wrote:
> > 
> > 
> >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma... <mailto:wal...@ma...>> wrote:
> >> 
> >> Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.
> >> 
> >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):    Mach-O 64-bit executable x86_64
> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):    Mach-O 64-bit executable arm64
> >> 
> >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.
> >> 
> >> Matt
> >> 
> > 
> > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. 
> 
> I do want to test it on 10.7 Lion to make sure there are no install errors.  It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand.
> 
> Matt
> 
> Sent from my iPad
> 
> 
> Of course!  I was just adding additional information.  The more testing the better!

Installs fine on Lion 10.7.5.  Both x86_64 and arm64 get installed.  Prints fine to my Epson WorkForce 1100.

Matt

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Steve L. <sle...@ya...>]

   On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma...> wrote:  
 
 

> On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya...> wrote:
> 
> 
>> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote:
>> 
>> Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.
>> 
>> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):    Mach-O 64-bit executable x86_64
>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):    Mach-O 64-bit executable arm64
>> 
>> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.
>> 
>> Matt
>> 
> 
> I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. 

I do want to test it on 10.7 Lion to make sure there are no install errors.  It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand.
Matt 
Sent from my iPad

Of course!  I was just adding additional information.  The more testing the better!
  

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Matt B. <wal...@ma...>]

> On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya...> wrote:
> 
> 
>> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote:
>> 
>> Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.
>> 
>> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):    Mach-O 64-bit executable x86_64
>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):    Mach-O 64-bit executable arm64
>> 
>> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.
>> 
>> Matt
>> 
> 
> I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. 

I do want to test it on 10.7 Lion to make sure there are no install errors.  It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand.
Matt 
Sent from my iPad

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Steve L. <sle...@ya...>]

> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote:
> 
> Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.
> 
> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):	Mach-O 64-bit executable x86_64
> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):	Mach-O 64-bit executable arm64
> 
> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.
> 
> Matt
> 

I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. 

Re: [Gimp-print-devel] Gutenprint

[Matt B. <wal...@ma...>]

> On Jan 29, 2021, at 6:16 PM, ma...@so... wrote:
> 
> Hello,
> 
> i need your know how -i have two old printer tektronix phaser 750 and
> xerox dc12 via splash 620 - do you have a tool, where i can create a
> printer driver or a driver? ..
> 
> ..costs? ..my mac system ist 10.13.6 high seria
> 
> THANKS
> 
> regards
> 
> Mit freundlichen Grüßen aus dem schönen Mühltal!
> 
> Sylvia Gohlke
> 
> Solutions!
> 
> Kirchstraße 1 - D-64367 Mühltal
> Telefon +49 (0) 61 51 - 50 11 - 916
> Telefax +49 (0) 61 51 - 50 11 - 918
> 
> www.solutions-darmstadt.de
> 
> Einzelkauffrau 
> Finanzamt Darmstadt 

I am one of the Mac people here.  I’m afraid that I am not familiar with fiery servers.  Perhaps someone else is. The best recommendation I have is to try the printing section on the Apple Discussion boards.  They have some very knowledgeable volunteers there that might be able to help you.
Matt 
Sent from my iPad

Re: [Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Matt B. <wal...@ma...>]

> On Feb 1, 2021, at 7:11 AM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> 
>>> Michael, 
>>> 
>>> I tried so many things I was certain I had tried that. So certain I started to write an email about how that didn’t work. But then I thought I’d better make damn sure I had tried it so I did.
>>> 
>>> And man do I feel stupid. Of course that was the answer.  I have uploaded the new disk image (built from the same files as pre1) to
>>> 
>>> https://sourceforge.net/projects/gimp-print/files/snapshots/gutenprint-5.3.4-pre2.dmg/download
>>> 
>>> I am still hacking, I haven’t produced a scripted build yet but I will once we are satisfied it is building correctly. 
>>> 
>>> Steve Letter
>>> Sent from my Symbolics Lisp Machine using zmail. 
>>> 
>>>> On Jan 31, 2021, at 5:02 PM, Michael Sweet <ms...@ms...> wrote:
>>>> 
>>>> Steve,
>>>> 
>>>> You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first...
>>>> 
>>>> 
>>>>> On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <gim...@li... <mailto:gim...@li...>> wrote:
>>>>> 
>>>>> As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, 
>>>>> dyld: Symbol not found: _cupsRasterOpen
>>>>> Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3
>>>>> Expected in: /usr/lib/libcups.2.dylib
>>>>> 
>>>>> I verified that libcupsimage was linked in (with otool -L)
>>>>> 
>>>>> otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3                    
>>>>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3:
>>>>> 	/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2..14.0)
>>>>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
>>>>> 	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7..0.0)
>>>>> 	/usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0)
>>>>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
>>>>> 	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
>>>>> 
>>>>> and that _cupsRasterOpen was indeed in libcupsimage
>>>>> Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen
>>>>> 00000000000035b8 T _cupsRasterOpen
>>>>> 00000000000035e3 T _cupsRasterOpenIO
>>>>> 
>>>>> Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups.  I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong.
>>>>> 
>>>>> Steve Letter

Success!! With macos 10.14.6 Mojave.  Install log looks clean, queue PPDs are updated, and it prints.  I checked a couple of binaries for the architectures included.  Both x86-64 and arm64 are listed.  The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble.

file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon 
/Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
/Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64):	Mach-O 64-bit executable arm64

I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro.  I will check with at least Lion 10.7.

Matt

[Gimp-print-devel] Fixed for MacOS 10.14 universal build uploaded

[Steve L. <sle...@ya...>]

>> Michael, 
>> 
>> I tried so many things I was certain I had tried that. So certain I started to write an email about how that didn’t work. But then I thought I’d better make damn sure I had tried it so I did.
>> 
>> And man do I feel stupid. Of course that was the answer.  I have uploaded the new disk image (built from the same files as pre1) to
>> 
>> https://sourceforge.net/projects/gimp-print/files/snapshots/gutenprint-5.3.4-pre2.dmg/download
>> 
>> I am still hacking, I haven’t produced a scripted build yet but I will once we are satisfied it is building correctly. 
>> 
>> Steve Letter
>> Sent from my Symbolics Lisp Machine using zmail. 
>> 
>>>> On Jan 31, 2021, at 5:02 PM, Michael Sweet <ms...@ms...> wrote:
>>>> 
>>> Steve,
>>> 
>>> You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first...
>>> 
>>> 
>>>> On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>>>> 
>>>> As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, 
>>>> dyld: Symbol not found: _cupsRasterOpen
>>>> Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3
>>>> Expected in: /usr/lib/libcups.2.dylib
>>>> 
>>>> I verified that libcupsimage was linked in (with otool -L)
>>>> 
>>>> otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3                    
>>>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3:
>>>> 	/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2..14.0)
>>>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
>>>> 	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7..0.0)
>>>> 	/usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0)
>>>> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
>>>> 	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
>>>> 
>>>> and that _cupsRasterOpen was indeed in libcupsimage
>>>> Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen
>>>> 00000000000035b8 T _cupsRasterOpen
>>>> 00000000000035e3 T _cupsRasterOpenIO
>>>> 
>>>> Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups.  I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong.
>>>> 
>>>> Steve Letter
>>>> 
>>>> _______________________________________________
>>>> Gimp-print-devel mailing list
>>>> Gim...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>>> 
>>> ________________________
>>> Michael Sweet
>>> 
>>> 
>>> 

Re: [Gimp-print-devel] Undefined Symbol _cupsRasterOpen

[Michael S. <ms...@ms...>]

Steve,

You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first...


> On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file,
> dyld: Symbol not found: _cupsRasterOpen
> Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3
> Expected in: /usr/lib/libcups.2.dylib
> 
> I verified that libcupsimage was linked in (with otool -L)
> 
> otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3
> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3:
> 	/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.14.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
> 	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
> 	/usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0)
> 	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0)
> 	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
> 
> and that _cupsRasterOpen was indeed in libcupsimage
> Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen
> 00000000000035b8 T _cupsRasterOpen
> 00000000000035e3 T _cupsRasterOpenIO
> 
> Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups.  I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong.
> 
> Steve Letter
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

________________________
Michael Sweet