You are not logged in.

#1 Re: Pacman / Pacman Upgrades » Luajittex broken » 2018-12-02 21:18:50

True, there might be code sections that are excluded from ever executing due to conflicting conditions, but that's bad form and should mainly be picked out by code review, and the compiler should really not be compiling those to bad opcodes anyway.  I guess a bigger problem if you don't know about it is scanning data sections as if they're opcodes; but as I understand it you can use readelf -S to filter only the PROGBITS sections and use that to filter out sections that aren't actually ever interpreted as code.  Granted, that's a little more involved than a grep with escape codes as I hinted at earlier, but perhaps almost possible using a bash script still (although I'd probably script it up first of all in a more capable language just to test my assertions).

#2 Re: Pacman / Pacman Upgrades » Filezilla stopped working with Illegal instruction (core dumped) » 2018-12-01 16:57:36

Hmm, yes I guess mitigations to raw metal hacks like spectre are liable to manifest as instruction sequences written out by compilers in the main.  I guess I'd need to start digging in the patches to even start to figure out what they actually did though, because I would have mainly though the mitigations would consist of not doing specific things in a row rather than writing specfic new opcode that are too new, and they're not advertising their patches in plain prose for fairly obvious reasons.

#3 Re: Pacman / Pacman Upgrades » Luajittex broken » 2018-12-01 16:23:00

I guess the difficulty is really in identifying all the opcodes and combinations thereof that don't turn out to be valid on specific older chips.  Searching for them in the code sections of an elf file should not be impossible; you could probably do it even with just grep and some escape codes.  But getting the definitive list of all the ways that code generation can foul up on older hardware is I guess just impractical to iterate.

I don't even really understand how these extensions are encoded in the raw bitstream.  This seems to be an educational resource for me at least: http://ref.x86asm.net/coder32.html . All of the mmx->sssse3 instructions at least are encoded as an opcode with up to two prefix bytes.

#4 Re: Installation » x86_64 Extra firefox 61.0.1-1 Standalone web browser from mozilla.org » 2018-11-25 20:42:46

Thanks, posting this from the new firefox 63.0.3-1.0.  Did the rust virtual mem space link issue get solved somehow?  I never really expected this issue to be solved to be honest.

BTW, if this thread is really closed, you (arch32yes) should go and mark the title with 'SOLVED' or something along those lines.

#5 Re: Installation » Which --- aur packages --- works with archlinux32? » 2018-11-25 00:10:59

Some will, many of those that don't will be fixable with a tweak of the 'arch=' line, and a few just won't work.  Nobody maintains a list of those that do work yet, but on inspecting the PKGBUILD if it just downloads a binary it probably will download the x64 version which won't work, but if on the other hand it calls some kind of make system then it will probably build fine.

#6 Re: Installation » Webbrowser min will not start » 2018-11-25 00:08:06

My libavcodec.so is at version 58 currently, so it's too new for you too I guess.  Mine got installed when I installed ffmpeg as a dependency of mplayer it seems.

Unfortunately I had to clear out my pacman cache the other day as my /var partition filled up too much, and the only old version of ffmpeg I have also has libavcodec.so.58 in it, so I'm not sure how far you'd need to go back to get so.57.

#7 Re: Installation » x86_64 Extra firefox 61.0.1-1 Standalone web browser from mozilla.org » 2018-11-22 22:14:58

I'm currently using your binary blob aur package and would use an update to 61.3.x, and appreciate it also.  I too am not so keen on binary blobs in user mode code (I dare say there are a few blobs called by kernel module shims), but I have a fair degree of trust in mozilla not to be selling my personal data, even if they do get most of their funding from google.

#8 Re: Pacman / Pacman Upgrades » Broken upgrades... libidn, icu, any ETA? » 2018-11-22 22:09:38

Because pacman doesn't support partial upgrades I guess.  If you want that, you will probably need to identify what depends on the packages you want to ignore and also ignore those, which could be automated, but is not something the pacman authors want to go out of their way to support.

#9 Re: Installation » x86_64 Extra firefox 61.0.1-1 Standalone web browser from mozilla.org » 2018-11-22 20:04:43

Until you hear otherwise, we're not getting any new firefox builds.  They're still trying to build it, last I heard, but it's still failing.

You will have to use one of the other solutions posted here to update your firefox if you know you're running an old unsafe version.

#10 Re: Installation » Survey: On what cpu do you (want to) use archlinux32? » 2018-11-22 16:50:26

Interesting, I think that's a new one.  We've got someone using a T2500 above which is another 2006 chip, and probably has the same flags, but numerically at least it's a new one on me.

#11 Re: Pacman / Pacman Upgrades » Broken upgrades... libidn, icu, any ETA? » 2018-11-21 23:01:31

The icu post has been continually updated though, and as time of writing only four out of 15 or so are listed as not fixed (if your rss reader hasn't flagged up the updated to the post - maybe you need a better rss reader?), one or two of which were already not being upgraded as a matter of course.  I'm less familiar with the libidn breaks, all I can really say is thus far as a user of the testing repos I've not had anything I use regularly break.

If icu is still a problem for you, you may need to look for alternative soltuions as I have, but libidn thus far hasn't touched me; is that more of a qt thing?

Edit: Swapped the intention of my first sentence.  Almost 25% remain to be fixed, if they ever cane be, rather than only 25% being fixed.

#12 Re: Installation » Which ---- flatpak ---- package work with archlinux32? » 2018-11-20 18:58:03

Ah, okay.  I'd not heard of flatpack before you mentioned it here, so I certainly don't have a list of what works and what doesn't.  I don't know if anyone else around these parts use it, and if not you're on your own.

But in case this suddenly becomes popular, you could help out by listing anything you find is broken because of illegal opcodes in a posting to this thread, I guess.  I suppose anything built in the past five years is liable to be 64-bit though, which is why binary distributions not backed by public source suck so badly.

#13 Re: Installation » Which ---- flatpak ---- package work with archlinux32? » 2018-11-20 16:51:02

Does this not work: https://flatpak.org/setup/Arch/ ?  If not, please tell us what errors the tools spit out when you try to install it or to run it.

#14 Re: Installation » snapd and archlinux32 » 2018-11-19 17:17:42

You need to build AUR packages before you can install them, but don't worry, it's a pretty easy process on Archlinux.  But you certainly don't install them with 'pacman -S' which I guess threw me.

The instructions are all here: https://wiki.archlinux.org/index.php/AU … g_packages

Personally, I don't like building things as root, so I don't use the -si flags to makepkg.  I just run it once, note which packages it depends on, install those (with a sudo'ed pacman -S command) and finally install the build package (with sudo pacman -U).

As andreas note, you'll also need to add i686 to the arch variable defined in the PKGBUILD that you download when you do the initial git clone.  Then continue with the makepkg step.  If you forget to do that it'll stop and tell you it can't be built for your architecture, but just go on and edit the variable to tell it it can and it is likely to work.

#15 Re: Installation » snapd and archlinux32 » 2018-11-19 15:24:52

I can not find a package called snapd in the arch32 repos.

That url is also 503ing for me, but doesn't appear to be a currently active repository.  Is your mirrorlist up to date?

#16 Re: Pacman / Pacman Upgrades » "Cannot mix incompatible Qt library" for some Qt apps » 2018-11-17 15:52:09

I'm no expert in qt, but this looks like a duplicate of this to me: https://bbs.archlinux32.org/viewtopic.php?id=2628, though it's fair to say this has the more succinct title at least.

#17 Re: Announcements » icu broken » 2018-11-14 00:21:27

You can also use a text mode browser like lynx or links when your main browser is broken.  They're a bit clunky, but just about usable especially for simple sites like this one.  I don't think I've brought up an archlinux machine yet without installing one of them at some point so I can at least bring up the installation instructions from the wiki on the target machine.

#18 Re: Announcements » icu broken » 2018-11-13 22:20:29

No need to install it anywhere; mine generally live in my builds directory (although that's because I usually build them from AUR, but it seems a reasonable location for them).  It doesn't seem to get copied to /var/cache or anywhere like that, because pacman doesn't really care about packages once it's intalled them, so it leaves those you give it not from the repos up to you to take care of.

If you can get the url onto the problem machine, you should still be able to download it using curl e.g 'curl -LO http://archlinux32.andreasbaumann.cc/aur/i686/icu62-62.1-1.1-i686.pkg.tar.xz'

#19 Re: Announcements » icu broken » 2018-11-13 19:35:31

No, I wouldn't start untarring packages; if you use the icu62 package, it should be installable alongside the icu package which happens to be at version 63.1 right now.

But I'm not using that personally.  I don't use thunderbird, but I am using Andreas' firefox-bin package from <a href="https://aur.archlinux.org/packages/firefox-bin/">the AUR</a>.  That used to be the only way to run firefox that was any newer than v60 or thereabouts, but now that I check the repos there's a firefox 62.0 there, which presumably won't work with the newer icu.  Andreas' version from the AUR doesn't depend on icu so presumably contains its own version

Now I'm a little confused, and it may be worth noting that both Andreas's AUR version and the repo version in extra are still stuck on 62.0 and haven't been updated in the past few weeks.

Er, so yeah, just download the icu62 stub and install it using 'sudo pacman -U', and ignore what I was saying about firefox-bin.

#20 Re: Announcements » icu broken » 2018-11-11 22:04:37

More likely if that's the case, it needs stuff pushed from testing rather than anything being rebuilt.  But otherwise, agreed.

#21 Re: Announcements » icu broken » 2018-11-10 21:41:39

Thanks for keeping this list up to date.  As far as pacman -Qi reports, I only need libreoffice-still rebuilt and it seems you've done that already.

Just updated, and libreoffice still loads and was able to load an odt of mine.  Thanks for working on this!

Also, this explains why this announcement in my RSS reader keeps getting flagged as new.

Edit: By the way, I'd be surprised if you manage to rebuild firefox without getting linking errors.  I've been using mozilla's official i686 builds via various AUR PKGBUILDS since firefox 60 IIRC.  In other words, you didn't break it, so you don't need to fix it.

My installed firefox 62 doesn't depend on libicu, so I guess it includes the binary libs in its own package.  I apparently need to update that to 63.x for a couple of weeks though, and I've not got round to that yet, although judging by the release notes I don't need to hurry, assuming they haven't secretly fixed a security bug I'm not aware of in it.

#22 Re: Pacman / Pacman Upgrades » libreoffice-fresh 6.1.1-1.0 needs to be rebuilt against icu 63.1-2.0 » 2018-11-09 03:37:02

Looks like you're unlikely to be the only one: https://bbs.archlinux32.org/viewtopic.p … 5217#p5217

I guess you still need to have extra perms added to your account to do anything useful on the bug tracker.  You'll need to nag the maintainers to add you the relevant permissions.

#23 Re: Pacman / Pacman Upgrades » [Solved] Recent texlive-bin upgrade has got issues with libpoppler » 2018-11-08 18:08:10

You should avoid using thread marked solved for new bug reports.  Either a new thread or a bug on the bug tracker would do.

But either way, while texlive-bin does depend on poppler (which provides libpoppler.so.*), it doesn't specify a version and as far as I can see my up to date libpoppler.so is still at version 67.  If the maintainers just update poppler they risk breaking libreoffice-still though, as that's why I have poppler installed (I use mupdf for viewing my pdfs).

For you though, as a quick fix you might just need to degrade texlive-bin to an older version still in you cache, then exclude it from future updates until this can be fixed properly.

#24 Re: Pacman / Pacman Upgrades » pacman libidn upgrade breaks rhythmbox » 2018-11-08 15:31:36

The link above is a report in upstream arch 64.  It includes hopeful instructions on how to build it, but it's a bit hacky, so unlikely to be built automatically like that, and especially not if it's not been tested on our configurations.  We're a little short of manpower to test it, and I personally have no interest in rhythmbox.

There's discussion above on rolling back libidn to version 11, and anything else using version 12 of it, but it seems that's not the only problem in the build dependencies.  It's going to take longer than a week and a bit to sort this out, I reckon.

#25 Re: Press Review » Youtube Videos » 2018-11-05 19:55:33

Oh sorry!  I download all of my youtube videos and play them back using mplayer, so I rarely acutally visit youtube from my browser.  I guess he might have introduced himself at the start of the video, but I was still probably still trying to remember my o-level french from decades ago at that point.

Board footer

Powered by FluxBB