Re: [gentoo-user] Need help to compile a minimal wine

[tuxic]

On 09/23 06:39, R0b0t1 wrote:
> On Sat, Sep 23, 2017 at 1:21 PM,   wrote:
> > Hi,
> >
> > I want to compile wine to execute a single commandline tool.
> > That's it.
> >
> > The commandline tool is the AVR-assembler made by ATmel to recompile
> > a FORTH interpreter for the AVR-line of microcontrollers of
> > ATMEL/Micorchip:
> >
> 
> Are you sure you need the assembler as released by Atmel? Most of
> their development work seems to have gone to AVR-GCC. Is the syntax of
> avrasm2 unique and are there any features that are not implemented in
> GNU as?
> 
> > avrasm2.exe: PE32 executable (console) Intel 80386, for MS Windows
> >
> > [...]
> >
> > (My system is not multilib.)
> >
> 
> As "WINE is Not an Emulator" it seems to me like you will either need
> to reinstall as a multilib system, or set up an x86 chroot or
> container to run the assembler.
> 
> There is a small possibility that WINE's WOW64 support (the thing that
> runs Win32 executables on Win64) does not require multilib, but if so
> then they would have needed to reimplement large parts of multilib and
> certain kernel facilities. It does not seem likely that they would
> have done this.
> 
> Looking at https://wiki.winehq.org/Building_Wine#Shared_WoW64 it seems
> like there is an implicit dependency on a multlib system. Most Linux
> distributions are multilib, likely because it is necessary to support
> many closed source Linux programs.
> 
> Cheers,
>  R0b0t1
> 


Yes, unfortunately I am sure that I need the ATmel-thingy...

Amforth as Flashforth are written in ATmel Assembler and based
on/compiled with avrasm2...I talked to the developers in beforehand.

How can I compile a minimal wine (as described) for my puposes?

Cheers
Meino

Re: [gentoo-user] Changing dependencies without upping version ??

[Rich Freeman]

On Sun, Sep 24, 2017 at 2:51 PM, John Blinka  wrote:
>
>> Is this an officially approved technique??  it is DIRTY.
>
> I imagine that it is sanctioned, otherwise why would there be a
> --changed-deps flag to emerge?  Does seem dirty.  Glad you asked the
> question.  Would love to learn why this is allowed.  In my experience, it
> happens quite often.

