Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sun, Jun 10, 2012 at 9:49 PM, Ciaran McCreesh wrote: > On Sun, 10 Jun 2012 21:45:27 +0100 > Nirbheek Chauhan wrote: >> It's a simple workaround for the lack of proper ebuild namespacing on >> the basis of slots. >> >> So, till we have that, this works pretty well. :) > > Until you have that, or something else designed to do what you want, > don't come up with some disgusting hack. > So the PMS process should be a bottleneck to getting software out to users? I think that's counter-productive. Our goal here is not to facilitate package manager development but to package and distribute software to users. On the other hand, you seem to be uniquely inclined to give a priority to this, and hence I implore you to continue your investigations into adding this feature to PMS and portage. :) Cheers, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] gtk3 useflag and support of older toolkits
On Sun, Jun 10, 2012 at 9:19 PM, Ciaran McCreesh wrote: > On Sat, 09 Jun 2012 23:54:21 -0400 > Alexandre Rostovtsev wrote: >> For libraries, if possible, try splitting gtk2 and gtk3 support into >> different slots (see net-libs/webkit-gtk for an example; the >> gtk2-based versions have -r2xx revision numbers and go in slot 2, >> while the gtk3-based versions have -r3xx revision numbers and go in >> slot 3). > > That is not what revisions are for. If you can't solve a problem > properly using existing mechanisms, ask for new ones. > It's a simple workaround for the lack of proper ebuild namespacing on the basis of slots. So, till we have that, this works pretty well. :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] net-misc/ntpclient up for grabs due solar concentrating in other packages
On Fri, Jun 8, 2012 at 3:06 PM, Nirbheek Chauhan wrote: > On Fri, Jun 8, 2012 at 2:58 PM, Pacho Ramos wrote: >> As talked with him via mail, thanks for taking it > > I think you missed the list of packages? > Hum, sorry about that. I got a bit confused there. :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] net-misc/ntpclient up for grabs due solar concentrating in other packages
On Fri, Jun 8, 2012 at 2:58 PM, Pacho Ramos wrote: > As talked with him via mail, thanks for taking it I think you missed the list of packages? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Thu, May 24, 2012 at 1:07 AM, Arun Raghavan wrote: > I, for one, think we should stay with CVS and leave all this git > Linusware to the new-fangled Fedora kids with their fancy init systems > and tight coupling. CVS was good enough for my grandfather, and it's > good enough for you. > +1 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
On Sun, May 20, 2012 at 6:55 PM, Michał Górny wrote: > On Sun, 20 May 2012 15:33:11 +0300 > Samuli Suominen wrote: > >> ChangeLog entries missing for every autotools.eclass modification >> today. > > I will repeat once again: autogenerate them. > +1 for this, seriously. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] autotools.eclass:eautoreconf now runs autopoint for you
On Sun, May 20, 2012 at 4:02 PM, Mike Frysinger wrote: > > i've extended eautoreconf to automatically call autopoint when the package > uses gettext. the configure check might seem naïve, but this is how > autoreconf > itself does it. this hopefully shouldn't break any packages (at least, > none > that weren't already broken), but if you guys start seeing eautoreconf > failures where there were none before, feel free to cc base-system. We went through this cycle in the GNOME team while working on live ebuilds. http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=eclass/gnome2-live.eclass;h=897adf863cb3f653ed96f45b14b637f7af651b1a;hb=HEAD#l110 You might want to cherry-pick some of those? Cheers, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Stability of /sys api
On Wed, May 16, 2012 at 1:59 AM, Walter Dnes wrote: > On Tue, May 15, 2012 at 02:32:57AM -0400, Olivier Cr?te wrote >> On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: >> > I *DON'T WANT* "a serious framework", I want a lightweight device >> > manager... period... end of story. Stick with the unix principle of one >> > app doing one thing well. mdev is enough for the vast majority of people. >> >> For the people who don't want to easily use USB sticks or digital >> cameras or gsm dongles or really any modern hardware, I'm sure mdev is >> fine. A static /dev is even fine for you probably. > > Huh!?!?!? USB sticks work just fine, thank you, with mdev. I also > regularly backup my mdev-based machine via rsync to an external drive > via USB. And yes my camera does show up as a USB mass storage device. > Ditto for my HTC Desire. > "Those who don't understand UNI^H^H^Hsoftware are condemned to reinvent it, poorly." -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: new global USE flag: jit
On Tue, May 15, 2012 at 1:52 AM, Maxim Kammerer wrote: > > On Mon, May 14, 2012 at 9:05 PM, Alexandre Rostovtsev > wrote: > > Current local flags that could probably be unified: > > What about USE=orc? It's JIT in a sense — IIRC, it creates an > executable in /tmp at run-time. > Doesn't make sense to unnecessarily unify USE-flags like that. "Consolidate just enough, but not too much." -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Sat, Feb 4, 2012 at 12:57 AM, Mike Frysinger wrote:
> On Friday 03 February 2012 11:44:42 Nirbheek Chauhan wrote:
> > On Fri, Feb 3, 2012 at 3:26 PM, Mike Frysinger
> wrote:
> > >> mozlinguas() {
> > >
> > > missing eclass documentation
> >
> > Is it really needed for private functions? Nothing should ever call this.
>
> needed ? no. nice ? sure. up to you as the maintainer, but the eclass
> doc
> format does support @INTERNAL on functions so it doesn't get exported to
> the
> man page.
>
Okay, that was my only concern (eclass doc). The function itself is
documented in the second line of the function body. I just moved that up
now.
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Fri, Feb 3, 2012 at 3:26 PM, Mike Frysinger wrote:
> please post it inline to make review easier
>
>> # @MAINTAINER: mozi...@gentoo.org
>> # @AUTHOR: Nirbheek Chauhan
>
> goes on newline, not inlined
>
Fixed
>> # @DESCRIPTION: Array containing the list of language pack xpis available
>
> text starts on the next line, not the existing line
>
Fixed
>> # @ECLASS-VARIABLE: LANGS
>> # @ECLASS-VARIABLE: LANGPACK_PREFIX
>> # @ECLASS-VARIABLE: LANGPACK_SUFFIX
>
> these prob could use MOZ prefixes as well
>
Fixed
>> : ${LANGS:=""}
>
> you say it's an array but then you initialize it to a string ...
>
Meh, no real difference. :p
Changed anyway!
>> if ! [[ ${PV} =~ alpha|beta ]]; then
>> for x in "${LANGS[@]}" ; do
>
> x is a global variable here ... one reason to write this as an internal func
> and then call it so you can use `local`
>
I just added an "unset x" at the end of the chunk, that should be
sufficient I think.
>> if [[ ${x} = en ]] || [[ ${x} = en-US ]]; then
>
> should be == imo
>
Fixed
>> SRC_URI="${SRC_URI}
>
> SRC_URI+="...
>
Fixed
>> IUSE="${IUSE} linguas_${x/-/_}"
>
> IUSE+="...
>
Fixed
>> mozlinguas() {
>
> missing eclass documentation
>
Is it really needed for private functions? Nothing should ever call this.
>> # Generate the list of language packs called "linguas"
>> # This list is used to unpack and install the xpi language packs
>
> shouldn't this initialize linguas=() ?
>
> and shouldn't it name the return value mozlinguas ?
>
Fixed, and renamed the function to mozlinguas_export()
>> # If this language is supported by ${P},
>> elif has ${lingua} "${LANGS[@]//-/_}"; then
>> # Add the language to linguas, if it isn't already
>> there
>> has ${lingua//_/-} "${linguas[@]}" ||
>> linguas+=(${lingua//_/-})
>> continue
>> # For each short lingua that isn't in LANGS,
>> # We used to add *all* long LANGS to the linguas list,
>> # but we stopped doing that due to bug 325195.
>> fi
>
> indentation on these comments seem to be off
>
No, that's on purpose. There used to be an `else` statement there.
That comment doesn't belong to the previous `elif` block. I've added
it outside a blank else block to clarify that.
>> # FIXME: Add support for unpacking xpis to portage
>> xpi_unpack "${MOZ_P}-${x}.xpi"
>
> or, add it to the new unpacker.eclass ;)
>
> also, seems to be missing `use linguas_${x} && xpi_unpack ...` ? otherwise,
> you just unpack all linguas and not just the ones the user has requested ...
> same goes for the install ...
>
No, "${mozlinguas[@]}" is already the intersection of MOZ_LANGS and LINGUAS.
>> if [[ "${linguas[*]}" != "" && "${linguas[*]}" != "en" ]]; then
>> einfo "Selected language packs (first will be default):
>> ${linguas[*]}"
>
> since linguas[*] will be big by default, i'd put the variable expansion into
> its own einfo
It's actually really small by default since it's the list of enabled langpacks.
Fixed version attached, thanks for the review!
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: mozlinguas.eclass
# @MAINTAINER:
# mozi...@gentoo.org
# @AUTHOR:
# Nirbheek Chauhan
# @BLURB: Handle language packs for mozilla products
# @DESCRIPTION:
# Sets IUSE according to MOZ_LANGS (language packs available). Also exports
# src_unpack and src_install for use in ebuilds.
inherit mozextension
case "${EAPI:-0}" in
0|1)
die "EAPI ${EAPI:-0} does not support the '->' SRC_URI
operator";;
2|3|4)
EXPORT_FUNCTIONS src_unpack src_install;;
*)
die "EAPI ${EAPI} is not supported, contact eclass
maintainers";;
esac
# @ECLASS-VARIABLE: MOZ_LANGS
# @DEFAULT-UNSET
# @DESCRIPTION:
# Array containing the list of language pack xpis available for
# this release. The list can be updated with scripts/get_langs.sh from the
# mozilla overlay.
: ${MOZ_LANGS:=()}
# @ECLASS-VARIABLE: MOZ_PV
# @DESCRIPTION:
# Ebuild package version converted to equivalent upstream version.
# Defaults to ${PV}, and should be o
[gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Thu, Feb 2, 2012 at 12:55 AM, Nirbheek Chauhan wrote:
> I'd love to have the attached eclass reviewed before I commit it. For
> those using gmail, here's a web copy: http://i.cx/ahp
> (git.o.g.o/mozilla)
>
After comments from mgorny on #gentoo-dev, I've made the following changes:
(a) Use mozlinguas() instead of linguas() (namespace)
(b) Use lowercase for local iterator variables
An updated eclass is attached (this time with a fake extension to get
gmail to see it as ascii text!).
Web version:
http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git;a=blob;f=eclass/mozlinguas.eclass;hb=HEAD
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: mozlinguas.eclass
# @MAINTAINER: mozi...@gentoo.org
# @AUTHOR: Nirbheek Chauhan
# @BLURB: Handle language packs for mozilla products
# @DESCRIPTION:
# Sets IUSE according to LANGS (language packs available). Also exports
# src_unpack and src_install for use in ebuilds.
inherit mozextension
case "${EAPI:-0}" in
0|1)
die "EAPI ${EAPI:-0} does not support the '->' SRC_URI
operator";;
2|3|4)
EXPORT_FUNCTIONS src_unpack src_install;;
*)
die "EAPI ${EAPI} is not supported, contact eclass
maintainers";;
esac
# @ECLASS-VARIABLE: LANGS
# @DEFAULT-UNSET
# @DESCRIPTION: Array containing the list of language pack xpis available for
# this release. The list can be updated with scripts/get_langs.sh from the
# mozilla overlay.
: ${LANGS:=""}
# @ECLASS-VARIABLE: MOZ_PV
# @DESCRIPTION: Ebuild package version converted to equivalent upstream version.
# Defaults to ${PV}, and should be overridden for alphas, betas, and RCs
: ${MOZ_PV:="${PV}"}
# @ECLASS-VARIABLE: MOZ_PN
# @DESCRIPTION: Ebuild package name converted to equivalent upstream name.
# Defaults to ${PN}, and should be overridden for binary ebuilds.
: ${MOZ_PN:="${PN}"}
# @ECLASS-VARIABLE: MOZ_P
# @DESCRIPTION: Ebuild package name + version converted to upstream equivalent.
# Defaults to ${MOZ_PN}-${MOZ_PV}
: ${MOZ_P:="${MOZ_PN}-${MOZ_PV}"}
# @ECLASS-VARIABLE: FTP_URI
# @DEFAULT-UNSET
# @DESCRIPTION: The ftp URI prefix for the release tarballs and language packs.
: ${FTP_URI:=""}
# @ECLASS-VARIABLE: LANGPACK_PREFIX
# @DESCRIPTION: The relative path till the lang code in the langpack file URI.
# Defaults to ${MOZ_PV}/linux-i686/xpi/
: ${LANGPACK_PREFIX:="${MOZ_PV}/linux-i686/xpi/"}
# @ECLASS-VARIABLE: LANGPACK_SUFFIX
# @DESCRIPTION: The suffix after the lang code in the langpack file URI.
# Defaults to '.xpi'
: ${LANGPACK_SUFFIX:=".xpi"}
# Add linguas_* to IUSE according to available language packs
# No language packs for alphas and betas
if ! [[ ${PV} =~ alpha|beta ]]; then
for x in "${LANGS[@]}" ; do
# en and en_US are handled internally
if [[ ${x} = en ]] || [[ ${x} = en-US ]]; then
continue
fi
SRC_URI="${SRC_URI}
linguas_${x/-/_}?
(
${FTP_URI}/${LANGPACK_PREFIX}${x}${LANGPACK_SUFFIX} -> ${MOZ_P}-${x}.xpi )"
IUSE="${IUSE} linguas_${x/-/_}"
# We used to do some magic if specific/generic locales were
missing, but
# we stopped doing that due to bug 325195.
done
fi
mozlinguas() {
[[ ${PV} =~ alpha|beta ]] && return
# Generate the list of language packs called "linguas"
# This list is used to unpack and install the xpi language packs
local lingua
for lingua in ${LINGUAS}; do
if has ${lingua} en en_US; then
# For mozilla products, en and en_US are handled
internally
continue
# If this language is supported by ${P},
elif has ${lingua} "${LANGS[@]//-/_}"; then
# Add the language to linguas, if it isn't already there
has ${lingua//_/-} "${linguas[@]}" ||
linguas+=(${lingua//_/-})
continue
# For each short lingua that isn't in LANGS,
# We used to add *all* long LANGS to the linguas list,
# but we stopped doing that due to bug 325195.
fi
ewarn "Sorry, but ${P} does not support the ${lingua} locale"
done
}
# @FUNCTION: mozlinguas_src_unpack
# @DESCRIPTION:
# Unpack xpi language packs according to the user's LINGUAS settings
mozlinguas_src_unpack() {
local x
mozlinguas
for x in "${linguas[@]}"; do
# FIXME: Add support for
[gentoo-dev] RFC: New eclass: mozlinguas.eclass
Hello folks,
We in the mozilla team got tired of duplicating the same 50 lines of
code across 6 ebuilds, and decided to consolidate them inside one
eclass.
The eclass is specific to Mozilla products (no one else can or should use it).
It generates SRC_URI using a list of supported language packs
${LANGS[@]}, and exports src_unpack and src_install to install
language packs.
I'd love to have the attached eclass reviewed before I commit it. For
those using gmail, here's a web copy: http://i.cx/ahp
(git.o.g.o/mozilla)
Thanks!
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
mozlinguas.eclass
Description: Binary data
Re: [gentoo-dev] Free Gentoo
On Sun, Jan 22, 2012 at 1:42 AM, Michał Górny wrote: > On Sat, 21 Jan 2012 21:01:26 +0300 > "." wrote: >> I'm also dissatisfied with the name of the distro. Linux is the kernel >> not the whole system. > > Please punish us by removing from distrowatch. Oh wait... > > I'm wonder why I'm replying to a mail sent by person who lacks enough > courage to sign him-/herself. I guess I want to be funny too. > Actually, I'm wondering how much cognitive dissonance it takes to complain about the possibility of using proprietary software in a mail sent via gmail. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 11, 2012 at 10:31 PM, Michał Górny wrote: > On Wed, 11 Jan 2012 10:34:34 -0600 > Dale wrote: >> I already stated the reason. I'm going to put /usr on LVM. That is >> not only a good reason, it is a GREAT reason. > > It is a hack. > https://fedoraproject.org/wiki/Features/UsrMove#Benefit_to_Fedora -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Last-rites: various packages needing esound
All these packages have dead upstreams, and are leaf packages which nothing else depends on, except with USE=esd, which is also masked for removal. Note: wmpop has replacements with the same name, the rest are useless. # Nirbheek Chauhan (04 Jan 2012) # Outdated and unused sound daemon. Why is this still in the tree? # Removal of esd and deps in 30 days. # In exceptional cases, you may use Pulseaudio's esound wrapper. media-sound/esound gpe-base/libsoundgen media-plugins/gst-plugins-esd media-sound/extace x11-plugins/wmpop x11-plugins/wsoundserver -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Exorcising a d(a)emon from GNOME's past (aka EsounD Last Rites)
On Fri, Jan 6, 2012 at 4:39 PM, Michael Weber wrote: > On 01/04/2012 04:42 AM, Arun Raghavan wrote: >> We've just made it optional in upstream git as well, so unless someone >> screams murder, I'm going to make esd support an off-by-default USE >> flag for media-sound/pulseaudio as well. >> > > MURDER!! > > Is the tree-cleaning really necessary? > Can't we just keep ESD as an working Option. Yes, it is necessary. EsounD causes subtle bugs in systems where it's installed, and there's no point testing for it since it has been bitrotting for ages. > PulseAudio is quite nasty and i would rather use *netcat* instead of > pulse for audio streaming. > Actually, you don't need netcat or pulse for audio streaming. You can use any streaming program (gst-launch, icecast, etc) to do that. Pulseaudio makes it really easy by exporting individual streams for each application, which allows easy management. EsounD has no advantages over icecast. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: Exorcising a d(a)emon from GNOME's past (aka EsounD Last Rites)
On Wed, Jan 4, 2012 at 9:03 PM, Mikko C. wrote: > Hi, > for me removing esound causes Thunderbird to not play sounds anymore. > Related bug is https://bugzilla.mozilla.org/show_bug.cgi?id=378155 > Also googling for "esound + thunderbird" yields quite a few results related > to this. The bug is quite clear on the status. The problem is with Thunderbird, which is not supposed to be using esound at all. Infact our thunderbird ebuilds don't even depend on esound => not a blocker for esound removal. It should use Alsa (libasound) or libcanberra to play sounds, which it obviously doesn't. No other distribution ships esound anymore, and if Thunderbird is being idiotic, it's upto their devs to fix the bug. Quite frankly, I'm shocked that Thunderbird *STILL* has code that depends on esound for playing wav files. Esound was deprecated half a decade ago. Thanks for reporting this bug! I'll keep track of it now and try to get it fixed. On Wed, Jan 4, 2012 at 6:48 AM, Nirbheek Chauhan wrote: > Hi folks, > > Today, I was shocked to find that the EsounD daemon is still in the > tree and new ebuilds are actually still pulling it in under USE=esd! > > Proposal: package.mask media-sound/esound, use.mask USE=esd. Anything > that still uses it should stop using it. Anything that /needs it/ > should be purged from the tree with extreme prejudice[1]. > > I'll do the first two today, and the rest of the rituals necessary to > complete the exorcism will take a month. Help in this regard is > welcome since the job is rather straightforward. > > Thanks! > > 1. In exceptional cases, a dependency on pulseaudio will also suffice > since pulseaudio emulates an esound socket while running with > `module-protocol-esound-unix` loaded, which is the default. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 6:43 PM, Rich Freeman wrote: > On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan wrote: >> Does mdev support all the rules we have in /lib/udev/rules.d/? The >> Internet is surprisingly mute on this subject, but a quick grep >> through the busybox source doesn't turn up anything that suggests that >> it might. > > I think the main use case for mdev is to do a one-time creation of > typical device nodes with minimal use of resources. In that case, you don't need a userspace daemon at all. Just use devtmpfs. That'll use even lower resources. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Exorcising a d(a)emon from GNOME's past (aka EsounD Last Rites)
Hi folks, Today, I was shocked to find that the EsounD daemon is still in the tree and new ebuilds are actually still pulling it in under USE=esd! Proposal: package.mask media-sound/esound, use.mask USE=esd. Anything that still uses it should stop using it. Anything that /needs it/ should be purged from the tree with extreme prejudice[1]. I'll do the first two today, and the rest of the rituals necessary to complete the exorcism will take a month. Help in this regard is welcome since the job is rather straightforward. Thanks! 1. In exceptional cases, a dependency on pulseaudio will also suffice since pulseaudio emulates an esound socket while running with `module-protocol-esound-unix` loaded, which is the default. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 1:05 AM, Rich Freeman wrote: > part of). For example, if eventually you can't run gnome without > systemd where does that leave bsd gentoo users? Is Mesa support on BSD really all that up-to-date these days? I don't expect that they keep up with bugfixes that well. For instance, Radeon works best with KMS + Gallium and afaik that has no driver for BSD at all. I don't think GNOME Shell is stable on BSD at all. > Gentoo is about > choice, and various upstream efforts are moving in the direction of > giving users only one choice - take it or leave it. If you're arguing purely on the basis of BSD, I think it's a lost cause. They're so far behind Linux that it's not even funny anymore. > How do you > install KDE and Gnome on the same system when they eventually want > different sysvinit implementations. I doubt that's going to happen, though. No DE other than GNOME is interested in vertical integration. Even if someone is, it's a technical problem to be solved with a technical solution. "Every problem in computer science can be solved by adding another layer of indirection". > Will the RedHat and Ubuntu of the > future have no more in common than Tivo and Android do today? > Setting aside the silly parts of comparison you've made, the rest is already true from the user's PoV. The two have drastically different UIs, and their packages are incompatible (rpm vs deb, yum vs apt). If some applications are indeed common between the two, it's no surprise since most of those run on Windows too. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, Jan 4, 2012 at 12:06 AM, William Hubbs wrote: > On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote: >> I don't think anyone's asked this yet: >> >> Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ? I realize that >> udev/kmod/systemd are moving, but there isn't anything in particular >> that would require everything else to move, is there? > > Well, I don't think everything is going to move immediately. The way I > see this happening is, udev/systemd/kmod are moving first, then other > upstreams will move their software. > >From what I can make out, *only* udev and systemd are making this a hard-and-fast thing so far. kmod has added a configure argument, and no one else has moved yet. In reality, fedora is patching a lot of packages to make them install in /usr. *If* GNU packages decide to move to /usr, *then* we can contemplate moving. Till then, I say let's just do whatever Debian is doing. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, Jan 1, 2012 at 2:23 PM, Sven Vermeulen wrote: > On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: >> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My >> understanding is that they want to move software that is installed in >> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move >> everything from /lib to /usr/lib. > > I don't like this one bit. Things used to be simple with the "split" between > /bin and /usr/bin (and its related directories), this isn't going to make it > more simple. Actually, I've always thought that the split between /usr/bin and /bin was quite arbitrary. However, I would like to note that merging /bin and /usr/bin would break some app combinations like bzip2+pbzip2, so that problem also needs to be solved (via eselect perhaps). Overall, this change "feels" wrong to me, but there's nothing intrinsically wrong with what they're suggesting. OTOH, it's probably just going to cause chaos and further divergence between distros for little gain. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Six month major project on Gentoo
On Thu, Dec 15, 2011 at 5:57 PM, Mike Frysinger wrote: > On Thursday 15 December 2011 00:39:44 Nirbheek Chauhan wrote: >> Nevertheless, the basic bug is about changing the distfile repository >> format in such a way that a single repo can contain several distfiles >> built with differing build conditions. Putting metadata in the >> filename is only one way of ensuring that. > > sounds like the summary needs updating then by someone who has waded through > all the followup comments ;) I didn't read every word, but I think I got the gist. I've changed the subject accordingly. :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Packages up for grabs due ian move to staffer
On Thu, Dec 15, 2011 at 4:31 AM, Pacho Ramos wrote: > Due ian move to staffer the following packages need a new maintainer: > app-portage/autounmask Is this still needed now that emerge has --autounmask* options? > app-portage/demerge > > > Thanks for taking them > -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Six month major project on Gentoo
On Thu, Dec 15, 2011 at 5:28 AM, Mike Frysinger wrote: > On Wednesday 14 December 2011 18:43:33 Alec Warner wrote: >> On Wed, Dec 14, 2011 at 1:25 PM, Leho Kraav wrote: >> > i'd be really happy if someone took care of >> > https://bugs.gentoo.org/150031 :> >> > >> > "include more info about binpkg in file name" >> >> That is great, but its not a 6 month project... > > is it though ? i'm inclined to mark INVALID. hijacking filenames for > metadata > is a tuuurrible idea. I agree. It's along the same lines as only using file extensions for determining the filetype (and we all know how that turned out...). It *does* have the advantage of being really fast, though. Nevertheless, the basic bug is about changing the distfile repository format in such a way that a single repo can contain several distfiles built with differing build conditions. Putting metadata in the filename is only one way of ensuring that. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/pkgcore: pkgcore-0.7.7.1.ebuild ChangeLog pkgcore-0.7.6.1.ebuild pkgcore-0.7.7-r1.ebuild pkgcore-0.7.7.ebuild
On Sat, Dec 3, 2011 at 6:45 AM, Brian Harring wrote: > Command history being: > > echangelog > # crap, need to redo it > rm ChangeLog > cvs up Changelog > echangelog > repoman commit -m "blah blah blah" > > See if you can spot the typo. ;) > Next time, use "cvs up" :p -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking
On Sun, Nov 27, 2011 at 1:36 AM, Zac Medico wrote: > GLEP 42 refers to GLEP 22, which says nothing of ~arch specifiers. The > current portage code literally compares the news item's keyword to the > current profile's ARCH variable, so ~arch specifiers will not match. The > code is in the DisplayKeywordRestriction class: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/news.py#l326 > Thanks for the information, I've committed the newsfile as is: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-news/2011/2011-11-27-gnome3-unmask/ PS: what do we have to do to get Display-If-Visible implemented? I volunteer to do whatever I can. :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking
On Sat, Nov 26, 2011 at 11:51 PM, Mart Raudsepp wrote: > On L, 2011-11-26 at 12:43 +0530, Nirbheek Chauhan wrote: >> A question: it currently restricts only on the basis of If-Installed, >> but is there a workaround for the absence Display-If-Visible filter? >> If there isn't, I'll commit it as-is. > > I think it'd be bad to get the news item out like that now for stable > users, and then after a long time once we stabilize it (if ever), it's > been long forgotten and marked away as read. Maybe the keyword checks > should be re-added for now and edited away later if necessary (before > stabling)? > I actually removed that keyword thing because I wasn't sure if it worked with ~arch specifiers. I think it's easier to just bump the news file version when we stabilize 3.2 so that people see it again. Presuming that that will work. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sat, Nov 26, 2011 at 9:49 PM, Mike Frysinger wrote: > On Saturday 26 November 2011 07:50:27 Nirbheek Chauhan wrote: >> I'm not sure the two are really comparable. However, looking at a >> simple string sort on 30,000 strings, I don't see it taking a >> significant amount of time at all: > > sure, it's probably not significantly higher, but i also can't see any point > in > sorting the entries. we've been doing fine so far in the 10+ years of it > being > unsorted. so unless Arfrever has a compelling reason, time to revert. > -mike > I agree. My argument was that if sorting has some benefit, the cost is negligible, and it should be done properly. If the benefits of the sorting are non-existent, or if it causes problems as Ciaran pointed out, then sorting should not be done. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sat, Nov 26, 2011 at 9:38 PM, Michał Górny wrote: > On Sat, 26 Nov 2011 21:28:51 +0530 > Nirbheek Chauhan wrote: >> There are still a few specific cases in which CoW would indeed be >> useful. IIRC, reflinking of files works across btrfs *subvolumes*, and >> such a copy would normally be detected as a cross-device move. > > For such a thing, shouldn't rename() work neat anyway? > No, because reflink is an ioctl that works directly on the FS level by sharing data blocks, and should theoretically not bother about the file hierarchy. On the other hand, rename() is a userland API and must behave itself. >> Another use would be an patch-merge which makes use of *ranged >> reflinks* to only CoW copy those parts of the file that were >> changed[1]. rsync has support for this, but only while appending to >> files (--append-verify --no-whole-file). > > So, it'd be like: > 1) CoW-dup old file, > 2) patch-merge into the duped old file, > 3) replace. > > Am I understanding correctly? > You can do that, or perhaps you can just do the patch-merge in-place. Not sure about the crash guarantees in the latter case. The former (rename) is documented here: https://btrfs.wiki.kernel.org/articles/f/a/q/FAQ_1fe9.html#What_are_the_crash_guarantees_of_overwrite-by-rename.3F But in all this, the hard part is really the "patch-merge" for anything except appends. ;) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sat, Nov 26, 2011 at 8:39 PM, Michał Górny wrote: > But in this particular case, I don't think COW is particularly useful. > If it works only on filesystem bounds, we could move the file directly > anyway. > There are still a few specific cases in which CoW would indeed be useful. IIRC, reflinking of files works across btrfs *subvolumes*, and such a copy would normally be detected as a cross-device move. Another use would be an patch-merge which makes use of *ranged reflinks* to only CoW copy those parts of the file that were changed[1]. rsync has support for this, but only while appending to files (--append-verify --no-whole-file). 1. Somewhat like rope data structures, with the caveat that ranges must be block-size aligned. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sat, Nov 26, 2011 at 7:14 PM, Rich Freeman wrote: > isn't supported. It is available in stable coreutils. Some speculate > that this option could increase fragmentation (both copies will share > extents from the original file, and have some extents of their own), > but btrfs doesn't overwrite anything in-place so fragmentation is a > potential issue with any file modification (change one byte in the Adding to your comments on this: To mitigate such issues, newer versions of the btrfs fs driver have automatic online defragmentation as well. Works quite well for moderate fragmentation. A particularly ghastly example where fragmentation issues become pathological in nature are files that are fsync()ed very frequently. A typical example are the *.sqlite files in ~/.mozilla which easily get hundreds or even thousands of fragments after a few hours worth of firefox usage (can be verified with filefrag). To fix such things, regular online defragmentation of those specific files can be done using `btrfs fi defrag `. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: RFC: Gentoo News file about GNOME 3.2's unmasking
On Sat, Nov 26, 2011 at 5:56 PM, Rich Freeman wrote: > On Sat, Nov 26, 2011 at 2:13 AM, Nirbheek Chauhan wrote: >> Since GNOME 3 is already in the >> tree, and the news file content is straightforward, I'd like to commit >> this in 24hrs if there are no problems. > > If we're gong to go to all the trouble to create upgrade guides and > news/etc, wouldn't it make sense to send out the news item a few days > BEFORE making the change? > That was indeed the intention, but there was a miscommunication. > If a user runs emerge -u world daily they wouldn't even see this news item. > > Obviously the horses have already left the barn, but maybe this is > something we can do differently when it comes time to stabilize the > change? > All is not quite lost. An elog was added to the end of gnome-base/gnome-core-libs which would be merged very early on in the upgrade process. Of course this is not a substitute at all, but does alleviate the issue. A forums post was also made by tetromino. > I'm sure this was inadvertent, but looking beyond just this particular > incident is there anything we can do to improve our use of news items? > Since we're a distro that uses rolling releases users really have no > way to know what to expect after any particular emerge world. It > could be some completely routine bump that isn't going to cause > problems, or it could require extensive rebuilding, config-file > tweaking, and risk of the system not booting. News is really the only > way to give them a heads-up in advance. Granted, something like a > gnome/kde bump is going to pull in so many packages that I think most > users would exercise caution, so that mitigates the issue a bit. > I think that the addition of a Display-If-Visible option would help, along with the addition of news file procedures to the devmanual and the quizzes. Even I didn't know where to commit the news file before some creative googling today gave me the right answer. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sat, Nov 26, 2011 at 5:08 PM, Fabian Groffen wrote: > On 26-11-2011 16:56:41 +0530, Nirbheek Chauhan wrote: >> [...] Besides, sorting even 30,000 >> entries (if you're merging every ebuild in portage) should not take >> more than a few secs. > > A linux kernel has around that much of files, and I really wonder if > it's worth waiting a couple of seconds (probably more on sparc and arm > systems) just because then the files are in sorted order. > I'm not sure the two are really comparable. However, looking at a simple string sort on 30,000 strings, I don't see it taking a significant amount of time at all: import random import time t1 = time.time() a = range(10, 13) random.shuffle(a) b = [str(i) for i in a] t2 = time.time() b.sort() t3 = time.time() print(t2-t1) print(t3-t2) 0.0682320594788 0.0464689731598 >> 1. I'm obviously assuming that dep nodes that do not depend on each >> other would be sorted > > I think this is per package. > Actually, reading the code it seems that it's about the file merge order of a single package. My participation in this entire discussion is m00t. Never mind. :p -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Sat, Nov 26, 2011 at 4:28 PM, Fabian Groffen wrote: > On 26-11-2011 01:54:35 +, Arfrever Frehtes Taifersar Arahesis wrote: >> commit: 1d4ac47c28706094230cb2c4e6ee1c1c71629aa0 >> T> Org> >> AuthorDate: Sat Nov 26 01:52:49 2011 + >> Commit: Arfrever Frehtes Taifersar Arahesis gentoo >> org> >> CommitDate: Sat Nov 26 01:52:49 2011 + >> URL: >> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1d4ac47c >> >> dblink.mergeme(): Merge files in alphabetic order. > > What's the advantage of this? I don't really like to pay for sorting a > potentially huge list just for some eye-candy. (That's omitted by > default these days anyway...) > Any other opinions on this one? > 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. Too many times have I sat waiting for libreoffice-bin to download while a webkit-gtk recompile waits in the queue. We already have the information during dependency resolution with --verbose, and it costs very little. Besides, sorting even 30,000 entries (if you're merging every ebuild in portage) should not take more than a few secs. 1. I'm obviously assuming that dep nodes that do not depend on each other would be sorted -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] RFC: Gentoo News file about GNOME 3.2's unmasking
Hello folks, Attached is a short news file announcing the unmasking of GNOME 3.2 with a link to the upgrade guide. Since GNOME 3 is already in the tree, and the news file content is straightforward, I'd like to commit this in 24hrs if there are no problems. It can also be found here: http://dev.gentoo.org/~nirbheek/gnome/2011-11-26-gnome3-unmask.en.txt (will be updated on the basis of comments). A question: it currently restricts only on the basis of If-Installed, but is there a workaround for the absence Display-If-Visible filter? If there isn't, I'll commit it as-is. Thanks! -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team Title: Unmasking of and Upgrade to GNOME 3.2 Author: Nirbheek Chauhan Content-Type: text/plain Posted: 2011-11-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: http://gnome.gentoo.org/howtos/gnome-3.2-upgrade.xml
Re: [gentoo-dev] Packages up for grabs due ricmm retirement
On Wed, Nov 23, 2011 at 12:33 AM, Nirbheek Chauhan wrote: > On Wed, Nov 23, 2011 at 12:16 AM, Pacho Ramos wrote: >> Due ricmm retirement the following packages need a new maintainer: >> > [snip] >> net-misc/youtube-dl >> > > I use this a lot, so I'll take it. > Just noticed that hanno and zmedico have been bumping it, so if you guys want, we can co-maintain. =) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Packages up for grabs due ricmm retirement
On Wed, Nov 23, 2011 at 12:16 AM, Pacho Ramos wrote: > Due ricmm retirement the following packages need a new maintainer: > [snip] > net-misc/youtube-dl > I use this a lot, so I'll take it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] elibtoolize/eautoreconf interactions and lazy eclasses/ebuilds
On Sun, Nov 13, 2011 at 11:15 PM, Samuli Suominen wrote: > also a bug in those ebuilds then, since gnome2_src_prepare() should > always be the last call/command in src_prepare() > It's slightly complicated. We don't always want gnome2_src_prepare to be the last call in src_prepare for live ebuilds, and ebuilds where we sed configure or Makefile.in directly to avoid an eautoreconf (it's extremely slow on arm/mips etc). It's very easy to not do the right thing. I think mike's change is a good thing. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Time to lastrite compiz AND blender due to lack of maintainer & broken
On Sun, Nov 13, 2011 at 3:01 PM, Luca Barbato wrote: > On 11/7/11 3:58 PM, Samuli Suominen wrote: >> >> On 11/07/2011 11:57 AM, Diego Elio Pettenò wrote: >>> >>> Il giorno dom, 06/11/2011 alle 19.37 +0200, Samuli Suominen ha scritto: >> Also blender should go, since we have had nothing usable in tree for a >> while[2]. > > I'm fixing it now, sorry but I got busy and blender isn't an easy > codebase... > Thanks for taking care of it. I care about blender too, but the codebase is daunting for me, so I couldn't commit to maintaining it. :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] have portage be quiet by default
On Sun, Nov 13, 2011 at 5:10 AM, Mike Frysinger wrote: > On Saturday 12 November 2011 17:24:08 Patrick Lauer wrote: >> Lots of people in #gentoo are unhappy with it. > > most changes people will be unhappy with because it's different > This is objectively true. That's why you weigh changes based on whether they yield a net gain. I don't have strong opinions about this, but from the beginning, I've thought that *always* showing verbose output in emerge wasn't really useful for general users except as a CPU-intensive screensaver. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
On Fri, Nov 11, 2011 at 3:02 PM, Brian Harring wrote: > On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom Chv??tal wrote: >> Hi guys, >> >> In last 3 days i recompiled chromium 3x >> >> 1x rebuild for cups useflag >> 1x update >> 1x rebuild for cups useflag > > > > Chromium moves fast and you're obviously running unstable keywording. > Meaning you're *intentionally* getting every beta channel release. > Actually, even in the mozilla team, we try to reduce the no. of revbumps and USE-flag changes ebuilds get by batching them up. Even though Firefox (and earlier xulrunner) doesn't have the crazy release cycle of Chromium (yet), it simply helps to reduce irritation for users. We try the same with webkit-gtk/evolution/e-d-s under GNOME (although, they don't require many updates anyway). Small things like these that cost little help in keeping users happy. It's a very easy development process change. I remember a blog post by the chromium team about this too, so they are aware of user complaints. scarabeus isn't the only one. :) Also, about attack vectors on beta builds of chromium, they're too fast-moving a target with a very low target population. Excessively unlikely that someone will release malware to attack a vulnerability in version 17.x.y.z. We don't need to go ape-shit over security of alpha/beta builds. Serious bugs, of course, should be fixed. OTOH, if you're seriously concerned about personalized attacks, you should be running adblock and noscript anyway. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible
On Sat, Nov 5, 2011 at 2:28 PM, Kacper Kowalik wrote: > Hi, > I'd like to ask that we enable verbose building by default. I have > cmake-utils.eclass in mind, because it's dead easy there, but there's a > lot of packages that support things like "make V=1" or "make VERBOSE=1" too. > > I've seen too many bugs reports today that gave me cute, colorful > build.logs and almost no information about underlaying bug... Is there a way to output the verbose log to build.log, but show the shortened log to the terminal? The non-verbose build is quite useful for seeing the actual warnings as they fly by rather than the entire gcc/libtool command, which is often mostly noise. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] linux-info.eclass: check_extra_config requires a configured kernel
On Fri, Nov 4, 2011 at 6:53 PM, Patrick Lauer wrote: > The running kernel is really irrelevant for those of us that build binpkgs. > /usr/src/linux is "more correct" in the case of binpkgs and most upgrade > scenarios where you don't reboot for a new kernel immediately. > Also, for out-of-kernel modules that need the kernel source for building, the build-time .config is much more relevant than the runtime config. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Old changelogs / eclass dir
On Mon, Oct 31, 2011 at 2:09 PM, Markos Chandras wrote: > There is always the problem with abandoned (but working) packages > which may have no commits in > 2 years. We'll end up with empty > ChangeLogs. > This is a simple technical problem, the solution of which is to take the "last 6 months" or "last one year" of activity, or the last 50 commits, whichever is more. Or something similar. It's not a fundamental problem with the idea. Note that this defence is not an endorsement of the idea itself. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: hardened glibc and gcc dependencies
On Fri, Oct 28, 2011 at 5:06 PM, Anthony G. Basile wrote:
> Approaching this naively, can't we just set EAPI="2" in the eclass, see
> what breaks and fix? Or is it more involved because some EAPI="0"
> ebuilds would be inheriting it and we'd need a lot of if "${EAPI}" == 0
> checks interspersed through the eclass?
>
afaik, eclasses aren't supposed to be setting EAPI. They can choose to
not support some EAPIs and error out, but they need checks.
Mostly, eclasses read ${EAPI} to do conditional exporting of phases
and conditional usage of features.
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: hardened glibc and gcc dependencies
On Fri, Oct 28, 2011 at 5:17 AM, Ryan Hill wrote: > On Thu, 27 Oct 2011 23:03:12 +0530 > Nirbheek Chauhan wrote: > >> So, I honestly see no reason why toolchain should not start using EAPI 2. > > I await your patch to toolchain.eclass. :P > Sure, whenever I'm feeling particularly masochistic and have devalued my sanity, I'll be sure to spend a few days on that... ;) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] hardened glibc and gcc dependencies
On Thu, Oct 27, 2011 at 9:38 PM, "Paweł Hajdan, Jr." wrote: > 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 allow use deps like > [hardened?]. > > I guess bumping the EAPI on those packages is not an option (is it?), so > I'm going to do some more experiments to see if there are more possible > problems. > As per council approval in the last meeting, profiles/ is now EAPI 1. EAPI 2 usage in profiles was not a blocker due to portage version problems, but due to unresolved questions about cat/pkg[use] atoms in package.mask etc. Barring those, EAPI 2 would've been approved for profiles/ as well. So, I honestly see no reason why toolchain should not start using EAPI 2. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, Oct 12, 2011 at 6:39 PM, Walter Dnes wrote: >> Goodbye desktop users then. >> >> We recently dropped HAL. Now all the magic that was done by HAL (and >> required udev anyway) is done through udev directly. > > My system worked just fine before HAL was introduced, thank you. I > always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask > and my system continued to work just fine, thank you. Given the great > HAL fiasco, the fact that HAL has been incorporated into udev is yet one > more reason for dropping udev . > Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. This thread is a waste of time. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Lastrite: media-gfx/pngcrush
On Tue, Oct 11, 2011 at 12:37 PM, Markos Chandras wrote: > On 10/11/11 06:22, Matt Turner wrote: >> On Sun, Oct 9, 2011 at 11:22 AM, Markos Chandras >> wrote: >>> I am not in QA fwiw just trying to keep a basic QA level in >>> portage tree. >> >> Wait, what? If you're not even in QA, then who are you to start >> masking other people's packages? >> > It seems you don't even bother to read the masking message or my > comments on the bug. I said "Talk to QA and CC me if you want to > discuss this further". Did you? Of course not cause you like trolling > publicly. > What is going on here? Why are you and Matt publicly slinging mud at each other and defiling this mailing list? Please behave like gentlemen, and not angry kids. I request you both to please take this conversation off the mailing list, and I encourage the pair of you to resolve your differences personally and amicably[1]. Preferably after a 24hr break to cool yourselves. Thank you. 1. If you persist, I offer to instead schedule a duelling session on IRC. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 11 Oct
Hello all, On Wed, Sep 28, 2011 at 10:52 PM, Fabian Groffen wrote: > Please respond to this email with agenda items. > I propose that profiles/ be migrated to EAPI 1 to allow the usage of atoms with SLOTs for package.mask, package.use.mask, etc. As I understand it, this just involves: echo 1 > profiles/eapi Since EAPI-1 supporting portage ebuilds have been stable for ~3 years now. Thanks, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Mon, Sep 26, 2011 at 7:57 AM, Zac Medico wrote: > On 09/25/2011 06:57 PM, Nirbheek Chauhan wrote: >> But neither portage, nor the portage tree, nor any of our branding are >> shipped with ChromeOS. Hence it's as much a Gentoo install as $company >> that uses portage to build $image for their embedded device, but >> doesn't leave any trace of Gentoo behind. > > So what? I work on Gentoo for the benefit of myself and others > (including Chrome OS devs), not because I want people to see Gentoo > branding, or have more people identify themselves as "Gentoo users." > I never meant to say that it's NOT beneficial to Gentoo. I've stated publicly, numerous times since the very beginning in emails, on IRC, twitter, etc. that the fact that ChromeOS uses Portage is and will be quite beneficial to us in many ways. If you recall my recent email to gentoo-core, I specifically talked about this. Please don't take my pedantic definition-wrangling as anything but pedantry. All I've been saying is that it's *misleading* to users for us to say that Google uses Gentoo on its Chrome Books. Google uses Gentoo's portage tools to build ChromeOS, which is hence arguably a *derivative* of Gentoo, but not really Gentoo. This is precisely what Mike said in his last email, and resolved his initial statement for me, which was ambiguous from my PoV. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Mon, Sep 26, 2011 at 7:02 AM, Mike Frysinger wrote: > On Sunday, September 25, 2011 05:53:18 Nirbheek Chauhan wrote: >> "Gentoo" is defined by portage and the portage tree. If we remove >> that, the end result is no different than compiling stuff manually in >> Slackware or by hand. > > which is how Chrome OS is built. > ROOT=/some/place emerge > Yes, I'm well aware of how ChromeOS is built. :) But neither portage, nor the portage tree, nor any of our branding are shipped with ChromeOS. Hence it's as much a Gentoo install as $company that uses portage to build $image for their embedded device, but doesn't leave any trace of Gentoo behind. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: udev and /usr
On Sun, Sep 25, 2011 at 12:05 PM, Mike Frysinger wrote: > On Fri, Sep 16, 2011 at 09:59, Rich Freeman wrote: >> I'm a bit concerned that the future of linux on the desktop is going to be >> one where your choices are things like Android, ChromeOS, Ubuntu, Gnome OS, >> or a "KDE OS." Each one would have its own package managers, repositories, >> distros, APIs, etc. Clearly there is some benefit from the vertical >> integration (Android and ChromeOS have a very high level of polish, and >> Ubuntu is approaching this often by just writing their own stuff). Instead >> of working to influence other projects (which can be frustrating), big >> distros are looking to just eliminate dependencies outside of themselves. >> This will be a big challenge for a smaller distro like Gentoo. Obviously we >> can't just go write our own Wayland replacement, even if we did essentially >> make our own "systemd" of sorts. > > you're aware the ChromeOS is built on top of / with Gentoo right ? "Gentoo" is defined by portage and the portage tree. If we remove that, the end result is no different than compiling stuff manually in Slackware or by hand. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: zlib breakage
On Sat, Sep 24, 2011 at 4:56 AM, Nikos Chantziaras wrote: > This was just another episode of Vapier's hostile and arrogant behavior > towards users. Every time someone comes up with a valid argument of why > he's wrong, the final answer is "don't care, I do what I please because I'm > the dev and you're not." So my reply was the politest I could come up with > without using the f-word. > If you felt like using swear words on bugzilla, you shouldn't be commenting there at all. Either be polite and know how to escalate, or don't speak at all. Publicly insulting people will not make them listen to you. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] zlib breakage
On Sat, Sep 24, 2011 at 3:48 AM, Andreas K. Huettel wrote: > Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him after > setting the group restriction. > That's not a very nice thing to do. However, Nikos didn't behave nicely either, so I don't quite blame vapier for his actions. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
On Tue, Sep 20, 2011 at 4:10 AM, Greg KH wrote: > p.s. and yes, this is the only reasonable explanation for this whole > thread, especially given the fact that this whole thing is explained in > extreme detail on the freedesktop.org site, and it has been beaten to > death on this very mailing list in the past. Otherwise what other > reason could this whole thing have been... > For reference, these are (some of?) the pages: http://www.freedesktop.org/wiki/Software/systemd http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Please don't use IUSE=static-libs unless really necessary
On Mon, Sep 19, 2011 at 2:25 AM, Michał Górny wrote: [snip] > '$(use_enable static-libs static)' themselves. While at it, it may be > better to just drop the flag if no other package relies on it and no > user has ever requested the static build of that package. > I don't see any harm with including IUSE="static-libs" for every package that has working/usable static libraries[1]. Why wait for users to request it on bugzilla when it's a near-zero-cost and zero-maintenance to add it to ebuilds? 1. An example of something with unusable static libraries: anything that links to libX11 (if I'm not wrong). -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
On Sun, Sep 18, 2011 at 7:57 PM, Jorge Manuel B. S. Vicetto wrote: > On 18-09-2011 12:59, Nirbheek Chauhan wrote: >> I'm astonished by the large amount of misinformation that is being >> spread around about systemd. If this originated on the gentoo-user >> mailing list, I'm disappointed that Gentoo users wouldn't do some >> basic research. >> >> I kind of expect this kind of trigger-happy FUD from websites like >> omgubuntu, but surely Gentoo folk are more mature. > > You mean that no Linux users, in particular anyone not running or not > wanting to run GNOME and Fedora, shouldn't be worried about the way > some people in the GNOME and Fedora community seem intent to impose > their ways to everyone else? If their ways are better, there should be absolutely no problem. > Worse, in the process seeming to want to > convince everyone they found the panacea and that the "old unix ways" > that have been around for 40+ years are all obsolete and that we > should give in to "the collective"? > I don't see how this is relevant to the problem of udev and /usr at all. Unless you want to go back to the days of devfs and lots of manual configuration. :) My problem was with people blaming the need for an initramfs on systemd, which is not true at all. The discussion of the relative merits and demerits of systemd is an entirely different discussion. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, Sep 18, 2011 at 7:50 PM, Jorge Manuel B. S. Vicetto wrote: > As we're talking about updating profiles EAPI, what do we need to get > to be able to mask use flags for the stable tree, but not the testing > tree? What's wrong with versioned masking of use-flags? The fact that they have to be constantly maintained is actually a good thing since it means that people will keep revisiting the mask with every STABLEREQ, and it won't get outdated and forgotten. > Also, should we get back to the discussion of decoupling > keywords from ebuilds and move them to profiles? > What's the use-case for this? What is the new proposed format to store the keywords? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] udev and /usr
On Sun, Sep 18, 2011 at 6:19 PM, Michał Górny wrote: > No, there isn't anything traumatic. The only thing systemd folks are > doing is nicely asking devs to include systemd unit files whenever > necessary or use the eclass whenever upstream supplies those files. > > In other words, some devs just found themselves a scapegoat. > ++ I'm astonished by the large amount of misinformation that is being spread around about systemd. If this originated on the gentoo-user mailing list, I'm disappointed that Gentoo users wouldn't do some basic research. I kind of expect this kind of trigger-happy FUD from websites like omgubuntu, but surely Gentoo folk are more mature. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Sun, Sep 18, 2011 at 10:56 AM, Zac Medico wrote: > On 09/17/2011 08:47 PM, Donnie Berkholz wrote: >> On 14:06 Fri 16 Sep , Zac Medico wrote: >>> Bumping the EAPI of the root profiles/eapi file would be a different >>> matter, since it applies to the whole repository. If you want to >>> version bump that repository-level EAPI, then you need to wait until >>> at least 6 months after supporting package managers have been >>> available in stable. >> >> So in your opinion, it would be fine to bump profiles/eapi to EAPI=4 >> now? > > Yes, it's feasible. As a consequence, we may get some complaints from > users who haven't upgraded during the last six months. I don't see any features in EAPI 3 and 4 that are useful for the profiles. However, a bump to EAPI 2 (or at least 1) would be *extremely* beneficial, and cause much less chaos. Speaking with my GNOME hat, it will be *extremely* useful for slot-masking GNOME packages. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Fixing eclass code relying on ${IUSE} greps?
On Wed, Sep 14, 2011 at 4:50 PM, Samuli Suominen wrote: > I second that. I've been "yelling" about it for years... > > Same for the stupid assumption gnome2.eclass does with IUSE="doc" for > gtk-doc > For reference, ye olde bug: https://bugs.gentoo.org/show_bug.cgi?id=262491 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [PATCH autotools-utils 1/9] Fix handling whitespace in filenames when looking for .la files.
On Tue, Sep 13, 2011 at 8:43 PM, Dirkjan Ochtman wrote: > 2011/9/13 Michał Górny : >> --- >> eclass/autotools-utils.eclass | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) > > I don't think sending 9 patches is very useful for this mailing list. > Next time just sent a link to a git repo or something? > On the contrary, I like that mgorny sent separate completely independent patches for review to the list instead of either sending on huge chunk, or not sending patches at all. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] obs eclasses
On Tue, Sep 13, 2011 at 8:29 PM, Donnie Berkholz wrote: >> HOMEPAGE="http://en.opensuse.org/openSUSE:OSC"; >> LICENSE="GPL-2" >> SLOT="0" >> IUSE="" >> RDEPEND+="dev-util/osc" > > You probably want a space here. > > RDEPEND+=" dev-util/osc" > Slightly bike-sheddy, but it's less error-prone to use: RDEPEND="dev-util/osc" iirc, portage handles merging of the values of *DEPEND defined in eclasses and ebuilds. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] virtual/polkit-agent virtual pkg
On Tue, Sep 6, 2011 at 9:50 PM, Fabio Erculiani wrote: > We have actually 3 polkit agent implementations in Portage: > > gnome-extra/polkit-gnome > lxde-base/lxpolkit > sys-auth/polkit-kde-agent > There's one more: gnome-base/gnome-shell GNOME Shell has its own polkit-agent implementation, which means that neither of these three should be running when GNOME Shell is running, otherwise they'll prevent the shell from showing well-integrated dialogs. The fallback mode still needs a separate polkit agent, though. > I guess a virtual is required. > Just a simple example, gnome-extra/nm-applet requires a polkit auth > agent (not present in RDEPEND atm -- bug!) in order to handle wifi > passwords, etc. > But the same applet can be used in both GNOME and LXDE, making > lxpolkit a better choice over polkit-gnome for the latter. > Actually, polkit-gnome is more like polkit-gtk. It has the same deps as lxpolkit (afaict), and is more widely used than lxpolkit. In addition, Davidz has stopped maintaining polkit-gnome, so we can stop worrying about him doing silly things to it. > My proposal is to create a virtual pkg listing all the polkit auth > agent implementations and make pkgs depend on it. > I'm ambivalent about this. I think I agree with what Samuli already said. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] USE=introspection has been unmasked in the tree
On Fri, Aug 19, 2011 at 8:04 PM, William Hubbs wrote: > On Wed, Aug 17, 2011 at 02:03:43AM +0200, Chí-Thanh Christopher Nguyễn wrote: > I tend to agree. I would rather see profile defaults here instead of > IUSE forcing on introspection at the package level. > > Remember that udev supports introspection, so if I put > IUSE="+introspection" in the udev ebuild, every system that has udev > will have introspection turned on by default unless users disable it. > That's for gudev, right? Anyway, I think system packages probably don't need to enable this by default. All other gobject-based libraries should, though. > Also, I see that dev-libs/glib wwants to force introspection onto my > system. I do not use gnome, so I don't know why I need introspection. > I added that use-flag because we were going to build and ship the glib typelibs and girs with glib because of this: https://bugs.gentoo.org/show_bug.cgi?id=324989#c6 But since we haven't done that, I've masked the use-flag till it doesn't do something as useless as simply pulling in gobject-introspection. > Nirbheek/gnome team: Please reconsider this and consider making > introspection a profile default instead. > I'm open to this, but I'll have to talk to the rest of the GNOME team before we decide. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] USE=introspection has been unmasked in the tree
On Wed, Aug 17, 2011 at 3:27 AM, Maciej Mrozowski wrote: > On Tuesday 16 of August 2011 22:14:28 Nirbheek Chauhan wrote: >> 2011/8/17 Chí-Thanh Christopher Nguyễn : >> > Then why don't you make it a default flag in desktop/gnome profile >> > instead? That way, the embedded users who don't use a desktop profile >> > won't even need to take action to disable the flag. >> >> We didn't do that because the use-case for not enabling introspection >> is a marginal one. > > Ah, use case like KDE, we get it, Nirbheek :D > As soon as it can be globally disabled (with a loss of functionality and > packages availability) I won't complain. > Anyone who installs gobject libraries, and wants to use language bindings with them will want introspection. This means python/vala/javascript for now, and *all* languages in the long run. If you use KDE, you simply won't install the various gobject libraries. The use-case for disabling introspection globally is if you will never use any gobject language bindings for the next 4-5 years. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] USE=introspection has been unmasked in the tree
2011/8/17 Chí-Thanh Christopher Nguyễn : > Nirbheek Chauhan schrieb: >>>> A side-note that we've wanted to get out to all devs is that everyone >>>> should *always* use IUSE="+introspection". >>> Then why is it a flag? >>> >> So that people who use, say, json-glib in embedded environments don't >> need to pull in a package that is quite unnecessary for them. >> > > Then why don't you make it a default flag in desktop/gnome profile > instead? That way, the embedded users who don't use a desktop profile > won't even need to take action to disable the flag. > We didn't do that because the use-case for not enabling introspection is a marginal one. We almost didn't even make it a use-flag. I think it would rather make sense to mask the use-flag in an embedded profile (small blacklist) than to enable it everywhere else (effectively a large whitelist). -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] USE=introspection has been unmasked in the tree
On Wed, Aug 17, 2011 at 12:29 AM, Donnie Berkholz wrote: > On 21:23 Tue 16 Aug , Nirbheek Chauhan wrote: >> A side-note that we've wanted to get out to all devs is that everyone >> should *always* use IUSE="+introspection". > > Then why is it a flag? > So that people who use, say, json-glib in embedded environments don't need to pull in a package that is quite unnecessary for them. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] USE=introspection has been unmasked in the tree
Hello folks, Introspection has finally been unmasked in the tree![1] This means that most of the issues with introspection have either been ironed out, or can be handled. Note that introspection was already being selectively unmasked on newer ebuilds using profiles/base/package.use.mask for quite a few months for this migration. This means that for most ~arch users this changes almost nothing, except that a ton of packages just got USE=introspection visible. For stable users, this changes nothing as well. The old package.use.mask whitelist of ebuilds has now been converted into a blacklist consisting of ebuilds that went stable before the whitelist was created. As those old stable ebuilds get removed due to age, the blacklist will winnow down and go away completely. For a list of some of the issues we had (and some minor problems that we still have) w.r.t. introspection, please see the following bugs: https://bugs.gentoo.org/show_bug.cgi?id=324989 https://bugs.gentoo.org/show_bug.cgi?id=350093 https://bugs.gentoo.org/show_bug.cgi?id=365413 A side-note that we've wanted to get out to all devs is that everyone should *always* use IUSE="+introspection". The reason for this is that the .gir and .typelib data that is installed is trivial compared to the rest of the package, takes just a few secs to generate, and is necessary for Python, Vala, and (in future) all other bindings. Also, if we don't do this, enabling USE=introspection on one package will cause the entire dependency tree all the way down to glib to be recompiled just for a few small 20KB files. Cheers! 1. Special thanks to pquery for making it easy for me to generate the package.use.mask blacklist. Hopefully I haven't made any human errors while generating the list :S -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: splitting virtual/
On Tue, Aug 16, 2011 at 12:11 AM, Michał Górny wrote: > Considering the number of different virtuals in this category, maybe it > would be a good idea to split it a little? What I'm proposing is maybe > creating some kind of '*-virtual' categories. > > For example, half of the current virtuals are prefixed with 'perl-'. > Maybe they could be transformed into 'perl-virtual/*'? > $ ls -1 /usr/portage/virtual/ | wc -l 155 $ ls -1 /usr/portage/dev-libs/ | wc -l 370 $ ls -1 /usr/portage/net-libs/ | wc -l 135 $ ls -1 /usr/portage/dev-util/ | wc -l 278 $ ls -1 /usr/portage/dev-perl/ | wc -l 1029 I don't see a pressing need to split virtual/ yet :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
Hey, On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen wrote: > In this email, I step away from the current model that Gentoo uses for > the gentoo-x86 repository. Instead, I consider a repo-per-package > model, as in use by e.g. Fedora [1] and Debian [2]. > > In short, the repo-per-package model means that each package > (my-cat/package) is a separate repository in some VCS. > Instead of having a huge tree that will only grow forever (gx86), > packages are just in their own repository. > I had mixed feelings while reading your email. The idea is certainly very intriguing, but there's a few things that make it a no-go for me: 1. One of the big things I've been looking forward to with git is the ability to do atomic commits across the tree. Addition of GNOME releases, pkgmove changes across the tree, changing ebuild/eclass behaviour, etc. without inconsistency or praying that my connection doesn't get dropped in the middle of a hundred interrelated commits. Without this feature, I think some arch teams and GNOME/KDE teams will become sad. 2. The ability to do "feature" commits across the whole tree instead of hundreds of tiny commits everywhere. This combined with the ChangeLog generation will save a lot of time and space. This will especially benefit arch teams, but I've felt the need for this numerous times myself. Example: we moved to using .xz tarballs for GNOME, and that touched a lot of ebuilds, and it was extremely time-consuming to repeat echangelog && repoman commit per-package. 3. Adding packages from overlays via `cherry-pick` or `git am` will become extremely tedious. If thin manifests are implemented, a series of patches + a simple merge hook will be all you need to move KDE/GNOME releases from the overlay to the tree. Without a single tree, you need to go back to the current way of doing things. 4. We'll need to write extra tools to keep the user's cat/pkg list up-to-date; adding and removing repositories as needed, etc. This is added complexity for which we'll need volunteers (we've been facing a manpower shortage already...) 5. The total size of the tree will increase a *lot* since all these repositories will no longer share data. The current gentoo-x86 tree stored in git without history takes only ~25MB because ebuilds are extremely redundant. The space requirements will balloon once we need to store 15,000 repositories. And arch teams will have to store *all* of them, often on devices with very low space. The per-package models looks very neat and tidy in some respects, but the loss of a common git repository is too great, IMO. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Ohloh statistics updated
On Sun, Jul 31, 2011 at 10:33 PM, Raúl Porcel wrote: > On 07/22/2011 03:11 PM, Stanislav Ochotnicky wrote: >> Hello fellow devs, >> [snip] > > Yey i'm number two :D > You're a bot, you don't count. ;) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] POSIX capability in Gentoo
On Sun, Jul 31, 2011 at 8:13 PM, Anthony G. Basile wrote: > Hi everyone, > > A couple of days ago, bonsaikitten (Patrick), kerframil (Kerin Millar) > and myself were talking about other distros moving away from setuid > binaries towards caps. Openwall and Fedora are now setuid-less [1]. > Some googling showed that Constanze has done quite a bit of work in the > area and that there was a consensus to include functions to set caps > within portage [2]. I don't know what, if anything has been done since > then, but I'd like to lend my support. > One problem that came up was that a lot of people use tmpfs for /var/tmp/portage, and tmpfs doesn't support xattrs which are needed for setting caps. Linux 3.0 has added support for xattrs with tmpfs (the redhat folks did the work, afaik), so that problem is partly solved now. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Ohloh statistics updated
On Mon, Jul 25, 2011 at 11:00 PM, Jeroen Roovers wrote: > On Fri, 22 Jul 2011 15:11:43 +0200 > Stanislav Ochotnicky wrote: > >> So go claim your commits, > > Great work! > >> [1] https://www.ohloh.net/p/gentoo >> [2] >> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary > > It appears they count rather more commits than does CIA - Manifest > commits look to be the likely cause. > Another reason for all of us to move to gpg signed manifests — another commit free with every ebuild commit! -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Ohloh statistics updated
2011/7/22 Stanislav Ochotnicky : > After 3 weeks of crunching (or was it more?) Ohloh machines finally spit > out updated statistics, removing few warnings from our project page > (such as "Decreasing year-over-year development activity""). Updates are > faster of course so our stats shouldn't be outdated anymore. > Awesome! More karma for you! I was waiting for this for a long time. :) -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: deprecation of baselayout-1.x
On Fri, Jul 1, 2011 at 11:03 AM, Dale wrote: > William Hubbs wrote: > As a user, if a person hasn't upgraded in about 6 months, they may as well > reinstall anyway. That is usually the advice given on -user. After a year > without updating, it is certainly easier and most likely faster to > reinstall. Except for the fact that while you upgrade, you still have a usable system. Reinstallation means a massive time-sink during which your machine is completely unusable. This is not an option for a lot of people. If -user is regularly giving that kind of advice, I think you guys are making a huge mistake. I'm not going to support this kind of max-6-month-upgrade life cycle for Gentoo. We're effectively driving our users away to distros like Ubuntu that allow you to upgrade every LTS release instead of constantly or every 6 months. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 9:16 PM, Ciaran McCreesh wrote: > On Wed, 29 Jun 2011 11:14:22 -0400 > Olivier Crête wrote: >> And you also underestimate the amount of momentum that Lennart has >> managed to amass behind systemd. I expect that much sooner than you >> think, we won't have a choice but to switch to systemd as many core >> components will start depending on it. > > Ah, are we talking about the "GNOME Operating System" here? If so, I'd > rather see Gentoo drop Gnome than force everyone to switch to using > DistributionKit... > Yes, I agree. We should be like Slackware which dropped GNOME in 2005. What an excellent decision they made and it helped them retain so many users too... -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 11:37 AM, Mike Frysinger wrote: > On Wednesday, June 29, 2011 01:48:16 Nirbheek Chauhan wrote: >> On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote: >> > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote: >> >> Honestly, I think a better solution would be to provide a convenience >> >> function library, independent of OpenRC. Sourcing random internal >> >> scripts of a random package is just broken by concept. >> > >> > except it hasnt been random and has clearly been defined by having >> > existed since the beginning of Gentoo >> >> I have no idea what this is supposed to mean. > > /etc/init.d/functions.sh has existed for the last decade, and was long ago > decided as the canonical public entry point for scripts external to baselayout > (as opposed to a path in /sbin/). it isnt going anywhere, and painting it as > something in flux at this point is disingenuous. > So... Gentoo's base system can never change, and hence new init systems are not welcome. Okay. Got it. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, Jun 29, 2011 at 10:35 AM, Mike Frysinger wrote: > On Wednesday, June 29, 2011 00:04:57 Michał Górny wrote: >> Honestly, I think a better solution would be to provide a convenience >> function library, independent of OpenRC. Sourcing random internal >> scripts of a random package is just broken by concept. > > except it hasnt been random and has clearly been defined by having existed > since the beginning of Gentoo > I have no idea what this is supposed to mean. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Sun, Jun 26, 2011 at 9:45 PM, Mike Frysinger wrote: > On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote: >> On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote: >>> On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote: >>>> On Sat, Jun 25, 2011 at 6:16 PM, justin wrote: >>>>> Another question, do we have a rule, how the metadata.xml has to be >>>>> indented? Tabs or n spaces? >>>> >>>> There's no rule, but we should follow the same rule as ebuilds — >>>> indentation should be with a tab that's displayed as 4 spaces in >>>> editors (no expansion of tabs to spaces). >>> >>> meh ... let devs do whatever they want >> >> Didn't I just say there's no rule? > > and if you keep reading, you'll see that you also said "devs should XXX" > should != must. I understand that you're touchy about rules after the whole ChangeLog mess, but must we debate the nuances of the English language and contribute to the massive amount of pre-existing bikeshed noise on this mailing list? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Sun, Jun 26, 2011 at 8:50 PM, Maciej Mrozowski wrote: > On Saturday 25 of June 2011 22:32:43 Jorge Manuel B. S. Vicetto wrote: >> *DEPEND=" >> !> !Y >> >> >> ... >> >> a? ( ) >> b? ( ) >> c? ( >> >> >> ) >> " > > ^^ is actually the main point of my "ebuild formatting nazi" agenda (usually > followed by "oh why did you break formatting in my shiny ebuild!11, revert!" > chants by various developers in case I happened to touch packages of theirs). > > I never understood the reason after keeping deps not sorted alphabetically > where order doesn't matter - it's like someone purposely made ebuild harder to > read - it's counter productive. > Well, the GNOME team likes to order it by "type" and "library heirarchy". So, libraries in one paragraph, then applications. Plain-C libraries first, followed by glib, and then glib-using libraries, and then gtk+, and gtk+-using libraries, then Python modules, etc. We also separate out lines with and without versions/blocks/use-conditionals in them to make them easier to read. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote: > On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote: >> On Sat, Jun 25, 2011 at 6:16 PM, justin wrote: >>> Another question, do we have a rule, how the metadata.xml has to be >>> indented? Tabs or n spaces? >> >> There's no rule, but we should follow the same rule as ebuilds — >> indentation should be with a tab that's displayed as 4 spaces in >> editors (no expansion of tabs to spaces). > > meh ... let devs do whatever they want > Didn't I just say there's no rule? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Sat, Jun 25, 2011 at 6:16 PM, justin wrote: > Another question, do we have a rule, how the metadata.xml has to be > indented? Tabs or n spaces? > There's no rule, but we should follow the same rule as ebuilds — indentation should be with a tab that's displayed as 4 spaces in editors (no expansion of tabs to spaces). -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Please migrate to git-2.eclass
On Sat, Jun 25, 2011 at 1:26 PM, Nikos Chantziaras wrote: > On 06/25/2011 12:35 AM, Michał Górny wrote: >> >> Hello, >> >> git-2.eclass is in the tree for a while now, and there's still awful >> lot of packages using old& deprecated git.eclass. > > I think I remember seeing deprecation warnings in the past when an ebuild > was using a deprecated eclass (right at the beginning when the emerge > starts.) Perhaps it would be a good idea to add one of those in git.eclass. > That's a horribly bad idea. Users should never need to see such things. The example you're thinking of is python.eclass, and that resulted in confused users filing bug reports. There's currently a repoman warning for git.eclass usage, and that suffices. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Packages up for grabs
On Mon, Jun 13, 2011 at 3:01 PM, Markos Chandras wrote: > 7) media-gfx/simple-scan I'm taking this since it's likely to be integrated with GNOME 3.2 or 3.4 Thanks, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: catalyst should use pbzip2 for stages
On Wed, Jun 8, 2011 at 1:55 AM, Mike Frysinger wrote: > isnt there a gentoo-release mailing list for catalyst and such ? > I presume this is so that users can extract stages using pbzip2 in parallel? Since pbzip2 can only parallel-extract bzip2 archives made with pbzip2? What's wrong with using lbzip2 instead of pbzip2? It can parallel decompress (and compress) *all* bzip2 archives, not just those made with pbzip2/lbzip2. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Proposal: include dbus session handling in baselayout (or somewhere, in which case where?)
On Wed, Jun 8, 2011 at 3:41 AM, Mike Frysinger wrote: > On Saturday, April 30, 2011 12:20:15 Leho Kraav wrote: >> /etc/profile.d/dbus-session.sh attached, looking for feedback about >> problems with it and if the whole approach even makes sense. I might be >> not knowing something important. > > i dont think this makes sense in baselayout. it works great without dbus. > > doesnt the login manager already take care of launching a dbus-session ? > I believe the use-case is being able to control applications from the VTs without having to launch a dbus session manually. Which should be done via ~/.bashrc, to be honest. Makes no sense to have a global dbus session, since it's supposed to be per-user. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Sun, Jun 5, 2011 at 1:30 PM, Fabian Groffen wrote: > On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote: >> All these problems are fixed if we don't re-generate the *existing* >> ChangeLogs. We should simply archive the existing ChangeLog, and >> append to it after the move to git. > > About this slightly hybrid approach: > > - the ChangeLog file is retained, some script just appends from VCS log > to it > * where is the ChangeLog file stored? > * is the VCS log appended to the ChangeLog every time it is generated, > or is it "committed" to the file? > - in case of a committed update to the ChangeLog file (commit hook? > repoman?), people would have the ability to edit the ChangeLog > I would suggest these things (I've omitted details irrelevant to ChangeLog management): (1) Convert using cvs2git, archive the old cvs repo. We now have a git repo with full history. (2) The new git tree must be without ChangeLog or (optionally) non-DIST Manifests. Remove all crud, git commit -m "Cleanup useless crud". Reason: no need to clutter the tree up with useless stuff that no one should touch. This will reduce the checked-out tree size by half. (3) No merge commits allowed to gentoo-x86.git. All commits must be rebased during pulls (git pull --rebase) or before pushing (git rebase && git push). Reason: keeps the history simple and easy to follow. The server can be made to reject merge commits. Most centralized git repos already follow this model. (4) No forced pushes which rewrite history are allowed to the server. Reason: well, this one is obvious. A lot of servers are configured to completely disallow this. (5) ChangeLogs do not exist in the git tree, they're maintained in a separate git repo by a script[1]. Reason: a git repo with history allows us to debug problems with the script, and follow its progress. (6) ChangeLog is updated incrementally with each changeset[2] (or every $time?), and the changes committed to its own git repo. This is made possible by (3) and (4). Reason: this way the workload of generating the ChangeLog won't increase at O(n*m) with time[3]. (7) The rsync server just copies over ebuilds, and then ChangeLogs, re-manifests (introducing non-DIST manifests if needed), maybe signs everything, and then pushes to mirrors. [1]. Note that pkgmoves would have to be detected and handled properly. [2]. This involves updating old ChangeLog entries if there are new git notes. [3]. n is the no. of commits per package, and m is the total no. of packages in the portage tree. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, Jun 2, 2011 at 6:29 PM, Fabian Groffen wrote:
> On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote:
>> > - no discussion on what to include or not (everything is in there)
>>
>> In git, we can make git log skip commit messages while generating the
>> ChangeLog, so this is incorrect. See section "Commit Limiting" in git
>> log --help.
>
> Assuming this is actually desirable, what rules would you suggest here?
>
Mostly only the trivial commits should be skipped. We should refer to
the other thread to decide what this consists of.
>> > Simple cons I see mentioned:
>> > - useless information on removals of ebuilds/files
>> > - useless information on whitespace changes
>>
>> None of these are valid with Commit Limiting and a tag such as
>> '[trivial]' in the commit message subject.
>
> By allowing this, "[trivial] old" is bringing you back to current policy
> ("commont sense") problems.
>
Yes, except that now it doesn't affect developers, and will result in
much less controversy. It certainly shouldn't come to forced
retirement. I don't see why we should bombard users with trivial
commits for political reasons...
>> Infact, if you do the same experiment on the openrc ChangeLog, you'll
>> see that it's too much work to regenerate the current ChangeLog
>> because a few commits managed to change the encoding of names in the
>> file, and a reverse-patch had to be applied to fix it. A number of
>> developers have made this mistake, and it shows up across the tree.
>
> I just created openrc's ChangeLog (attached to this mail). In what way
> exactly is it too much work? It's just a ChangeLog like many others, e.g.:
>
Ah, you don't include changes to ChangeLog as a part of your script.
Nevermind then :)
>> In git, there's no harm with making commit messages verbose, so we
>
> Why is this harmful with the current system?
>
Because it results in double the wasted space inside the repository.
Also, git is orders of magnitude better at compressing commit
messages, so the cost is massively lower.
>> > - a clear policy is necessary on what is going in the ChangeLog and what
>> > not (like the current "common sense" discussions going on and the
>> > updated devmanual)
>>
>> However, with git the issue is simplified because then developers will
>> stop relying on ChangeLogs for information, and ChangeLogs will be
>> used entirely to convey information to users.
>
> I don't see how that simplifies. I only see how that would completely
> change things/intents. Can you elaborate?
>
It simplifies things because most of the current situation arises from
shoe-horning of user as well as developer needs into a feature that is
supposed to be primarily user-oriented.
With CVS: "Trivial" changes that weren't documented in ChangeLog cause
breakage. cvs log/diff is too slow/hard to use, that delays
identification and fixing of breakage, and leads to a stricter policy
on ChangeLog updation.
With git: Changes that were marked [Trivial] in the commit message
cause breakage. git log, and you're done. There's no ChangeLog in the
git repo anyway, so no one will use ChangeLogs for this information.
This leaves us with user-oriented information. 99.99% of users won't
care about some commit messages being skipped from ChangeLog. Those
that do can clone the git repo, or sources.gentoo.org (which will be
faster with git). This doesn't mean we should skip *all* information
and not care at all. Just that the situation is less controversial
than before.
Cheers,
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, Jun 2, 2011 at 2:43 PM, Fabian Groffen wrote: > I start from the assumption that generation of ChangeLogs is NOT limited > to any VCS. This assumption is incorrect, but I guess it's a close enough approximation for the current discussion. > Simple pros I see mentioned: > - no more need for echangelog + repoman commit (identical message) This can be done without autogeneration as well. We can make repoman commit run echangelog before cvs commit. The main advantage is that there's no duplication of information, which would result in a less bloated repository. > - no discussion on what to include or not (everything is in there) In git, we can make git log skip commit messages while generating the ChangeLog, so this is incorrect. See section "Commit Limiting" in git log --help. > Simple cons I see mentioned: > - useless information on removals of ebuilds/files > - useless information on whitespace changes None of these are valid with Commit Limiting and a tag such as '[trivial]' in the commit message subject. > - inability to edit ChangeLog entries (typos, bug refs, etc.) > See "git notes --help". It allows you to append notes to commit messages without editing them. > 1) it appears echangelog messages more than just a couple of times > differ from the repoman commit messages; sometimes useful information > is lost when just using the VCS logs > 2) typo fixing on VCS-generated logs is sometimes necessary, but > probably impossible > 3) dates and new ebuilds generated from VCS are always correct, > ChangeLog editting/echangelog -> commit delays can cause > inconsitencies > 4) package moves might lose all history for essentially the same files > 5) entries for all commits show up, including those that weren't > originally tracked in ChangeLog for some reason > All these problems are fixed if we don't re-generate the *existing* ChangeLogs. We should simply archive the existing ChangeLog, and append to it after the move to git. Since the beginning, we've been working with the assumption that ChangeLogs can be edited. This has caused a *lot* of quirks to appear as you've demonstrated. Infact, if you do the same experiment on the openrc ChangeLog, you'll see that it's too much work to regenerate the current ChangeLog because a few commits managed to change the encoding of names in the file, and a reverse-patch had to be applied to fix it. A number of developers have made this mistake, and it shows up across the tree. > If a move to VCS-generated ChangeLogs is to be made, it appears the > council has to decide that the following is desirable: > - a commit message is supposed to be always right/correct > - since the commit message is right, either > - repoman commit runs echangelog, or > - ChangeLogs are generated on current CVS as well > - any typos and incorrect refs, bugs, messages, etc. are accepted as > drawback of the system that does not compare to its advantages We can append to existing commit messages using git-notes. Typos are hard to fix, but using git-notes to include sed commands, we can hack up a solution if there's a *pressing* need for it. As a result, commit messages are supposed to be double-checked with git log -p before pushing; but if you make a mistake, that can be fixed as well. > - it is accepted that all current information in the ChangeLogs gets > lost in favour of the VCS commit messages This is not an issue if we archive and re-use the current ChangeLogs. > - there is no point in discussing what should be in or out of a > ChangeLog, since by definition, "everything" is in (and tools should > effectuate so ASAP) > This issue will come up again if we implement commit-message limiting using a [trivial] tag. > If the council deems a separate ChangeLog file useful, they decide that: > - ChangeLog messages can (and sometimes should) be different from commit > messages, as they are intended as information for users In git, there's no harm with making commit messages verbose, so we should give as much information as possible. However, if some developers *really* don't want some lines to show up in the ChangeLog, they can prepend it with a '#omit' (or similar), and the ChangeLog-generating script will skip those lines. > - editting ChangeLog messages is necessary to emit the most correct > information to our users at all times Once again, git-notes. > - a clear policy is necessary on what is going in the ChangeLog and what > not (like the current "common sense" discussions going on and the > updated devmanual) However, with git the issue is simplified because then developers will stop relying on ChangeLogs for information, and ChangeLogs will be used entirely to convey information to users. > - basically nothing changes, and the whole idea of generating ChangeLogs > from VCS is no longer a point of discussion > I'm not sure I understand this. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto wrote: > On 01-06-2011 19:50, Nirbheek Chauhan wrote: >> The current situation is: >> >> (a) Not dire. >> (b) Not urgent. > > (c) has irked enough developers and users that people pushed council to > update the policy about the use of ChangeLogs. Yes, and I'm surprised that these same developers pushed towards a negative solution (kick productive people out) rather than a positive solution (move to git). >> And if we decide, hey, let's move to git instead of having this >> discussion, the current situation is also: >> >> (c) A waste of everyone's time. >> >> So no, future plans are not independent of the current situation, and >> a move to git *is* a way to deal with the current situation. >> >> In effect, we kill (at least) two birds with one stone and prevent a >> lot of argument and bad blood. > > To be clear I support the goal to move our tree to git. > However, I'd like to point out that simply moving to git will leave us > in the same state. Assuming everyone agrees that git is far more useful > than cvs to check for changes in the tree, a simple but important issue > remains: the plan is to move the "development tree" to git, but to keep > the rsync mirrors for users. So the "move to git" doesn't fix the issue > for users or developers using an rsync tree. Arguably, if developers want to know the history they should use the copy of the git tree that they're supposed to be having. Relying on ChangeLogs for history is just silly if you have the complete history at your fingertips with git. > One solution that has been proposed before and that was raised again in > this thread is to generate ChangeLogs directly from scm commit messages. > That is already a solution with cvs, so moving to git won't help here. This is not true. One of the main problems of generating ChangeLog messages from cvs/svn is that you don't have much control over the `cvs log` output, cvs itself is extremely slow, and cvs maintains log information *per-file*. Hence ChangeLog generation in the format we want would be slow/impractical. There's tens of thousands of packages. How long do you think it'll take to generate ChangeLogs from cvs for all of them? Notice how every project that did a move to git from cvs/svn started auto-generating ChangeLogs[1]. One reason was that ChangeLogs will *always* cause merge conflicts, and they're duplicate information, so there's no point keeping them in the local tree. The other reason is that with git it takes a fraction of a second to generate a ChangeLog from the commit messages. 1. https://live.gnome.org/Git/ChangeLog > The same objections that have been raised about doing it for cvs, not > being able to use different messages for the commit message and in > ChangeLog (something I understand but admit have hardly used before), > are also valid if we move to git. > Not really. This problem has been raised and the solution is to add a '[trivial]' or '#trivial' etc tag to the commit message (either subject of body), and it won't be included in the auto-generated ChangeLog. The main issue that people have with not writing ChangeLog messages for removals is that developers can't figure out when, why, and by whom an ebuild was removed; because there's no ChangeLog entry, and cvs log/cvs diff is too painful to use. This makes it hard to fix breakage. There's a fringe issue of users wanting to know why an 'old' ebuild was removed while they're offline in a train or something (and don't want to keep a cloned git repo around), but that's not reason enough to kick our second-most-hardworking developer. In essence, the most basic issue here is *not* users who want to have all information offline, but the fact that /developers/ rely on ChangeLog for information because cvs log/diff suck. Note that the developer in question always wrote proper commit messages, so `git log` WOULD solve all our problems. Cheers, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel wrote: > >> So we come back to the problem being *CVS* not ChangeLog rules. > > Well of course we can just tell everyone "go look it up on > sources.gentoo.org". > However, this is a different discussion. > sources.gentoo.org is a much worse (and slower) solution than cvs log. The main advantage of a ChangeLog (and of git) is that it allows you to check the history locally, without needing access to the network. >> All this is such a massive waste of time. Can't we just expend this >> energy on the move to git? > [snip] > We're not talking about future plans here but about the current situation. > And about how to deal with it. > The current situation is: (a) Not dire. (b) Not urgent. And if we decide, hey, let's move to git instead of having this discussion, the current situation is also: (c) A waste of everyone's time. So no, future plans are not independent of the current situation, and a move to git *is* a way to deal with the current situation. In effect, we kill (at least) two birds with one stone and prevent a lot of argument and bad blood. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
On Wed, Jun 1, 2011 at 9:09 PM, Andreas K. Huettel wrote: > Am Mittwoch 01 Juni 2011, 17:27:04 schrieb Samuli Suominen: > >> Wouldn't it be better to just trust devs to use common sense in what >> gets into ChangeLogs, and actually be grateful about if they take the >> time to sensor the crap out from it, and scrap the whole topic? > > The problem is, not everyone has the same notion of common sense. I hate > fumbling around with cvs, and see it as an absolutely great convenience if > the changelog clearly indicates when exactly an ebuild has been removed... > So we come back to the problem being *CVS* not ChangeLog rules. All this is such a massive waste of time. Can't we just expend this energy on the move to git? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
On Mon, May 23, 2011 at 12:43 PM, Michał Górny wrote:
> On Mon, 23 May 2011 12:35:12 +0530
> Nirbheek Chauhan wrote:
>
>> As I understand it, that's precisely what William's plan is.
>>
>> $ ls -ld /var/{lock/run}
>> /var/lock -> /run/lock
>> /var/run -> /run/
>>
>> This should work transparently for all existing applications.
>>
>> The only way this would fail is if they do an incorrect stat() on
>> /var/run and error out if it's a symbolic link. OTOH, it's precisely
>> to iron out such kinks that we have ~arch.
>
> What if a daemon tries to do braindead compat attempt through creating
> a pidfile in both directories?
>
I think the answer is obvious — we patch it to use /run/lock ...
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
On Mon, May 23, 2011 at 12:00 PM, Ciaran McCreesh
wrote:
> On Tue, 17 May 2011 19:12:38 -0500
> William Hubbs wrote:
>> On Tue, May 17, 2011 at 11:50:32PM +0100, Ciaran McCreesh wrote:
>> > I would be interested to hear how you plan to do the migration,
>> > given that everyone else has managed to screw it up...
>>
>> I'm not sure what you mean here. Openrc git will mount a tmpfs on /run
>> if it exists and create a lock directory inside the tmpfs.
>>
>> To make it work, I just need a new release of baselayout to make the
>> /run directory. Then, I also need to figure out where in the boot
>> process to make the symbolic links from /var/lock to /run/lock and
>> from /var/run to /run.
>> what else am I missing?
>
> The problem is that packages that have things installed to the old
> directories are going to get confused when upgraded if things have been
> moved around behind their backs.
>
> You may be better having both directories present, and not attempting
> to rename or move things at all. Then start fixing packages that install
> to the old directories.
>
As I understand it, that's precisely what William's plan is.
$ ls -ld /var/{lock/run}
/var/lock -> /run/lock
/var/run -> /run/
This should work transparently for all existing applications.
The only way this would fail is if they do an incorrect stat() on
/var/run and error out if it's a symbolic link. OTOH, it's precisely
to iron out such kinks that we have ~arch.
The other problem of daemons needing pre-existing directories is being
handled in https://bugs.gentoo.org/show_bug.cgi?id=332633
Cheers,
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] arch teams and better tools
On Mon, May 23, 2011 at 12:54 AM, Peter Volkov wrote: > Hi! > > В Вск, 22/05/2011 в 10:13 +0200, Thomas Kahle пишет: >> On 18:44 Sat 21 May , "Paweł Hajdan, Jr." wrote: > >> > Here's my answer to that, still in very early development: >> > <http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary> > >> Have you seen app-portage/tatt ? >> https://github.com/tom111/tatt > > It looks that quite similar functionality is required to open > stabilization bugs. It's really takes time to check that there is no > bugs opened in the package and all dependent libraries, then to copy all > maintainers and create list of packages with archs like: > > cate-gory/library-ver amd64 ppc ppc64 x86 > cate-gory/pkg-ver amd64 x86 > > Have anybody thought/programmed such tool? :) > One part of this, i.e. the generation of that list of packages with arches, is done by a script that the gnome and gstreamer herds use: http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=scripts/gen_archlist.py;hb=HEAD Usage: ./gen_archlist.py Reading the script leads to eye-bleeds (it needs to be rewritten), but it works quite well. Here's some example output: http://bugs.gentoo.org/show_bug.cgi?id=368281 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, May 18, 2011 at 3:56 AM, Drake Wyrm wrote: > Nirbheek Chauhan wrote: > Even if you don't have to wipe them with a service, you're going to need > to mount them with a service. You'll need to mount /run as tmpfs, create > the /run/lock directory, and then mount /run/lock as tmpfs. Do you > really want to add that to localmount? > (a) You don't need to mount anything except /run (b) Creating a directory in tmpfs takes so little time it's not even worth measuring. The same cannot be said of rotating media. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
