Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote: WARNING: One or more updates have been skipped due to a dependency conflict: dev-python/numpy:0 (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts with ~dev-python/numpy-1.5.1 required by (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed) dev-python/pexpect:0 (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for merge) conflicts with ~dev-python/pexpect-2.0 required by (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed) Fact is that sci-mathematics/sage can't be made work without those deps. Fact is that I want this package and couldn't care less if I have the latest version of these other two packages. If in turn I cared for the other two packages, then I would have to remove sage. It's a choice but nothing else. it's a crap choice. users shouldn't have to select from diff sets of packages because some are too broken to work properly. it's a bug and needs to be fixed. and it shouldn't require twisting of arms to make people fix their broken packages. also, sci-mathematics/sage is a poor example here. it isn't in the main tree. if people want to add poor packages to their overlays, they're free to. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Original-Nachricht Datum: Fri, 14 Oct 2011 02:01:00 -0400 Von: Mike Frysinger vap...@gentoo.org An: gentoo-dev@lists.gentoo.org Betreff: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote: WARNING: One or more updates have been skipped due to a dependency conflict: dev-python/numpy:0 (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts with ~dev-python/numpy-1.5.1 required by (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed) dev-python/pexpect:0 (dev-python/pexpect-2.4-r1::sage-on-gentoo, ebuild scheduled for merge) conflicts with ~dev-python/pexpect-2.0 required by (sci-mathematics/sage-4.7.1-r2::sage-on-gentoo, installed) Fact is that sci-mathematics/sage can't be made work without those deps. Fact is that I want this package and couldn't care less if I have the latest version of these other two packages. If in turn I cared for the other two packages, then I would have to remove sage. It's a choice but nothing else. it's a crap choice. users shouldn't have to select from diff sets of packages because some are too broken to work properly. it's a bug and needs to be fixed. Sure, it would be better if it could be fixed. But that's far out of reach at this point (and maybe forever because of the complexity of this thing). People already have to do random choices for some packages, where completely unrelated packages block each other because of file collisions. and it shouldn't require twisting of arms to make people fix their broken packages. also, sci-mathematics/sage is a poor example here. it isn't in the main tree. If you want an example from the tree, use geany and geany-plugins. if people want to add poor packages to their overlays, they're free to. There are two different aspects here. Having strange deps may make it look poor for the packager, but this does not mean that the package is poor from a user pov. After all the primary point of packages being in the tree is be used by the users and not for the packager's fun of maintaining them (even though it helps if it is fun). I agree that those deps should be avoid if possible, but killing an otherwise working package because of them hurts the user more than it helps. -mike Sebastian -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: [gentoo-dev] new helper: econf_build
On 10/14/11 01:48, Mike Frysinger wrote:
i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
CPPFLAGS=${BUILD_CPPFLAGS} \
LDFLAGS=${BUILD_LDFLAGS} \
CC=$(tc-getBUILD_CC) \
LD=$(tc-getBUILD_LD) \
econf --host=${CBUILD} $@
snip
so rather than continuing to copy paste this logic everywhere, i'm going to
add it to toolchain-funcs.eclass as econf_build. any feedback before i do ?
Eventually not to stick to 'econf', but provide a more generic one,
so it is useable like this (in lack of a better name):
run_with_build_env econf --host=${CBUILD} ...
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] Re: rfc: news item for png15
El jue, 13-10-2011 a las 20:48 -0600, Ryan Hill escribió:
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?
Maybe we could suggest to run revdep-rebuild --library libpng14.so.14
-- --keep-going two times :-/
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
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: news item for png15
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? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: news item for png15
Pacho Ramos wrote: El jue, 13-10-2011 a las 20:48 -0600, Ryan Hill escribió: On Fri, 14 Oct 2011 01:01:50 +0300 Samuli Suominenssuomi...@gentoo.org wrote: Title: Upgrade to libpng15 Author: Samuli Suominenssuomi...@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? Maybe we could suggest to run revdep-rebuild --library libpng14.so.14 -- --keep-going two times :-/ I tested that and it just wanted to rebuild the same packages, twice. On mine, libreoffice was one of them. Recompiling that twice on a older system may annoy some. ;-) Dale :-) :-)
Re: [gentoo-dev] new helper: econf_build
On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote:
On 10/14/11 01:48, Mike Frysinger wrote:
i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
CPPFLAGS=${BUILD_CPPFLAGS} \
LDFLAGS=${BUILD_LDFLAGS} \
CC=$(tc-getBUILD_CC) \
LD=$(tc-getBUILD_LD) \
econf --host=${CBUILD} $@
snip
so rather than continuing to copy paste this logic everywhere, i'm
going to add it to toolchain-funcs.eclass as econf_build. any
feedback before i do ?
Eventually not to stick to 'econf', but provide a more generic one,
so it is useable like this (in lack of a better name):
run_with_build_env econf --host=${CBUILD} ...
i thought of that, but it seems like we've generally moved away from this
style in the tree. the biggest example being `try ...` - `... || die`.
i'll probably implement as an @INTERNAL:
tc-env_build() { ... }
then define econf_build on top of that as an exported API. then let's see what
grows organically beyond.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new helper: econf_build
On 10/14/11 17:45, Mike Frysinger wrote:
On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote:
On 10/14/11 01:48, Mike Frysinger wrote:
i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \
CPPFLAGS=${BUILD_CPPFLAGS} \
LDFLAGS=${BUILD_LDFLAGS} \
CC=$(tc-getBUILD_CC) \
LD=$(tc-getBUILD_LD) \
econf --host=${CBUILD} $@
snip
i'll probably implement as an @INTERNAL:
tc-env_build() { ... }
then define econf_build on top of that as an exported API. then let's see
what
grows organically beyond.
Fine with me.
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation
i think cases can be made for the other internal gcc libraries:
...
- libmudflap.la: build/link with `gcc -fmudflap`, not `gcc -lmudflap`
I'm afraid -fmudflap won't work alone (might be easy to fix in gcc?):
// a.c:
int main() { return 0; }
$ gcc -fmudflap a.c -o a
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.6/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `__wrap_main'
/tmp/ccCbbGQy.o: In function `global constructors keyed to 00099_0_main':
a.c:(.text+0x10): undefined reference to `__mf_init'
collect2: ld returned 1 exit status
$gcc -fmudflap -lmudflap a.c -o a
# all ok
same is true for all -{f,l}mudflap{,th,ir}
--
Sergei
signature.asc
Description: PGP signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Sat, Oct 1, 2011 at 3:16 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and I can't (for a long time). Unless there are really important reasons like breakages I think we should really make python.eclass support EAPI=4. Two weeks and no response from python@?
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 03:29:19PM -0400, Matt Turner wrote: On Sat, Oct 1, 2011 at 3:16 PM, Pawe?? Hajdan, Jr. phajdan...@gentoo.org wrote: OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and I can't (for a long time). Unless there are really important reasons like breakages I think we should really make python.eclass support EAPI=4. Two weeks and no response from python@? You probably should've cc'd them. You emailed gentoo-dev only. ~brian
Re: [gentoo-dev] Re: rfc: news item for png15
El vie, 14-10-2011 a las 03:53 -0500, Dale escribió: Pacho Ramos wrote: El jue, 13-10-2011 a las 20:48 -0600, Ryan Hill escribió: On Fri, 14 Oct 2011 01:01:50 +0300 Samuli Suominenssuomi...@gentoo.org wrote: Title: Upgrade to libpng15 Author: Samuli Suominenssuomi...@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? Maybe we could suggest to run revdep-rebuild --library libpng14.so.14 -- --keep-going two times :-/ I tested that and it just wanted to rebuild the same packages, twice. On mine, libreoffice was one of them. Recompiling that twice on a older system may annoy some. ;-) Dale :-) :-) It shouldn't, I am sure I have used this some times before and it worked as expected, but I don't know when revdep-rebuild cache files are removed (and then, broken packages recalculated) :-/ Any revdep-rebuild maintainer here to clarify this please? Thanks :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On 10/14/11 12:39 PM, Brian Harring wrote: On Fri, Oct 14, 2011 at 03:29:19PM -0400, Matt Turner wrote: On Sat, Oct 1, 2011 at 3:16 PM, Pawe?? Hajdan, Jr. phajdan...@gentoo.org wrote: OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and I can't (for a long time). Unless there are really important reasons like breakages I think we should really make python.eclass support EAPI=4. Two weeks and no response from python@? You probably should've cc'd them. CC-ing python@ then (but I expect the developers to follow gentoo-dev anyway). In case of no response, I plan to submit the thing to the council agenda. I think the parts of python eclass that I use should work with EAPI 4. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 4:20 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 10/14/11 12:39 PM, Brian Harring wrote: On Fri, Oct 14, 2011 at 03:29:19PM -0400, Matt Turner wrote: On Sat, Oct 1, 2011 at 3:16 PM, Pawe?? Hajdan, Jr. phajdan...@gentoo.org wrote: OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and I can't (for a long time). Unless there are really important reasons like breakages I think we should really make python.eclass support EAPI=4. Two weeks and no response from python@? You probably should've cc'd them. CC-ing python@ then (but I expect the developers to follow gentoo-dev anyway). In case of no response, I plan to submit the thing to the council agenda. I think the parts of python eclass that I use should work with EAPI 4. Its being worked on currently. There are many fairly difficult issues to be worked through here. Your patience and/or contribution is welcome. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 5:25 PM, Matthew Summers quantumsumm...@gentoo.org wrote: Its being worked on currently. There are many fairly difficult issues to be worked through here. That's kind of the question though. What's are the issues?
Re: [gentoo-dev] Re: rfc: news item for png15
Pacho Ramos wrote: It shouldn't, I am sure I have used this some times before and it worked as expected, but I don't know when revdep-rebuild cache files are removed (and then, broken packages recalculated) :-/ Any revdep-rebuild maintainer here to clarify this please? Thanks :) I always run revdep-rebuild with the -i option. It starts fresh each time or is supposed to anyway. This is a snipped list of what was rebuilt the first time and that it says it wants to rebuild again as I just ran it again: root@fireball / # revdep-rebuild -i --library libpng14.so.14 -- -a -j5 * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libpng14.so.14 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 8% ] * found /usr/bin/enblend SNIPPED [ 100% ] * Generated new 3_broken.rr SNIPPED * All prepared. Starting rebuild emerge --complete-graph=y --oneshot --with-bdeps y --backtrack=30 --keep-going -v -D -a -j5 app-emulation/emul-linux-x86-baselibs:0 app-emulation/emul-linux-x86-gtklibs:0 app-emulation/emul-linux-x86-medialibs:0 app-office/libreoffice:0 app-text/ghostscript-gpl:0 app-text/podofo:0 app-text/poppler:0 dev-db/libiodbc:0 dev-lang/R:0 dev-python/notify-python:0 gnome-base/libglade:2.0 gnome-base/librsvg:2 gnome-extra/polkit-gnome:0 kde-base/kdelibs:4 kde-base/ksplash:4 media-gfx/enblend:0 media-gfx/gimp:2 media-gfx/hugin:0 media-gfx/imagemagick:0 media-libs/gd:2 media-libs/gegl:0 media-libs/imlib2:0 media-libs/libpano13:0 media-libs/libwmf:0 media-libs/netpbm:0 media-libs/openjpeg:0 media-libs/plotutils:0 media-libs/sdl-image:0 media-libs/vigra:0 media-video/dvdauthor:0 media-video/mplayer:0 net-libs/webkit-gtk:2 net-print/cups:0 sys-libs/slang:0 www-client/links:2 www-client/seamonkey:0 x11-libs/cairo:0 x11-libs/fltk:1 x11-libs/fox:1.6 x11-libs/gdk-pixbuf:2 x11-libs/qt-gui:4 x11-libs/wxGTK:2.8 .. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] app-emulation/emul-linux-x86-baselibs-20110722 USE=-development 0 kB [ebuild R] sys-libs/slang-2.2.2 USE=pcre png readline zlib -cjk 0 kB [ebuild R] media-libs/libpano13-2.9.18 USE=java -static-libs 0 kB [ebuild R] media-libs/gd-2.0.35-r1 USE=jpeg png truetype -fontconfig -xpm 0 kB [ebuild R] media-libs/imlib2-1.4.4 USE=X bzip2 gif jpeg mp3 nls png tiff zlib -doc (-mmx) 0 kB [ebuild R] www-client/links-2.3_pre1-r1 USE=X bzip2 gpm jpeg ssl tiff unicode zlib -directfb -fbcon -livecd (-svga) 0 kB [ebuild R] media-libs/plotutils-2.6 USE=X png -static-libs 0 kB [ebuild R] x11-libs/fltk-1.1.10-r2 USE=opengl threads xinerama -debug -doc -examples -games -xft 0 kB [ebuild R] x11-libs/fox-1.6.40 USE=bzip2 jpeg opengl png tiff truetype zlib -debug -doc -profile 0 kB [ebuild R] media-gfx/enblend-4.0 USE=image-cache openexr openmp -debug -doc -gpu 0 kB [ebuild R] media-libs/sdl-image-1.2.10-r1 USE=gif jpeg png tiff -static-libs 0 kB [ebuild R] media-libs/netpbm-10.51.00-r1 USE=X jbig jpeg jpeg2k png tiff xml zlib -rle (-svga) 0 kB [ebuild R] x11-libs/cairo-1.10.2-r1 USE=X glib opengl svg xcb (-aqua) -debug -directfb -doc (-drm) (-gallium) (-openvg) -qt4 -static-libs 0 kB [ebuild R] x11-libs/gdk-pixbuf-2.22.1-r2 USE=X introspection jpeg jpeg2k svg tiff -debug -doc -test 0 kB [ebuild R #] net-print/cups-1.5.0-r2 USE=X dbus java jpeg pam png ssl threads tiff -acl -debug -gnutls -kerberos -ldap -perl -php -python -samba -slp -static-libs -usb -xinetd LINGUAS=-da -de -es -eu -fi -fr -id -it -ja -ko -nl -no -pl -pt -pt_BR -ru -sv -zh -zh_TW 0 kB [ebuild R] gnome-base/librsvg-2.34.1 USE=gtk -doc -tools 0 kB [ebuild R] app-text/ghostscript-gpl-9.04-r3 USE=X cups dbus gtk jpeg2k -bindist -djvu -idn -static-libs LINGUAS=-ja -ko -zh_CN -zh_TW 0 kB [ebuild R] dev-db/libiodbc-3.52.7 USE=gtk 0 kB [ebuild R] gnome-base/libglade-2.6.4 USE=-doc -static-libs -test 0 kB [ebuild R] gnome-extra/polkit-gnome-0.101-r1 USE=introspection -doc -examples 0 kB [ebuild R] x11-libs/wxGTK-2.8.11.0 USE=X opengl sdl tiff -debug -doc -gnome -gstreamer -odbc -pch 0 kB [ebuild R] media-libs/libwmf-0.2.8.4-r4 USE=X xml -debug -doc -expat 0 kB [ebuild R] dev-lang/R-2.10.1 USE=X bash-completion cairo java jpeg nls png readline threads tk -doc -lapack -minimal -perl 0 kB [ebuild R] media-gfx/imagemagick-6.7.1.0 USE=X bzip2 corefonts cxx jbig jpeg jpeg2k lcms openmp png svg tiff truetype wmf xml zlib -autotrace -djvu -fftw -fontconfig -fpx -graphviz -gs -hdri -lqr -lzma -opencl -openexr -perl -q32 -q64 -q8 -raw -static-libs -webp 0 kB [ebuild R] media-video/dvdauthor-0.6.18 0 kB [ebuild R ~] x11-libs/qt-gui-4.7.4 USE=accessibility cups dbus exceptions glib mng
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On 10/14/2011 5:28 PM, Matt Turner wrote: On Fri, Oct 14, 2011 at 5:25 PM, Matthew Summers quantumsumm...@gentoo.org wrote: Its being worked on currently. There are many fairly difficult issues to be worked through here. That's kind of the question though. What's are the issues? The only issue that has been raised is that the eclass will die if python_pkg_setup is not called from the ebuild. This can happen either implicitly (the function is exported) or explicitly (by calling it from pkg_setup). I haven't gotten a very good explanation as to why this is necessary from Arfrever. He has given some very short, non-informative explanations like Jython requires it. Puzzling it out myself takes quite a bit of brain power, given the complexity of the eclass. There may in fact be no reason for it at all. Either way, somebody needs to actually understand it. Other than that issue, I think we really just need to do some testing. Despite there being a large number of people in the python herd, there aren't many who actually have the time to do this. It would be helpful if folks could brain storm a list of python related packages to test under EAPI 4. I may have some time over the next few weekends to work on this. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
Paweł Hajdan, Jr. schrieb: On 10/14/11 12:39 PM, Brian Harring wrote: On Fri, Oct 14, 2011 at 03:29:19PM -0400, Matt Turner wrote: On Sat, Oct 1, 2011 at 3:16 PM, Pawe?? Hajdan, Jr. phajdan...@gentoo.org wrote: OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and I can't (for a long time). Unless there are really important reasons like breakages I think we should really make python.eclass support EAPI=4. Two weeks and no response from python@? You probably should've cc'd them. CC-ing python@ then (but I expect the developers to follow gentoo-dev anyway). In case of no response, I plan to submit the thing to the council agenda. I think the parts of python eclass that I use should work with EAPI 4. What do you expect the council to do? Neither you nor the council can force anyone to do anything. The only thing you can do is to kindly ask about remaining issues and helping with solving them. And i am sure, that everyone would like to see some help to understand and improve the python eclass. :-) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On 10/14/11 3:32 PM, Thomas Sachau wrote: What do you expect the council to do? Say it's OK to make python.eclass not die on EAPI-4. At least my use case will not become broken by this. Neither you nor the council can force anyone to do anything. Not really. It should always be possible to escalate painful issues like this. The only thing you can do is to kindly ask about remaining issues and helping with solving them. And i am sure, that everyone would like to see some help to understand and improve the python eclass. :-) Maybe we should start over. Seriously, I'm considering proposing some lightweight eclass for python-dependent packages that *works* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 05:52:59PM -0400, Mike Gilbert wrote: It would be helpful if folks could brain storm a list of python related packages to test under EAPI 4. I may have some time over the next few weekends to work on this. dev-vcs/git needs python eclasses to have EAPI4 so REQUIRED_USE can be used to solve bug #353657. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Re: rfc: news item for png15
El vie, 14-10-2011 a las 16:48 -0500, Dale escribió: Pacho Ramos wrote: It shouldn't, I am sure I have used this some times before and it worked as expected, but I don't know when revdep-rebuild cache files are removed (and then, broken packages recalculated) :-/ Any revdep-rebuild maintainer here to clarify this please? Thanks :) I always run revdep-rebuild with the -i option. It starts fresh each time or is supposed to anyway. This is a snipped list of what was rebuilt the first time and that it says it wants to rebuild again as I just ran it again: root@fireball / # revdep-rebuild -i --library libpng14.so.14 -- -a -j5 * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using libpng14.so.14 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 8% ] * found /usr/bin/enblend SNIPPED [ 100% ] * Generated new 3_broken.rr SNIPPED * All prepared. Starting rebuild emerge --complete-graph=y --oneshot --with-bdeps y --backtrack=30 --keep-going -v -D -a -j5 app-emulation/emul-linux-x86-baselibs:0 app-emulation/emul-linux-x86-gtklibs:0 app-emulation/emul-linux-x86-medialibs:0 app-office/libreoffice:0 app-text/ghostscript-gpl:0 app-text/podofo:0 app-text/poppler:0 dev-db/libiodbc:0 dev-lang/R:0 dev-python/notify-python:0 gnome-base/libglade:2.0 gnome-base/librsvg:2 gnome-extra/polkit-gnome:0 kde-base/kdelibs:4 kde-base/ksplash:4 media-gfx/enblend:0 media-gfx/gimp:2 media-gfx/hugin:0 media-gfx/imagemagick:0 media-libs/gd:2 media-libs/gegl:0 media-libs/imlib2:0 media-libs/libpano13:0 media-libs/libwmf:0 media-libs/netpbm:0 media-libs/openjpeg:0 media-libs/plotutils:0 media-libs/sdl-image:0 media-libs/vigra:0 media-video/dvdauthor:0 media-video/mplayer:0 net-libs/webkit-gtk:2 net-print/cups:0 sys-libs/slang:0 www-client/links:2 www-client/seamonkey:0 x11-libs/cairo:0 x11-libs/fltk:1 x11-libs/fox:1.6 x11-libs/gdk-pixbuf:2 x11-libs/qt-gui:4 x11-libs/wxGTK:2.8 .. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] app-emulation/emul-linux-x86-baselibs-20110722 USE=-development 0 kB [ebuild R] sys-libs/slang-2.2.2 USE=pcre png readline zlib -cjk 0 kB [ebuild R] media-libs/libpano13-2.9.18 USE=java -static-libs 0 kB [ebuild R] media-libs/gd-2.0.35-r1 USE=jpeg png truetype -fontconfig -xpm 0 kB [ebuild R] media-libs/imlib2-1.4.4 USE=X bzip2 gif jpeg mp3 nls png tiff zlib -doc (-mmx) 0 kB [ebuild R] www-client/links-2.3_pre1-r1 USE=X bzip2 gpm jpeg ssl tiff unicode zlib -directfb -fbcon -livecd (-svga) 0 kB [ebuild R] media-libs/plotutils-2.6 USE=X png -static-libs 0 kB [ebuild R] x11-libs/fltk-1.1.10-r2 USE=opengl threads xinerama -debug -doc -examples -games -xft 0 kB [ebuild R] x11-libs/fox-1.6.40 USE=bzip2 jpeg opengl png tiff truetype zlib -debug -doc -profile 0 kB [ebuild R] media-gfx/enblend-4.0 USE=image-cache openexr openmp -debug -doc -gpu 0 kB [ebuild R] media-libs/sdl-image-1.2.10-r1 USE=gif jpeg png tiff -static-libs 0 kB [ebuild R] media-libs/netpbm-10.51.00-r1 USE=X jbig jpeg jpeg2k png tiff xml zlib -rle (-svga) 0 kB [ebuild R] x11-libs/cairo-1.10.2-r1 USE=X glib opengl svg xcb (-aqua) -debug -directfb -doc (-drm) (-gallium) (-openvg) -qt4 -static-libs 0 kB [ebuild R] x11-libs/gdk-pixbuf-2.22.1-r2 USE=X introspection jpeg jpeg2k svg tiff -debug -doc -test 0 kB [ebuild R #] net-print/cups-1.5.0-r2 USE=X dbus java jpeg pam png ssl threads tiff -acl -debug -gnutls -kerberos -ldap -perl -php -python -samba -slp -static-libs -usb -xinetd LINGUAS=-da -de -es -eu -fi -fr -id -it -ja -ko -nl -no -pl -pt -pt_BR -ru -sv -zh -zh_TW 0 kB [ebuild R] gnome-base/librsvg-2.34.1 USE=gtk -doc -tools 0 kB [ebuild R] app-text/ghostscript-gpl-9.04-r3 USE=X cups dbus gtk jpeg2k -bindist -djvu -idn -static-libs LINGUAS=-ja -ko -zh_CN -zh_TW 0 kB [ebuild R] dev-db/libiodbc-3.52.7 USE=gtk 0 kB [ebuild R] gnome-base/libglade-2.6.4 USE=-doc -static-libs -test 0 kB [ebuild R] gnome-extra/polkit-gnome-0.101-r1 USE=introspection -doc -examples 0 kB [ebuild R] x11-libs/wxGTK-2.8.11.0 USE=X opengl sdl tiff -debug -doc -gnome -gstreamer -odbc -pch 0 kB [ebuild R] media-libs/libwmf-0.2.8.4-r4 USE=X xml -debug -doc -expat 0 kB [ebuild R] dev-lang/R-2.10.1 USE=X bash-completion cairo java jpeg nls png readline threads tk -doc -lapack -minimal -perl 0 kB [ebuild R] media-gfx/imagemagick-6.7.1.0 USE=X bzip2 corefonts cxx jbig jpeg jpeg2k lcms openmp png svg tiff truetype wmf xml zlib -autotrace -djvu -fftw -fontconfig -fpx -graphviz -gs -hdri -lqr -lzma -opencl -openexr -perl -q32 -q64 -q8 -raw -static-libs
Re: [gentoo-dev] rfc: news item for png15
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/13/2011 11:01 PM, Samuli Suominen wrote:
small news item for stable users. lets keep it simple... You can
identify those files with following one-liner: ... # find /usr/
-name '*.la' -exec grep png14 {} +
What happens once you identify the broken .la files? Should people
delete these .la files? Should they just rebuild the package? Should
they run lafilefixer? I think you need to add some bits here on how to
deal with the remaining .la files ;)
- --
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBCgAGBQJOmMRpAAoJEPqDWhW0r/LCleIQAJkRkWEIMyQR1Zwlq+3Ykb81
T9a2MluJZ52G+wJfy7UoeSJ9rAU6W23EXabS6l/ENiIwFmiAg9V7LmFFslyWFLCE
noSjJxcoknDfWGWAhIiYBX7k2JBwwMZG/6NJpQLNs68L5MhJP/tgt6LNlvdfHs0P
Ats3DY4K+1NF098rtgpV9wE8wlcBuyABeZIbsY4jHGeIl4QalLOm0oqq4V+wVM4l
6QVTgRGYGz0mlWooHLmjBRqao2yAk0ZBFnHOEhClUfiz1tpPftZP7h91k8YLOkca
rpthTHzN1OxEQS5BGvUjq0IX54WPjnlOuKz6RSfm4QFFP5zn9mnovW5hcLu1f+68
fOvbNvzlJ6SHdr/iXuGT/U8DcUTqFWucoSJa0Yxi2qFfiLnvmkrPQKKdfhb2e9xx
l29OVGzN/BKs213XCrlVY40ghWucUd8jzr5WGE1heV7t3Nhx5YYcn0GRBmoyD7L6
Vk/Z6GhD5BE/rYVBUsQqOEq1JkYQ3qAWgW/0pOrHi8xwguGiENx8PnX816JrRS2J
DJDLxpoayU9Li9URZBmgBNCjtyVKoZWjwe9QZjQhVTTq+MXGfl3En727jiMqjKSq
kZa6rczspDebnTNCD6l48VcDbnqIAhbHUopm+ACStLVIVx0j++4vZiYIdY4nQFqb
yFy6/eNVw3JMdsHRb0D1
=v70x
-END PGP SIGNATURE-
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, 2011-10-14 at 22:53 +, Robin H. Johnson wrote: dev-vcs/git needs python eclasses to have EAPI4 so REQUIRED_USE can be used to solve bug #353657. Similar problems in dev-vcs/subversion... Regards, Tony V. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: news item for png15
Pacho Ramos wrote: El vie, 14-10-2011 a las 16:48 -0500, Dale escribió: Pacho Ramos wrote: It shouldn't, I am sure I have used this some times before and it worked as expected, but I don't know when revdep-rebuild cache files are removed (and then, broken packages recalculated) :-/ Any revdep-rebuild maintainer here to clarify this please? Thanks :) I always run revdep-rebuild with the -i option. It starts fresh each time or is supposed to anyway. This is a snipped list of what was rebuilt the first time and that it says it wants to rebuild again as I just ran it again: SNIPPED That list is identical to the first time I ran it. I don't know what you were expecting but this is what it does. Dale :-) :-) Well, I would expect it to properly recalculate broken packages after previous run that failed to complete to build failures From my understanding, it looks for what packages link/use/whatever the library then it rebuilds them all. I guess this is one way to catch them all for sure but it is sort of difficult to know what was already fixed and what is still broke. I think I see what you are expecting and I wish it was that way but it appears we are not getting what we want with this. Is it doable, maybe, but not at the moment. By the way, I run the unstable versions of those tools. I guess if the emerge fails, then one would have to use the --resume option to try to rebuild packages or just rebuild what fails by hand and hope you don't miss anything. Dale :-) :-)
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
On Fri, Oct 14, 2011 at 3:51 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 10/14/11 3:32 PM, Thomas Sachau wrote: What do you expect the council to do? Say it's OK to make python.eclass not die on EAPI-4. At least my use case will not become broken by this. Neither you nor the council can force anyone to do anything. Not really. It should always be possible to escalate painful issues like this. 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. -A The only thing you can do is to kindly ask about remaining issues and helping with solving them. And i am sure, that everyone would like to see some help to understand and improve the python eclass. :-) Maybe we should start over. Seriously, I'm considering proposing some lightweight eclass for python-dependent packages that *works*
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
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* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] python.eclass EAPI 4 support, this gets really annoying
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? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote https://www.xkcd.com/963/ Xorg --configure -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Suggestion for getting rid of udev
On Fri, Oct 14, 2011 at 8:37 PM, Walter Dnes waltd...@waltdnes.org wrote: On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote https://www.xkcd.com/963/ Xorg --configure Funny, I haven't used a /etc/X11/Xorg.conf in years: negra ~ # ll /etc/X11/ total 20 drwxr-xr-x 2 root root 4096 Sep 12 17:49 app-defaults -rwxr-xr-x 1 root root 1301 Aug 31 15:54 chooser.sh drwxr-xr-x 2 root root 4096 Sep 30 09:36 Sessions -rwxr-xr-x 1 root root 923 Aug 31 15:54 startDM.sh drwxr-xr-x 3 root root 4096 Aug 31 15:54 xinit negra ~ # It's great; it just works. And it is thanks (in great part) to udev. 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 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? -- Walter Dnes waltd...@waltdnes.org
