Re: [gentoo-dev] Help offered - Portage tree

[Luca Barbato]

Robin H. Johnson wrote:

- "What I am asking Gentoo Foundation is, let me fix them"
Apply to be a developer, then you can fix them. I don't personally have
any opinion (positive or negative) about Sabayon, but a former coworker
of mine was a big fan.


Addendum, the Foundation cannot do anything about that.

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Luca Barbato]

Raúl Porcel wrote:
Xulrunner-1.9 is a big change, and the apps using it won't work until 
they are fixed. So this needs to be decided, i've been working on 
slotting xulrunner, and i'm ready to put it in the tree. However i'd 
like to see what developers(since they will be the ones who will have to 
deal with this) and users prefer. Even if an app is compatible with 
xulrunner-1.9, it will have to be patched if we slot xulrunner. Since 
the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions 
with current xulrunner-1.8.
The other approach would be not slotting it, p.mask xulrunner-1.9 and 
wait until all the packages work against it and then unmask.


Given the number of applications I'd rather have them fixed with the 
patches pushed to respective upstreams if we got there first.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Donnie Berkholz]

On 17:12 Sat 15 Mar , Raúl Porcel wrote:
> That's what i would like to hear opinions about. Should we slot it, or 
> should we not slot it and wait until all the apps are fixed?

Favoring upstream's approach seems to better fit the Gentoo way. If 
upstream doesn't intend it to be slotted, neither should we.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Last rites: sci-electronics/lard

[Denis Dupeyron]

It finally happened. Last version was 5 years ago or so. From package.mask:

# Denis Dupeyron <[EMAIL PROTECTED]> (15 Mar 2008)
# Masked for removal in 30 days. Requires Tcl 8.3 which
# isn't in the tree anymore. See bugs 172356 and 173467.
sci-electronics/lard
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] [LAST RITES] mit-scheme

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Binary package mit-scheme has been masked and will be removed from the tree. 
Our overlay
has source mit-scheme-c ebuilds which is the C compiler backend.

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH3DOkp/VmCx0OL2wRAltSAJ4kq6LHxUqBAaQlM/IaSfVOyif1DQCghK3J
tgh2SCkK3NDmBFUUP/KT+s0=
=Mihm
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work

[Rémi Cardona]

Torsten Rehn a écrit :

On Saturday 15 March 2008, Rémi Cardona wrote:

Just curious, who would be the default assignee for those 2 new components?


I don't think anything should be changed here. Unpriviledged users 
automatically assign to bug-wranglers, everyone else goes for the target 
packages' maintainer.



Do you see any problem with this?


Nope, none at all, just wondering if anything were to change there.

Rémi
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work

[Torsten Rehn]

On Saturday 15 March 2008, Rémi Cardona wrote:
> Just curious, who would be the default assignee for those 2 new components?

I don't think anything should be changed here. Unpriviledged users 
automatically assign to bug-wranglers, everyone else goes for the target 
packages' maintainer.
Do you see any problem with this?

-- 
Torsten Rehn <[EMAIL PROTECTED]>
Gentoo AMD64 Arch Tester
http://scel.info


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-power/nut: ChangeLog nut-2.2.1.ebuild

[Jeroen Roovers]

On Sat, 15 Mar 2008 00:20:31 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:

> On 06:03 Sun 09 Mar , Rajiv Aaron Manglani (rajiv) wrote:
> > 1.1  sys-power/nut/nut-2.2.1.ebuild
> > 
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-power/nut/nut-2.2.1.ebuild?rev=1.1&view=markup
> > plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-power/nut/nut-2.2.1.ebuild?rev=1.1&content-type=text/plain
> 
> > src_install() {
> 
> ...
> 
> > eval fperms 0640 ${NUT_PRIVATE_FILES}
> > eval fowners root:nut ${NUT_PRIVATE_FILES}
> > 
> > eval fperms 0644 ${NUT_PUBLIC_FILES}
> > eval fowners root:root ${NUT_PUBLIC_FILES}
> 
> ...
> 
> > pkg_postinst() {
> > # this is to ensure that everybody that installed old
> > versions still has # correct permissions
> > 
> > chown nut:nut "${ROOT}"/var/lib/nut 2>/dev/null
> > chmod 0700 "${ROOT}"/var/lib/nut 2>/dev/null
> > 
> > eval chown root:nut "${ROOT}"${NUT_PRIVATE_FILES}
> > 2>/dev/null eval chmod 0640 "${ROOT}"${NUT_PRIVATE_FILES}
> > 2>2>/dev/null
> > 
> > eval chown root:root "${ROOT}"${NUT_PUBLIC_FILES}
> > 2>/dev/null eval chmod 0644 "${ROOT}"${NUT_PUBLIC_FILES} 2>/dev/null
> 
> Is there any reason why eval is used in either of these places?

Or indeed why potentially useful debugging information is redirected
to /dev/null... :)


Kind regards,
 JeR
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Rémi Cardona]

