Mailing List Archive

On Mon, Jun 1, 2015 at 11:33 AM, Philip Webb <purslow@ca.inter.net> wrote:
> Yesterday, while doing my weekly system update, I encountered a msg :
>
> !!! The following installed packages are masked:
> - media-libs/lcms-1.19-r1::gentoo (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Matthias Maier <tamiko@gentoo.org> (27 May 2015)
> # on behalf of Andreas K. Huettel <dilfridge@gentoo.org>
> # media-libs/lcms:0 has serious security issues and is unmaintained,
> # see bug 526642. Please uninstall it and/or upgrade to media-libs/lcms:2
>
> I looked at the bug, which explains the reason for dropping Lcms:0 .
>
> Unfortunately, Kde-Sunset appears to require Lcms:0 for Libmng:0 ,
> which is required by Qt-Meta:3 & which aren't included in Kde-Sunset itself.
> For now, I can simply ignore the warning, but it looks
> as if it wb no longer possible to install Kde-Sunset on a new machine.
>
> I realise Gentoo itself doesn't provide support for Kde-Sunset,
> but does anyone know of a way round this obstacle or have other advice ?

IIRC mng support in Qt3 is optional. And I doubt you need it, so you
can easily patch the Qt3 ebuild to pass -no-libmng to configure (or
something like that), and you should be able to get rid of the
dependency.

The other (more obvious) alternative is importing lcms:0 in kde-sunset
or in a local overlay, but as the announcement says, it "has serious
security issues"...

Cheers,
Davide

On Mon, 1 Jun 2015 05:33:01 -0400
Philip Webb <purslow@ca.inter.net> wrote:

> [ forwarded to Gentoo-Desktop, the list given for Kde-Sunset ]
>
> Using Kde-Sunset, I have 3 useful apps available in forms
> which aren't provided by KDE 4 (Kworldclock Ksokoban Kmahjongg).
>
> Yesterday, while doing my weekly system update, I encountered a msg :
>
> !!! The following installed packages are masked:
> - media-libs/lcms-1.19-r1::gentoo (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Matthias Maier <tamiko@gentoo.org> (27 May 2015)
> # on behalf of Andreas K. Huettel <dilfridge@gentoo.org>
> # media-libs/lcms:0 has serious security issues and is unmaintained,
> # see bug 526642. Please uninstall it and/or upgrade to media-libs/lcms:2
>
> I looked at the bug, which explains the reason for dropping Lcms:0 .
>
> Unfortunately, Kde-Sunset appears to require Lcms:0 for Libmng:0 ,
> which is required by Qt-Meta:3 & which aren't included in Kde-Sunset itself.
> For now, I can simply ignore the warning, but it looks
> as if it wb no longer possible to install Kde-Sunset on a new machine.
>
> I realise Gentoo itself doesn't provide support for Kde-Sunset,
> but does anyone know of a way round this obstacle or have other advice ?

Compile libmng without lcms support? I'm pretty sure it's optional,
and qt-meta doesn't care what USE flags are set for libmng. No one
uses the mng format anyway, so it isn't much of a loss.

While it isn't optimal, it's possible to get any ebuild that was ever in the
main tree from the attic if you need to fill in gaps for a new installation:

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/?hideattic=0

Some ebuilds from this source may need to be retouched before portage
is happy with them, but if they're not too old it's usually possible to get them
working.

There's also the option of trying the Trinity Desktop Environment, if
ebuilds for the packages you want are available. There's an unofficial overlay
for the most recent release at https://bitbucket.org/mgebert/gentoo-trinity
Trinity is still being actively developed, and bugs about failures to compile
against modern libs should be addressed over time. (Sometimes over a
lot of time, granted, but no-one's perfect.)

E. Liddell

On 01/06/15 19:33, Philip Webb wrote:
> [ forwarded to Gentoo-Desktop, the list given for Kde-Sunset ]
>
> Using Kde-Sunset, I have 3 useful apps available in forms
> which aren't provided by KDE 4 (Kworldclock Ksokoban Kmahjongg).
>
> Yesterday, while doing my weekly system update, I encountered a msg :
>
> !!! The following installed packages are masked:
> - media-libs/lcms-1.19-r1::gentoo (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Matthias Maier <tamiko@gentoo.org> (27 May 2015)
> # on behalf of Andreas K. Huettel <dilfridge@gentoo.org>
> # media-libs/lcms:0 has serious security issues and is unmaintained,
> # see bug 526642. Please uninstall it and/or upgrade to media-libs/lcms:2
>
> I looked at the bug, which explains the reason for dropping Lcms:0 .
>
> Unfortunately, Kde-Sunset appears to require Lcms:0 for Libmng:0 ,
> which is required by Qt-Meta:3 & which aren't included in Kde-Sunset itself.
> For now, I can simply ignore the warning, but it looks
> as if it wb no longer possible to install Kde-Sunset on a new machine.
>
> I realise Gentoo itself doesn't provide support for Kde-Sunset,
> but does anyone know of a way round this obstacle or have other advice ?
>

lcms:0 can always be added to the overlay too.

On Monday 01 June 2015 05:33:01 Philip Webb wrote:
> Using Kde-Sunset, I have 3 useful apps available in forms
> which aren't provided by KDE 4 (Kworldclock Ksokoban Kmahjongg).

You are probably aware that KDE comes with a kworldclock plasmoid, a
native KMahjongg, and that there is a port of the KDE3 ksokoban to KDE4
(http://sourceforge.net/projects/ksokoban/)?

What is wrong with them?

> I realise Gentoo itself doesn't provide support for Kde-Sunset,
> but does anyone know of a way round this obstacle or have other advice ?

You could check if the trinity project has ported Qt3 to the new libmng/lcms.
If it is a simple patch you might be able to apply it to Qt3 in kde-sunset.

Regards,
Martin Walch
--

150601 Martin Walch wrote:
> On Monday 01 June 2015 05:33:01 Philip Webb wrote:
>> Using Kde-Sunset, I have 3 useful apps available in forms
>> which aren't provided by KDE 4 (Kworldclock Ksokoban Kmahjongg).
> You are probably aware that KDE comes with a kworldclock plasmoid,

Yes, but I use Fluxbox to manage my desktop, so that doesn't help.
There is the alternative of Marble, which shows relative timezones,
but it's clumsy compared with Kworldclock.

> a native KMahjongg

Yes, but it doesn't have the removed-tiles display,
which is vital to be able to play the game usefully.

> and that there is a port of the KDE3 ksokoban to KDE4 :
> http://sourceforge.net/projects/ksokoban/ ?

Thanks, I didn't know re that :
perhaps I could install it via usr/local on a new machine.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Philip Webb posted on Tue, 02 Jun 2015 07:00:26 -0400 as excerpted:

> 150601 Martin Walch wrote:
>> On Monday 01 June 2015 05:33:01 Philip Webb wrote:
>>> Using Kde-Sunset, I have 3 useful apps available in forms which
>>> aren't provided by KDE 4 (Kworldclock Ksokoban Kmahjongg).
>> You are probably aware that KDE comes with a kworldclock plasmoid,
>
> Yes, but I use Fluxbox to manage my desktop, so that doesn't help. There
> is the alternative of Marble, which shows relative timezones,
> but it's clumsy compared with Kworldclock.

There is a plasmoid-in-window executable called plasma-windowed, that can
be used to run plasmoids as stand-alone apps. In kde4, plasma-windowed
is part of the plasma-workspace package.

I use that here to run (via configured hotkey) the calendar plasmoid in a
window, since the usual method of launching the calendar, from the clock
plasmoid, doesn't work here because I don't have a clock plasmoid,
because my clock is part of my superkaramba theme and I thus don't need a
plasmoid doing the same thing.


Tho building all of plasma and its deps just to run the kworldclock
plasmoid using plasma-windowed, seems a bit much. But if you have other
plasmoids of interest, however, or simply can't live without kworldclock
no matter what deps you have to build to get it, it's an option.

Meanwhile, I find it a bit... ironic... that just as kde5 is beginning to
be seen in distros and I'd say probably about a year before gentoo starts
considering dropping kde4 (tho a full kde5 isn't even in-tree yet, so
it'll be awhile...), you're barely considering upgrading to kde4 from the
kde3 you've been running from the sunset overlay. I definitely respect
that choice and am glad the kde-sunset overlay filled the bill when no
gentoo devs were willing to maintain kde3 in-tree any longer, but the
timing is just... ironic... is all.

(Meanwhile, I keep trying kde5 from the kde overlay every couple months,
and still haven't gotten it to run. Seems kwin5 goes into an endless
crash/respawn cycle, not liking either my radeon turks graphics hardware,
or the fact that I'm running triple monitor, or possibly both. Between
that, and the fact that I can't keep kde4 installed at the same time so I
can't keep a working kde4 while I try to fix kwin5/kde5, I have to kill
kde5 and rollback to kde4 in ordered to get a working system again, so it
tends to be 2-4 months between tests. =:^( When gentoo/kde decides it's
actually working well enough to go in-tree, I'll try again, and file bugs
if I can't get it working at that point.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

150602 Duncan wrote:
> Philip Webb posted on Tue, 02 Jun 2015 07:00:26 -0400 as excerpted:
>> 150601 Martin Walch wrote:
>>> You are probably aware that KDE comes with a kworldclock plasmoid,
>> Yes, but I use Fluxbox to manage my desktop, so that doesn't help.
> There is a plasmoid-in-window executable called plasma-windowed
> that can be used to run plasmoids as stand-alone apps.
> In kde4, plasma-windowed is part of the plasma-workspace package.
> Tho building all plasma and its deps just to run the kworldclock plasmoid
> using plasma-windowed seems a bit much.

Thanks for the info, but as you say, it wb a bit much (wry smile).

> I find it a bit ironic that just as kde5 is beginning to be seen in distros
> you're barely considering upgrading to kde4 from the kde3
> you've been running from the sunset overlay.

I didn't say that (grimace) : I'm a happy user of KDE 4 apps
-- Konsole Gwenview Okular etc -- , but don't need the heavyweight desktop
& do still like to use 3 small pkgs which didn't get ported.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Philip Webb posted on Tue, 02 Jun 2015 09:31:25 -0400 as excerpted:

> I didn't say that (grimace) : I'm a happy user of KDE 4 apps -- Konsole
> Gwenview Okular etc -- , but don't need the heavyweight desktop & do
> still like to use 3 small pkgs which didn't get ported.

OK, thanks for the correction. I had read that before and simply
forgotten about it.

At least with the 4-2-5 upgrade, upstream is supporting qt4 and kdelibs4
still being installed, along with various misc kde4 apps, some of which
are known not to have (stable) qt5/kde5 versions, yet, and actually ship
some still kde4 versions in their recent kde4/5 unified desktop
releases. It's only the core desktop (including kwin, unfortunately for
me) that must be 5 if any of it is 5 and can't be installed with 4, the
rest can still be 4.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

150601 E. Liddell wrote:
> 150601 Philip Webb wrote:
>> Kde-Sunset appears to require Lcms:0 for Libmng:0 ,
>> which is required by Qt-Meta:3 & which aren't included in Kde-Sunset itself.
>> For now, I can simply ignore the warning, but it looks
>> as if it wb no longer possible to install Kde-Sunset on a new machine.
> Compile libmng without lcms support ? I'm pretty sure it's optional
> and qt-meta doesn't care what USE flags are set for libmng.

That wb possible, but it would mean upgrading to libmng:2 ,
which doesn't work with qt-meta:3 .

> No one uses the mng format anyway, so it isn't much of a loss.

There's no USE flag for mng on qt-meta:3 .

So 2 further questions :
(1) is there a way to remerge qt-meta:3 without using libmng ?
(2) if I make a quickpkg of libmng:0 or lcms:0 , will Portage allow me
to re-install them if I want to after testing the upgrade,
given that they are no longer in the Portage tree ?

> While it isn't optimal, it's possible to get any ebuild
> that was ever in the main tree from the attic,
> if you need to fill in gaps for a new installation:
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/?hideattic=0
> Some ebuilds from this source may need to be retouched
> before portage is happy with them,
> but if they're not too old it's usually possible to get them working.

I probably have a note of that site in my home-made help files.
Would I put the ebuild in my local layman dir & would Portage like it ?

And isn't there a problem for Kde-Sunset, given the facts above :
ie KDE 3 needs qt-meta:3 , which requires libmng:0 ,
which is no longer in the Portage tree nor is in the Sunset tree ?

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Philip Webb posted on Wed, 03 Jun 2015 08:14:04 -0400 as excerpted:

> (2) if I make a quickpkg of libmng:0 or lcms:0 , will Portage allow me
> to re-install them if I want to after testing the upgrade,
> given that they are no longer in the Portage tree ?

Yes, portage should take that, provided you use -K (package-only).

Alternatively, before you replace it, copy the ebuild from the installed-
packages database (/var/db/pkg/) to your overlay.

It's even possible to get the ebuild out of a binpkg if necessary -- open
the binpkg in a text-editor, and while the first part will be a bunch of
compressed garbage, near the end you'll find the ebuild in plain-text,
followed by some additional metadata. You can then delete the stuff
before and after the ebuild in the editor (don't save it back to the
original binpkg file) and save the remaining ebuild to a normal ebuild
file.

>> While it isn't optimal, it's possible to get any ebuild that was ever
>> in the main tree from the attic,
>> if you need to fill in gaps for a new installation:
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/?hideattic=0
>> Some ebuilds from this source may need to be retouched before portage
>> is happy with them,
>> but if they're not too old it's usually possible to get them working.
>
> I probably have a note of that site in my home-made help files.
> Would I put the ebuild in my local layman dir & would Portage like it ?

Yes, local overlay, and portage should like it, tho as above you may need
to retouch it a bit. Also, if it requires eclasses that have been
changed too much or removed, you may need to get them from "the attic"
too.

> And isn't there a problem for Kde-Sunset, given the facts above :
> ie KDE 3 needs qt-meta:3 , which requires libmng:0 ,
> which is no longer in the Portage tree nor is in the Sunset tree ?

It's a problem... until someone adds the package back to the sunset tree.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-06-03 12:08, Duncan wrote:
> Philip Webb posted on Wed, 03 Jun 2015 08:14:04 -0400 as
> excerpted:
>
>> (2) if I make a quickpkg of libmng:0 or lcms:0 , will Portage
>> allow me to re-install them if I want to after testing the
>> upgrade, given that they are no longer in the Portage tree ?
>
> Yes, portage should take that, provided you use -K (package-only).
>
> Alternatively, before you replace it, copy the ebuild from the
> installed- packages database (/var/db/pkg/) to your overlay.
>
> It's even possible to get the ebuild out of a binpkg if necessary
> -- open the binpkg in a text-editor, and while the first part will
> be a bunch of compressed garbage, near the end you'll find the
> ebuild in plain-text, followed by some additional metadata. You
> can then delete the stuff before and after the ebuild in the editor
> (don't save it back to the original binpkg file) and save the
> remaining ebuild to a normal ebuild file.
>

An easier method, if you have portage-utils installed, is to use
`qtbz2 -s package-ver.tbz2` to split the .tbz2 binpkg into a .tar.bz2
with the contents and a .xpak with the metadata, then use `qxpak -x
package-ver.xpak package-ver.ebuild` to extract just the ebuild from
the xpak.

- --
Jonathan Callen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVb5+ZAAoJEEIQbvYRB3mgOgoP/ij0hSlnI7vv/zd22sv8kDGX
xkmtpmAWAlqShR3wj98HQ/r0xTwD7IH/8UE4EJALoFRXl2Zjy5P8hSH+OYgUpJkW
UHkwz/WIHzI8KvY4KPP2giu96FvNvOwbXjIiFuIjXj2+t0ouRNlGVx+ruNGfgUtb
AUlVH72bgq5+VXSlolbgkdXpq/KUr3k7RQ3+oHPUVTAJBQ0JLZMNnbEW543eE1q5
9qYwRYG/mSLDmKxNu4l0zydi+Uiovz8pJYOsDXFrEoRliVxR5RpKr4EUe713Kv4A
HsTGZ1Ea0xmAnJcsj+LBximdfVyKyOuRRQnPi3WBMx2Kd/I3SEwyueoPX8vIe5uK
Z7dDVOh++gVgcr58z3eWeMZkSWmF16rpl9YTlkH9l0egmRylUObpLFd21ZNahYZn
d78TL1dG5S9+VWZyBscbMnuhx7cJfpzM3lsU1J9y1TiljRnxc65F8iNwjwE/fnf6
lc4arvzpANzQm3DaoP1Et12sYIRPg0NG3RkNr9a9Xqgutm57ajAjURR5us7qYgmk
zFKQTf82ea7OvWBlQR+htm2CXBCgftK39rdyz2dvRvXhlalQ0V3BnzFPaNe7sV9F
7/cVU/yPsJq0h7iRDENsrfkXMOBSDj+nyA5uejgEgyyKdfqpiELTeF2oGKqqt4U9
EKuX2VV0HcU1Mz9UtN54
=LcKz
-----END PGP SIGNATURE-----

Jonathan Callen posted on Wed, 03 Jun 2015 20:45:17 -0400 as excerpted:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2015-06-03 12:08, Duncan wrote:

>> It's even possible to get the ebuild out of a binpkg if necessary --
>> open the binpkg in a text-editor, and while the first part will be a
>> bunch of compressed garbage, near the end you'll find the ebuild in
>> plain-text, followed by some additional metadata. You can then delete
>> the stuff before and after the ebuild in the editor (don't save it back
>> to the original binpkg file) and save the remaining ebuild to a normal
>> ebuild file.
>>
>>
> An easier method, if you have portage-utils installed, is to use `qtbz2
> -s package-ver.tbz2` to split the .tbz2 binpkg into a .tar.bz2 with the
> contents and a .xpak with the metadata, then use `qxpak -x
> package-ver.xpak package-ver.ebuild` to extract just the ebuild from the
> xpak.

I guess "easier" is defined by the person doing it. =:^)

Obviously, were I doing it frequently it'd be worth scripting your
commands, thus avoiding both having to remember the specific command
details /and/ the manual editing, but I don't end up doing it enough to
remember the commands and their options or to be worth scripting it, and
absent a script supplying the specific command and options I need, in the
time it would take me to look it up, type them in, and verify correctness
before actually hitting enter, I can edit the file manually and be on to
something else.

But thanks. TIMTOWTDI (common perl camp abbreviation: there is more than
one way to do it), and the more options posted, the easier it should be
to find something that works best for them. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman