Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thu, Oct 13, 2011 at 11:01 PM, Mike Frysinger wrote: > 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. I think you are misrepresenting the choice a bit here. If we aim for high quality in gentoo-x86 by avoiding deps like this I fear the choice will not be 'broken foo' or 'working foo' but instead 'broken foo' or 'no foo' as packages get masked and removed for not keeping up with the joneses. Don't get me wrong; I get the impression that there exist vast swaths of gentoo-x86 that are ...I'll use the term 'poorly maintained' and it would be good to get some of that stuff out. However I doubt our users would agree that this is necessarily 'better'. > > 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 >
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 > 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] 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] rfc: news item for png15
On Fri, 14 Oct 2011 04:30:56 +0400
Peter Volkov wrote:
> 2. better find:
> find /usr -name "*.la" -o -name "*.pc" -o -name "*-config" -exec grep
> -H png14 {} \;
find /usr -name "*.la" -o -name "*.pc" -o -name "*-config" \
-exec grep -H png14 {} +
This is going to take less grep calls, and it is easier to type too.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: libtool.eclass documentation
On Friday 30 September 2011 11:27:18 Diego Elio Pettenò wrote: > Il giorno ven, 30/09/2011 alle 11.06 -0400, Mike Frysinger ha scritto: > > and azarah ;) > > Right, by the way have you (or anyone else) got any news of him? > > > want to do a brain dump into the @DESCRIPTION part of libtool.eclass ? > > Yup, will be my weekend's task then. get a chance to do this yet ? -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild
Samuli Suominen wrote:
> On 10/12/2011 06:30 AM, Steven J Long wrote:
>> Michał Górny wrote:
>>> I don't think that passing multiple files to epatch actually improves
>>> readability. Simple example:
>>>
>>> # bug #123456, foo, bar
>>> epatch "${FILESDIR}"/${P}-foo.patch
>>> # bug #234567, baz bazinga blah blah
>>> epatch "${FILESDIR}"/${P}-baz.patch
>>>
>>> With multiple arguments, you can't put comments in the middle.
>>>
>> ++ It's also a lot easier to remove the single patches when they're no
>> longer needed.
>
> Removing an 'epatch foo' line is easier than 'foo \' ? You are kidding,
> right?
>
No; in general, most editors make it really simple to delete a line. Not
having to worry about line-continuation is just another routine memo that
doesn't have to be kept in mind*, and I'd argue that it's useful to readers
of the ebuild, to have the bug # in the ebuild.
* All right, not a *lot* easier, just a bit ;-)
>> In the context of configuring, building and installing a
>> package, the extra overhead is miniscule, whereas the above is *much*
>> easier to maintain.
>
> Based on what argument?
Based on it being easier to edit, and easier to look up the bug straight
from the ebuild, should someone working with an ebuild choose (or need) to
do so. I guess I'm arguing for Mike's style within the ebuild (tho that
PATCHES array looks nice and allows bug # comments.)
Again, perhaps '*much*' went a bit far; sorry for that.
> Having the comments inside the patch allows everyone, including
> _upstreams_ straight up see what's it for and link to the bug it's
> coming from. Where as keeping them in ebuilds makes it Gentoo specific,
> which is not what we are about.
Having a bug # in the ebuild doesn't excuse anyone from having correct
comments in the patch; they're orthogonal imo. Personally I think you should
do both; bug # in ebuild* so a user can quickly look up what's happening,
and both full bug URL, and a fuller explanation in the patch. Bug # in
ebuild is also useful when you get an ebuild from someone and no patches in
files/ as it's effectively a fragment. You can argue it's redundant; I see
it as equivalent to a doubly-linked list: you don't _need_ both links to
function, but it makes things easier.
In any event you're the maintainer; but this was a discussion about style,
well "readability" at least, and I think it's better practice to have bug #
in ebuild.
Regards,
igli.
* After all, you only add the bug id once, when you're adding the patch and
are well aware of what bug/s you're working on; it's not an ongoing burden.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: rfc: news item for png15
On Fri, 14 Oct 2011 01:01:50 +0300
Samuli Suominen wrote:
> Title: Upgrade to libpng15
> Author: Samuli Suominen
> Content-Type: text/plain
> Posted: 2011-10-14
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:
> 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
>
--
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
[gentoo-dev] Re: rfc: news item for png15
On Fri, 14 Oct 2011 01:01:50 +0300
Samuli Suominen wrote:
> Title: Upgrade to libpng15
> Author: Samuli Suominen
> Content-Type: text/plain
> Posted: 2011-10-14
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:
> 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
>
--
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] new helper: econf_build
On Thursday 13 October 2011 21:41:02 Alec Warner wrote:
> On Thu, Oct 13, 2011 at 4:48 PM, 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} "$@"
>
> I'm a newb, are BUILD_* expected to be set by users?
yes & no. toolchain-funcs is intelligent to setup sane values if need be.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] new helper: econf_build
On Thu, Oct 13, 2011 at 4:48 PM, 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} "$@"
I'm a newb, are BUILD_* expected to be set by users?
-A
>
> this is to deal with packages that build up not insignificant (let's call them
> "nificant") binaries which are then used at build time. when cross-compiling,
> you can't execute those binaries, and things fail.
>
> python is a good example. it builds up the local python interpreter (which is
> all written in C/etc...), and then uses that to parse local python scripts
> which take care of building everything else. so a while ago we added code so
> that it'd build two python binaries when cross-compiling: a local ${CBUILD}
> version which is then used to parse the python build files to compile for
> ${CHOST}. using host python won't work if it's newer/older/insane/afk.
>
> ncurses compiles its local term database by first creating a tic helper and
> then parsing its local files. we can't use the build system's tic because if
> the installed ncurses is a different version, we run into fun things like
> crashes/infinite loops/etc...
>
> the latest thing i hit was elfutils where it creates a local binary to
> generate a database of headers which it then compiles into the target code.
>
> 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 ?
> -mike
>
Re: [gentoo-dev] rfc: news item for png15
В Птн, 14/10/2011 в 01:01 +0300, Samuli Suominen пишет:
> small news item for stable users. lets keep it simple...
I think it's better to put all knowledge from forum post inside:
1. --keep-going option for revdep-rebuild.
2. better find:
find /usr -name "*.la" -o -name "*.pc" -o -name "*-config" -exec grep -H
png14 {} \;
or even better to provide one-liner for user's convenience.
--
Peter.
[gentoo-dev] new helper: econf_build
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} "$@"
this is to deal with packages that build up not insignificant (let's call them
"nificant") binaries which are then used at build time. when cross-compiling,
you can't execute those binaries, and things fail.
python is a good example. it builds up the local python interpreter (which is
all written in C/etc...), and then uses that to parse local python scripts
which take care of building everything else. so a while ago we added code so
that it'd build two python binaries when cross-compiling: a local ${CBUILD}
version which is then used to parse the python build files to compile for
${CHOST}. using host python won't work if it's newer/older/insane/afk.
ncurses compiles its local term database by first creating a tic helper and
then parsing its local files. we can't use the build system's tic because if
the installed ncurses is a different version, we run into fun things like
crashes/infinite loops/etc...
the latest thing i hit was elfutils where it creates a local binary to
generate a database of headers which it then compiles into the target code.
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 ?
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] rfc: news item for png15
small news item for stable users. lets keep it simple... Title: Upgrade to libpng15 Author: Samuli Suominen Content-Type: text/plain Posted: 2011-10-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://forums.gentoo.org/viewtopic-t-894950.html
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On Thu, Oct 13, 2011 at 12:12 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Mike Frysinger posted on Thu, 13 Oct 2011 00:39:52 -0400 as excerpted: > >> i thought there was talk of an automatic @security set at some point, >> but not sure if that got anywhere. Marius (genone) added @security support along with the other sets in portage-2.2, and it's still supported. > Sets (other than @system and @world) aren't available in stable portage > yet. Are they even in ~arch? We migrate features to ~arch (which becomes stable) as soon as they're in a state that we're happy enough to support long-term. Bug 144480 [1] tracks issues related to sets. > I've been running the masked 2.2 in > ordered to have sets for so long it's beginning to feel like openrc all > over again, except now it's not even in ~arch, AFAIK. FWIW, we've already got plans to bring support for /etc/portage/sets to ~arch [2]. [1] https://bugs.gentoo.org/show_bug.cgi?id=144480 [2] https://bugs.gentoo.org/show_bug.cgi?id=384061 -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Samuli Suominen schrieb: >> This is something that I have been asking for all the time. If you think >> that what qutecom did should be illegal in Gentoo, then disallow it in >> policy or code. > > Drop that "should be" act, please. It looks as if you were still > suggesting it was fine to do what qutecom did... Before the package was masked for removal, I was fairly convinced that it was fine. Then I noticed that you have different opinions. If "
Re: [gentoo-dev] Re: Build dependencies and upgrades.
On 10/12/2011 08:20 PM, Mike Frysinger wrote: > On Wednesday 12 October 2011 11:09:56 Zac Medico wrote: >> How about if we add a `emerge --upgrade` target that is analogous to >> `apt-get upgrade`? > > isn't that already done with @installed ? `emerge --upgrade @installed` At this time, @installed tends to trigger unsolvable blockers during updates [1], so it's not really usable for general purpose updates unless you want users to go back to the days of solving blocker by themselves even though the package manager is capable of doing it automatically. Also, @installed pulls in slot atoms just for the installed slots, so it won't pull in new slots like un-slotted atoms would. [1] https://bugs.gentoo.org/show_bug.cgi?id=387059 -- Thanks, Zac
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thursday 13 October 2011 14:55:45 Canek Peláez Valdés wrote: > On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote: > > On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: > >> While I've seen a lot of whining about this whole issue, I certainly > >> haven't been seen any effort to actually solve the problem within the > >> existing framework. For example, if someone cares enough, why not > >> write a wrapper script to track down the programs and libraries at > >> runtime that actually do use /usr so it's easier to say "these > >> packages install rules that need / and /usr on the same partition". > > > > (1) udev has provided a workaround of sorts for this already: udevadm > > trigger --type=failed. this is the udev-postmount init.d script. (2) > > it's fairly trivial to locate most (all?) the failing rules with a > > single grep: grep /usr -R /lib/udev/rules.d/. > > If this comment is true (haven't looked at the code): > > https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 > > that trigger has been removed from udev. ... which is what spurred this entire debate in the first place -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés wrote: > On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger wrote: >> On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: >>> While I've seen a lot of whining about this whole issue, I certainly >>> haven't been seen any effort to actually solve the problem within the >>> existing framework. For example, if someone cares enough, why not >>> write a wrapper script to track down the programs and libraries at >>> runtime that actually do use /usr so it's easier to say "these >>> packages install rules that need / and /usr on the same partition". >> >> (1) udev has provided a workaround of sorts for this already: udevadm trigger >> --type=failed. this is the udev-postmount init.d script. (2) it's fairly >> trivial to locate most (all?) the failing rules with a single grep: grep /usr >> -R /lib/udev/rules.d/. > > If this comment is true (haven't looked at the code): > > https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 > > that trigger has been removed from udev. Answering myselef; it is gone: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=289a1821a4a7636ce42a6c7adc3a9bb49421a5ea commit 289a1821a4a7636ce42a6c7adc3a9bb49421a5ea Author: Kay Sievers Date: Thu Oct 6 00:45:06 2011 +0200 remove 'udevadm trigger --type=failed' and SYSFS, ID, BUS keys 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 10:02 AM, Mike Frysinger wrote: > On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: >> While I've seen a lot of whining about this whole issue, I certainly >> haven't been seen any effort to actually solve the problem within the >> existing framework. For example, if someone cares enough, why not >> write a wrapper script to track down the programs and libraries at >> runtime that actually do use /usr so it's easier to say "these >> packages install rules that need / and /usr on the same partition". > > (1) udev has provided a workaround of sorts for this already: udevadm trigger > --type=failed. this is the udev-postmount init.d script. (2) it's fairly > trivial to locate most (all?) the failing rules with a single grep: grep /usr > -R /lib/udev/rules.d/. If this comment is true (haven't looked at the code): https://bugs.gentoo.org/show_bug.cgi?id=375263#c23 that trigger has been removed from 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 10/13/2011 08:02 PM, Mike Frysinger wrote: > On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: >> While I've seen a lot of whining about this whole issue, I certainly >> haven't been seen any effort to actually solve the problem within the >> existing framework. For example, if someone cares enough, why not >> write a wrapper script to track down the programs and libraries at >> runtime that actually do use /usr so it's easier to say "these >> packages install rules that need / and /usr on the same partition". > > (1) udev has provided a workaround of sorts for this already: udevadm trigger > --type=failed. this is the udev-postmount init.d script. (2) it's fairly > trivial to locate most (all?) the failing rules with a single grep: grep /usr > -R /lib/udev/rules.d/. nitpicking for (2): also /var, since that's used by alsa's udev rules (alsactl stores info there to restore mixers for eg)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Am 13.10.2011 15:13, schrieb Ciaran McCreesh: > On Thu, 13 Oct 2011 12:23:07 +0200 > Chí-Thanh Christopher Nguyễn wrote: >> So qutecom is not broken and needs not be removed as long as >> > Dependencies using <, <=, =, ~ or =* are broken, except in certain > special situations inside ||. > Why exactly are they broken? Sure, it will force the user to choose between installing this and having the latest version of the package installed. But I don't see this being a problem. As an example I always get this on world updates: 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. And before some asks, no portage wouldn't break this dep these days: # emerge -1u --ignore-default-opts -vtp pexpect These are the packages that would be merged, in reverse order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB WARNING: One or more updates have been skipped due to a dependency conflict: 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-notebook-0.8.19-r1::sage-on-gentoo, installed) Sebastian
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thu, 13 Oct 2011 13:52:37 -0400 Rich Freeman wrote: > While slotting libraries is often an option, that gets a lot messier > when you're talking about things like header files. You can make slots mutually blocking if you do it carefully. It does get a bit horrible without := dependencies though... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thu, Oct 13, 2011 at 1:45 PM, Samuli Suominen wrote: > Merely saying if we had some documentation snippet, or an end-quiz > question for this, QA could more easily/faster revoke access if someone > were to do this intentionally in tree. This could be minor motivation > for me to write such snippet, but it's definately not near top on my TODO. I think that something that is worth an official policy is whether in fact "<" or "=" dependencies are acceptable, or in general when they are acceptable. That isn't to say that we have to enumerate all possibilities, but there should be guidelines. I don't think there really is a clear consensus on this. It is definitely a can of worms and I don't think black-and-white is the right approach to take. While slotting libraries is often an option, that gets a lot messier when you're talking about things like header files. Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On 10/13/2011 06:09 PM, Chí-Thanh Christopher Nguyễn wrote: > Samuli Suominen schrieb: >> you're right. sorry. that came out too harsh. lets rephrase this as: > > No offense taken :) > >> "This /topic should be in the end-quiz, and mentioned in the mentoring >> guide to cover basis as part of the KEYWORDS visibility handling." > > This is something that I have been asking for all the time. If you think > that what qutecom did should be illegal in Gentoo, then disallow it in > policy or code. Drop that "should be" act, please. It looks as if you were still suggesting it was fine to do what qutecom did... Merely saying if we had some documentation snippet, or an end-quiz question for this, QA could more easily/faster revoke access if someone were to do this intentionally in tree. This could be minor motivation for me to write such snippet, but it's definately not near top on my TODO.
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thu, 13 Oct 2011 11:14:31 -0400 Olivier Crête wrote: > On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: > > On Wed, 12 Oct 2011 23:00:23 +0530 > > Nirbheek Chauhan 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote: > While I've seen a lot of whining about this whole issue, I certainly > haven't been seen any effort to actually solve the problem within the > existing framework. For example, if someone cares enough, why not > write a wrapper script to track down the programs and libraries at > runtime that actually do use /usr so it's easier to say "these > packages install rules that need / and /usr on the same partition". (1) udev has provided a workaround of sorts for this already: udevadm trigger --type=failed. this is the udev-postmount init.d script. (2) it's fairly trivial to locate most (all?) the failing rules with a single grep: grep /usr -R /lib/udev/rules.d/. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
On 13 October 2011 20:58, Rich Freeman wrote: > 2011/10/13 Olivier Crête : >> 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. > > I'd also look at it another way. It is a lot easier to take a > well-integrated platform and chop out the parts that you don't need, > than to take a million pieces and build yourself an integrated > platform. While it has been the way just about all platform development on Linux has taken place, what this mode of thinking ignores is that gratuitously supporting as many corner cases as you can means that you need to support a combinatorial explosion of pieces, which so far has only managed to keep our stack fragmented and an enormous pita to work with. I'm not saying we should narrow our focus too much, but every decision to support weird ways of doing things has a cost, and if you're going to support it, you (as an upstream developer) are spending time that could possibly have been spent making the whole system better. (that's to set some perspective on why things are heading the way they are, and discussing whether this is sensible or not probably is going to spin offtopic for gentoo-dev really quickly) While I've seen a lot of whining about this whole issue, I certainly haven't been seen any effort to actually solve the problem within the existing framework. For example, if someone cares enough, why not write a wrapper script to track down the programs and libraries at runtime that actually do use /usr so it's easier to say "these packages install rules that need / and /usr on the same partition". -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)
Re: [gentoo-dev] Suggestion for getting rid of udev
On Thursday 13 October 2011 11:17:07 Olivier Crête wrote: > That said, we, the GNOME upstream, think that having a separate /usr is > a completely stupid idea. considering GNOME's track record wrt what they think is a "good idea" in the UI land, i'm not sure this statement is terribly compelling -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Suggestion for getting rid of udev
2011/10/13 Olivier Crête : > 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. I'd also look at it another way. It is a lot easier to take a well-integrated platform and chop out the parts that you don't need, than to take a million pieces and build yourself an integrated platform. I think the key is to still define boundaries between the layers and interfaces such that you still can chop out parts. I think that there is a danger that we may get to a point where that becomes increasingly difficult. If KDE and Gnome were to come out with separate incompatible implementations of SysVInit, XDM, X11, and automounting then having both on the same system would no longer be a matter of just picking a session in the XDM interface. However, the vertical integration right now isn't that bad. We can deploy udev/dbus/etc and people who don't need it can just remove it without much fuss. Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thu, Oct 13, 2011 at 11:26 AM, Michał Górny wrote: > So, in your opinion, if we have 'foo' and 'libfoo' which are strictly > version-bound, we can't allow users to install older versions? Obviously the real issue is when libfoo is libpng or openssl or whatever. It almost makes you wonder if the solution is to do a LOT more slotting. Maybe with the right automation slotting could be less painful to maintain. Of course, if you take that to the ultimate extreme you'd just have every package install each file with a hash in the filename and then have /usr/bin et all be a collection of symlinks. And before you know it you're running Plan9. :) Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thu, 13 Oct 2011 14:13:11 +0100 Ciaran McCreesh wrote: > On Thu, 13 Oct 2011 12:23:07 +0200 > Chí-Thanh Christopher Nguyễn wrote: > > So qutecom is not broken and needs not be removed as long as > > > Dependencies using <, <=, =, ~ or =* are broken, except in certain > special situations inside ||. So, in your opinion, if we have 'foo' and 'libfoo' which are strictly version-bound, we can't allow users to install older versions? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 2011-10-12 at 00:40 -0400, Walter Dnes wrote: > Hi all > > Recently, there was a firestorm on the gentoo-user list over the idea > that udev would eventually require /usr to be on the same physical > parition as /, or else use initramfs, which is its own can of worms. I'm > not a programmer, let alone a developer. Rather than merely ranting, I > went and searched for an alternative. You completely misunderstand what Kay wants, what we are saying that is that you need to mount /usr at the same time as you mount /, which you can still do in your initramfs, etc. That said, we, the GNOME upstream, think that having a separate /usr is a completely stupid idea. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: > On Wed, 12 Oct 2011 23:00:23 +0530 > Nirbheek Chauhan 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. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: Most of the net-zope category and related packages
Per previous discussion, Arfrever will be maintaining these packages outside of the main tree. This entry was committed just under a month ago, but it seems the announcement was not sent at that time. # Mike Gilbert (15 Sep 2011) # Arfrever Frehtes Taifersar Arahesis (15 Sep 2011) # Zope Toolkit, Zope and other Zope-related packages are now maintained in # Progress Overlay. Use 'layman -a progress' to install Progress Overlay. # See http://www.gentoo.org/proj/en/overlays/userguide.xml for more information. # These packages will be removed from the main tree on 2012-03-01. app-admin/zope-config app-admin/zprod-manager dev-python/manuel dev-python/martian dev-python/restrictedpython net-zope/abracadabraobject net-zope/accesscontrol net-zope/acquisition net-zope/annotations net-zope/archetypes net-zope/atcontenttypes net-zope/btreefolder2 net-zope/cmf net-zope/cmfactionicons net-zope/cmfboard net-zope/cmfcollectorng net-zope/cmfformcontroller net-zope/cmfforum net-zope/cmfmember net-zope/cmfoodocument net-zope/cmfopenflow net-zope/cmfphoto net-zope/cmfphotoalbum net-zope/cmfquickinstallertool net-zope/coreblog net-zope/coreblog2 net-zope/cvsfile net-zope/datetime net-zope/documenttemplate net-zope/epoz net-zope/extensionclass net-zope/externaleditor net-zope/externalfile net-zope/externalmethod net-zope/externalstorage net-zope/extfile net-zope/exuserfolder net-zope/filesystemsite net-zope/five-formlib net-zope/five-grok net-zope/five-intid net-zope/five-localsitemanager net-zope/fle3 net-zope/formulator net-zope/generator net-zope/genericuserfolder net-zope/grokcore-annotation net-zope/grokcore-component net-zope/grokcore-formlib net-zope/grokcore-security net-zope/grokcore-site net-zope/grokcore-view net-zope/grokcore-viewlet net-zope/groups net-zope/groupuserfolder net-zope/i18ndude net-zope/indexedcatalog net-zope/infrae-rest net-zope/initgroups net-zope/issuetrackerproduct net-zope/kupu net-zope/ldapuserfolder net-zope/localfs net-zope/localizer net-zope/mailhost net-zope/mimetools net-zope/mimetypesregistry net-zope/missing net-zope/mpoll net-zope/multimapping net-zope/mymediamanager net-zope/namespaces net-zope/neoboard net-zope/neoportallibrary net-zope/ofsp net-zope/parsedxml net-zope/passwordresettool net-zope/persistence net-zope/photo net-zope/placelesstranslationservice net-zope/placelesstranslationservice-fork net-zope/plone net-zope/plone4artistssite net-zope/plonecollectorng net-zope/ploneerrorreporting net-zope/plonepopoll net-zope/plonetranslations net-zope/portaltransforms net-zope/propertyfolder net-zope/propertyobject net-zope/proxyindex net-zope/pythonscripts net-zope/record net-zope/silva net-zope/silvadocument net-zope/silvametadata net-zope/silvaviews net-zope/simpleuserfolder net-zope/speedpack net-zope/sprout net-zope/squishdot net-zope/standardcachemanagers net-zope/tempstorage net-zope/threadlock net-zope/tinytableplus net-zope/transaction net-zope/translationservice net-zope/ttwtype net-zope/validation net-zope/xmlwidgets net-zope/xron net-zope/z3c-recipe-scripts net-zope/zaaplugins net-zope/zattachmentattribute net-zope/zc-lockfile net-zope/zc-recipe-egg net-zope/zc-recipe-testrunner net-zope/zcatalog net-zope/zconfig net-zope/zctextindex net-zope/zdaemon net-zope/zexceptions net-zope/zfspath net-zope/zlog net-zope/zmysqlda net-zope/zodb signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Samuli Suominen schrieb: > you're right. sorry. that came out too harsh. lets rephrase this as: No offense taken :) > "This /topic should be in the end-quiz, and mentioned in the mentoring > guide to cover basis as part of the KEYWORDS visibility handling." This is something that I have been asking for all the time. If you think that what qutecom did should be illegal in Gentoo, then disallow it in policy or code. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Ciaran McCreesh schrieb: > On Thu, 13 Oct 2011 12:23:07 +0200 > Chí-Thanh Christopher Nguyễn wrote: >> So qutecom is not broken and needs not be removed as long as >> Dependencies using <, <=, =, ~ or =* are broken, except in certain > special situations inside ||. I don't find that documented anywhere. Besides, a number of packages use = and ~ not inside ||. Are they all broken? How do you suggest to address this? Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Suggestion for getting rid of udev
On 09:09 Wed 12 Oct 2011, Walter Dnes wrote: > > Goodbye desktop users then. > > > > We recently dropped HAL. Now all the magic that was done by HAL (and > > required udev anyway) is done through udev directly. > > My system worked just fine before HAL was introduced, thank you. I > always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask > and my system continued to work just fine, thank you. Given the great > HAL fiasco, the fact that HAL has been incorporated into udev is yet one > more reason for dropping udev . https://www.xkcd.com/963/ -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
On Thu, 13 Oct 2011 12:23:07 +0200 Chí-Thanh Christopher Nguyễn wrote: > So qutecom is not broken and needs not be removed as long as > signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
Mike Frysinger schrieb: >>> by splitting my reply, you changed the meaning. having qutecom in the >>> tree with a depend on versions that i'm now removing breaks the >>> depgraph. >> The depgraph is broken after the old versions are removed, not before. > which is what i said So qutecom is not broken and needs not be removed as long as
[gentoo-dev] bugs-web[34].gentoo.org launched
Hi all,
Webnodes #3 and #4 have been launched for Bugzilla.
They'll ultimately replace nodes #1 and #2, but meanwhile all 4 nodes
are running. The new DB nodes aren't 100% ready yet.
If you to specifically reach a node instead of the load balancer:
https://bugs-web{1,2,3,4}.gentoo.org/
(and accept the SSL warning)
If you see weirdness and the frontpage shows that you are on node 3/4,
please ping us on IRC in #gentoo-infra, or email infra@.
--
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
[gentoo-dev] Re: Build dependencies and upgrades.
Mike Frysinger posted on Thu, 13 Oct 2011 00:39:52 -0400 as excerpted: > i thought there was talk of an automatic @security set at some point, > but not sure if that got anywhere. Sets (other than @system and @world) aren't available in stable portage yet. Are they even in ~arch? I've been running the masked 2.2 in ordered to have sets for so long it's beginning to feel like openrc all over again, except now it's not even in ~arch, AFAIK. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
