[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
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 linux-headers-2.6.38 is in the tree. Of course any package breaks when you remove its dependencies. 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
On Thu, 13 Oct 2011 12:23:07 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: So qutecom is not broken and needs not be removed as long as linux-headers-2.6.38 is in the tree. Dependencies using , =, =, ~ or =* are broken, except in certain special situations inside ||. -- 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
Ciaran McCreesh schrieb: On Thu, 13 Oct 2011 12:23:07 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: So qutecom is not broken and needs not be removed as long as linux-headers-2.6.38 is in the tree. 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
[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 flop...@gentoo.org (15 Sep 2011) # Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com (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 net-zope/zope-2.12.19 =net-zope/zope-2.13.6* =net-zope/zope-2.13.7* =net-zope/zope-3* net-zope/zope-annotation net-zope/zope-app-applicationcontrol net-zope/zope-app-appsetup net-zope/zope-app-basicskin net-zope/zope-app-container net-zope/zope-app-debug net-zope/zope-app-dependable net-zope/zope-app-form net-zope/zope-app-intid net-zope/zope-app-locales net-zope/zope-app-pagetemplate net-zope/zope-app-publication net-zope/zope-app-publisher net-zope/zope-app-schema net-zope/zope-app-testing net-zope/zope-applicationcontrol net-zope/zope-authentication net-zope/zope-broken net-zope/zope-browser net-zope/zope-browsermenu net-zope/zope-browserpage net-zope/zope-browserresource net-zope/zope-cachedescriptors net-zope/zope-component net-zope/zope-componentvocabulary net-zope/zope-configuration net-zope/zope-container net-zope/zope-contentprovider net-zope/zope-contenttype net-zope/zope-copy net-zope/zope-copypastemove net-zope/zope-datetime net-zope/zope-deferredimport net-zope/zope-deprecation net-zope/zope-dottedname net-zope/zope-dublincore net-zope/zope-error net-zope/zope-event net-zope/zope-exceptions net-zope/zope-filerepresentation net-zope/zope-formlib net-zope/zope-hookable net-zope/zope-i18n net-zope/zope-i18nmessageid net-zope/zope-intid net-zope/zope-keyreference net-zope/zope-lifecycleevent net-zope/zope-location net-zope/zope-login net-zope/zope-minmax net-zope/zope-mkzeoinstance net-zope/zope-pagetemplate net-zope/zope-password net-zope/zope-processlifetime net-zope/zope-proxy net-zope/zope-ptresource net-zope/zope-publisher net-zope/zope-schema net-zope/zope-security
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 nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. -- 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 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] 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 ciaran.mccre...@googlemail.com wrote: On Thu, 13 Oct 2011 12:23:07 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: So qutecom is not broken and needs not be removed as long as linux-headers-2.6.38 is in the tree. 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] 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 mgo...@gentoo.org 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] Suggestion for getting rid of udev
2011/10/13 Olivier Crête tes...@gentoo.org: 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] 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
On 13 October 2011 20:58, Rich Freeman ri...@gentoo.org wrote: 2011/10/13 Olivier Crête tes...@gentoo.org: 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 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 Thu, 13 Oct 2011 11:14:31 -0400 Olivier Crête tes...@gentoo.org wrote: On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. The problem with a platform that just works is that when it doesn't work, no-one knows how to fix it. That's what's happened here: the deep integration doesn't work in the common case that /usr is on its own filesystem, but because of all the excessive coupling you're unable to fix it and so are trying to pass the blame elsewhere. The first step in fixing it is to decouple all of the horrible mess that has been making its way into the base system over the past couple of years. -- 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 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] 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 ssuomi...@gentoo.org 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 Thu, 13 Oct 2011 13:52:37 -0400 Rich Freeman ri...@gentoo.org 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
Am 13.10.2011 15:13, schrieb Ciaran McCreesh: On Thu, 13 Oct 2011 12:23:07 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: So qutecom is not broken and needs not be removed as long as linux-headers-2.6.38 is in the tree. 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] 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] Suggestion for getting rid of udev
On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger vap...@gentoo.org 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 Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés can...@gmail.com wrote: On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger vap...@gentoo.org 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 kay.siev...@vrfy.org 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 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] 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] 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 linux-headers-… dependencies violate policy, then I would like to read the authoritative document which describes that policy. If downgrading linux-headers breaks systems, then I would like to hear about incidents where this actually happened. My Google-fu is apparently too weak to find these. If the policy is not clear on the matter then removal against maintainer's consent is not justified. If the breakage is only hypothetical then not even a p.mask is justified IMO (though I understand that QA can mask packages at their discretion without needing any reason). Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] rfc: news item for png15
small news item for stable users. lets keep it simple...
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.
Then you can proceed with rebuilding rest of the software against the new
library:
# revdep-rebuild --library libpng14.so.14
In case of failure, try skipping the failing package and rebuilding it
later in the process.
If you find packages not building with message ld: cannot find -lpng14,
they are likely caused by broken libtool archives (.la) in your system.
You can identify those files with following one-liner:
# find /usr/ -name '*.la' -exec grep png14 {} +
More information and help is available at following forums post:
http://forums.gentoo.org/viewtopic-t-894950.html
[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.
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.
Re: [gentoo-dev] new helper: econf_build
On Thu, Oct 13, 2011 at 4:48 PM, Mike Frysinger vap...@gentoo.org 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] 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.
[gentoo-dev] Re: rfc: news item for png15
On Fri, 14 Oct 2011 01:01:50 +0300
Samuli Suominen ssuomi...@gentoo.org wrote:
Title: Upgrade to libpng15
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2011-10-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-libs/libpng-1.5
After upgrading from libpng14 to libpng15 it's important that you rebuild
cairo and gdk-pixbuf soon as possible if they are installed.
^ as
Then you can proceed with rebuilding rest of the software against the new
^ the
library:
# revdep-rebuild --library libpng14.so.14
In case of failure, try skipping the failing package and rebuilding it
later in the process.
How?
If you find packages not building with message ld: cannot find -lpng14,
^ the
they are likely caused by broken libtool archives (.la) in your system.
You can identify those files with following one-liner:
# find /usr/ -name '*.la' -exec grep png14 {} +
More information and help is available at following forums post:
^ the ^-s?
http://forums.gentoo.org/viewtopic-t-894950.html
--
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 ssuomi...@gentoo.org wrote:
Title: Upgrade to libpng15
Author: Samuli Suominen ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2011-10-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-libs/libpng-1.5
After upgrading from libpng14 to libpng15 it's important that you rebuild
cairo and gdk-pixbuf soon as possible if they are installed.
^ as
Then you can proceed with rebuilding rest of the software against the new
^ the
library:
# revdep-rebuild --library libpng14.so.14
In case of failure, try skipping the failing package and rebuilding it
later in the process.
How?
If you find packages not building with message ld: cannot find -lpng14,
^ the
they are likely caused by broken libtool archives (.la) in your system.
You can identify those files with following one-liner:
# find /usr/ -name '*.la' -exec grep png14 {} +
More information and help is available at following forums post:
^ the ^-s?
http://forums.gentoo.org/viewtopic-t-894950.html
--
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: 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 ;-)
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.
Re: [gentoo-dev] rfc: news item for png15
On Fri, 14 Oct 2011 04:30:56 +0400
Peter Volkov p...@gentoo.org 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
