Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild

On 10/2/11 8:26 PM, Arun Raghavan wrote: > Removing the package again seems to just be unnecessary when the > maintainer has stated that he'll fix the problem. Would masking it > till it was fixed not suffice? Seems like a bit unjustified to me > (from information on this thread alone). I find the

Re: [gentoo-dev] FEATURES="stricter" as a default in developer profile not the best idea

On 9/17/11 5:42 PM, "Paweł Hajdan, Jr." wrote: > TLDR: Let's remove FEATURES="stricter" from developer profile, I bet > most people have it disabled anyway and it doesn't seem useful. This is now done. Nobody complained and there was +1 from Rafael Martins. E

[gentoo-dev] python.eclass EAPI 4 support, this gets really annoying

OK, so what are the _blocking_ reasons for no EAPI 4 support in python.eclass yet? I understand you have some complicated patches in flight etc etc, but are they _required_ for the eclass not to break with EAPI 4? My point is that I'd like to use pkg_pretend in packages that use python.eclass and

[gentoo-dev] svgalib FUBAR

svgalib is maintainer-needed and does not build: Is anyone interested in repairing it? Should it be treecleaned? signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] Re: udev and /usr

On 9/25/11 5:53 AM, Rich Freeman wrote: > Repeat this 100 times and you end up with a chromium tarball > that consists of 90% redistributed 3rd-party libraries with subtle > tweaks. However, can you really argue with Google's success with this > approach. At least in Gentoo we remove _most_ of th

[gentoo-dev] finding reverse dependencies for arch testing (and other purposes)

