Found here https://pear.php.net/package/Mail_Mime/download that 1.10.4 would be downloadable from there, but as I’m not really familiar with php, I’ve no clue if there might be a chance to put the downloaded 1.10.4 at a place to get the zypper-installed version “overridden/overloaded” by the (temporary) downloaded pear package? Like “playing” with CLASSPATH in Java?
I’m looking at the man page for “zypper”. I have never actually done this – I always use Yast and the “Version” tab for downgrading. But it looks as if you need:
zypper install --oldpackage php-pear-Mail_Mime=1.10.4-lp151.1.1
Loading repository data...
Reading installed packages...
'php-pear-Mail_Mime=1.10.4-lp151.1.1' not found in package names. Trying capabilities.
No provider of 'php-pear-Mail_Mime=1.10.4-lp151.1.1' found.
Seems to me that server:php:applications.repo only have the latest version packages available, is this correct?
Remembering some pains from our period of php5 to php7 upgrade I tried to avoid to “mix” php pkgs. As you see I nevertheless did now, downgraded to 1.10.1, to continue my tests.
Maybe a wrong assumption by me, or a wrong remembrance, but I’ve assumed / believed to remember that updated packages are still stored in a repo for fallback-needed issues like mine
The Leap OSS repo still has the version that LEAP version is released with. And the OSS Update repo contains all the updates of each package that are published since the original release.
Try to contact the repo maintainer to ask him about her/his policy.
There’s a problem there that’s consistent with the error “Package… not found”
The repo really doesn’t have that package despite the various metadata and the Software Search website which indicate the package should be there.
Hi tsu,
just to be sure before opening an issue: The Mail_Mime (1.10.6) package is in the repo, but in the “noarch” subfolder, not in X86_64 as you mentioned.
You (still) think that this is a bug?
[HR][/HR]So, yes, as far as the PHP MIME classes for the implementation interface for mail applications under the PEAR hierarchy is concerned, only those versions listed are currently available in the openSUSE repositories.
[HR][/HR]I looked for the PHP PEAR MIME packages for Mail on “the net{work}” and found this: <https://pear.php.net/package/Mail_Mime> – latest stable version 1.10.7.
Looking at <https://pear.php.net/package/Mail_Mime/download> I notice that, the previous versions can be downloaded.
Given that, we’re talking about PHP classes and that, the concerned package contains a couple of PHP source files in a /usr/share/ directory and, a XML source file in a /var/lib/ directory, it should not be too difficult to merge a previous version from the developer’s source to your local directories.
You’ll have to make sure that, the openSUSE package is locked – to avoid any updates via the openSUSE Repositories until such time that, the PHP PEAR developers have resolved the issue you’re experiencing.
You’ll also have to make sure that, within your environment, everyone is aware that, “zypper verify” and “rpm --verify” will complain about the checksums and everything else associated with the files related to that implementation interface …
My issue has been getting a little more complex than I’ve initially estimated. I’ve started to dig into this because after one of the recent upgrades of roundcubemail on my VPS I’ve recognized that my emails, or precisely the ones sent by roundcubemail, are getting “corrupted”. E.g. German umlauts after storing/sending. Character Set issue. Both for emails with content-type text/plain and also HTML. I’m usually trying to avoid HTML emails, but tried as potential workaround as plain text was corrupted. More worse with HTML, unreadable.
After opening my original issue for roundcubemail https://github.com/roundcube/roundcubemail/issues/7270, with great help of Aleksander, (one of?) the leading contributor of roundcubemail AND the PHP Mail_Mime module, we found out that my issue is very probably distro specififc, does not happen with plain vanilla roundcubemail.
So in fact my search for Mail_Mime 1.10.4 and maybe backwards was in fact useless, as our server:php:applications.repo based roundcubemail ships with a distro specific “vendor” subdirectory. Containing many things including a local pear installation… accessed first, of course.
Sorry, but wrong: you can use the ‘noparse’ and ‘/noparse’ tags ( like code tags, between square brackets ). See: [noparse]home:Dadada:Papapa[/noparse]
Well, I see below my editor panel a part Extra Options (or something like that) and it has a box “Switch smileys out in text”.
My question is: did you try that and did it not work as you intended?
This post with the checkbox “Switch off Smileys” checked.
Nice, I entered them by clicking on the smileys top-right and see hem as such in the edit space, but the preview (and thus the post) shows the characters.
And for this, I guess nobody needs documentation. It is right in front of you when you compose a post.
(Nevertheless, thanks for showing the existence of the NOPARSE tags).
