Wiki status

Hi list,

seeing Donnie link to a GSOC page on en.gentoo-wiki.com, I was wondering
about the status of our own, gentoo-hosted wiki. When gentoo-wiki.com
had its major failure, I was very frustrated and thus have some concerns
about planning GSOC or anything else there.

There are 17 people listed on http://www.gentoo.org/proj/en/wiki/ and
the last meeting seems to have been 10 months ago: so, what is the state
of the project? What is the timeline for the wiki? Is the team still
active at all? Could you be a bit more public about it or point me to an
url if I missed something? Thanks! :)

Best regards,

Craig

Re: Wiki status

On Tue, 01 Mar 2011 01:17:18 +0100
Stefan Behte <craig <at> gentoo.org> wrote:

> Hi list,
> 
> seeing Donnie link to a GSOC page on en.gentoo-wiki.com, I was
> wondering about the status of our own, gentoo-hosted wiki. When
> gentoo-wiki.com had its major failure, I was very frustrated and
> thus have some concerns about planning GSOC or anything else there.
> 
> There are 17 people listed on http://www.gentoo.org/proj/en/wiki/
> and the last meeting seems to have been 10 months ago: so, what is
> the state of the project? What is the timeline for the wiki? Is the
> team still active at all? Could you be a bit more public about it
> or point me to an url if I missed something? Thanks! :)

Why not email the wiki team, rather than everyone on the general -dev
mailing list?

glibc-2.12 stabilization process

we've had glibc-2.12 sitting in ~arch for long enough, and i think we've 
gotten used to its new features where other packages break with it.  looking 
at the tracker bug #331665, all tracked issues have been closed out in at 
least ~arch.  so before i start plodding through the list, people are 
encouraged to get things rolling themselves now.

if you have any such bugs, mark them as blocking #356913.
-mike

bash-4.2 going into ~arch

ive just added bash-4.2_p5, and will ~arch that this week at some point
-mike

Re: gtk 3 preparation work

On 2/28/11 11:34 PM, Nirbheek Chauhan wrote:
> Herd: chromium
> 	www-client/chromium-10.0.648.114
> 	www-client/chromium-10.0.648.82
> 	www-client/chromium-11.0.672.2
> 	www-client/chromium-11.0.672.2-r1
> 	www-client/chromium-11.0.672.2-r2
> 	www-client/chromium-9.0.597.94
> 	www-client/chromium-9.0.597.98
> 	www-client/chromium-9999
> 	www-client/chromium-bin-9.0.597.84

Latest ebuilds visible in ~arch should be fixed now. Older ebuilds
should get removed soon. If there's anything more to be done there,
please let me know.

Paweł Hajdan, Jr.

Re: gtk 3 preparation work

On Tue, Mar 1, 2011 at 4:04 AM, Nirbheek Chauhan <nirbheek <at> gentoo.org> wrote:
> On Mon, Feb 28, 2011 at 8:28 AM, Donnie Berkholz <dberkholz <at> gentoo.org> wrote:
>> On 11:13 Sun 27 Feb     , Gilles Dartiguelongue wrote:
>>> a quick mail to announce that the gnome team, in order to prepare for
>>> gnome 3, started slotting a lot of gnome team managed packages. If you
>>> find yourself using such a package, please update your ebuilds to use
>>> slot notations or other EAPI compliant notation resulting in the same
>>> effect.
>>
>> This email would be much more useful if it included a list of affected
>> packages, sorted by maintainer and/or herd.
>>
>
> As requested, here is a (probably) complete list of packages which
> depend on x11-libs/gtk+ without a slot. The list was generated using
> the tinderbox rindex, so it may be slightly out of date.
>

I just realized that there was a bug in my script which caused the
maintainer-sorted list to not group packages together. Attached is an
updated list.

--

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Herd: gnome-accessibility
	app-accessibility/dasher-4.11

Re: Adding app-arch/xz-utils to the system set

 On Mon, 31 Jan 2011 22:33:54 -0100, Jorge Manuel B. S. Vicetto wrote:
> Hello.
>
> Given the increased use of lzma compressed files, including on 
> portage
> snapshots, I'd like to add app-arch/xz-utils to the system set.
> We already have a few bugs about requiring xz-utils such as
> 347557[1] and 305127[2].
>
>  [1] - https://bugs.gentoo.org/show_bug.cgi?id=347557
>  [2] - https://bugs.gentoo.org/show_bug.cgi?id=305127
>
> Can anyone think of any reason "not" to do it?

 Well, the interesting bit of info is that the wider developer community 
 maybe already assumes it to be in the system set. *OR* can't be bothered 
 to remember that it is NOT in the system set. The data to back up this 
 statement is in https://bugs.gentoo.org/349315 in which ~20 packages are 
 discovered to be missing the build time dep.

 So, after 30 days on the mailing list..now does anyone have a reason to 
 not do it? The benefits are obvious in my opinion and they all lead to a 
 better user experience which should be the main goal. The drawbacks are 
 slim, which include but are not limited to, a larger system set [by one 
 package].

 Let's add it to improve the situation in general.

 Thanks,
 -Jeremy

Re: www-client/chromium icon theme dependencies, help needed

Does anyone else want to comment on this?

On 2/25/11 5:43 PM, Mike Gilbert wrote:
> On Fri, Feb 25, 2011 at 9:42 AM, "Paweł Hajdan, Jr."
> <phajdan.jr <at> gentoo.org> wrote:
>> Portage obviously doesn't know which DE the user is running (multiple
>> DE's may be installed on the system), so I don't see a way to create
>> "foolproof" dependencies.
>>
>> The two approaches I'm thinking about are:
>>
>> a) Drop any icon themes from RDEPEND, tell the user in pkg_postinst
>> about possible choices.
>>
>> b) Add "kde" to IUSE, and then kde? ( kde-base/oxygen-icons ) !kde ( all
>> || the || rest ) to RDEPEND.
>>
>> What do you think? Do you have some better ideas?
> 
> Option (a) sounds good to me. Maybe you could add something to the FAQ
> section on the project page so it will show up in Google search
> results.

Thank you for the feedback, that sounds like a good idea.

> Chromium should really have some generic fallback icon to use when it
> can't find an icon for a given mime type. A broken image icon is less
> than ideal for that. I guess that would be an upstream issue though.

Feel free to file an upstream bug. It might also be an issue with

Re: Adding app-arch/xz-utils to the system set

* Jeremy Olexa <darkside <at> gentoo.org>:
> Well, the interesting bit of info is that the wider developer
> community maybe already assumes it to be in the system set. *OR* can't
> be bothered to remember that it is NOT in the system set. The data to
> back up this statement is in https://bugs.gentoo.org/349315 in which
> ~20 packages are discovered to be missing the build time dep.

The same argument can be used to add app-arch/unzip to the system set.
~106 packages do not DEPEND on app-arch/unzip while using a zip file.

I think the missing dependency problem should be fixed by a repoman
patch.

The two bugs in the OP weren't PM-can-not-unpack-the-sources problems.
--

-- 
Regards Torsten

Re: gtk 3 preparation work

Could you provide a script, which checks and/or reports on ebuild basis,
which has to be fixed? It seems you already have one to create the list
you sent around.

Thanks justin