Raúl Porcel a écrit :
So, firefox-3, seamonkey-2, thunderbird-3 and other mozilla products 
will be using xulrunner-1.9, which is the codebase the mozilla products 
are based on. In fact, everytime you emerge any of those apps, you're 
compiling xulrunner, which takes 90% of the time to build. The good 
thing about those new versions, is that they'll be capable of using the 
xulrunner library installed of the system. So you only have to build 
xulrunner once, and you could build firefox-3, seamonkey-2, 
thunderbird-3 against it, and firefox-3 takes less than two minutes to 
build with shared xulrunner.


Brilliant! I thought they had dropped the idea of using xulrunner. Great 
to hear this!


Since firefox-3 seems usable now, i was thinking on adding it to the 
tree, however that'll need to add net-libs/xulrunner-1.9. Some apps use 
xulrunner at the moment[3], instead of building against firefox or 
thunderbird or seamonkey. Xulrunner is not mandatory to build firefox-3, 
in fact you can build firefox only with the current ebuilds in the overlay.


Do firefox and seamonkey still provide their own gtkmoz-embed? Are they 
still different (ie, almost the same, but not quite entirely 100% the 
same, although if you look at them they really look the same, but really 
they're not?)


My other question is this, can't we do a big community thing à la Bug 
Day where we make sure that all the apps that currently have 
firefox/seamonkey/xulrunner use flags all build against xulrunner 1.9 
and drop all other keywords for the sake of simplicity?


Anyhow, I'd say mask ff3 and xulrunner 1.9. Better fix things for real 
instead of having our own hand-made workarounds.


Cheers,

Rémi
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work

[Rémi Cardona]

Torsten Rehn a écrit :
Two weeks ago, dirtyepic suggested making some modifications to how ATs and 
developers interact using Bugzilla [1].


<+jakub> scel: basically... instead of KEYWORDREQ/STABLEREQ
<+jakub> create keywording and stabilization components
<+jakub> and use flags accordingly there
<+jakub> bugzilla already has the features, why not use them
<+jakub> also, nuke things like TESTED and STABLE


Just curious, who would be the default assignee for those 2 new components?

/me will vote for whatever helps to improve Gentoo :)

Cheers

Rémi
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work

[Dawid Węgliński]

Saturday, 15 of March 2008 17:37:15 Torsten Rehn wrote:
> Two weeks ago, dirtyepic suggested making some modifications to how ATs and
> developers interact using Bugzilla [1].
>
> <+jakub> scel: basically... instead of KEYWORDREQ/STABLEREQ
> <+jakub> create keywording and stabilization components
> <+jakub> and use flags accordingly there
> <+jakub> bugzilla already has the features, why not use them
> <+jakub> also, nuke things like TESTED and STABLE
>
+1 

-- 
Cheers
Dawid Węgliński


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Alexis Ballier]

Hi,

> Since the pkgconfig files for xulrunner-1.9 are renamed to avoid
> collisions with current xulrunner-1.8.

In general I dont think that is a good idea to do that as you said
we'll have to patch all the rev deps of xulrunner. More importantly
we'll have to carry on those patches forever because we're doing non
"standard" things.

> The other approach would be not slotting it, p.mask xulrunner-1.9 and 
> wait until all the packages work against it and then unmask.

I don't know how hard it would be but I think that's the best option.

Alexis.


signature.asc
Description: PGP signature

[gentoo-dev] [RFC] Bugzilla enhancements wrt AT work

[Torsten Rehn]

Two weeks ago, dirtyepic suggested making some modifications to how ATs and 
developers interact using Bugzilla [1].

<+jakub> scel: basically... instead of KEYWORDREQ/STABLEREQ
<+jakub> create keywording and stabilization components
<+jakub> and use flags accordingly there
<+jakub> bugzilla already has the features, why not use them
<+jakub> also, nuke things like TESTED and STABLE

This is trivial to implement and would greatly improve the ability to search 
for {STABLE,KEYWORD}REQs that have been tested by ATs. All ATs I've spoken to 
(most of the active ones at amd64) would really appreciate this change.

Discuss.

Also notice bug 213514 [2] for actual progress on this.

[1] 
http://archives.gentoo.org/gentoo-dev/msg_a5495659df35010ae44c266dd785ae4e.xml
[2] http://bugs.gentoo.org/213514

-- 
Torsten Rehn <[EMAIL PROTECTED]>
Gentoo AMD64 Arch Tester
http://scel.info


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?

[Raúl Porcel]

