Jump to content
Read the Funtoo Newsletter: Summer 2023 ×

dantrell

Members
  • Posts

    36
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by dantrell

  1. I'm fairly confident that if there is any remaining instability with GNOME 3.14 it has nothing to do with my patchset but instead with changes introduced by GNOME 3.14 itself.

    The only issue that comes to mind is FL-1687 which I belleive relates to a larger issue of how GNOME 3.14 is handling graphic related things and subsequently affects nvidia-drivers and to a lesser extent, fglrx. Otherwise, 3.14 is an improvement over 3.12 in almost every way.

    Still, if 3.14 is giving you unnecessary trouble, simply downgrade by masking it.

  2.  

    woodelf,

     

    I get what you mean. Overall, it did take a while (although I was on 3.8 and 3.10 througout it all; I regret nothing :P).

     

    P.S. Regarding Wayland... no promises.

     

    uudruid74,

     

    The state of GNOME is such that:

    1. systemd is not a hard compile time dependency. You can build everything except for ~2 packages and it will all work out of the box.
    2. systemd is a hard run time dependency for basic functionality.

    Basic functionality is what the GNOME team has decided includes:

    • power management
    • session tracking
    • lid close handling
    • log/event viewing
    • Wayland

    My patchset has reintegrated support for everything but Wayland (I thank the relevant GNOME and Gentoo teams for making my job easier). Furthermore, my patchset was done for 2 reasons:

    1. It was trivial to do so (I'm of opinion that upstream should have left the relevant code in and marked it as deprecated but that's another matter).
    2. To buy more time to come up with a proper solution.

    One possible solution is to fork ConsoleKit and pm-utils then have the GNOME team reintegrate support as they said they would.

  3. There's no need to be combative here. I see no no problem with documenting how to get it working for those who want to try it (although I'm not sure those instructions are 100% correct) so long as they understand that it is not officially supported (and while systemd does work in Funtoo it is necessary to restore certain ebuilds to the their Gentoo variants). There are actually quite a few Funtoo users using systemd because while they want systemd, they also want Funtoo be their underlying ecosystem so I see no reason to remove it.

    In any case, it is not entirely systemd I dislike but rather the exponentially growing insistence that it must be used and the removal of support for any other alternatives and without a proper transition period.

    This is why I decided to deliver a complete (or nearly complete) GNOME 3.12+ experience without systemd.

    P.S. Woodelf, I remember you from your one blog post regarding GNOME 3.12. For the record, it took me about a week if you count testing, not half a year :).

  4. It would require forking quite a few packages to properly unbundle cups and I'm not sure that's a good idea. I no longer have the time to do it now anyway so what I did do was resolve the blocker.

    That said, lprng still pulls in cups if you enable the foomatfcidb USE flag. But even you changed that ebuild, foomatic-db-engine also pulls in cups.

    You may want to try your luck contacting the responsible team on Gentoo upstream.

  5. Aha, sorry about that. I have updated the instructions to reflect the default PORTDIR location.

    I have also updated the gnome mix-in so in another tree regen (or thereabouts), the package.use change shouldn't be necessary.

  6. With the information you have provided, my best guest is that this is related to dev-libs/gobject-introspection. You need to either globally enable (in your make.conf or through the gnome mix-in) the introspection USE flag or globally disable (in your make.conf) it. Then do "emerge -vauDN world" before emerging whatever it is you are emerging.

     

    The output of "eselect profile list", the emerge command you were using, the FULL build log (snipped at the point before it started to repeat) and the USE flags of the packages you were emerging is more useful than the output of "emerge --info". Of course, use a pastebin such as http://paste.kde.org/ if the output is too long.

  7. Hello and welcome. :)

    If you are going to put Funtoo in a VM and not configure an appropriate kernel by hand (e.g. gentoo-sources or vanilla-sources) then you are going to need to pump a bit more resources into your VM since, as you discovered, debian-sources is a bit of a hog.

     

    If you want less updates, on average, then the stable profile is what you want. It shouldn't be too far behind current.

  8. For the record, you should be talking to the people maintaining the mva overlay about this since both Funtoo and Gentoo use RPM from http://www.rpm.org/ whereas you are dealing with RPM vs http://rpm5.org/ so don't file a bug about this. To elaborate, Funtoo and Gentoo puts the RPM from rpm.org at app-arch/rpm and the one from rpm5.org at app-arch/rpm5, the mva overlay squashes it all together.

    That said, if this worked before and currently doesn't then it is most likely due to the recent sys-libs/db update. Try downgrading that package to 4.8 and see if rpm will build against it. Otherwise it would probably be easier to just mask >=app-arch/rpm-5*, unless you want it for some reason.

×
×
  • Create New...