Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? And what happens, if GNU folks make GNU userland depend on Hurd? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 12 Oct 2011 18:49:19 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? What's the 'deep integration' here? AFAICS the main point here is that you want to make udev capable of guessing all your filesystem structure, and maybe even mounting it. Yeah, sounds really KISS. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
Sorry for being completely OT now, will be the only mail on this from my side... On Thursday, 13. October 2011 18:05:47 Ciaran McCreesh wrote: On Thu, 13 Oct 2011 11:14:31 -0400 Olivier Crête tes...@gentoo.org wrote: On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. The problem with a platform that just works is that when it doesn't work, no-one knows how to fix it. That's what's happened here: the deep integration doesn't work in the common case that /usr is on its own filesystem, but because of all the excessive coupling you're unable to fix it and so are trying to pass the blame elsewhere. The first step in fixing it is to decouple all of the horrible mess that has been making its way into the base system over the past couple of years. in what way will exherbo deal wih this mess? Are there any plans? Feel free to mail me privately and/or answer this on the user-ML, I think some of us are quite interested. Thanks, Michael
Re: [gentoo-dev] Suggestion for getting rid of udev
On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. Best regards, Wulf signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger w...@mailstation.de wrote: On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. And I believe exherbo recommends systemd as init system. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Suggestion for getting rid of udev
On Sat, Oct 15, 2011 at 2:13 AM, Canek Peláez Valdés can...@gmail.com wrote: On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger w...@mailstation.de wrote: On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. And I believe exherbo recommends systemd as init system. Yes, they do: http://exherbo.org/docs/install-guide.html o Install an init system There’s no init system in our stages. This allows you to choose whatever init system (or none) you’d like to use: - sys-apps/systemd (recommended) - modern, fast init system. Needs kernel =2.6.36-rc1. - sys-apps/baselayout - Gentoo’s old, crufty Baselayout-1. - sys-apps/upstart - Ubuntu’s init system. We don’t generally supply init scripts for this. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Sat, Oct 15, 2011 at 03:54, Mike Gilbert flop...@gentoo.org wrote: That would be an ok approach from my perspective: We could just change line 14 of python.eclass and let package maintainers report breakage as they increment EAPI. I am confident that nothing EAPI = 3 would break. Is anyone (especially djc and the python herd members) opposed to this? Seems fine to me; I can't really think of a practical better way. Cheers, Dirkjan
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 9:54 PM, Mike Gilbert flop...@gentoo.org wrote: On 10/14/2011 09:11 PM, Paweł Hajdan, Jr. wrote: On 10/14/11 5:38 PM, Alec Warner wrote: I believe op's point is that there is no one to escalate the problem to; certainly the council members are not going to do the work themselves and we already have our best people on it. I'm aware of that. My point is that I think there are many scenarios in which EAPI-4 + python.eclass can work, especially if it's used only for few things in cases like www-client/chromium Because the python team takes _ages_ to do the transition that is holding back many other packages, because they've made python.eclass overly complex and now try to make it perfect, I'd just like to get an OK to enable EAPI-4 for that eclass. Please note that it's still up to dependent packages which EAPI they use. If they break python.eclass with EAPI-4 they shouldn't update to that EAPI. However, if there are packages using python.eclass that could work fine with EAPI-4, it shouldn't be blocking them for *ages* That would be an ok approach from my perspective: We could just change line 14 of python.eclass and let package maintainers report breakage as they increment EAPI. I am confident that nothing EAPI = 3 would break. Is anyone (especially djc and the python herd members) opposed to this? Sorry I wasn't able to post before. But... This can be done and in fact has been discussed before, just allow ebuild to not die with EAPI=4, but this doesn do anything at all, just not die on EAPI=4. All the features and the good stuff just won't be there as other use cases need (as Robin and Tony mentioned). We've been working on a redesign of the eclass but is nothing like stealing candy from a kid, there are many things involved, such as the large amount of Python ABIs that people use regularly, distutils quirks, current eclass complexity, among others that make it quite challenging to come up with something new. I'm all up for making eclass accept EAPI=4 ebuilds, but to fully implement EAPI=4 fesatures, I'm going to have to ask you guys for a bit of more patience. I know you have done just that, being patient, but just a bit more. I know we can deliver a solution for this soon enough. Best regards, -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] Re: rfc: news item for png15
On 10/14/2011 04:59 AM, Ryan Hill wrote:
On Fri, 14 Oct 2011 01:01:50 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
Title: Upgrade to libpng15
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2011-10-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-libs/libpng-1.5
After upgrading from libpng14 to libpng15 it's important that you rebuild
cairo and gdk-pixbuf soon as possible if they are installed.
^ as
Then you can proceed with rebuilding rest of the software against the new
^ the
library:
# revdep-rebuild --library libpng14.so.14
In case of failure, try skipping the failing package and rebuilding it
later in the process.
How?
If you find packages not building with message ld: cannot find -lpng14,
^ the
they are likely caused by broken libtool archives (.la) in your system.
You can identify those files with following one-liner:
# find /usr/ -name '*.la' -exec grep png14 {} +
More information and help is available at following forums post:
^ the ^-s?
http://forums.gentoo.org/viewtopic-t-894950.html
Attaching draft #2. I've taken account all the replies so far. I left
complex one-liners out in _purpose_, and _want to_ people not
understanding the issue to follow up in the forums post.
Title: Upgrade to libpng15
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2011-10-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-libs/libpng-1.5
After upgrading from libpng14 to libpng15 it's important that you rebuild
cairo and gdk-pixbuf as soon as possible if they are installed.
Then you can proceed with rebuilding the rest of the software against the new
library:
# revdep-rebuild --library libpng14.so.14 -- --keep-going
Note: It might be necessary to run the previous command more than once.
If you find packages not building with the message ld: cannot find -lpng14,
they are likely caused by broken libtool archives (.la) in your system.
You can identify those files with following one-liner:
# find /usr/ -name '*.la' -exec grep png14 {} +
Ocne you have identified the broken files, you can either delete them,
edit them in place and replace png14 with png15, or re-emerge the packages
they belong to.
More information and help is available at the following forum post:
http://forums.gentoo.org/viewtopic-t-894950.html
Re: [gentoo-dev] rfc: news item for png15
On 10/14/2011 11:48 AM, Pacho Ramos wrote: El vie, 14-10-2011 a las 01:01 +0300, Samuli Suominen escribió: small news item for stable users. lets keep it simple... Is early rebuilding of gdk-pixbuf still needed now that fixed version will be stabilized before libpng15? The blockers that will force gdk-pixbuf to rebuilt first will just ensure there are no -lpng14 or -lpng15 entries in gdk-pixbuf-2.0.pc that would break apps compile-time. The rebuilding of gdk-pixbuf and cairo is still necessary early, because apps using gdk-pixbuf to handle .png at buildtime AND runtime (mostly gnome apps) will fail with message .png: File type is not supported (Maybe not with this exact wording, but close to it.) that is an result of condition where eg. cairo is built against png14 but gdk-pixbuf with png15 or otherway around -- conflict
Re: [gentoo-dev] Suggestion for getting rid of udev
On Saturday 15 October 2011 03:29:54 Michał Górny wrote: On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes wrote: On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? And what happens, if GNU folks make GNU userland depend on Hurd? with gnulib in place, they (directly) won't -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: news item for png15
El sáb, 15-10-2011 a las 19:35 +0300, Samuli Suominen escribió: On 10/14/2011 11:48 AM, Pacho Ramos wrote: El vie, 14-10-2011 a las 01:01 +0300, Samuli Suominen escribió: small news item for stable users. lets keep it simple... Is early rebuilding of gdk-pixbuf still needed now that fixed version will be stabilized before libpng15? The blockers that will force gdk-pixbuf to rebuilt first will just ensure there are no -lpng14 or -lpng15 entries in gdk-pixbuf-2.0.pc that would break apps compile-time. The rebuilding of gdk-pixbuf and cairo is still necessary early, because apps using gdk-pixbuf to handle .png at buildtime AND runtime (mostly gnome apps) will fail with message .png: File type is not supported (Maybe not with this exact wording, but close to it.) that is an result of condition where eg. cairo is built against png14 but gdk-pixbuf with png15 or otherway around -- conflict OK, thanks a lot for the explanation :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On Saturday, October 15, 2011 09:29:54 AM Michał Górny wrote: On Sat, 15 Oct 2011 00:06:03 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Thu, Oct 13, 2011 at 11:14:31AM -0400, Olivier Cr?te wrote We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. Eventually, that hits Mac or Windows-like levels of dictating 1 or 2 sets of choices and nothing else. If I wanted Mac or Windows, I'd be running Mac or Windows. If the developers don't deliberately make my system break if /usr and /var aren't physically on / (and no initramfs), I'm willing to do a bit of extra work to configure things my way. Speaking of tight integration, what happens if Redhat's employees make udev depend on systemd? And what happens, if GNU folks make GNU userland depend on Hurd? They'll finally get to version 1.x and Hurd can be used instead of the Linux kernel if someone wants to? :) -- Joost
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On 10/15/11 2:42 AM, Dirkjan Ochtman wrote: On Sat, Oct 15, 2011 at 03:54, Mike Gilbert flop...@gentoo.org wrote: That would be an ok approach from my perspective: We could just change line 14 of python.eclass and let package maintainers report breakage as they increment EAPI. I am confident that nothing EAPI = 3 would break. Is anyone (especially djc and the python herd members) opposed to this? Seems fine to me; I can't really think of a practical better way. Thank you, change committed to CVS then. Hopefully nobody will get upset about this. I'll wait a few days before I start using EAPI-4 in ebuilds using python.eclass, but I've done local tests and everything works fine (for the ebuild I (co-)maintain). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On 10/16/2011 12:00 AM, Paweł Hajdan, Jr. wrote: On 10/15/11 2:42 AM, Dirkjan Ochtman wrote: On Sat, Oct 15, 2011 at 03:54, Mike Gilbert flop...@gentoo.org wrote: That would be an ok approach from my perspective: We could just change line 14 of python.eclass and let package maintainers report breakage as they increment EAPI. I am confident that nothing EAPI = 3 would break. Is anyone (especially djc and the python herd members) opposed to this? Seems fine to me; I can't really think of a practical better way. Thank you, change committed to CVS then. Hopefully nobody will get upset about this. I'll wait a few days before I start using EAPI-4 in ebuilds using python.eclass, but I've done local tests and everything works fine (for the ebuild I (co-)maintain). Thanks, this is most appericiated. This allowed me to kill EAPI=3 support from xfconf.eclass.
[gentoo-dev] Re: rfc: news item for png15
On Sat, 15 Oct 2011 19:17:17 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Ocne you have identified the broken files, you can either delete them, ^ edit them in place and replace png14 with png15, or re-emerge the packages Otherwise good. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rfc: news item for png15
On 10/16/2011 12:43 AM, Ryan Hill wrote: On Sat, 15 Oct 2011 19:17:17 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: Ocne you have identified the broken files, you can either delete them, ^ edit them in place and replace png14 with png15, or re-emerge the packages Otherwise good. Thanks. slyfox pointed this out to me already at Freenode and I've fixed it before committing the news item. - Samuli
Re: [gentoo-dev] Suggestion for getting rid of udev
On 10/15/2011 01:57 AM, Wulf C. Krueger wrote: On 15.10.2011 10:42, Michael Schreckenbauer wrote: in what way will exherbo deal wih this mess? Are there any plans? We don't support /usr on a separate partition. People can, of course, do that and I'll point them to dracut for creating an initramfs. Or they can do whatever works for them. People using Exherbo are expected to be able to deal with such stuff. I don't think it's a good idea for Gentoo to encourage users to have /usr on a separate partition. We should probably remove the separate /usr partition from Code Listing 2.1: Filesystem usage example in our handbook: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=4#doc_chap2_pre1 -- Thanks, Zac