Is this recent experience in the main repository?  This is something
QA started cracking down on maybe a year ago.  It is definitely
problematic, because portage won't pull in the new dependency until
you re-install the package, which means the dependency could get
removed/etc.  I'd have to dig up the details around the policy - it
might be allowed in very limited circumstances (there could be reasons
to change a dep that won't actually break anything already installed).

I ended up putting --changed-deps in my update script because I'd
rather not deal with the bugs this can cause.

-- 
Rich

[gentoo-user] Re: Changing dependencies without upping version ??

[Ian Zimmerman]

On 2017-09-24 21:05, Neil Bothwick wrote:

> If the change doesn't affect the installed code, it is encouraged to
> avoid unnecessary rebuilding.
> 
> For example, a new version of LibreOffice or Chromium depends on
> libfoo, but the dev doesn't notice and already has libfoo installed so
> it works for him. You also have it installed so the upgrade works for
> you, then it fails for me and I file a bug report. If the dev
> revbumped the ebuild, you would have to spend a couple of hours
> rebuilding Chromium to get exactly the same code you had before. By
> not revbumping it, he fixes the problem for me without inconveniencing
> you.

I see, but of course in this case the effect would be exactly the
opposite - forcing me to rebuild the core qt packages and everything
that depends on them.  And if this was not a mistake, it must have been
clear that would happen.

It feels like a sneaky way to finally get the few remaining qt4 stragglers
out of the way.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Thunderbird build failure

[Mick]

On Sunday, 24 September 2017 21:37:16 BST Christoph Böhmwalder wrote:
> Hey, you fixed it (sort of)!
> 
> I tried your suggestions but diverted a little bit. Basically here's what
> happened:
> 
> * depclean did nothing (except remove a few Thunderbird dependencies I
> actually needed, whoops) * `revdep-rebuild` also found nothing
> * `ldd` gave /lib/libz.so.1.2.11
> * I noticed that /usr/lib/libz.so.1.2.7 existed as well and proceeded to
> delete it * Re-emerged both libz and libpng, Thunderbird build still failed
> * Decided "let's delete /lib/libz.so.1.2.11 as well" (bad idea I know, I
> just barely recovered from that) * After replacing libz from the stage3
> tarball, re-emerged libz
> 
> Aaaand then it just worked, I must admit I'm not entirely sure why ¯\_(ツ)_/¯

Not sure what dependencies were broken or why, but you seem to have installed 
at some point various versions of zlib, which were thereafter uninstalled in a 
somewhat unclean way.

Next time you can use quickpg to create a binary of an installed package 
before you unmerge it.  This could help you recover from unintended breakages.

Portage *should* remove a package completely and cleanly, while by deleting 
files manually you could mess things up and leave portage in a messy state.  
If unmerging a package does not uninstall it cleanly, this means there's a bug 
in the ebuild and it would merit posting a report in BGO.

Otherwise,

 emerge @preserved-rebuild -v -a

and 

 revdep-rebuild -v -- -a

ought to (re)emerge any missing dependencies or dependencies which need to be 
rebuilt.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Thunderbird build failure

[Christoph Böhmwalder]

Hey, you fixed it (sort of)!

I tried your suggestions but diverted a little bit. Basically here's what 
happened:

* depclean did nothing (except remove a few Thunderbird dependencies I actually 
needed, whoops)
* `revdep-rebuild` also found nothing
* `ldd` gave /lib/libz.so.1.2.11
* I noticed that /usr/lib/libz.so.1.2.7 existed as well and proceeded to delete 
it
* Re-emerged both libz and libpng, Thunderbird build still failed
* Decided "let's delete /lib/libz.so.1.2.11 as well" (bad idea I know, I just 
barely recovered from that)
* After replacing libz from the stage3 tarball, re-emerged libz

Aaaand then it just worked, I must admit I'm not entirely sure why ¯\_(ツ)_/¯

Anyways, thanks for taking the time to support me here!

--
Regards,
Christoph

Re: [gentoo-user] Changing dependencies without upping version ??

[Neil Bothwick]

On Sun, 24 Sep 2017 10:37:53 -0700, Ian Zimmerman wrote:

> Is this an officially approved technique??  it is DIRTY.

If the change doesn't affect the installed code, it is encouraged to
avoid unnecessary rebuilding.

For example, a new version of LibreOffice or Chromium depends on libfoo,
but the dev doesn't notice and already has libfoo installed so it works
for him. You also have it installed so the upgrade works for you, then it
fails for me and I file a bug report. If the dev revbumped the ebuild,
you would have to spend a couple of hours rebuilding Chromium to get
exactly the same code you had before. By not revbumping it, he fixes the
problem for me without inconveniencing you.


-- 
Neil Bothwick

System halted - Press all keys at once to continue.


pgpDQf6rM9CF2.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Changing dependencies without upping version ??

[John Blinka]

>
>
> Is this an officially approved technique??  it is DIRTY.


I imagine that it is sanctioned, otherwise why would there be a
--changed-deps flag to emerge?  Does seem dirty.  Glad you asked the
question.  Would love to learn why this is allowed.  In my experience, it
happens quite often.

John Blinka

>

[gentoo-user] Changing dependencies without upping version ??

[Ian Zimmerman]

I think this is the first time a package tried to play this trick on me:

--- /var/db/pkg/dev-libs/qcustomplot-1.3.2/qcustomplot-1.3.2.ebuild 
2017-05-21 13:38:15.482740587 -0700
+++ /usr/portage/dev-libs/qcustomplot/qcustomplot-1.3.2.ebuild  2017-09-22 
19:27:30.0 -0700
@@ -1,4 +1,4 @@
-# Copyright 1999-2016 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=6
@@ -14,19 +14,13 @@
 SLOT="0"
 LICENSE="GPL-3"
 KEYWORDS="amd64 ~arm x86 ~amd64-linux ~x86-linux"
-IUSE="qt5"
+IUSE=""
 
 RDEPEND="
-   !qt5? (
-   dev-qt/qtcore:4
-   dev-qt/qtgui:4
-   )
-   qt5? (
-   dev-qt/qtcore:5
-   dev-qt/qtgui:5
-   dev-qt/qtprintsupport:5
-   dev-qt/qtwidgets:5
-   )
+   dev-qt/qtcore:5
+   dev-qt/qtgui:5
+   dev-qt/qtprintsupport:5
+   dev-qt/qtwidgets:5
 "
 DEPEND="${RDEPEND}"
 
@@ -42,7 +36,7 @@
 }
 
 src_configure() {
-   use qt5 && eqmake5 || eqmake4
+   eqmake5
 }
 
 src_install() {


Is this an officially approved technique??  it is DIRTY.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Thunderbird build failure

[Daniel Frey]

On 09/23/2017 10:55 PM, Christoph Böhmwalder wrote:


Thanks for the suggestion Stephano. I tried re-emerging libpng and 
running a clean Thunderbirs build overnight, however it still fails with 
the same message.


--

Regards,
Christoph


I had a similar problem but it was a while ago (a couple years.) I seem 
to recall that one of the packages didn't clean up properly after an 
unmerge/depclean and left behind some remnants that nothing owned.


My memory is pretty hazy, but I remember having to see what libpng 
needed (using ldd) and making sure there were no erroneous libraries around.


Have you done a --depclean recently? Have you tried `revdep-rebuild`? It 
may fix the problem first.


Otherwise, try issuing `ldd /usr/lib/libpng16.so.16`. Then see what 
versions are installed by `equery list media-libs/libpng sys-libs/zlib`.


Then manually check the libs directory (use the ldd output, it will show 
paths) to make sure there's no old libraries hanging around:


`ls /lib64/libz*`

You can see if it's owned by a package by using `equery belongs 
/lib/libz.so`.


I think what happened in my case is an old library was there that didn't 
belong to any package and that's what the linker used (and failed.)


Dan