Okay, so here's the thing: Firefox 3 will be released probably some time 
during this year, as you probably know, they released a few days ago 
beta4 and beta5 will be out probably at the start of the next month or 
so. I started doing ebuilds for net-libs/xulrunner-1.9 and 
www-client/mozilla-firefox-3.0 in the mozilla overlay [1] since november 
2007, mainly thanks to Gergan Penkov's patches on his overlay, info 
available on the forums [2], which i've been adjusting them to do static 
releases and not livecvs ebuilds like he does.


So, firefox-3, seamonkey-2, thunderbird-3 and other mozilla products 
will be using xulrunner-1.9, which is the codebase the mozilla products 
are based on. In fact, everytime you emerge any of those apps, you're 
compiling xulrunner, which takes 90% of the time to build. The good 
thing about those new versions, is that they'll be capable of using the 
xulrunner library installed of the system. So you only have to build 
xulrunner once, and you could build firefox-3, seamonkey-2, 
thunderbird-3 against it, and firefox-3 takes less than two minutes to 
build with shared xulrunner.


Since firefox-3 seems usable now, i was thinking on adding it to the 
tree, however that'll need to add net-libs/xulrunner-1.9. Some apps use 
xulrunner at the moment[3], instead of building against firefox or 
thunderbird or seamonkey. Xulrunner is not mandatory to build firefox-3, 
in fact you can build firefox only with the current ebuilds in the overlay.


Xulrunner-1.9 is a big change, and the apps using it won't work until 
they are fixed. So this needs to be decided, i've been working on 
slotting xulrunner, and i'm ready to put it in the tree. However i'd 
like to see what developers(since they will be the ones who will have to 
deal with this) and users prefer. Even if an app is compatible with 
xulrunner-1.9, it will have to be patched if we slot xulrunner. Since 
the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions 
with current xulrunner-1.8.
The other approach would be not slotting it, p.mask xulrunner-1.9 and 
wait until all the packages work against it and then unmask.
That's what i would like to hear opinions about. Should we slot it, or 
should we not slot it and wait until all the apps are fixed?


Obviously, not slotting it will require to wait until upstream or a 
developer patches the app to work with xulrunner-1.9.


--

On the other hand, you won't be able to use firefox-3, seamonkey-2, 
thunderbird-3 to build an app against, since what the apps needs is 
xulrunner, not firefox or seamonkey.
So whatever is decided, please start fixing your ebuilds that use 
firefox, xulrunner, seamonkey or thunderbird, to stick the DEPEND to 


Thanks

[1] http://overlays.gentoo.org/proj/mozilla
[2] http://forums.gentoo.org/viewtopic-t-556225.html
[3] http://tinderbox.dev.gentoo.org/misc/rindex/net-libs/xulrunner
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Help offered - Portage tree

[Jakub Moc]

Fabio Erculiani napsal(a):

I'll try to file a huge bug on all the broken RDEPENDs
I'll found. I'll try to find a free slot during the end of the next
week for the hunting.


No, please don't. One bug per category is acceptable, no way I'm going 
to CC 150 maintainers on such monster bug and watch the resulting huge 
bugspam landing in bug-wranglers and other people's mailboxes, it's 
extremely annoying, extremely messy and generally not a good way to 
things fixed.



--
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 
3D9E


 ... still no signature   ;)
--
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-power/nut: ChangeLog nut-2.2.1.ebuild

[Donnie Berkholz]

On 06:03 Sun 09 Mar , Rajiv Aaron Manglani (rajiv) wrote:
> 1.1  sys-power/nut/nut-2.2.1.ebuild
> 
> file : 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-power/nut/nut-2.2.1.ebuild?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-power/nut/nut-2.2.1.ebuild?rev=1.1&content-type=text/plain

> src_install() {

...

>   eval fperms 0640 ${NUT_PRIVATE_FILES}
>   eval fowners root:nut ${NUT_PRIVATE_FILES}
> 
>   eval fperms 0644 ${NUT_PUBLIC_FILES}
>   eval fowners root:root ${NUT_PUBLIC_FILES}

...

> pkg_postinst() {
>   # this is to ensure that everybody that installed old versions still has
>   # correct permissions
> 
>   chown nut:nut "${ROOT}"/var/lib/nut 2>/dev/null
>   chmod 0700 "${ROOT}"/var/lib/nut 2>/dev/null
> 
>   eval chown root:nut "${ROOT}"${NUT_PRIVATE_FILES} 2>/dev/null
>   eval chmod 0640 "${ROOT}"${NUT_PRIVATE_FILES} 2>/dev/null
> 
>   eval chown root:root "${ROOT}"${NUT_PUBLIC_FILES} 2>/dev/null
>   eval chmod 0644 "${ROOT}"${NUT_PUBLIC_FILES} 2>/dev/null

Is there any reason why eval is used in either of these places?

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list