Re: [gentoo-dev] keepdir /var/run/package/?
On 8/12/10 11:29 AM, Eray Aslan wrote: It is perfectly legal to clear /var/run across reboots. Below is a bug from a user that ran into some trouble because an init script assumes that /var/run/package/ exists for its PID file: Can we add a repoman check for that? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-emacs/google-c-style: metadata.xml ChangeLog google-c-style-20091009.ebuild
On 8/10/10 11:09 PM, Christian Faulhammer wrote:
PaweA Hajdan (phajdan.jr) phajdan...@gentoo.org:
pkg_postinst() {
einfo Example usage (.emacs):
einfo (require 'google-c-style)
einfo (add-hook 'c-mode-common-hook 'google-set-c-style)
einfo (add-hook 'c-mode-common-hook
'google-make-newline-indent) }
You did not receive my mail regarding the autoload stuff when you
asked for Emacs support?
I did, but I was not familiar enough with Emacs to know that I can add
the autoload support so easily.
Fortunately, Ulrich Mueller (ulm) has done it on the same day I added
the ebuild to the tree. Thanks Ulrich!
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Cleanup of the Get Gentoo page
On 8/8/10 6:22 PM, Paweł Hajdan, Jr. wrote: I'd like to suggest a cleanup of our Get Gentoo page. It is one of the more important pages, because every new user has to visit it. http://dev.gentoo.org/~phajdan.jr/where.xml Okay, let's get some decisions on it. Joshua Saddler raised some concerns, and I asked what essential information is missing from my suggested page that is on the current page. In my opinion everything that should be there is still there, and I only changed the order of things. Roy Bamford suggested we post more information about CPU families for each arch to make the right choice easier. I think we can do that in another cleanup pass (let's fix one issue at a time), and it would be nice to get a more detailed suggestion (there are just so many x86 cpu families). Sebastian Pipping and Markos Chandras liked the new page. So, how do we proceed? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Chromium in Gentoo project looking for developers
If you are a Gentoo developer and are using www-client/chromium, please consider joining the Chromium in Gentoo project: http://www.gentoo.org/proj/en/desktop/chromium/index.xml You don't need to modify or bump packages to join. In fact, I'm rather looking for good testers. We have some bugs to confirm, workarounds and fixes to verify, etc. All bug links are at the project page. My plan is to make our Chromium packages even better. I'm working on solid chromium-bin package now (built on Gentoo), and on separating v8 to its own package. All this work takes time and effort, so I'm looking for more people to help. Hopefully in the near future www-client/chromium will use even more system libraries (I'm working on icu and sqlite). This will require even more testing on Gentoo side, because using system libraries is a scenario that upstream's QA _never_ tests. Non-developers can contribute as well, we have a section about Herd Testers on the project page. There are already some people doing great work on that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Cleanup of the Get Gentoo page
On 8/16/10 5:29 PM, David Abbott wrote: I can but just want to make sure this is what everyone wants; http://dev.gentoo.org/~dabbott/pr/where.xml I got that from http://dev.gentoo.org/~phajdan.jr/where.xml Looks fine to me I am ready to commit, just say so and its done. Looks good to me. Thanks! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] use_echo() as a universal '?:' operator-like function
On 9/8/10 12:03 PM, Michał Górny wrote: We already have a variety of use_*() functions with their specific uses. But what I miss is a single, simple and universal use_echo() function, behaving similarly to ?: operator in C. In other words, a simple function replacing monsters like: $(use foo echo bar || echo baz) I'm not sure about the name use_echo, but some form of ternary operator other than || (which is very hard to read for me and just error prone) would be very useful. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug-wranglers queue is large
On 9/10/10 4:18 AM, Markos Chandras wrote: I plan to create a patch for this[1] page and poke devrel for that [1]: http://www.gentoo.org/proj/en/devrel/staffing-needs/ Actually, you just need to add some tags to your project page and the Staffing Needs page gets automatically updated after few minutes. Example: recruitment job summaryHerd Tester/summary details Chromium in Gentoo project needs more people testing packages. We are not always able to reproduce reported issues, and having more people respond to testing requests would be useful. No quiz is necessary to start. /details requirements If you are running www-client/chromium or chromium-bin, and are willing to spend some time helping Gentoo, feel free to apply. /requirements contactal...@g.o/contact /job /recruitment signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: use_echo() as a universal '?:' operator-like function
On 9/11/10 11:03 AM, Jonathan Callen wrote:
Just as a proof-of-concept, here's one implementation of such a
function, allowing for an arbitrary number of arguments:
use_echo() {
while [[ $# -gt 1 ]]; do
if use $1; then
echo $2
return
fi
shift 2
done
[[ $# -eq 1 ]] echo $1
}
Looks good to me. If it doesn't get included in any eclass, I will just
paste it to the chromium ebuilds. :)
Paweł
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Closing bugs
On 9/11/10 11:51 AM, justin wrote: is the following comment an adequate way to close bugs with RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too. virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS=amd64 you mix stable unstable - your problem I think that closing as INVALID is fine in that case, but would say please do not mix stable and unstable instead of your problem. We should be polite when handling bugs. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 9/19/10 9:14 PM, Matti Bickel wrote: So, yeah, what do you think? Is it worth it? I second this GLEP. It seems like it will cleanly replace our hacked eblits implementations from packages like php, glibc, and possibly more. Also, it will allow more code sharing between ebuilds, which is good. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: per package eclass GLEP
On 9/20/10 7:30 PM, Alec Warner wrote: How does it provide more code sharing than the existing system? Previously I could put code I wanted shared: 1) In a global eclass, which means any ebuild in the tree can likely use it A global eclass is quite heavyweight. It requires a review on gentoo-dev, is difficult to deprecate, and so on. That's discouraging if you only want to share 2-3 simple functions used by only one package. 2) In a pkg eblit Which is hacky. Wouldn't taking code from a global eclass and moving it to a per-package eclass limit code re-use? No. It lowers the barrier to entry in cases where the shared code is only useful for one package. It can always be promoted to a global eclass later (with a proven API). Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] suspicious code snipped in gcc-4.5* ebuilds
I was just looking at some random ebuilds recently, and noticed this snippet in gcc-4.5* ebuilds: SSP_STABLE=amd64 x86 ppc ppc64 arm # uclibc need tls and nptl support for SSP support SSP_UCLIBC_STABLE= Please note how the #-starting comment is inside the SSP_STABLE variable declaration. It looks very obvious when seen in a syntax-coloring editor. I'm not sure if it breaks, as uclibc, need, tls etc. are not valid arch names, but it's still probably not intended. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: make system-sqlite a global USE flag
$ euse --info system-sqlite global use flags (searching: system-sqlite) no matching entries found local use flags (searching: system-sqlite) [-] system-sqlite (mail-client/thunderbird): Use the system-wide dev-db/sqlite installation with secure-delete enabled [-] system-sqlite (net-libs/xulrunner): Use the system-wide dev-db/sqlite installation with secure-delete enabled [-] system-sqlite (www-client/chromium): Use the system-wide dev-db/sqlite installation with secure-delete enabled [-] system-sqlite (www-client/firefox): Use the system-wide dev-db/sqlite installation with secure-delete enabled [-] system-sqlite (www-client/icecat): Use the system-wide dev-db/sqlite installation with secure-delete enabled [-] system-sqlite (www-client/seamonkey): Use the system-wide dev-db/sqlite installation with secure-delete enabled [-] system-sqlite (x11-plugins/enigmail): Use the system-wide dev-db/sqlite installation with secure-delete enabled The meaning is identical in all those cases, and I think the number of packages may have hit the threshold for a global flag. However, we already have a very similar global USE flag: sqlite, which makes this a bit more tricky. The difference is very subtle: IUSE=sqlite means the sqlite support is optional; -sqlite means no sqlite support IUSE=system-sqlite means we can use the bundled sqlite or the system one; -system-sqlite means we use the bundled one; both settings result in sqlite support If we'd make system-sqlite a global USE flag, I'd suggest a description like Use the system-wide dev-db/sqlite instead of bundled copy of sqlite. What do you think? signature.asc Description: OpenPGP digital signature
[gentoo-dev] libstdc++ compatibility and -bin packages
Today I got http://bugs.gentoo.org/340517 filed against chromium-bin. The machine that compiled the package had only gcc-4.4.3 installed. It'd probably be difficult to solve the problem using dependencies (the bug reporter had gcc-4.4.3 installed, but active version was 4.3.4). I was thinking about using a lower version of gcc on the builder, like 4.1.2 or 4.3.4. However, I'm not sure how likely this is to cause C++ ABI mismatch issues. I remember some problems with half of KDE compiler with one GCC version and half with a more recent version. What do you think? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/mpfc/files: mpfc-1.3.7-INT_MAX.patch
On 10/28/10 7:42 PM, Mike Frysinger wrote: Il giorno lun, 25/10/2010 alle 18.50 -0300, Alexis Ballier ha scritto: Am I missing something obvious or is it just hiding a bug in the linux headers? I see no usage of INT_MAX in the patched .c file... the maintainer already has done his due diligence and reviewed the field. at this point, it is *you* who disagrees with the situation thus it is *you* who needs to resolve *your* complaint. Just curious: what are the technical reasons for that? My understanding is that one header depends on another for proper compilation but doesn't #include it. Is that correct? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: dev-lang/v8 SONAME
On 10/27/10 1:05 PM, Diego Elio Pettenò wrote: Il giorno mer, 27/10/2010 alle 12.49 +0200, Paweł Hajdan, Jr. ha scritto: Some context first. Upstream does not promise any binary compatibility between releases, so each version has a different SONAME, if any. That's a good approach (although a bothersome for its users).. By the way, what do you think about http://ispras.linux-foundation.org/index.php/ABI_compliance_checker ? Currently dev-lang/v8 does not use SONAME (I think that's the default), because I'm not sure what's the best way to handle it. That's bad, it _has_ to have a SONAME, otherwise you're indicating that al the versions have the same ABI (which as you just said is not the case). That's one of the reasons it's still hard masked. Okay now you're confusing the two concepts. The DT_SONAME tag has nothing to do with the name on the filesystem for what concerns the link editor, it's used by the dynamic loader. The link above would be fine though, just let it link as libv8.so, and then be loaded as libv8-1.2.3.so. Ah, thanks! I think I understand it much better now. Bumped v8, now with SONAME and a symlink. I was able to compile www-client/chromium against that, and added an experimental system-v8 USE flag to it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dev-lang/v8 SONAME
On 10/27/10 8:59 PM, James Rowe wrote: * Paweł Hajdan, Jr. (phajdan...@gentoo.org) wrote: There is one issue that keeps dev-lang/v8 in hard mask and prevents its broader usage (I think www-client/chromium could start using it). Thanks for working on this. I use v8 quite a bit, and being able to simply depend on the ebuilds would make life easier. You're welcome! I started the work because people asked for it. I'm curious: do you have some more ebuilds using v8? It'd be great to add them to the portage tree at some point, if possible. Or maybe sunrise overlay... One question: Are the v8 ebuilds going to be switched to use some kind of snapshot tarballs before they're unmasked? Yes, I think it's going to stay hard masked until I resolve issues like this. subversion shouldn't be required to install v8. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changes in server profiles
On 10/29/10 1:03 PM, Markos Chandras wrote: 1) I want to drop the warning message located on profile.bashrc files e.g $PORTDIR/default/linux/amd64/10.0/server/profile.bashrc It is more than obvious what this profile is for so I don't think this message makes any sense. ewarn This profile has not been tested thoroughly and is not considered to be ewarn a supported server profile at this time. For a supported server The above is definitely not obvious. Is this documented in any other place? ewarn the software being used on the server. This profile should also be used ewarn if you require GCC 4.1 or Glibc 2.4 support. If you don't know if this That too. By the way, I think there was some way to mark a profile as development, unsupported, or something like that. 2) Furthermore I would like to drop the following use flags from default IUSE -apache2 -ldap A minimal server installation does requires neither apache2 nor ldap Sounds good (I'm not using a server profile though). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changes in server profiles
On 10/29/10 1:24 PM, Markos Chandras wrote: On Fri, Oct 29, 2010 at 01:18:14PM +0200, Paweł Hajdan, Jr. wrote: ewarn This profile has not been tested thoroughly and is not considered to be ewarn a supported server profile at this time. For a supported server If the above is no longer true you can safely ignore my earlier comments. :-D Actually, removing the no-longer-true message sounds good. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Changes in server profiles
On 10/29/10 6:29 PM, Markos Chandras wrote: Furthermore the message about glibc-2.4 and gcc-4.1 looks rather obsolete. At least this part has to be removed/changed Fine for me. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category for Lua related packages
On 11/2/10 4:24 AM, Rafael Goncalves Martins wrote: I think that a first step should be create a new category, maybe called dev-lua, for all the Lua related stuff. Just checking: how many packages would be in the new category? Generally sounds good. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: metadata.xml ChangeLog quassel-9999.ebuild quassel-0.7.1.ebuild
On 11/4/10 6:40 PM, Mark Loeser wrote: Please do remove the flag. The fact that there are some ebuilds in the tree that use it does not make it alright to introduce more. Yeah, the he's doing that too bad excuse... But there is a right point in that: why QA doesn't just commit fixes to the ebuilds that misuse the logrotate flag? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please move your packages to virtual/jpeg
On 11/7/10 8:51 PM, Jory A. Pratt wrote: As some of you are aware libjpeg-turbo is in the tree, with v8 support. We will not keyword for any archs until we officially add the 1.1 release that is not avaliable as of yet. If we all use virtual/jpeg we can ensure that the user has the right to determine what version of jpeg they wish to use. Is media-libs/jpeg binary compatible with media-libs/libjpeg-turbo? I'm not sure what to do with chromium-bin, which is compiled on a Gentoo system. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 150 bugs at bug-wranglers@
On 11/10/10 4:10 PM, Markos Chandras wrote: Ping. 130 bugs again If there are no objections, I will update the staffing needs page with info that we need more bug wranglers. I think we have clear indication there are not enough people wrangling bugs, and we should just recruit them. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: Dropping Java support on ia64
On 11/14/10 8:36 PM, Petteri Räty wrote: The IA64 arch team does not have the resources to maintain Java support so we agreed that support will be dropped unless more man power becomes available. Could you also add the info to http://www.gentoo.org/proj/en/devrel/staffing-needs/ ? Moreover, what does dropping support mean? Are there any packages that are not obviously java-related (i.e. not in dev-java), but will have dropped support? If you are willing to help maintaining support please contact i...@gentoo.org. If there is no interest the removal of Java support well be done during week 50 of year 2010. IMHO a date range would be more readable than a week number. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Restabilizing MIPS
On 11/15/10 11:20 AM, Christian Faulhammer wrote: * reducing your keyword set (stable-wise) to a relative small subset and rethink your normal testing keywords. I think there is a related point here: when you start with a minimal stable set, it's easy to extend that set later. However, if you attempt to have a (relatively) large stable set, and it turns out later you're not able to maintain it, the situation is much worse because you'd probably have to force downgrades, drop stable keywords, etc. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] 150 bugs at bug-wranglers@
On 11/15/10 8:19 AM, Paweł Hajdan, Jr. wrote: On 11/10/10 4:16 PM, Markos Chandras wrote: On Wed, Nov 10, 2010 at 04:14:28PM +0100, Paweł Hajdan, Jr. wrote: If there are no objections, I will update the staffing needs page with info that we need more bug wranglers. Please do. Thanks I have just committed the patch below. Of course feel free to make further adjustments to it. Hopefully you will get some more volunteers. Good luck! Here's the diff I'm going to apply: Index: index.xml === RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/qa/bug-wranglers/index.xml,v retrieving revision 1.18 diff -u -B -r1.18 index.xml --- index.xml 26 Oct 2010 18:46:09 - 1.18 +++ index.xml 15 Nov 2010 07:17:57 - @@ -45,6 +45,21 @@ /p /goals +recruitment +job +summaryBug Wrangler/summary +details +Gentoo needs more people handling new bugs (i.e. assigning them +to the right people, making sure the reporter has submitted enough info, +etc.) +/details +requirements +Good understanding of Gentoo and Bugzilla, always respecting the users. +/requirements +contactjer/contact +/job +/recruitment + dev role=Leadjer/dev dev role=Memberjlec/dev dev role=MemberPolynomial-C/dev signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dev-lang/v8 SONAME
On 10/29/10 11:33 AM, James Rowe wrote: * Paweł Hajdan, Jr. (phajdan...@gentoo.org) wrote: I'm curious: do you have some more ebuilds using v8? It'd be great to add them to the portage tree at some point, if possible. Or maybe sunrise overlay... We took the easy way out and chose Debian because v8/nodejs were packaged when we needed them, but we'd prefer to be using Gentoo. That is the reason I jumped straight in when I saw the mail subject. FYI, dev-lang/v8 is now in ~arch. If you'd like some additional packages in portage like nodejs, please file bugs. Feel free to CC me. Also, let me know if the v8 support in Gentoo can be somehow improved, even if you're not using it yet. I'd like to get feedback from people who are using it for other applications than www-client/chromium. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change policy about live ebuilds
On 11/25/10 2:59 PM, Alexis Ballier wrote: I fail to understand why you claim that live ebuilds are a QA nightmare, you may want to have a look at how I play with, eg, ffmpeg or vlc and their live ebuilds: they make version bumps much easier and far less error prone. I'm just curious. Could you explain more how the live ebuilds make version bumps easier and less error prone? My experience with chromium- ebuild is different. Indeed users do test it and report very useful early warning bugs, but when I actually do a version bump I also have to modify the live ebuild, and that modification is usually untested. Furthermore, when one of local Gentoo patches lands upstream, the live ebuild has to be modified again. If there are some tips/techniques that work for you and make live ebuilds more helpful, I'd like to learn a bit more. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Change policy about live ebuilds
On 11/25/10 4:07 PM, Alexis Ballier wrote: By following closely upstream development you are able to adapt the live ebuild to the current status, eg, for new deps. Usually with vlc, when a new major version comes out, there are a couple of new features and a couple of outdated features removed, doing all these changes at once is more error prone than doing it once you notice the change for each of them in the live ebuild. As for version bumps, the live ebuild is simply copied to an ebuild with a name matching the version that has just been released. Ah, I see. It makes sense. In the case of www-client/chromium, we have weekly dev channel releases, which go through Google's QA etc, and it's useful for me to work based on those and not the trunk for packaging. Everything else seems to work very similarly for me. What kind of modification do you need to do? The only cases I had to change anything is when the live ebuild was out of sync. I do adjustments for dev channel releases, and when I need to do them, the live ebuild usually is out of sync, so I forward-port the fixes to the live ebuild. In case of a responsive upstream, like vlc or ffmpeg here, you can apply the policy of backports only for patches and have absolutely zero patches for the live version. Right, Chromium is actually very responsive and I'm also a Chromium committer, so upstreaming patches is usually easy. However, my patches related to using system libraries instead of bundled copies are often controversial, so getting them through code review takes some time. Most of the time when I'm making local patches, they fix _regressions_ in the system library support, i.e. we were using a system library, but an upstream change broke it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 12:45 PM, Sebastian Pipping wrote: Sorry to hear. Please put a line like USE_PYTHON=2.6 2.7 3.1 into /etc/make.conf. It sounded like that's the versions you want. Is that documented anywhere? I couldn't find it easily on gentoo.org in the docs. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2.7 status check?
On 11/29/10 1:42 PM, Markos Chandras wrote: *sigh*, Planet is not a place to inform users about these things. How about a -dev-announce or even better a news item. IMHO a news item is not much better. All users who install later than some date will not see the news item (by design). USE_PYTHON seems to be an important /etc/make.conf setting that is not documented. I think it should be added somewhere under http://www.gentoo.org/doc/en/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On 12/1/10 9:13 PM, Alec Warner wrote: How does a developer know when the stage generation is broken? Is there a dashboard? At work we have a guy who is basically a build cop and checks our build dashboard once a day or so and if it is broken he goes and finds the guy who broke it and punches him in the face until he fixes it. I imagine we do not have staff for this (and no one has invented punching over the internet.) It should be possible to create a public dashboard for the stage build process. Also, we have an automated warning about the bug queue size, we can have a similar warning about stage generation. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Disabling auto-bumping of active Python version
On 12/1/10 9:34 PM, Joshua Saddler wrote: Catalyst sends automated emails to rel...@gentoo.org from the various build boxes: dolphin, poseidon, other dev.g.o machines. So we have some automatic reporting. Can we have a webpage for that, or a mailing list that people can subscribe to? Idea: make python team receive those emails. ;-) I am curious how often stage builds fail (how long can they be broken until we actually care?) Fairly often, especially in the last couple of months or so. There were some arches that, last I checked, hadn't had any new media in several months. Do we have some bugs or other actions towards fixing those problems? I see messages like this pretty much every day. Releng is understaffed on a few arches, which is why no one has time to track down the errors, fix them, and get the builds completed. Is it possible to bisect the portage tree and identify a breaking commit? By the way, it would be great to have some kind of continuous integration for the portage tree, even something very basic, and visible to the public. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Boost maintenance
On 12/12/10 9:19 PM, Markos Chandras wrote: However, I do not have the hardware to perform any kind of build testing to this package because it requires a significant amount of resources during compilation phase. Note that Gentoo has some machines for development purposes, see http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml I'm using one of those for www-client/chromium development, and it's very helpful. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Boost maintenance
On 12/12/10 9:57 PM, Markos Chandras wrote: Can you please tell me which box ( I'd prefer an amd64 one ) are you using for chromium? If it is in a working state I will ask for access again! I'm using miranda. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [warning] the bug queue has 118 bugs
On 12/15/10 2:54 AM, Jeroen Roovers wrote: I am starting to wonder if this is helping. It looks like everyone now attempts to keep it 100 on a daily basis, but not to far 100, which means a lot of old, difficult, nasty bug reports are left unattended. Still, I got it down to about two dozen now. I was just wondering... did you get any e-mails from people who would like to become Bug Wranglers? The main problem seems that the team is understaffed, so we can't really fix the problem without recruiting more people. By the way, we have a nice team of arch and herd testers - how about encouraging them to wrangle some bugs? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What are || ( ) dependencies?
On 12/17/10 4:25 PM, Ciaran McCreesh wrote: As a result of things like this, Portage has had various different sets of heuristics over time, and Paludis has had a different set. Generally it seems fine to have different heuristics (I'll comment on the specific problem below). Paludis currently interprets this as I prefer 1.3.99.901, but will also accept =1.3.99.901. In particular, if 1.3.99.901[xcb] is already installed, libX11 won't be upgraded. Some Portage versions also do this, and others don't. I don't understand why we can't upgrade libX11 in that case. Shouldn't emerge -uDNa world (or its Paludis equivalent) think like this: Okay, I have libX11 installed here, and a more recent version is available. The more recent version satisfies this || () dependency, so just update it. There's one easy fix, which solves this and every other possible convoluted case (and some of those can be fairly horrible...): require ebuild developers to always list 'best' things leftmost. Sounds reasonable. The other option is that we mandate a particular selection algorithm for || ( ) dependencies. Doesn't that somehow contradict the idea that || () lists equivalent dependencies? Maybe we should fix the heuristics. In this specific case, it seems reasonable to still upgrade libX11, right? So would anyone be especially opposed to making best leftmost an explicit requirement, enforced by repoman where possible (at least for the = / case)? I don't think that = / case is enforceable by repoman (i.e. that we always prefer the more recent version of a package). However, saying that the preferred dependency should be listed first sounds reasonable. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecate EAPIs 0 and 1?
On 12/31/10 12:13 PM, Petteri Räty wrote: EAPI 0 might stick around for quite a while but for example deprecating EAPI 1 shouldn't be as hard. That seems also to be a safe first step. EAPI-1 ebuilds were at least written with EAPIs in mind. That's obviously not true for EAPI-0. We could even deprecate EAPI-2 in favor of EAPI-3, hmmm I think a repoman non-fatal warning would be fine. If we have a warning about forcing -j1, we can surely have one about ancient EAPIs. Paweł Hajdan, Jr. P.S. I'm excited to see the progress with PMS and new EAPIs being more and more convenient and addressing frequent annoyances or deficiencies! signature.asc Description: OpenPGP digital signature
[gentoo-dev] mysterious change of system python to python3
I've noticed at least two forums threads that suggest there might be a bug resulting in automatic flip of system python to python3: http://forums.gentoo.org/viewtopic-t-859654-highlight-.html http://forums.gentoo.org/viewtopic-p-6541077.html Do you think it may be a bug, and if so, how can we debug it? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Blockers and package moves
On 1/16/11 2:49 PM, Ciaran McCreesh wrote: Second, when performing updates, Paludis also rewrites dependencies of installed packages to use the names. This seems to imply that portage behaves differently. Should we update PMS when we determine what's the correct behavior? signature.asc Description: OpenPGP digital signature
[gentoo-dev] bugzilla cleanup: remove SECURITY keyword?
I've noticed we have a SECURITY keyword on bugs.gentoo.org, but only 79 bugs have it, and doesn't seem to be actively used, so it seems to only add confusion. What do you think about removing it? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bugzilla cleanup: remove SECURITY keyword?
On 1/17/11 6:00 PM, Christian Ruppert wrote: All 79 bugs would need a fix then. We can't remove used keywords/groups and so on. Only two bugs with SECURITY keywords are still open: https://bugs.gentoo.org/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=SECURITYbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= Does anyone still use the SECURITY keyword? It doesn't seem to be a part of Security or Infrastructure teams' documented practices. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: bugzilla cleanup: remove SECURITY keyword?
On 1/18/11 2:45 PM, Torsten Veller wrote: What sort of confusion does SECURITY add? I started thinking about it when https://bugs.gentoo.org/351922 was filed (this is only an example). The SECURITY keyword is not applied consistently (~80 bugs total), but the description says Add this on all security related issues. Do other keywords[1] like Bug add confusion too? Yes, the same way. Is it worthwhile to remove the SECURITY keyword from 79 bugs... ...if you consider that (if everyone gets keyword-changes bugzilla mails, it's an Email Preference[2] configurable in bugzilla) 79 mails are sent to 11 + 63 + other CC'ed recipients? I wonder how many e-mails would be sent if we used the Change several bugs at once Bugzilla feature. My guess is just one e-mail. ...if the keyword modification mails weren't sent but one of our infra members had to spend time on this? Oh, I guess infra would reject spending time on this (low benefit to effort ratio indeed). Maybe we can just update description of obsolete KEYWORDS with something like *** DEPRECATED *** don't use for new bugs. That should be easy and address most of my original point. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: check for enewuser, enewgroup outside of pkg_setup
There was a discussion on irc about a package that called enewuser and enewgroup from pkg_preinst. That made it fail on fresh install, because the new user was needed at the src_install time (for ownership of the installed files). However, if the user was already present on the system, it was just a no-op, making the issue very hard to detect for the package's maintainer or anyone who had it previously installed. To avoid this type of problem in the future, I'd like to add the following check: If enewuser or enewgroup is called from outside of pkg_setup, fail Initially I was thinking about a repoman check, but in theory someone may extract code to a function called from pkg_setup, confusing the tool. An alternative solution would be to make enewuser and enewgroup check which ebuild phase called them, and fail if it's not pkg_setup (important: that must happen before the check for existing user/group). To make transition easy, we can make the error non-fatal for some time. What do you think? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] On hosting self-produced distfiles
On 1/20/11 1:50 AM, Diego Elio Pettenò wrote: If you produced the file yourself, and it doesn't matter if the file is reproducible (unless it is reproducible to sha512 identity), please use the public_html directory in your dev.gentoo.org home to host these. This makes sure that the file won't be deleted from all its sources if the ebuild is removed (or more likely replaced) from tree. Ask the Emacs team how easy has been to recover gentoo-syntax files before. Storing distfiles in public_html is not a perfect solution either. If the developer retires, what do we do with the files? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI usage in main tree
On 1/25/11 12:20 PM, Tomáš Chvátal wrote: I would like to upgrade tree-wide policy for EAPI usage in main tree. I have a great idea for you. How about creating a project (possibly a subproject of QA or something else) that would help people do that? In case of no response from maintainers just do your job, and that should get the tree converted more quickly than setting a policy. My main point is that said X should be Y does not automatically make it so. We'd have to think about the migration plan anyway. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Slacker arches
On 1/25/11 12:38 PM, Tomáš Chvátal wrote: Every arch teams should stabilise OR write out reason why they can't do so to stable bug in 90 days. If any arch team fails to do so the maintainer can decide to drop their keywords to testing. Given depgraph breakages the maintainer can coordinate with the QA team to drop all reverse dependencies to testing too. Seconded. Reality++ Be prepared for some issues though. Sometimes maintainers don't agree with reasons arch teams provide that block stabilizations. In those cases, who makes the decision? My suggestion is QA. Also, we should have someone to check for stale stabilization bugs. I'm not sure if all reporters are able to take care of that, especially if they have a lot of bugs open. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI usage in main tree
On 1/25/11 1:29 PM, Tomáš Chvátal wrote: Why would we need subproject for this. The idea was that if you want to introduce a new policy, you should also provide resources to make it possible. The below satisfies most of that. QA team itself is done to help developers with this tasks. So if someone come to #gentoo-qa and ask us to help him with his shiny eclass we won't sent him somewhere else where sun is not shining :P SGTM. One additional point is that there may be rarely bumped packages that won't be migrated naturally, but will need an update just for the EAPI bump, and the maintainers may just ignore this, so there should be someone actively monitoring the progress. And that apply even if developer itself is not maintainer and did not get reply from the maintainer... :) Yes, definitely. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Slacker arches
On 1/26/11 3:14 AM, Ryan Hill wrote: On Tue, 25 Jan 2011 12:38:03 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Won't this just pile on more work on already stressed to the max arch teams? As in, now they have to stabilize more packages to get back to where they were in the first place? This seems to be a self-balancing system to me. If the arch team is so stressed that it can't stabilize something within 90 days, and can't even state a reason for that, just move the package back to testing. After some time, the stable set for that arch should be small enough to let the arch team handle it on time. And as I understand it, the reason maintainers are complaining is because they want to drop old versions. I'm not sure why maintainers are complaining, but generally managing bugs that sit there for a long time is harder. Meaning stable users of these archs can suddenly lose large parts of the tree if this happens. From their point of view, we've just broken perfectly working systems. That's pretty much the opposite of what stable is supposed to promise. That's an important point. I think that a message should be sent somewhere (gentoo-dev-announce?) that something like that is going to happen, and wait some 60 days for someone to save the package. And I've never been an arch tester, but I bet after the first few times I tested a package only to have it dropped to ~arch because no developer was around to commit the keyword change, I wouldn't feel much like doing it anymore. Good point. How about the opposite? If everyone but $arch has stabilized the package, and you can't get a response from them in a reasonable time, then use your discretion as maintainer and mark it stable yourself. Very dangerous, especially for exotic arches. I think we should not go that way, or at least _require_ the maintainer to test on that arch. We have some development machines for various arches so it should be technically possible. But it generally seems to me that maintainers miss more problems than arch testers/developers. Arch testers would remain useful by giving the maintainer some measure of assurance that they won't accidently break anything for that arch. Good point, again provided the maintainer at least compile-tests the package on that arch. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)
On 1/28/11 10:11 PM, Tomáš Chvátal wrote: So draft we would like to have implemented as Glep update is this diff: http://dev.gentoo.org/~scarabeus/glep-0048.diff I'd suggest to split the diff, discussion and voting to make it more focused: 1) QA team lead, deputy, and accepting new members of the QA team 2) Revoking/reevaluating commit rights While I mostly agree with both suggested updates, 2) is obviously very controversial. It would be great to hear what QA team thinks about it, especially some rationale about the changes. Also, I think we don't have a too much QA problem in Gentoo. The opposite may be true (i.e. not enough QA). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Slacker arches
On 1/25/11 1:30 PM, Markos Chandras wrote: QA is not a solution to everything. The problem Tomas is trying to counter here is the idle/slacking arches. If the arch is active but have some concerns regarding the stabilization then let the maintainer deal with it. This is the way we do it now anyway Also, we should have someone to check for stale stabilization bugs. I'm not sure if all reporters are able to take care of that, especially if they have a lot of bugs open. Thats really their problem. Arches can always remove themselves from the bugs. No need to care about stale bugs. If the maintainers don't care then we(arches) don't care. I was mostly thinking about cases like https://bugs.gentoo.org/329633 where indeed arches remove themselves from the bug, but there is a dispute between them and the maintainer about the correct course of action. The usual conflict resolution procedure would be to contact the team lead, and eventually the council. However, I'm not sure whether that would be optimal for stabilization bugs. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] avoiding urgent stabilizations
From time to time there are stabilization bugs where the current stable is broken. For example, https://bugs.gentoo.org/show_bug.cgi?id=353487 However, in theory that should not happen, because presumably the current stable has been tested in the past and considered not broken. Of course that would be rather idealistic to assume such situation will never happen, but can we do something more to avoid detecting important problems in the stable tree too late? Are we missing something when stabilizing some important packages that later causes the breakages and need for urgent stabilizations? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] avoiding urgent stabilizations
On 2/7/11 9:50 PM, Markos Chandras wrote: My suggestion, as I said to fosdem, is to freeze, or take a snapshot if you like, of the current tree, stabilize what you need to stabilize, test the whole tree ( at least compile wise ) for a couple of weeks and then replace the existing stable tree. Of course this requires automated script testing, hardware facilities etc etc that we don't have so claiming that stable tree is stable is quite wrong. This more thorough testing sounds really interesting. But do we really lack hardware resources? There are machines available for various arches at http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml. I have at least a few chromium-related chroots on miranda, and I've never heard complaints, so it seems a few more chroots for arch testing wouldn't hurt. Of course for testing bootability and whether X11 starts up correctly, etc we'd probably have to host some virtual machines, but better compile testing (for example for toolchain updates) would be a good start. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] avoiding urgent stabilizations
On 2/8/11 9:24 AM, Markos Chandras wrote: On Mon, Feb 07, 2011 at 10:02:36PM +0100, Paweł Hajdan, Jr. wrote: There are machines available for various arches at http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml. I have at least a few chromium-related chroots on miranda, and I've never heard complaints, so it seems a few more chroots for arch testing wouldn't hurt. No. Miranda, in particular, can go down anytime soon. This is what infra told me twice. Oh, they didn't tell me that. What's the problem with miranda? signature.asc Description: OpenPGP digital signature
[gentoo-dev] glibc-2.13 news item?
It seems that with glibc-2.13 there are some serious compatibility issues. There are good warnings on the planet (http://psykil.livejournal.com/340806.html), but not every ~arch user reads the planet, so how about creating news item with detailed instructions how to ensure smooth glibc-2.13 update or recover a hosed system? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] avoiding urgent stabilizations
tl;dr - can we add more automated tests to auto-generated stages? On 2/8/11 1:22 PM, Fabian Groffen wrote: Hmmm, odd. I experience amd64 (stable) as being pretty stable on my servers. Last breakage which really got me upset was php, but that's already some time ago. Makes sense. Most of the breakages I had in mind when starting this thread were related to consolekit/policykit/login manager/de breakages, or some desktop software not compiling with an updated gcc. Those issues generally don't affect servers. By the way, to turn this thread into some action: what testing do we currently perform for auto-generated stages? It'd be cool to at least compile-test that the stage can emerge -e world itself, and emerge some common packages (with FEATURES=test so that we run at least some of the produced code). With Gentoo you should update on fairly regular intervals, and have the time inbetween as short as possible, but 2 or 3 weeks appears to be fine. I myself have a cronjob that syncs every night, and mails me the output of emerge -Dupv world. When this list gets too large, it's typically about time to do some updating. Sounds like a good idea. I think I'll start using it. I have masked new major releases of PostgreSQL and MySQL for instance, and of course Python 3. Yeah, this ease of masking is a great strength of Gentoo. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] avoiding urgent stabilizations
On 2/9/11 2:57 PM, Rich Freeman wrote: Perhaps we should target having glsas published within a certain amount of time after a vulnerability is disclosed, whether corrected or not. We could re-publish a final notice once all is well. We really shouldn't consider users safe from a security vulnerability until the vulnerability is patched in the tree AND the notice to update has been sent out. I think http://www.gentoo.org/security/en/vulnerability-policy.xml specifies the target delay, and also mentions temporary GLSAs. Unfortunately, that process does not seem to be followed due to general difficulty of drafting GLSAs (I don't even know what is the problem, as GLSAmaker is only available to security team members). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Installer (text-based)
On 2/9/11 10:33 PM, Fabio Erculiani wrote: What would be the main goals of this installer? Could you elaborate a high level description of it? As I said in the past, beside some annoying deps, anaconda already works for Sabayon and working on a pure Gentoo module would be quite easy. In change you get one of the most reliable graphical installer out there. Text frontend comes for free, but nowadays, there aren't many servers without a vesa-compatible video card or VNC/X-over-ssh/whatever availability. Oh, if we can get that installer for free, that would sound great. Can anaconda give the user a shell at any point of the installation? Is it possible to manually skip the automated steps? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Downgrading glibc?
On 2/11/11 10:55 AM, Michael Haubenwallner wrote: what do you think of working around the memcpy troubles with glibc-2.13 by simply redirecting memcpy to memmove within glibc, either unconditionally or optional/temporary (via USE-flag?) until everyone uses memmove where necessary? I'm not a maintainer of base-system, but it seems to me that such a change in behavior would only add to the confusion. glibc behaving differently on Gentoo than other distros... no, that doesn't sound good. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Downgrading glibc?
On 2/11/11 1:06 PM, Sebastian Pipping wrote: I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now gone again! Just curious, what downgrade method did you use? Just untaring an older glibc package? signature.asc Description: OpenPGP digital signature
[gentoo-dev] libpng-1.5 smooth upgrade
I'm not a member of QA team or libpng maintainer, but hopefully I'm not going to write something horribly wrong here. To ensure good upgrade experience for our users, and learning some lessons from previous, um... disruptive upgrade (1.2 - 1.4), I'd have some questions: 1) Are we going to have a tinderbox run *before* libpng-1.5 gets keyworded? 2) If the upgrade is non-trivial, i.e. just emerge -uDNa world and revdep-rebuild isn't going to fix it, will we have an upgrade guide, possibly as a news item? 3) Can we do something to make catching libpng problems easier? As Samuli pointed out in https://bugs.gentoo.org/show_bug.cgi?id=354479 there is a predictable compilation warning. How about making portage print it as a QA warning, so more people can report the issues without even emerging libpng-1.5 on their systems? That may be a good backup option for the tinderbox too. 4) What have we learned from libpng 1.2 - 1.4 upgrade? I'd just like to be better informed. Finally, it seems that hard work on --as-needed and automatic fixing of .la files is going to make the upgrade experience better now, right? Paweł Hajdan, Jr. P.S. The 1.2 - 1.4 upgrade wasn't really bad for me, but I guess it could be frustrating for some people, and I just wonder if we can make it better. signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
Sometimes there are very simple things we can do to make arch developers' life easier. For example, when stabilizing multiple packages it's very helpful to post a snippet that can be copy-pasted to package.keywords, like in those bugs: http://bugs.gentoo.org/show_bug.cgi?id=322791 http://bugs.gentoo.org/show_bug.cgi?id=329703 I'd like to suggest that all multiple-package stabilization bugs follow that convention. What do you think? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On 2/14/11 3:07 PM, Tomáš Chvátal wrote: Same does x11 team... Example: http://bugs.gentoo.org/show_bug.cgi?id=354237 I think this does not need any policy, most teams can use brains and fill the bugs quite conveniently :) Well, that's the entire point. For the bug you cited, and - for another example - http://bugs.gentoo.org/show_bug.cgi?id=353434 I can't just copy-paste something to my package.keywords file. The table is indeed pretty, and it has value, but I'm just asking for a bit more convenience. One more time, the good examples are: http://bugs.gentoo.org/show_bug.cgi?id=322791 http://bugs.gentoo.org/show_bug.cgi?id=329703 Citing part of good example inline: Stabilization list for x86: === =media-libs/gstreamer-0.10.29 =media-libs/gst-plugins-base-0.10.29 =media-plugins/gst-plugins-alsa-0.10.29 =media-plugins/gst-plugins-cdparanoia-0.10.29 And citing part of *bad* example inline: app-admin/eselect-opengl-1.2.1 alpha amd64 arm ppc ppc64 s390 x86 media-libs/mesa-7.9.1 alpha amd64 arm ppc ppc64 x86 The *good* example can be copy-pasted to package.keywords with no editing. The *bad* examples requires some editing, and while it can be automated, there are different formatting conventions, etc etc so IMHO it's not really feasible. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On 2/14/11 9:13 PM, Samuli Suominen wrote: And http://bugs.gentoo.org/show_bug.cgi?id=349053#c1 ? I tried to provide a clue howto get usable p.keywords list easy. IMHO it's in the middle. I still have to do a manual step, but at least it's pretty straightforward. Anyway, I think a list that can be blindly copy-pasted makes things even easier. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: package.keywords-compatible snippets when stabilizing multiple packages
On 2/15/11 9:10 AM, Gilles Dartiguelongue wrote: I don't think making a list for each arch is going to make anything any easier for maintainers requesting stabilization, which means those list we need more time to generate before being released. You just move the problem to another place. I was expecting such argument. It's a good point, but please consider the following: - if the stabilization list has been created automatically, we should adjust the tool to print in a format more suitable for the intended audience (arch developers) - if the stabilization list has been created manually, what prevents you from doing it in a slightly different way? I think it doesn't change the amount of work, and might even decrease it (no need for pretty tables) signature.asc Description: OpenPGP digital signature
[gentoo-dev] www-client/chromium icon theme dependencies, help needed
There is a bug about www-client/chromium icon theme dependencies (https://bugs.gentoo.org/show_bug.cgi?id=352263), and I'm not quite sure what's the best way to solve it. The main issue is that in KDE only oxygen-icons work, and in XFCE oxygen-icons *don't* work and one needs other icon themes installed (which in turn don't work in XFCE). Portage obviously doesn't know which DE the user is running (multiple DE's may be installed on the system), so I don't see a way to create foolproof dependencies. The two approaches I'm thinking about are: a) Drop any icon themes from RDEPEND, tell the user in pkg_postinst about possible choices. b) Add kde to IUSE, and then kde? ( kde-base/oxygen-icons ) !kde ( all || the || rest ) to RDEPEND. What do you think? Do you have some better ideas? signature.asc Description: OpenPGP digital signature
[gentoo-dev] unbreaking net-print/foo2zjs
Currently foo2zjs is completely broken because of digest verification issues. I happen to have a printer that requires foo2zjs, and I decided to fix this problem. I've submitted a live ebuild, see http://bugs.gentoo.org/356695 It's not ideal, but it works for me, and can be a starting point for creating fully versioned tarballs on Gentoo side. As the package seems rather unmaintained, I'm going to wait for a while and check in the ebuild if nobody is against that. Any feedback is welcome, please let me know what you think. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gtk 3 preparation work
On 2/28/11 11:34 PM, Nirbheek Chauhan wrote: Herd: chromium www-client/chromium-10.0.648.114 www-client/chromium-10.0.648.82 www-client/chromium-11.0.672.2 www-client/chromium-11.0.672.2-r1 www-client/chromium-11.0.672.2-r2 www-client/chromium-9.0.597.94 www-client/chromium-9.0.597.98 www-client/chromium- www-client/chromium-bin-9.0.597.84 Latest ebuilds visible in ~arch should be fixed now. Older ebuilds should get removed soon. If there's anything more to be done there, please let me know. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] www-client/chromium icon theme dependencies, help needed
Does anyone else want to comment on this? On 2/25/11 5:43 PM, Mike Gilbert wrote: On Fri, Feb 25, 2011 at 9:42 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Portage obviously doesn't know which DE the user is running (multiple DE's may be installed on the system), so I don't see a way to create foolproof dependencies. The two approaches I'm thinking about are: a) Drop any icon themes from RDEPEND, tell the user in pkg_postinst about possible choices. b) Add kde to IUSE, and then kde? ( kde-base/oxygen-icons ) !kde ( all || the || rest ) to RDEPEND. What do you think? Do you have some better ideas? Option (a) sounds good to me. Maybe you could add something to the FAQ section on the project page so it will show up in Google search results. Thank you for the feedback, that sounds like a good idea. Chromium should really have some generic fallback icon to use when it can't find an icon for a given mime type. A broken image icon is less than ideal for that. I guess that would be an upstream issue though. Feel free to file an upstream bug. It might also be an issue with xdg-utils, I'm not quite sure how that works. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: www-client/chromium-bin
# Pawel Hajdan jr phajdan...@gentoo.org (04 Mar 2011) # Masked for removal in 90 days. # Multiple hard to fix and time consuming maintenance problems: # - history of bugs (bug #304527, bug #335101, bug #347175, #bug #349249, bug #356609) # - upstream's binary builds cannot be used on Gentoo #as easily as other -bin packages (ubuntu-specific #library names that require compatibility symlinks, #bundling libraries, mirror/redistribution policy, and so on) # - dependencies for the -bin package are harder to manage; #often we have source compatibility, but not binary compatibility www-client/chromium-bin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On 3/5/11 12:51 AM, Tomáš Chvátal wrote: Dne 5.3.2011 00:46, Alex Alexander napsal(a): Chromium has its own version of webkit :) For this lovely thing it should be webkit-gtk Actually, Alex is right. Chromium has its own port of WebKit, different from Qt and GTK ports. Reasons for that include sandboxing, process separation, and little rendering differences (for example using the skia library). This might be possible to change in the future (a separate library to possibly avoid recompilations), but for now I'm not aware of any effort to do that (it's really non-trivial). On 3/5/11 3:41 AM, Rich Freeman wrote: Still, the build has gotten faster with time as the excellent g.o chromium team slowly strips out bundled libs. If you want a real eye-opener do a du -s * in the source tree for chromium and see where all the code is. Thanks! Anyway, I guess that the WebKit part of the browser still takes the majority of the compile time. On 3/5/11 12:58 AM, Alex Alexander wrote: I can also give you a binpkg from one of my chroots :P It sounds like a possible option. We could then advertise those binpkgs on the project page, or make them semi-official. If you or someone else is interested in doing that, I second that effort. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 3/6/11 1:22 PM, Christian Ruppert wrote: We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org. So, do we want the new workflow or do we want to keep the old? I like the new workflow more, mostly because of simplicity. This is also closer to what code.google.com uses, and my experience with it was very positive. Before we start arguing for and against various details, let's ask one simple question - are we actually using all those CLOSED and VERIFIED statuses, and what does it change that a bug is REOPENED vs. NEW. Now one of the issues I can indeed understand is the CONFIRMED status vs. UNCONFIRMED. Still, I'm not sure whether we use UNCONFIRMED so much. Anyway, it should be possible to add UNCONFIRMED on top of the new workflow, right? Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 3/6/11 1:50 PM, Brian Harring wrote: NEW will become CONFIRMED This seems mildly insane; sure you didn't mean UNCONFIRMED? I don't understand that concern. There is UNCONFIRMED and NEW, now you'd get UNCONFIRMED and CONFIRMED. It seems to me it's just NEW with a different name, and UNCONFIRMED would still be there: http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/ I'm in favor of the new workflow. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unbreaking net-print/foo2zjs
On 3/7/11 1:05 PM, Hanno Böck wrote: Am Sun, 27 Feb 2011 15:44:13 +0100 schrieb Paweł Hajdan, Jr. phajdan...@gentoo.org: As the package seems rather unmaintained, I'm going to wait for a while and check in the ebuild if nobody is against that. Any feedback is welcome, please let me know what you think. I thought about splitting the stuff to make maintaining easier. One ebuild for the driver itself, one for the color profiles and one for the firmwares. Yeah, I was also thinking about that. However, I haven't analyzed the build system enough to know how to handle the files downloaded from the network separately. I think my plan for now is to check in something working, and try to improve it when I have another chunk of time. Of course anyone is free to hack on it too. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 3/7/11 11:13 AM, Brian Harring wrote: Re-read what he stated- it'll convert all existing NEW bugs to CONFIRMED upon migration. There's a fair number of bugs that are in a NEW state, decent number that have sat for a long while too. Those bugs aren't 'confirmed'- just like with the new work flow where the dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip the current bugs from UNCONFIRMED to CONFIRMED rather than just marking everything as CONFIRMED. Maybe I'm misunderstanding something, but it seems we have both UNCONFIRMED and NEW in the old workflow. My understanding is that CONFIRMED is the new name for NEW, which makes sense. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
On 3/5/11 11:05 AM, Duncan wrote: What about handling chromium-bin the same way amd64 handles grub-static? They create a standard binpkg of the normal grub ebuild (using standardized USE flags, of course), using that as the source tarball for the grub-static ebuild, which then simply ebuild-scripts the unpack and install of the binpkg tarball. That's the chromium-bin, really. The difference is that chromium has more deps and takes more time to compile than grub. Also, it has much more frequent releases, and almost every stable release is a security update. In theory, the ebuild could even grab and merge the appropriate binpkg based on arch, allowing the ebuild to be keyworded for more archs than the usual binary-only ebuild tends to be, altho I'm not sure that'd work in practice as I'm unsure of the effects on the metadata cache and whether that would be allowed or not. Yeah, I can understand how it could work technically. The only issue is to make the version bump one automated step. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
On 3/10/11 9:33 PM, Mike Gilbert wrote: Chromium tarballs are actually around 140 MB. It would be interesting to see if we can trim that tarball down. Oh yes, we can. I guess the biggest problem is testing, but we can certainly remove more from the tarball. If anyone's interested, it's src/tools/export_tarball/export_tarball.py in the Chromium source tree. I can review patches. :-D Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] virtualx eclass possible issue
One of my ebuilds is using virtualx eclass, and I noticed the following
code inside the eclass:
retval=$?
# Now kill Xvfb
kill $(cat /tmp/.X${XDISPLAY}-lock)
else
debug-print ${FUNCNAME}: attaching to running X display
# Normal make if we can connect to an X display
debug-print ${FUNCNAME}: ${VIRTUALX_COMMAND} \$@\
${VIRTUALX_COMMAND} $@
retval=$?
fi
# die if our command failed
[[ $? -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
Shouldn't that last line look more like this (notice $retval instead of $?):
[[ $retval -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
What do you think?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] unbreaking net-print/foo2zjs
I have just committed the live ebuild for foo2zjs. At least it works. On 3/7/11 1:05 PM, Hanno Böck wrote: I have a printer using foo2zjs and have my own ebuild for that. Though my printer is black-white and thus doesn't need the whole color-profile stuff and no firmware. Ah, I missed a few bits from your message when reading earlier. Could you please send me the ebuild you are using? If some printers can be supported with no additional firmware/files, creating a non-live, versioned-tarball based packages should be possible, and I can do it. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] pax-utils.eclass: elog - einfo?
I wonder why pax-utils.eclass uses elog instead of just einfo. An example message looks like this: * Fallback PaX marking -m * out/Release/chrome IMHO it's not very useful in the elog messages, but maybe there are scenarios in which it is useful. My idea is to just replace all elogs with einfos in pax-utils.eclass. What do you think? signature.asc Description: OpenPGP digital signature
[gentoo-dev] FEATURES=test, sys-devel/gcc ignored test failures
sys-devel/gcc runs tests, but the results are ignored and I remember the
tests fail most of the time.
Because the tests take long time to run and fail anyway (I understand
it's non-trivial to fix those on Gentoo side), I wonder whether it makes
sense to run them at all:
toolchain.eclass:
gcc_src_test() {
cd ${WORKDIR}/build
emake -j1 -k check || ewarn check failed and that sucks :(
}
My suggestion is to make the src_test empty (I think the default one
still calls make). I can produce a patch if needed.
What do you think?
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] pax-utils.eclass: elog - einfo?
On 3/17/11 11:18 PM, Mike Frysinger wrote: also, this code is run at the pkg_* stage, so it's not the normal src host feature detection. and we're talking about minor output behavior. Is calling pax-mark in src_compile a misuse then? At least one ebuild I maintain does that (and at least in one case it'd have to be either in src_compile or src_test because the test binary has to be pax-mark-ed). By the way, what do you think about using the hardened USE flag to control the elog behavior, and forcing it on the hardened profile? In my opinion it's a bit hacky. Would it make more sense to scan all installed files in pkg_postinst for pax-mark-ed files, and then elog something? Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] python.eclass EAPI 4 support
I remember there was an effort to make python.eclass support EAPI 4 even before it has been officially approved. Now that we have EAPI 4 support even in stable portage, it would be awesome to make python.eclass support that EAPI. What do you think? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: FEATURES=test, sys-devel/gcc ignored test failures
On 3/21/11 11:02 PM, Ryan Hill wrote: It does to me, I use them all the time. ;) The important part is that we install the test results, which can then be used for regression testing when rolling patchsets. I see, it makes sense. I guess you're comparing the test results before and after rolling patchsets and look for regressions. I think that glibc and gcc tests and other testsuites that nearly always fail shouldn't be run for the average user but should still be easily accessible in a standard way. I think we need a more finely grained test setup, where we can say tests are expensive or interesting only to developers or known to fail, and let people opt-in to these on a per-package basis. Right now you always have to opt-out using package.use.mask which works but is unintuitive. My main point is that the developer profile has FEATURES=test, and also arch testers and developers run with FEATURES=test. Being able to quickly rebuild gcc, glibc and others is a win. I'm trying to understand the problem better - do you know what causes those test failures? I don't expect a complete answer because that'd probably be a half of actually fixing the failures. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rejecting unsigned commits
On 3/24/11 10:59 PM, Mike Frysinger wrote:
is there any reason we should allow people to commit unsigned
Manifest's anymore ? generating/posting/enabling a gpg key is
ridiculously easy and there's really no excuse for a dev to not have
done this already.
Firstly, I'm excited we're moving towards a signed portage tree.
We can start with a repoman warning (yellow) and a transition period.
when i look at the tree, the signed stats are stupid low:
$ find *-* -maxdepth 2 -name Manifest | wc -l
14438
$ find *-* -maxdepth 2 -name Manifest -exec grep -l 'BEGIN PGP
SIGNATURE' {} + | wc -l
6032
If I'm interpreting the data correctly, about 43% of Manifest files are
signed. That's not too bad, I was expecting something more like 5%.
By the way, is it acceptable to use the same GPG key for e-mail and
signing packages?
Paweł Hajdan, Jr.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] rejecting unsigned commits
On 3/25/11 3:43 PM, Michał Górny wrote: How about Gentoo Foundation funding devs a full blown X509 client certs? Let's get signing and verifying working first, and then consider anything that requires funding. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] validity of manifest signing key
On 3/25/11 8:00 PM, Mike Frysinger wrote: i wasnt aware you could extend the expiration date of a key. that sort of defeats the purpose of having an expiration date doesnt it ? then someone could steal your expired key, extend the date, and keep using it. I think that's one more reason for revocation certificates. By the way, an expiration date that can be extended is still useful. It can serve as a dead-man switch in case you lose the private key, see https://we.riseup.net/riseuplabs+paow/openpgp-best-practices#set-an-expiration-date-if-you-do-not-have-one. In other words, an expiration date that can be extended is still safer than no expiration date at all, and is almost as convenient (transition to a new key generally is somewhat inconvenient). signature.asc Description: OpenPGP digital signature
[gentoo-dev] developer profile, FEATURES=digest
FEATURES=digest results in a scary warning and a possibly dangerous re-generation of manifests at the beginning of every emerge: * The FEATURES=digest setting can prevent corruption from being noticed. * The `repoman manifest` command is the preferred way to generate * manifests and it is capable of doing an entire repository or category at * once. However, FEATURES=digest is enabled in the developer profile, and only in that profile: $ egrep '^FEATURES=.*digest' -r /usr/portage/profiles/ /usr/portage/profiles/targets/developer/make.defaults:FEATURES=collision-protect digest multilib-strict sign splitdebug stricter test test-fail-continue userpriv usersandbox I'd like to suggest removing digest from the line above. I've been running with the developer profile and -digest in /etc/make.conf, and everything is working fine. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On 3/28/11 2:05 AM, Robin H. Johnson wrote: I see so many bad ideas mentioned in this thread. The suggestions to keep a gpg-agent with a very long passphrase TTL just provides a massive new security hole: === Attacker breaks into developer's system, has access to SSH agent and GPG agent thanks to software like keychain, now can commit as that developer. If a dev machine is compromised, the attacker can install a keylogger and sniff the passphrase. Or he can wait for the dev to enter the password into gpg-agent and then use it. Or pop up a fake passphrase dialog box. There many other things that can happen at that point. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] lastrite: net-mail/mailwrapper net-mail/mailer-config
On 3/29/11 9:52 PM, Eray Aslan wrote: # Eray Aslan e...@gentoo.org (29 Mar 2011) # Abandoned project. Last release in 2005. Bugs #158003, #97589, # #359411. # Removal in 90 days net-mail/mailwrapper net-mail/mailer-config That's cool. All I remember about it are file collisions. Thanks! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: virtual/ffmpeg and media-video/libav
On 3/31/11 9:37 AM, Tomáš Chvátal wrote: Ok two versioned virtuals (0.5 0.6) are now in the tree if people need to specify the version. Thank you, but it's still not enough for chromium. The virtual uses =ffmpeg-0.6, and chromium is known to be broken with ffmpeg-0.6_p25767. We need to require =ffmpeg-0.6_p25767, not just 0.6. By the way, I still didn't have time to test with libav, but it seems that it's expected to be compatible. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] developer profile, FEATURES=digest
On 3/27/11 1:13 PM, Paweł Hajdan, Jr. wrote: I'd like to suggest removing digest from the line above. I've been running with the developer profile and -digest in /etc/make.conf, and everything is working fine. Are there any objections against doing the above? Christos (angelos), Mike (vapier): your comments don't sound like a strong no objections to me, but they also don't sound like please don't do that. I guess you may need to add FEATURES=digest to your /etc/make.conf after the profile change, but that should generally be fine, right? Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] developer profile, FEATURES=digest
On 4/2/11 7:08 PM, Mike Frysinger wrote: On Sat, Apr 2, 2011 at 12:22 PM, Paweł Hajdan, Jr. wrote: On 3/27/11 1:13 PM, Paweł Hajdan, Jr. wrote: I'd like to suggest removing digest from the line above. I've been running with the developer profile and -digest in /etc/make.conf, and everything is working fine. Are there any objections against doing the above? drop it done. signature.asc Description: OpenPGP digital signature
[gentoo-dev] www-client/chromium and asian fonts, help needed
There is a bug about www-client/chromium and asian fonts: http://bugs.gentoo.org/show_bug.cgi?id=359153 First, I'm just wondering whether making the browser RDEPEND on some fonts would be a correct solution. Maybe, similarly to the icon themes, we should just suggest some fonts in pkg_postinst. I have no idea which of the fonts listed in the bug above handle Chinese, Japanese, or Korean. It seems that it is important to differentiate between them. Short example: for a Chinese page we need the Chinese font, not just any CJK font. A Korean font might seem to render most of the Japanese characters correctly, but it's not 100% correct. Do you have some ideas how to handle that? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] www-client/chromium and asian fonts, help needed
On 4/5/11 6:37 PM, Ulrich Mueller wrote: Already chromium's dependency on virtual/ttf-fonts is wrong, IMHO. Oh, I added it to RDEPEND after Raúl Porcel (armin76) asked me on IRC to do that - I think the issue was that the browser failed to launch without the fonts installed. I don't remember all the details here, but do you have some idea for better solution? I'd like the browser to be launchable out-of-the-box, an elog message like Your browser will fail to start if you don't have ttf-fonts wouldn't be OK I think. We had the same discussion for Emacs some time ago (see bug 137598), and we output a message in pkg_postinst() that Emacs requires fonts. Yeah, I just added an elog for the Asian fonts here too. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Removal of default/linux/x86/gcc2 and default/linux/x86/vserver
On 4/9/11 10:50 AM, Samuli Suominen wrote: On 04/09/2011 11:35 AM, Samuli Suominen wrote: The 2 profiles in $subject will go away in 30 days wrt bug #361133. And some early warning: If you still use Linux 2.4, you should really look into migrating away from it. For now the 2.4 profiles stay but that might not be the case for much longer. Isn't that a material for a news item? I mean both the 2 profiles removal and the above. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] openrc portage news item
On 4/13/11 8:15 PM, William Hubbs wrote: The baselayout package provides files which all systems must have in order to function properly. You are currently using version 1.x, which has several issues. The most significant of these is that the included init system is written entirely in bash, which makes it slow and not very flexable. I think it would be worth it to mention other problems too (just a list of most important bugs if that makes sense). signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Devmanual text on ChangeLogs
On 4/30/11 3:05 PM, Panagiotis Christopoulos wrote: On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote: If you read the last paragraph in my suggestion was to cycle the logs... Maybe this would be better together with a mechanism (automatic?) to keep the complete ChangeLogs (as they are now) somewhere (but not in the main tree). Sometimes, full history/ChangeLog can be useful, eg. when you want to see quickly how old a package in the tree is, or find bug numbers of fixes you may want to recheck etc etc. Seconded. I sometimes read entire ChangeLogs, for example for abandoned packages or packages I suspect to be abandoned, sometimes I read them for fun, and so on. I'm fine with shipping a trimmed down versions to users, but I think the full version must be easy to access. A possible solution would be to truncate the logs in the cvs-rsync migration. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ACE gcc and libc dependency
On 5/3/11 5:27 PM, Kfir Lavi wrote: In the ebuild there is no mention of runtime dependency like gcc or glibc. See http://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency Why sys-devel/gcc don't have a library version without the actual compiler? This question may be a bit hard to understand, at least for me. signature.asc Description: OpenPGP digital signature
