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: 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] 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 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: 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] 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/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] [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] 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] 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'

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

[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

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

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

[gentoo-dev] batch-committing stabilizations

I've updated my scripts at to also update Bugzilla bugs when doing stabilizations. It's even clever enough to close bugs for last arch, but not security bugs. Check it out!

[gentoo-dev] integrity of stage files

I checked and the Handbook only mentions validating MD5 checksums. There are two possible issues: 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we be using something stronger? 2. I noticed the checksums

Re: [gentoo-dev] integrity of stage files

On 10/8/11 3:43 PM, Robin H. Johnson wrote: >> 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we >> be using something stronger? > Fixed in Catalyst now. > http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=42b4f6608682cf03954918ecce7923330a1656fe > So when t

Re: [gentoo-dev] integrity of stage files

On 10/8/11 5:01 PM, Robin H. Johnson wrote: >> Ah, I just forgot about that page. Okay, so can we also update the >> Handbook to include GPG signature checking? > It DOES already mention checking the signature: > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2#doc_chap3 That's

Re: [gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

On 10/10/11 4:45 AM, Diego Elio Pettenò wrote: > Not really. GCC, like most other libraries, only supports > forward-compatibility. Which means that you can use code built against > 4.5 when using 4.6. I'm not sure about that. It might be a bit speculative, but I think I remember problems with tha

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

On 10/14/11 12:39 PM, Brian Harring wrote: > On Fri, Oct 14, 2011 at 03:29:19PM -0400, Matt Turner wrote: >> On Sat, Oct 1, 2011 at 3:16 PM, "Pawe?? Hajdan, Jr." >> wrote: >>> OK, so what are the _blocking_ reasons for no EAPI 4 support in >>> python.eclass yet? >>> >>> I understand you have some

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

On 10/14/11 3:32 PM, Thomas Sachau wrote: > What do you expect the council to do? Say it's OK to make python.eclass not die on EAPI-4. At least my use case will not become broken by this. > Neither you nor the council can force anyone to do anything. Not really. It should always be possible to e

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

On 10/14/11 5:38 PM, Alec Warner wrote: > I believe op's point is that there is no one to escalate the problem > to; certainly the council members are not going to do the work > themselves and we already have our best people on it. I'm aware of that. My point is that I think there are many scenari

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

On 10/15/11 2:42 AM, Dirkjan Ochtman wrote: > On Sat, Oct 15, 2011 at 03:54, Mike Gilbert wrote: >> That would be an ok approach from my perspective: We could just change >> line 14 of python.eclass and let package maintainers report breakage as >> they increment EAPI. I am confident that nothing

[gentoo-dev] Moving more hardening features to default?

I've noticed , i.e. Debian is starting to make more and more hardening features default, at least for most packages. Should we start doing that too? What are possible problems with that? It seems like it's mostly about USE=hardened,

Re: [gentoo-dev] huse: new helper for low level eclass writers

On 10/20/11 9:22 PM, Donnie Berkholz wrote: > alright, use_if_iuse. That's my last bikeshed for today. I think this is the best one. I didn't really like any of the previously proposed names, but this one is good. signature.asc Description: OpenPGP digital signature

[gentoo-dev] Building hardened gcc specs always, just not enabling them by default

Looks like the thread I started about moving more hardened features to default got a lot of positive feedback. Kernel hardening features are more problematic, but hardening the toolchain seems to be within reach. I'd

Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default

On 10/23/11 9:47 PM, Anthony G. Basile wrote: > So if you look in the hardened profiles, you'll see some things masked > like net-im/skype because of the kernel, and some things masked like > =sys-devel/gdb-7.0* because of the toolchain. If the hardened toolchain > moves into mainstream, then we'l

Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default

On 10/24/11 12:58 PM, Anthony G. Basile wrote: > Well not totally on their own, they'd report it and we'd have to see > what we want to do on an ad hoc basis. Fair enough, that's why I suggested to make the hardened spec non-default, so that they have to switch it, and include the info in emerge -

Re: [gentoo-dev] Re: Moving more hardening features to default?

On 10/23/11 5:56 AM, Steven J Long wrote: > Will we be able to switch off SSP via config, or will we have to setup our > own profile? In my proposal the SSP would be off by default on non-hardened profiles, at least initially. At any time I'd like it to be switchable via gcc-config, as it current

Re: [gentoo-dev] Moving more hardening features to default?

On 10/25/11 5:11 PM, Rich Freeman wrote: > And "Debian is doing it" or whatever isn't actually a bad reason to > consider this. When Debian does something by default, it means that > upstream packages will take notice. Right, I was thinking about the change for a long time, but if Debian, which a

Re: [gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default

On 10/25/11 3:58 PM, Anthony G. Basile wrote: > Zorry's the expert here, so I'll ask him to correct me if I miss > anything or get something wrong. > > You won't get hardening without those patches. So they need to be there > if the user switches specs from vanilla to hardened. Thanks, I've file

[gentoo-dev] redundant code in toolchain.eclass?

I was browsing toolchain.eclass and noticed this: if [[ ${PN} != "kgcc64" && ${PN} != gcc-* ]] ; then ... [[ -n ${SPECS_VER} ]] && IUSE+=" nossp" ... if tc_version_is_at_least 3 ; then ... if tc_version_is_at_least "4.4" ; then IUSE+=" graphite"

[gentoo-dev] hardened glibc and gcc dependencies

As a part of my earlier threads I tried to figure out the migration plan from not hardened glibc and not hardened gcc to both of them hardened. That of course raises questions like - what we compile first, and what are dependencies here? Here's what I have figured out - by _experimenting_ not spe

Re: [gentoo-dev] hardened glibc and gcc dependencies

On 10/27/11 11:03 AM, "Paweł Hajdan, Jr." wrote: > In glibc: DEPEND="gcc[hardened?]" > In gcc: PDEPEND="elibc_glibc? glibc[hardened?]" I even got an OK on #gentoo-hardened, but I just realized that EAPI-0 (that both packages in question use) doesn't

[gentoo-dev] recovering from corrupted vdb

Shouldn't portage offer some means to recover from a corrupted vdb? I just stumbled upon and it seems really bad. It would suck if the only solution to this is reinstall (I remember package database bec

[gentoo-dev] linux-info.eclass: check_extra_config requires a configured kernel

check_extra_config requires a configured kernel (/usr/src/linux/.config), while I think it should also be satisfied by /proc/config.gz (i.e. just a way to verify the config, not necessarily kernel built locally). An example use case is www-client/chromium, which makes sure the kernel will support

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

First thanks for the feedback about chromium, and sorry for the annoyances. I'm not sure how we can "fix" that though. I've batched my replies to several people in this e-mail. On 11/11/11 8:58 AM, Tomáš Chvátal wrote: > In last 3 days i recompiled chromium 3x So the timeline is: 26 Oct

Re: [gentoo-dev] have portage be quiet by default

On 11/12/11 11:24 PM, Patrick Lauer wrote: > Most devs will be unhappy as it makes it harder to view the log while > building. We can have a different default in the developer profile. > Please consider reverting it and let users set it with > EMERGE_DEFAULT_OPTS if they want it less noisy. Why

Re: [gentoo-dev] making the stable tree more up-to-date

tl;dr - I plan to file stabilization bugs without CC-ing arches first so that maintainers have chance to comment anyway. That'd still generate large amount of bugs, and I was mostly asking about that. On 11/21/11 1:14 PM, Andreas K. Huettel wrote: > Are the cited advances relevant for all stable a

Re: [gentoo-dev] Packages up for grabs due loki_val retirement

On 11/24/11 1:38 PM, Pacho Ramos wrote: > Due loki_val retirement the following packages need a new maintainer: > > dev-util/lafilefixer Do we still need lafilefixer? I think it's been integrated into portage, right? signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] Re: making the stable tree more up-to-date

On 11/23/11 3:27 PM, Torsten Veller wrote: > What do you expect to happen with bugs assigned to maintainer-needed? I'm going to CC arches myself after a while, similarly as with bugs with other maintainers who don't respond. > I don't know if any of the packages is really good to be stabilized. >

[gentoo-dev] repoman not complaining when going straight to stable

This shouldn't be allowed, should it? The package is keyworded only ~x86, and I'm adding amd64 stable keyword, and repoman doesn't complain. $ ekeyword x86 netboot-0.10.2.ebuild netboot-0.10.2.ebuild --- netboot-0.10.2.ebuild 2011-11-23 02:41:03.0 +0100 +++ netboot-0.10.2.ebuild.new

Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

On 11/26/11 12:26 PM, Nirbheek Chauhan wrote: > If it should be sorted[1], it should really be sorted in the reverse > order of distfile-download size. That would be extremely useful on > systems with slow internet connections. [...] > > 1. I'm obviously assuming that dep nodes that do not depend

[gentoo-dev] tkabber completely broken in stable

Please see , tkabber is completely broken in stable since February. * ERROR: net-im/tkabber-0.9.9 failed: * dev-tcltk/tclxml-3.2-r1 does not actually support the expat USE flag! * * Call stack: * ebuild.sh, line 56: Called pkg_se

Re: [gentoo-dev] repoman not complaining when going straight to stable

On 11/26/11 11:29 AM, Sergei Trofimovich wrote: > On Sat, 26 Nov 2011 10:15:53 +0100 > ""Paweł Hajdan, Jr."" wrote: > >> This shouldn't be allowed, should it? The package is keyworded only >> ~x86, and I'm adding amd64 stable keyword, and re

Re: [gentoo-dev] making the stable tree more up-to-date

On 11/25/11 5:39 PM, Thomas Kahle wrote: > I still remember that arfrever had such a script running for python > packages and that we were quite annoyed by the automatic stable bugs > for every minor version of every small python package. I also still remember it, and that was one of the things

Re: [gentoo-dev] Re: making the stable tree more up-to-date

On 11/24/11 6:12 PM, Rich Freeman wrote: > I support stabilizing bug-free newer versions of maintainer-needed > packages that already have stable versions. I'm not sure I'd extend > that to stabilizing packages that have no stable versions already. > [...] > Those benefits don't exist for a packag

Re: [gentoo-dev] So now that we have --quiet-build as default, can we talk about a forced LC_ALL=C again?

On 12/4/11 12:58 PM, Chí-Thanh Christopher Nguyễn wrote: > Mike Frysinger schrieb: >> and in reality, you're complaining only about LC_MESSAGES, not LC_ALL or any >> other locale category ... > > I too think it is sufficient to have > LC_MESSAGES=C > in the default make.conf (or somewhere else wh

Re: [gentoo-dev] dropping of ssp/pie support in

On 12/4/11 8:33 PM, Mike Frysinger wrote: > since hardened doen't support on > dropping the custom code we have to support this. it allows me to simplify > the common code a bit. Simplifying toolchain.eclass sounds great to me. :) signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] We need *you* for a USE="selinux" dependency

On 12/4/11 9:35 PM, Sven Vermeulen wrote: > Within the Gentoo Hardened project, we are working on getting the SELinux > support into shape. Recent evolutions are the stabilization of latest upstream > userspace utilities and policies as well as documentation improvements and > even > some "human r

Re: [gentoo-dev] We need *you* for a USE="selinux" dependency

On 12/5/11 9:42 PM, Sven Vermeulen wrote: > For end users, this is much more enjoyable. If we load up all policies, then > any interaction with the SELinux policies will take some time. Also, all > policies in memory do take up some space. Finally, for development purposes, > this is very much enjo

[gentoo-dev] eclipse-ecj is broken and slows down arch testing / stabilizations

Please take a look at . checking if /usr/bin/ecj works... configure: error: The Java compiler /usr/bin/ecj failed (see config.log, check the CLASSPATH?) * ERROR: dev-java/gnu-classpath-0.98-r3 failed (configure phase): * configure failed # esel

Re: [gentoo-dev] making the stable tree more up-to-date

On 12/16/11 11:42 AM, justin wrote: > I really like that you open all those bugs. But it makes no sense to > add arches after a "time out". At least not after a such a short > one. I'm sorry this has annoyed/upset you. Let me just point out some facts: - in November I first wrote about this new

[gentoo-dev] mass stabilization and non-x86-non-amd64 arches

For several mass-filed stabilization bugs I got comments why I didn't cc arches like ppc. One problem is that I cc x86 and amd64 via "edit many bugs at once" Bugzilla feature, and when filing bugs the script checks that it's repoman-possible to stabilize given package on x86 and amd64. Not all pa

Re: [gentoo-dev] making the stable tree more up-to-date

On 12/16/11 3:12 PM, justin wrote: > So lets agree that your proceeding is worth the effort, but extend the > time you give the maintainer to iron their packages. Sounds good, looks like other people have similar comments about this. I'll do that, thank you for feedback. :) signature.asc Descri

Re: [gentoo-dev] Six month major project on Gentoo

On 12/18/11 6:02 PM, Petteri Räty wrote: > There are parallel computing aspects in libbash for metadata generation, > data structures in AST building for bash and it's quite low level. By the way, I've always wondered why libbash is separate from the "upstream" bash. Have you considered contribut

Re: [gentoo-dev] Six month major project on Gentoo

On 12/19/11 7:14 PM, Sébastien Fabbro wrote: > One project that could be very useful for Gentoo is an automated > stabilization/testing for ebuilds. Obviously it will require some work > from the ebuild maintainers, but the ability to distribute the > stabilization recipes across a volunteering Gen

Re: [gentoo-dev] RFD: split out some functions from eutils.eclass?

On 1/7/12 12:42 PM, Ulrich Mueller wrote: > Some functions in eutils.eclass address very special tasks, so I > wonder if they shouldn't be split out to dedicated eclasses: > > - CDROM functions (cdrom_get_cds, cdrom_load_next_cd). > These are used by some 40 ebuilds only, most of them in games-*

Re: [gentoo-dev] Re: RFD: split out some functions from eutils.eclass?

On 1/11/12 11:09 PM, Ulrich Mueller wrote: > A draft version for a new cdrom.eclass is attached. It contains the > cdrom_* functions split out from eutils.eclass. Mike says that the new > eclass could be maintained by the games team. > > Please review. I think it could be worth it to add PROPERTI

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: cdrom.eclass

On 1/14/12 12:36 AM, Markos Chandras wrote: > On 01/13/2012 10:35 PM, Ulrich Mueller (ulm) wrote: >> Don't set PROPERTIES=interactive, bug 398809. How about this: set PROPERTIES=interactive by default (so it's difficult to forget it), but allow the ebuilds to specify a USE flag in case the interac

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: cdrom.eclass

On 1/14/12 12:21 PM, Ulrich Mueller wrote: > It can't be a USE flag, but something like the following might work: > > # @ECLASS-VARIABLE: CDROM_DISABLE_PROPERTIES > # @DEFAULT_UNSET > # @DESCRIPTION: > # By default, the eclass sets PROPERTIES="interactive". > # A non-empty value of CDROM_DISABLE_P

[gentoo-dev] adding list of variables exported by make.conf to emerge --info

People frequently break their systems by exporting weird variables like SYSTEM from /etc/make.conf (USE variable "grouping"). Example here: What do you think about adding list of variables in make.conf to emerge --info ? I know we can alw

[gentoo-dev] Last rites: dev-util/chromium-tools

# Determined by the maintaining team to be no longer useful. # Removal in 30 days (02/16/2012). dev-util/chromium-tools signature.asc Description: OpenPGP digital signature

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

On 1/16/12 12:36 PM, Pacho Ramos wrote: > I agree but, why not *also* make portage warn people when they are > exporting some "known to break" variables in their make.conf? That'd require coming up with such list of "known bad" variable names, and generally I don't think blacklisting is very effec

Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

On 1/17/12 6:35 PM, Zac Medico wrote: > On 01/16/2012 02:54 AM, "Paweł Hajdan, Jr." wrote: >> People frequently break their systems by exporting weird variables like >> SYSTEM from /etc/make.conf (USE variable "grouping"). >> >> Example here: &l

Re: [gentoo-dev] How help in arch testing work

On 1/18/12 4:48 PM, Donnie Berkholz wrote: > On 10:05 Wed 18 Jan , Mike Frysinger wrote: >> On Wednesday 18 January 2012 09:23:00 Agostino Sarubbo wrote: >>> 3) Check your rdepend, where is possible with scanelf[3] and if you >>> declare it, please, as you said, exclude gcc/glibc and all packa

Re: [gentoo-dev] How help in arch testing work

On 1/18/12 7:10 PM, Mike Frysinger wrote: > On Wednesday 18 January 2012 12:32:08 Paweł Hajdan, Jr. wrote: >> Same here. How about adding some warning to portage (maybe just in the >> developer profile) when files in NEEDED are provided by packages not in >> RDEPEND? > &

Re: [gentoo-dev] latest boost vs. eselected boost

On 1/19/12 9:05 AM, Johannes Huber wrote: > Summary of the comments: > 1) Ebuilds should always pick the latest boost version. > 2) Boost should be compared to gcc, python, ruby etc > > [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 Right, Tiziano Müller's (dev-zero) comments are pretty cle

[gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

While dealing with I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite libjpeg-turbo is not necessarily binary co

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 1/19/12 10:45 AM, Michał Górny wrote: > Hmm, does this mean the ABI differs on runtime compilation options? No, at least I'm not aware of such a thing. I'd sum it up as "libjpeg-turbo is not binary-compatible with libjpeg and also with a different version of itself, and is not supposed to be".

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 1/19/12 6:02 PM, Samuli Suominen wrote: > On 01/19/2012 06:56 PM, Mike Frysinger wrote: >> that doesn't help. the libjpeg turbo peeps themselves have said they >> don't >> guarantee compatibility across their own versions. > > it's forward compatible, which is all we should care about Just a

Re: [gentoo-dev] Last rites: media-sound/minitunes

On 1/21/12 5:45 PM, Matt Turner wrote: > On Sat, Jan 21, 2012 at 5:28 AM, Markos Chandras wrote: >> # Markos Chandras (21 Jan 2012) >> # Package renamed to media-sound/musique >> # http://flavio.tordini.org/minitunes-renamed-to-musique >> # Removal in 30 days >> media-sound/minitunes > > Is it n

Re: [gentoo-dev] Free Gentoo

On 1/21/12 7:01 PM, . wrote: > The main goal of the GNU project was to replace the proprietary Unix system. > You are actually ruining this goal. Forcing people to use a system that doesn't meet their requirements is not the right solution to this problem. It's not like people using one of

Re: [gentoo-dev] RFC: More versatile return codes for emerge

On 1/25/12 10:23 AM, Thomas Kahle wrote: > I suggest that emerge could signal its various failures via return > codes. That would be useful in automated archtesting: > > https://bugs.gentoo.org/show_bug.cgi?id=400705 My opinion is very similar to what Brian Harring said on that bug: some Python

Re: [gentoo-dev] How help in arch testing work

On 1/27/12 10:41 AM, Thomas Kahle wrote: > On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote: > [...] > >> 5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree >> and an easy way to check the list of rdepend is asking our bot: >> !rdep ${package} >> Unfortunately it print

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On 1/27/12 8:02 PM, Jason A. Donenfeld wrote: > I've just been informed that RHEL does not allow non-PIE executables. We > really should follow suit here. I'm generally in favor of enabling more hardening features by default (i.e. reversing the default, so that people who want to disable PIE can s

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

On 1/27/12 8:45 PM, Fabian Groffen wrote: > On 27-01-2012 20:39:24 +0100, "Paweł Hajdan, Jr." wrote: >> If the discussion on this doesn't get conclusive, how about adding the >> question to the Council's agenda? > > Negative from my point of view, this

Re: [gentoo-dev] Keeping older versions around

On 1/30/12 6:17 AM, Donnie Berkholz wrote: > Agreed with a slight modification — once you've kept the old > {stable,~arch} version around for a reasonable amount of time (say 30 > days), you should be safe pulling it. Agreed with a slight modification ;-) Please make sure that at _any_ given mo

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 1/19/12 6:42 PM, Samuli Suominen wrote: >> a) changing the virtual/jpeg dependency to>=libjpeg-turbo-... > > will be done soon as 1.2.0 is released and stabilized, i'd like to skip > 1.1.90 Sounds good to me. > a) is fine, preventing any downgrades. a fatal check, like glibc and > qt4 has t

Re: [gentoo-dev] RFC: Application name in metadata.xml

On 2/11/12 2:00 PM, Fabio Erculiani wrote: > Other distros associate a more user-friendly package name (application > name) to packages. > Say, they bind libreoffice-writer to "LibreOffice Writer" in package metadata. > > How about expanding metadata.xml (adding to its .dtd) to also support this?

Re: [gentoo-dev] About masking net-misc/mDNSResponder for removal

On 2/13/12 11:55 AM, Pacho Ramos wrote: > El jue, 09-02-2012 a las 12:41 +0100, Pacho Ramos escribió: >> Hello >> >> Looks like our net-misc/mDNSResponder packages are orphan and >> unmaintained for a looong time, they also have some opened bugs (with >> hangs, build problems...) and looks like ava

[gentoo-dev] dev-java/ant-core slot conflicts

I'm getting an annoying slot conflict while arch testing: !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-java/ant-core:0 (dev-java/ant-core-1.7.1-r4::gentoo, ebuild scheduled for merge) pulled in by

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

On 26/08/2018 12:53, Mart Raudsepp wrote: > The common issue here is that upstream COPYING files really do only > talk about one of the versions. And then you get to validate or source > files to be sure that they do have a "or later" clause in them. And > then on each bump you ideally should valid

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

On 26/08/2018 13:15, Michał Górny wrote: > I'm not aware of any major implications. However, I think that if we > provide for the distinction, the distinction should be used correctly. Makes sense. Note that this might also be an argument for _not_ providing such fine-grained distinction (unless

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

On 28/08/2018 00:46, Michael Mol wrote: > I can say that if the licenses are habitually misidentified, I could not use > Gentoo's portage tree in my job without extensive and ongoing revalidation of > the license metadata. > > There are, in fact, automated tools for advising about the license >

[gentoo-dev] tinderbox infrastructure project

On 07/09/2018 15:11, Andreas K. Huettel wrote: >> - Invest significantly in Infrastructure spending to fund ambitious >> projects. > > You need people who work on that first. > > Suggestion: Found a tinderbox project, get toralf, kensington, zerochaos, > mgorny, whoelse? on board, integrate thi

Re: [gentoo-dev] proposed update to toolchain.eclass

On 1/18/15 10:50 PM, Anthony G. Basile wrote: > Hi everyone, I'd like to make a commit to toolchain.eclass in a few > days. mgorny noticed some code which can be improved. Basically gcc > creates "fixed" include files from system headers because of the > requirement that it have ansi c compliant

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

On 2/20/15 12:10 PM, Ben de Groot wrote: > At the suggestion of radhermit, I'm putting my neovim & deps ebuilds > up here for review, before I commit them to the official tree. Do you > see any possible improvements? Overall the ebuilds look nice and clean. Some ideas: - consider asking libtermke

[gentoo-dev] do we need special elog messages for bindist?

I'm looking at which suggests removing elog messages chromium has for bindist: This is the snippet we use in the ebuild: if use bindist; then elog "bindist enabled: H.264 video support will be disabled." else

[gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org

On 2/26/15 9:23 AM, Robin H. Johnson wrote: > The Gentoo Infrastructure team is proud to announce that we have re-engineered > the mailing list archives, and re-launched it, back at archives.gentoo.org. > > [...] > > Major thanks to a3li, for his development of this project. Awesome work! I was

Re: [gentoo-dev] do we need special elog messages for bindist?

On 2/25/15 8:38 PM, Mike Gilbert wrote: > I would like to remove the elog for a couple of reasons: > > 1. The use flag description is there for whoever cares to read it. > There is no need to alert the user every time. > 2. We are not lawyers, and I have no business giving legal advice > about pat

[gentoo-dev] what's the correct format for bugs containing package name and version?

I'm trying to find the best fix for Currently file-stabilization-bugs.py uses the '%s: stabilization request' % cpv format. Here are some options I see: a) keep '%s:' as is b) change to just '%s' c) change to '=%s:' d) change to '=%s' e) something

Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM

On 6/3/15 10:56 PM, Mike Gilbert wrote: > The chromium build issue is a point of some contention; see the bug below. > > https://bugs.gentoo.org/show_bug.cgi?id=471810 > > I agree that it makes sense to check virtual memory. I guess that > would be MemTotal + SwapTotal in /proc/meminfo. > > It w

Re: [gentoo-dev] useflag policies

On 8/2/15 7:27 PM, Michał Górny wrote: > What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME > team policy. USE=qt would mean 'any version of Qt, if optional', and > qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be > obligatory, no USE=qt would apply. If only one Qt

<    1   2   3   4   5   6   >