Requests for current-next (15.0-->15.1)

glennmcc · 02-06-2024, 10:30 PM

Quote:

Originally Posted by jwoithe

For what it's worth, I do. It's a Centrino-2 laptop running at 2 GHz with 2 GB RAM which is still perfectly adequate for the tasks I use it for (mostly cue playouts in performances, multi-channel audio recording, libreoffice, browsing, email). Since purchase, the spinning rust HDD has became an SSD and the RAM taken to maximum (yes, 2 GB). It currently runs Slackware 15.0.

While it continues to work for me I see no reason to add to the eWaste problem by replacing it. I continue to be thankful that Slackware still provides a 32-bit distribution.

That appears to be a 64bit machine not 'bare metal 32bit'.

https://www.cnet.com/culture/intel-c...o-2-explained/

https://www.anandtech.com/show/2649/7

https://www.cnet.com/science/intel-c...es-appearance/

Soooo... why not upgrade it to slackware64 ?

jwoithe · 02-06-2024, 10:45 PM

Quote:

Originally Posted by glennmcc

That appears to be a 64bit machine not 'bare metal 32bit'.

https://www.cnet.com/culture/intel-c...o-2-explained/

Well, that's fascinating. The above page indicates that "Centrino 2" uses a Core2 Duo CPU (which is 64 bit). However, the machine concerned does not have a Core2 Duo CPU. It's very definitely single core, single thread, 32 bit only, and was advertised as such at the time of purchase. <SHRUG> The CPU op-modes and flags confirm it. However, it's also clearly labelled as "Centrino 2" (which had no bearing on the decision to purchase). Go figure.

Given the URL quoted, I can only suggest that some over-zealous marketing person decided to throw a "Centrino-2" label on the laptop for giggles.

Quote:

Soooo... why not upgrade it to slackware64 ?

Because in this specific case it's really a 32-bit CPU, despite being labelled "Centrino-2".

glennmcc · 02-06-2024, 10:49 PM

Quote:

Originally Posted by jwoithe

Well, that's fascinating. The above page indicates that "Centrino 2" uses a Core2 Duo CPU (which is 64 bit). However, the machine concerned does not have a Core2 Duo CPU. It's very definitely single core, single thread, 32 bit only, and was advertised as such at the time of purchase. <SHRUG> The CPU op-modes and flags confirm it. However, it's also clearly labelled as "Centrino 2" (which had no bearing on the decision to purchase). Go figure.

Given the URL quoted, I can only suggest that some over-zealous marketing person decided to throw a "Centrino-2" label on the laptop for giggles.

Because in this specific case it's really a 32-bit CPU, despite being labelled "Centrino-2".

Well then, in your particular case, slackeware-15.0 and as Patrick has stated 15.1 will be continuing as 32bit & 64bit...
you're good to go for many years even if 32bit gets abandoned for let's say 15.2 and on.

The same goes for anyone running 32bit slackware
on a bare metal 32bit machine that's fast enough with enough RAM to handle it.
(my old-as-dirt P-II certainly does not fit that bill so the EOLed 14.0 it shall remain with no security fixes

)

perrin4869 · 02-07-2024, 12:42 AM

Quote:

Originally Posted by volkerdi

Won't compile on 32-bit, evidently because one of the crates it depends on had partial 32-bit x86 support, and that upstream decided it wasn't worth trying to finish it and deleted what was there. Now attempting tree-sitter on 32-bit fails with "unsupported architecture."