I uploaded my script for finding reverse dependencies here: http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary Advantages over existing solutions (browsing to websites like tinderbox or qa-reports): - only prints stable packages when run on a stable system (no need to manually

Re: [gentoo-dev] euscan proof of concept (like debian's uscan)

On 3/21/11 1:24 AM, Corentin Chary wrote: > I recently started working on a small gentoo utility named "euscan" > (for Ebuild Upstream Scan) > For those who don't know debian's uscan, it allows to scan upstream > for new versions. It's used by packages.qa.debian.org (example: > http://packages.qa.d

[gentoo-dev] FEATURES="stricter" as a default in developer profile not the best idea

TLDR: Let's remove FEATURES="stricter" from developer profile, I bet most people have it disabled anyway and it doesn't seem useful. I recently started more testing in one of my stable chroots, and I switched it to the developer profile. During the update the following error happened: > * QA Not

Re: [gentoo-dev] udev and /usr

On 9/15/11 1:14 PM, Michał Górny wrote: > On Thu, 15 Sep 2011 22:03:53 +0200 > Joost Roeleveld wrote: > >> I'm trying to think of how best to avoid users who are not aware to >> get caught with non-booting systems. > > Guess we could try to detect a few common cases and die in pkg_setup() > when

[gentoo-dev] Xen completely busted in the stable tree

Hey guys, I think app-emulation/xen-tools are completely broken in stable tree, especially see bugs like and I noticed some activity and work being done on those packages, but only in ~arch. If someon

Re: [gentoo-dev] License for Google Chrome

On 8/26/11 9:32 PM, Mike Gilbert wrote: > To clarify: Chrome is a pre-built, officially branded version of the > open-source "Chromium" project. It also includes a few proprietary > components, like a PDF reader plugin from Adobe. To be precise, the PDF reader in Chrome is not Adobe's, but Google'

Re: [gentoo-dev] Implicit system dependencies

On 8/22/11 12:21 PM, Michael wrote: > I wrote a script to search for discrepancies between linked libraries and > what's defined in (R)DEPEND, with the intention of improving QA for minimal > package installs. It would be great to integrate this into portage and make it a part of the developer p

Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package

On 8/8/11 7:42 AM, Andreas K. Huettel wrote: > Am Samstag 06 August 2011, 23:57:13 schrieb Fabio Erculiani: >> I really love the idea of being able to atomically push updates >> across multiple CPVs. This is also what KDE, GNOME, and many other >> teams are waiting for. Having multiple repos means

Re: [gentoo-dev] RFC: virtual/icon-theme

On 8/8/11 2:52 AM, Markos Chandras wrote: > x11-themes/faenza-icon/theme )" nit: This is a typo, right? I guess repoman would still catch it, but anyway. signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

On 7/27/11 10:06 AM, Arfrever Frehtes Taifersar Arahesis wrote: > python.eclass from python overlay supports EAPI="4". Sounds good to me. Why isn't it yet in the main portage tree? signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: virtual/icon-theme

On 8/2/11 11:20 AM, Markos Chandras wrote: > I would like to discuss the possibility to create a new virtual package > for all the icon-theme packages. According to this bug[1], it seems like > pcmanfm, and possible other applications too, require an icon-theme to > be present, no matter which one.

Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends

On 8/2/11 11:18 AM, Michał Górny wrote: >> I think I prefer the second option (copying from Exherbo). A better >> integration with the package manager than USE flags should result in a >> better user experience. > > Are you willing to update and EAPI-bump all the eclasses? May I remind > you that

Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends

On 8/2/11 12:35 AM, Michał Górny wrote: > On Sun, 31 Jul 2011 10:19:03 -0700 > ""Paweł Hajdan, Jr."" wrote: >> I'm interested in some sort of suggested/recommend deps for >> www-client/chromium, but I'm not sure if eclass is the right >> imple

Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends

On 7/31/11 8:27 AM, Michał Górny wrote: > The last discussion on new solutions optional runtime depends lead to no > agreement. Thus, I'd like to propose a solution extending the usability > of current methods of handling them. I'm interested in some sort of suggested/recommend deps for www-client

Re: [gentoo-dev] Remember to update eclass/ and profiles/ in your tree before committing anything!

On 6/16/11 7:22 AM, Diego Elio Pettenò wrote: > Just a friendly reminder that you should update profiles/ and eclass/ > before committing anything to the tree, so that you don't end up > committing packages with either broken dependencies or fetching the > wrong SRC_URI, if they were changed since

Re: [gentoo-dev] RFC: Disambiguation of "hardened" use flag and proposal for a new global flag "pax_kernel"

On 7/15/11 3:51 AM, Anthony G. Basile wrote: > So, here's the glitch. For example, in dev-lang/mono, following the > above plan, we would drop the "hardened" flag, remove > >DEPEND=" ... hardened? ( sys-apps/paxctl )" In the cited scenario, if you're not inheriting the pax-utils eclass, you

Re: [gentoo-dev] On the use of bash-completion use flag

On 6/24/11 9:07 AM, Michał Górny wrote: > For the additional dependency, I'd put it in some common ebuild (like > bash, or something without compiled binaries -- even better) and I'd > put the flag there. > > There's no reason that a dozen of packages PDEPENDs on bash-completion. > If one decides

Re: [gentoo-dev] Please review fortran-2.eclass

On 6/13/11 11:06 AM, justin wrote: > # @FUNCTION: fortran-2_pkg_setup > # @DESCRIPTION: > # Setup functionallity, checks for a valid fortran compiler and optionally > for its openmp support. > fortran-2_pkg_setup() { > _have-valid-fortran || \ > die "Please emerge the current g

Re: [gentoo-dev] RFC: removal of

On 6/8/11 6:25 PM, Michał Górny wrote: > Such an eclass would have to take tarball URIs in some kind of envvar > and export some kind of 'download timestamp'. Then the Python module in > s-l-r would HEAD those URIs to get the current timestamp and compare > that to the value exported in environment

Re: [gentoo-dev] RFC: removal of

On 6/8/11 4:17 PM, Michał Górny wrote: > BTW if you'd like to create an eclass for that kind of live packages > (which fetch packages from upstream), I could add smart rebuild > possibility to start-live-rebuild [1]. This way, foo2zjs users would be > able to upgrade their package whenever upstream

Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011

On 6/8/11 4:36 PM, Vikraman wrote: > I'm working on the `Package statistics` project this year. Till now, I > have managed to write a client and server[0] to collect the following > information from hosts: Excellent, good luck with the idea! I think that better information about how Gentoo is actu

Re: [gentoo-dev] RFC: removal of

On 6/2/11 5:20 PM, "Paweł Hajdan, Jr." wrote: > I'd like to remove severely outdated (2008) and unusable (upstream changes tarballs > in-place, digest verification is broken). I went ahead and committed the change. I might try to provide some non-live ebuild in the future,

Re: [gentoo-dev] RFC: remove annoying "You should enable -g (or higher) for debugging!" message

On 5/7/11 4:20 PM, "Paweł Hajdan, Jr." wrote: > This is mostly a nit-like RFC. The developer profile adds a > profile.bashrc, which prints the "You should enable -g (or higher) for > debugging!" message when "-g" is not in CFLAGS. > > I wonder if we ca

Re: [gentoo-dev] Reducing glibc's default locale.gen

On 6/7/11 9:53 PM, Matt Turner wrote: > Building 400~ locales is not fun on mips when building stages. Do you have some data to quantify "not fun"? How long does it take? > No user has a need for more than some small subset of the total > available locales. > > I filed bug [1] to request the abi

Re: [gentoo-dev] RFC: removal of

On 6/3/11 9:18 AM, dev-ran...@mail.ru wrote: > On Fri, Jun 03, 2011 at 08:40:26AM +0200, "Paweł Hajdan, Jr." wrote: >> ... >> We can't have a tarball, most of the files from the package are >> non-redistributable. >> ... > > Then why do ebuilds cont

Re: [gentoo-dev] RFC: removal of

On 6/3/11 4:09 PM, Chí-Thanh Christopher Nguyễn wrote: > Michał Górny schrieb: >> You could have a 'versioned' ebuild linked to the actual SRC_URI, >> and bump it whenever you notice the upstream tarball changes. This >> would allow users to have the package upgraded automatically. > I don't think

Re: [gentoo-dev] RFC: remove annoying "You should enable -g (or higher) for debugging!" message

On 5/7/11 5:04 PM, Tomáš Chvátal wrote: > Dne 7.5.2011 16:20, "PaweB Hajdan, Jr." napsal(a): >> This is mostly a nit-like RFC. The developer profile adds a >> profile.bashrc, which prints the "You should enable -g (or higher) for >> debugging!" message when "-g" is not in CFLAGS. > >> I wonder if

Re: [gentoo-dev] RFC: removal of

On 6/2/11 6:04 PM, Gökdeniz Karadağ wrote: > I use the foo2zjs package, and because other versions are broken, have > moved to the live version. But I think expecting a stable version in the > tree is not too much for a user. A tarball snapshot in a ~dev space > would solve the issue I presume. We

Re: [gentoo-dev] RFC: removal of

On 6/2/11 7:00 PM, Dane Smith wrote: > I'm going to guess you've already tried this, but just in case. Did you > try asking him to version things more... sanely? I've had to do that a > few times and people are usually surprisingly receptive. Ah, and see also

Re: [gentoo-dev] RFC: removal of

On 6/2/11 7:00 PM, Dane Smith wrote: > I'm going to guess you've already tried this, but just in case. Did > you try asking him to version things more... sanely? I've had to do > that a few times and people are usually surprisingly receptive. Right, that's a good idea. Have you visited

Re: [gentoo-dev] RFC: removal of

On 6/2/11 6:51 PM, Michał Górny wrote: > I think it may be useful to have a snapshot anyway. If you can't > tarball it, maybe a tagged VCS ebuild? I'm not sure if such a thing is > supposed to lie unmasked in the tree but it's better than no non-live > ebuild. I know that would be useful, and I'd

[gentoo-dev] RFC: removal of

I'd like to remove signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] arch teams and better tools

On 5/22/11 11:33 AM, Markos Chandras wrote: > Thanks for sharing your scripts. I would prefer to have a single > script doing everything, instead of multiple scripts here and there. Right, having to complete pieces from various sources can be frustrating. I'm planning to make arch-tools a complete

Re: [gentoo-dev] arch teams and better tools

On 5/22/11 10:13 AM, Thomas Kahle wrote: > I like it. Funnily It digged up some stable bugs from the stone-age > that have been processed, but x86 was still on the CC-list. Thanks. Those old bugs being displayed was a bug, I fixed it. > Have you seen app-portage/tatt ? I think there is a huge ov

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dns/dnsmasq: ChangeLog dnsmasq-2.57-r1.ebuild

On 5/22/11 4:07 PM, Markos Chandras wrote: > Since you are not using EAPI=4 you need to add || die to every do* and > new* function. I just bumped to EAPI 4 then. Thanks! signature.asc Description: OpenPGP digital signature

[gentoo-dev] arch teams and better tools

Recently there was a discussion about better tools for arch teams, to speed up stabilizations and make them less error-prone. Here's my answer to that, still in very early development: You can just launch it like this: ./bu

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/nspr: nspr-4.8.8.ebuild ChangeLog

On 5/16/11 11:15 AM, Peter Volkov wrote: > Why do you need such complex detection? Is it possibly similar to the scenario from , i.e. multilib portage and other non-standard configurations? If so, it may also be useful to re-use the detection logic in

Re: [gentoo-dev] Re: rejecting unsigned commits

On 5/10/11 4:08 AM, Jim Ramsay wrote: > - Does this tree signing key have to be DSA? Or is RSA okay too? No idea, I'd probably just try and see if signing works. > - If I have a key already, should I generate a new subkey just > for manifest signing, make a whole new primary key, or just use >

[gentoo-dev] RFC: remove annoying "You should enable -g (or higher) for debugging!" message

This is mostly a nit-like RFC. The developer profile adds a profile.bashrc, which prints the "You should enable -g (or higher) for debugging!" message when "-g" is not in CFLAGS. I wonder if we can remove that file. It has been added 3 years ago:

Re: [gentoo-dev] hardened flavor of the developer profile

On 5/5/11 10:45 PM, Anthony G. Basile wrote: > We simplified our profiles recently (last Oct-Nov 2010) You're referring to http://archives.gentoo.org/gentoo-dev/msg_d847f6258a398052deecc9786c45c604.xml, right? > and I only > listed hardened/linux/x86 in profiles.desc. You can manually set > >

[gentoo-dev] hardened flavor of the developer profile

Currently I'm using the default/linux/x86/10.0/developer profile, but I'd like to switch to hardened on my developer system to catch more issues. However, eselect profile list only displays one hardened profile for me: $ eselect profile list Available profile symlink targets: [1] default/linu

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 > Why sys-devel/gcc don't have a library version without the actual compiler? Thi

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 no

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

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

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 al

[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

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 >>&g

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 doi

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, not just 0.6. B

Re: [gentoo-dev] lastrite: net-mail/mailwrapper net-mail/mailer-config

On 3/29/11 9:52 PM, Eray Aslan wrote: > # Eray Aslan (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! signatur

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 > agen

[gentoo-dev] developer profile, FEATURES=digest

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ł

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 fo

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] rejecting unsigned commits

anifest -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

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 ro

[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 si

Re: [gentoo-dev] pax-utils.eclass: elog -> einfo?

7;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] 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

[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

Re: [gentoo-dev] unbreaking net-print/foo2zjs

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.

[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

Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin

d, 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

Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin

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] 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 n

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." : > >> 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

Re: [gentoo-dev] Bugzilla - New Default Status Workflow

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] Bugzilla - New Default Status Workflow

ndeed 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] Last rites: www-client/chromium-bin

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

[gentoo-dev] Last rites: www-client/chromium-bin

# Pawel Hajdan jr (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 othe

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." > wrote: >> Portage obviously doesn't know which DE the user is running (multiple >> DE's may be installed on the s

Re: [gentoo-dev] gtk 3 preparation work

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, pl

[gentoo-dev] unbreaking net-print/foo2zjs

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

[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 ins

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.

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

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 - fo

[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.gent

[gentoo-dev] libpng-1.5 smooth upgrade

n 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.

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

Re: [gentoo-dev] Downgrading glibc?

essary? 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] 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 c

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

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

[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

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 fe

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 tre

[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 wou

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

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

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 > 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 b

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 so

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

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

<    1   2   3   4   5   6   >