Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tuesday 07 August 2007, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 07 August 2007, Richard Brown wrote: On 07/08/07, Mike Frysinger [EMAIL PROTECTED] wrote: in an ideal world, yes ... in the real world however, i wouldnt trust it You wouldn't trust what, exactly? A dev to install a package they're bumping? you cant tell me the build experience a dev goes through mirrors exactly the same experience very user sees Which is why it's so important to catch failures. yes, it's important to catch *important* failures. a missing doc is generally not such a failure. Something that builds correctly for a developer may not build correctly for a user, so being strict will help prevent users from installing a broken package. it's up to the dev to determine what determines a broken package. a missing TODO in the doc tree does not a broken package make. perhaps it'd be useful to introduce an anal_die. developers run anal tests, users get sane tests. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] stabilizing expat 2.0.0
On Tuesday 15 May 2007, Carsten Lohrke wrote: On Dienstag, 15. Mai 2007, Caleb Tennis wrote: I just read the bug, but I don't see any compelling reason against using the preserve_old stuff. The big problem with it is that we do not store information about retained libraries and let portage throw warnings. When people miss such a post install message, the library potentially remains forever in the system, not unlikely with seldom updated stuff linking against it. As soon as a vulnerability is popping up, the system is vulnerable, remains vulnerable and its owner assumes everything is fine. not really every merge will continue to warn about the library still being on the system the only things that will be vuln are things that were not rebuilt -- but that would be because the user did not run revdep-rebuild you could also make the case that people who dont reboot their system would remain vuln as the broken lib would stay in memory -- it isnt uncommon for me to have a KDE system running for months w/out even logging out -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] stabilizing expat 2.0.0
On Tuesday 15 May 2007, Caleb Tennis wrote: I think the preserve_old_libs thing might just be the hack we need here. It's been brought to my attention that a bad side effect from using the preserve_old_libs method is that if an intermediary library, like qt3, gets rebuilt then you end up having both expat libraries linked against the kde libraries at the same time which causes rather undesriable crashes. Presumably this will affect GNOME in a similar fashion as well. this is semi-incorrect you cannot have 1 library linked both against libexpat.so.0 and libexpat.so.1 you can have 1 library linked against libexpat.so.0 while another library is linked against libexpat.so.1 and both of those libraries are linked against each other looking at `ldd` output of one library and saying oh, this is linked against libs X Y Z is wrong. ldd shows the entire library chain, not just direct dependencies. the reason the gcc-3.3.x - gcc-3.4.x transition allowed for one library to be linked against different libstdc++.so is due to having multiple libstdc++ archives with unique paths existing on the system at the same point. that cannot happen with libexpat as it installs into the same path regardless of version. so anyone who fails to run revdep-rebuild will have an inconsistent system, but i'd rather have people having some programs running freaky like and telling them they need to run revdep-rebuild than *every single user* having a completely unusable system (which is what we have now). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [crossdev] problem building pure 64bit toolchain for mips64
(1) dont cross-post (2) this belongs on gentoo-embedded, not gentoo-user, and most certainly not gentoo-dev -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [crossdev] problem building pure 64bit toolchain for mips64
hi, I'm trying to build a pure 64bit cross toolchain for mips64 on a x86(x86 or x86_64) host, using the following method: 1. set PORTATE_OVERLAY in /etc/make.conf echo PORTDIR_OVERLAY=/usr/local/portage /etc/make.conf 2. emerge crossdev emerge -av crossdev 3. select CTARGET (mips64el for instance here), Setup 'categories', set proper package/use mask mkdir -p /etc/portage echo cross-mips64el-unknown-linux-gnu /etc/portage/categories echo =cross-mips64el-unknown-linux-gnu/mips-headers-2.6.10 * -* ~* /etc/portage/package.keywords echo cross-mips64el-unknown-linux-gnu/gcc n64 /etc/portage/package.use mkdir -p /usr/portage/profile echo '-n64' /etc/portage/profile/use.mask 4. make neccessary package symlinks mkdir -p /usr/local/portage/cross-mips64el-unknown-linux-gnu cd /usr/local/portage/cross-mips64el-unknown-linux-gnu ln -s /usr/portage/sys-devel/binutils binutils ln -s /usr/portage/sys-devel/gcc gcc ln -s /usr/portage/sys-kernel/mips-headers mips-headers ln -s /usr/portage/sys-libs/glibc glibc 5. emerge binutils about USE flags, please look at [1] emerge -av cross-mips64el-unknown-linux-gnu/binutils 6. emerge bootstrap gcc (Pass 1) make sure only nocxx and bootstrap are selected: USE=nocxx bootstrap n64 -fortran -mudflap -nls emerge -av cross-mips64el-unknown-linux-gnu/gcc also use gcc-config to select the new (cross) gcc: gcc-config -l # to list gccs gcc-config XXX 7. emerge linux-headers emerge -av cross-mips64el-unknown-linux-gnu/mips-headers 8. emerge glibc emerge -av cross-mips64el-unknown-linux-gnu/glibc make sure nptl ntplonly is in USE flags if you wan't nptl. USE=ntpl nptlonly emerge -av cross-mips64el-unknown-linux-gnu/glibc 9. emerge gcc (Pass 2), with c and c++ compilers: make sure nocxx is not set, you could also enalbe nls or mudflap if you like. emerge -av cross-mips64el-unknown-linux-gnu/gcc 10. build stuff When you go to emerge packages, you should just need to do: ROOT=/blah/ CHOST=mips64el-unknown-linux-gnu emerge cpio - you should also set CBUILD to your building machine for completeness sake ... most of the time you won't need it, but sometimes you will :) - CTARGET is no longer needed so don't set it ! If you want to cross compile a kernel, do this: make ARCH=mips CROSS_COMPILE=mips64el-unknown-linux-gnu- [1] for step 6, the USE flags should better have nocxx bootstrap and no other flags, they are tested to work on my system. other than step 6, the USE flags is not abitrary so we could keep it as same as the host system as possible. .ref: http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO at step 8 I got the following error message: mips64el-unknown-linux-gnu-gcc -mabi=n32 -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib32/ld.so.1 -B/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/csu/ -Wl,--version-script=/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/libc.map -Wl,-soname=libc.so.6 -Wl,-z,relro -nostdlib -nostartfiles -e __libc_main -Wl,-z,now -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/math -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/elf -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/dlfcn -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/nss -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/nis -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/rt -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/resolv -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/crypt -L/var/tmp/portage/cross-mips64el-unknown-linux-gnu/glibc-2.5-r4/work/build-n32-mips64el-unknown-linux-gnu-nptl/nptl
Re: [gentoo-dev] Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: perhaps it'd be useful to introduce an anal_die. developers run anal tests, users get sane tests. -mike Anal ftw -Alec Also known as FEATURES=stricter. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxdAXtbrAj05h3oQRAsUxAJ48+iW/EEhe87Q37xEP/gWwUPmrPACfbS1e rVtezxohQ6Bh+NOTEbWH02c= =uhBq -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
perhaps it'd be useful to introduce an anal_die. developers run anal tests, users get sane tests. -mike Anal ftw -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. dodoc stuff on the other hand is within our control, so I'd be happy to see ebuilds die because of that, either with stricter or even with strict. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Friday 17 August 2007, Hans de Graaff wrote: On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. i can make it more selective about which ones actually die ... dodoc stuff on the other hand is within our control, so I'd be happy to see ebuilds die because of that, either with stricter or even with strict. FEATURES=strict is inappropriate as it implies things like Manifest checking and is the default for everyone -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-17 at 13:40 -0400, Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. i can make it more selective about which ones actually die ... That would be useful, because I'm sure that different people have different ideas about which checks to die on, and introducing more FEATURES for this seems to take it a bit too far. dodoc stuff on the other hand is within our control, so I'd be happy to see ebuilds die because of that, either with stricter or even with strict. FEATURES=strict is inappropriate as it implies things like Manifest checking and is the default for everyone Agreed if it is the default. Kind regards, Hans signature.asc Description: This is a digitally signed message part
[gentoo-dev] Lastrites media-video/xmps
# Samuli Suominen [EMAIL PROTECTED] (17 Aug 2007) # Does not build with GCC4, no upstream, last release 2002. # GTK+-1.2. Masked for removal in 30 days. media-video/xmps If you still want to keep it around, patch and port it using GCC 4.2 and GTK+-2.0, otherwise it's gone. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Lastrites media-sound/usbmidi
# Samuli Suominen [EMAIL PROTECTED] (17 Aug 2007) # Code has been merged or replaced in 2.6 series kernels. # 2.4 no-nptl no longer supported by sound. # Masked for removal in 30 days. media-sound/usbmidi No way to test this, and it's no longer needed. However if *you* use x86 2.4 no-nptl, and own a MidiMan USB ports, feel free to takeover. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 13:40 Fri 17 Aug , Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Friday 17 August 2007, Donnie Berkholz wrote: On 13:40 Fri 17 Aug , Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. what do you think of comment #14 in Bug 185567 ? i think that plus having hooks for all phase funcs ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
В Птн, 17/08/2007 в 13:18 -0700, Donnie Berkholz пишет: On 13:40 Fri 17 Aug , Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: Unfortunately FEATURES=stricter stopped being really useful i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. But is it good idea to let developers disable QA checks? Seems that it's better to set QA checks in profile (arch team decision). Of course for overlays only it'll be possible to redefine this. Also speaking about bad programming practice seems that it's good to be able to disable them on ebuild basis as some upstreams (e.g. wireshark) are really interested in any compiler warnings and I report such thing for them. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 8/17/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 17 August 2007, Donnie Berkholz wrote: On 13:40 Fri 17 Aug , Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. what do you think of comment #14 in Bug 185567 ? i think that plus having hooks for all phase funcs ... -mike +1 for pkg_maint -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 8/17/07, Peter Volkov [EMAIL PROTECTED] wrote: В Птн, 17/08/2007 в 13:18 -0700, Donnie Berkholz пишет: On 13:40 Fri 17 Aug , Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: Unfortunately FEATURES=stricter stopped being really useful i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. But is it good idea to let developers disable QA checks? Seems that it's better to set QA checks in profile (arch team decision). Of course for overlays only it'll be possible to redefine this. Developers = Users. Many users have wanted the checks and dies reduced for a long time. Most users could care less about half the tests that run. I know I disable most of the crap that runs after src_install(). QA has always been and will always be a pragmatic effort. You cannot force people to run the software you want and you can't even force them to run repoman before commiting even though it's 'required'. You cannot force QA. In the end the only requirement is to not break shit, and we fail to meet that even with our current tools. │ИМ╒┤^╬╖╤┼(╝ ┼X╖┌X╛
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Friday 17 August 2007, Alec Warner wrote: On 8/17/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 17 August 2007, Donnie Berkholz wrote: On 13:40 Fri 17 Aug , Mike Frysinger wrote: On Friday 17 August 2007, Hans de Graaff wrote: On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. what do you think of comment #14 in Bug 185567 ? i think that plus having hooks for all phase funcs ... +1 for pkg_maint i was thinking more mnt_qa since the new phase will be like maint_ or mnt_ -mike signature.asc Description: This is a digitally signed message part.