I'm throwing it out. Only emacs was using it anyway, and I won't have different versions in 32-bit vs. 64-bit (and there's no point if the older tree-sitter has already lost grammar compatibility).

In other news, 6.6.16 won't compile on 32-bit. I must be the last person testing this. I bisected, reverted the bad commit, and now other things that use the affected header file won't compile.

The bitrot is real.

oh that's really disappointing, I was happy when I noticed tree-sitter had moved to -current, I've been maintaining the sbo SlackBuild for it cause I use it in neovim, but guess that's life... maybe 32bit support will be restored down the line...

cycojesus · 02-07-2024, 03:19 AM

Quote:

Originally Posted by perrin4869

oh that's really disappointing, I was happy when I noticed tree-sitter had moved to -current, I've been maintaining the sbo SlackBuild for it cause I use it in neovim, but guess that's life... maybe 32bit support will be restored down the line...

It is very sad. I do appreciate Slackware not rushing to the latest things at all costs but this and the lack of libgccjit means Slackware provides a crippled Emacs, of all things.

chrisretusn · 02-07-2024, 07:46 AM

v0.3.0 https://github.com/ksnip/kColorPicker
v0.7.0 https://github.com/ksnip/kImageAnnotator

Since we using two program from this github project, maybe consider ksnip, a nice alternative to Spectacle.

sombragris · 02-07-2024, 08:21 AM

enchant-2.6.6, updated last Monday, causes a segfault in my build of claws-mail. Here's the terminal output:

Code:

(claws-mail:8841): GLib-WARNING **: 11:14:46.042: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error opening directory “/home/eduardo/.config/enchant/hunspell”: No such file or directory
Segmentation fault

Of course I had both enchant and hunspell installed.

Rebuiliding claws-mail against the new versions does not fix the issue.

Reverting to enchant-2.6.5 (the previous version) fixes the segfault.

I suspect there's something missing from the 2.6.6 build.

Thus, I request enchant to be reverted to 2.6.5 or maybe fixed, if that's possible.

sombragris · 02-07-2024, 08:24 AM

Quote:

Originally Posted by chrisretusn

v0.3.0 https://github.com/ksnip/kColorPicker
v0.7.0 https://github.com/ksnip/kImageAnnotator

Since we using two program from this github project, maybe consider ksnip, a nice alternative to Spectacle.

Seconded. I have a SlackBuild if needed. Too bad ksnip still is not a featureful on Wayland as it is under X11 (for example, screenshots of rectangular regions are not easy to make). But it's a great, powerful screenshot tool.

gian_d · 02-07-2024, 10:46 AM

Quote:

Originally Posted by sombragris

enchant-2.6.6, updated last Monday, causes a segfault in my build of claws-mail. Here's the terminal output:

Code:

(claws-mail:8841): GLib-WARNING **: 11:14:46.042: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error opening directory “/home/eduardo/.config/enchant/hunspell”: No such file or directory
Segmentation fault

Of course I had both enchant and hunspell installed.

Rebuiliding claws-mail against the new versions does not fix the issue.

Reverting to enchant-2.6.5 (the previous version) fixes the segfault.

I suspect there's something missing from the 2.6.6 build.

Thus, I request enchant to be reverted to 2.6.5 or maybe fixed, if that's possible.

Same issues encountered rebuilding Bluefish, I think this happens for all or several packages that depend on enchant. I downgraded enchant to version 2.6.5

volkerdi · 02-07-2024, 12:28 PM

Quote:

Originally Posted by cycojesus

It is very sad. I do appreciate Slackware not rushing to the latest things at all costs but this and the lack of libgccjit means Slackware provides a crippled Emacs, of all things.

I could throw that out as well.

reddog83 · 02-07-2024, 12:36 PM

If u need to use that dep just recompile the program with that dep included

Pat gives you everything to do just that…

cycojesus · 02-07-2024, 03:58 PM

Quote:

Originally Posted by volkerdi

I could throw that out as well.

There's not need for hostility here. Maybe throw 32bit support out rather than Emacs and me.
Anyway, that was uncalled for, please have a sip of a good beverage on me.

Quote:

Originally Posted by reddog83

If u need to use that dep just recompile the program with that dep included

Pat gives you everything to do just that…

I do build my own packages of what's missing and build my own Emacs package as well, among many others. I have been maintaining my own bunch of packages for decades, I'm fine.

I'm not so much asking for myself than expressing my apparently meaningless opinion here.

If all you vi heathen are willing to throw everything out to keep your piles of dusty 586s puffing and huffing doing nothing I'll see myself out.

EDIT: Whatever. I just finished polishing that last bits of SlackBuilds to not have to depends on anybody for my Emacs needs as I see that solidarity is out of fashion. I don´t know why I bother trying to communicate and help people. That whole discussion should teach me that misanthropy is key. I'll go read a book, that'll be a better use of my time.

EDIT2: I'll keep my money too, because why bother?!

glennmcc · 02-07-2024, 06:05 PM

Quote:

Originally Posted by cycojesus

Anyway, that was uncalled for,

Anything Patrick has to say _is_ called for.

Him the boss.

sombragris · 02-07-2024, 08:14 PM

Code:

l/enchant-2.6.5-x86_64-1.txz: Upgraded.
       Reverted to non-broken version.

Thanks for fixing the issue with enchant!

volkerdi · 02-07-2024, 08:41 PM

Quote:

Originally Posted by cycojesus

There's not need for hostility here.

Hey sorry, I thought it was pretty obvious that it wasn't a serious statement. But also... it's "sad" that our emacs is "crippled"? I mean, it goes both ways.

Anyway, I'm willing to call it water under the bridge if we see you here again.

I've left tree-sitter alone for now, and I'm not sure how we'll handle that. I guess it's not out of the question that it could be dropped only in 32-bit. This probably isn't the last of this sort of thing.

Compiling libgccjit is kind of a mess, but I'll look into it eventually I'm sure.