Re: [gentoo-dev] Bugzilla 4 migration

[Hans de Graaff]

On Mon, 2011-03-07 at 08:13 -0600, Donnie Berkholz wrote:

> Thanks! One thing I've been very interested about in 3.x and 4.x is API 
> access that's better than screen-scraping. I tried using the 
> python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't 
> seem to work. Do we have anything available?

I've tried an ipad application that uses xmlrpc and that seemed to work
fine.

Kind regards,

Hans


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

Re: [gentoo-dev] bugs.g.o - Bugzilla4 testing

[Jeroen Roovers]

On Sun, 6 Mar 2011 17:37:27 +0100
Dirkjan Ochtman  wrote:

> One thing I noticed is that by default, search now also searches
> "content", instead of just the titles. I rather liked the old
> behavior.

Yes, and it gets weirder when you search for a term that matches a
package name as well as, say, a USE flag, or anything else that might
turn up in someone's `emerge --info' output, which greatly increases
the number of hits. Since there is probably no smarter way for a
computer of doing this (unless we deploy IBM's Watson), reverting to the
old behaviour is probably the smartest thing we can do.


 jer

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

[Jeroen Roovers]

On Sun, 6 Mar 2011 14:17:37 +0100
Christian Faulhammer  wrote:

> Hi,
> 
> Christian Ruppert :
> > We're almost done with the preparation of bugzilla-4.x for
> > bugs.gentoo.org. So, do we want the new workflow or do we want to
> > keep the old?
> 
>  New one, reopened is a bit pointless information on first glance.
>  History tells enough.

It's an important flag for a bug wrangler.


 jer

Re: [gentoo-dev] multilib clean up

[Mike Frysinger]

On Monday, March 07, 2011 12:35:53 Thomas Sachau wrote:
> Am 07.03.2011 11:24, schrieb Mike Frysinger:
> > also, i'll be converting the glibc ebuilds do always invoke the
> > multilib_env helper functions.  this will allow us to drop the
> > {C,LD}FLAGS_xxx and friends from profiles since glibc was the main
> > consumer.  i imagine this inadvertently break some other packages, so
> > if people want to test this on their own systems before i make the
> > commit, that'd be cool.  the plan would be for said breakage will go
> > through bugzilla to get the ebuild updated rather than reverting the
> > profile.
> 
> Please leave those vars in the profile, i depend on them in
> multilib-portage to crosscompile e.g. for x86 on the amd64 profile. If you
> remove them now, they would be re-added again once multilib-portage (and
> the related EAPI) become official, so imho we can just leave them in for
> now.

these need to be centralized somehow.  duplicating multilib.eclass and the 
profiles indefinitely isnt going to fly.

perhaps we unify all the multilib settings into one file such as 
base/make.defaults ... that would require normalizing of the ABI value across 
all targets, but i dont think that's an issue.
-mike


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

Re: [gentoo-dev] Bugzilla 4 migration

[Mike Frysinger]

On Monday, March 07, 2011 16:32:55 Fabian Groffen wrote:
> On 07-03-2011 15:06:25 -0500, Olivier Crête wrote:
> > Maybe it's not to protect the user, but to protect the Gentoo
> > infrastructure.. And really, SSL has been supported by every browser for
> > the last 15 years. And it is not in any way slow or slower than non-SSL.
> 
> but the certificate security click-through-couple-of-times before you
> can access bugzilla is sort of annoying

i heard rumors the cacert is finally going into firefox ...

> As outsider, I don't like to accept another certificate thing, just to
> view a bugtracker.

if we're only forcing *login*, then this isnt an issue
-mike


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

Re: [gentoo-dev] Bugzilla 4 migration

[Mike Frysinger]

On Monday, March 07, 2011 16:59:22 Fabian Groffen wrote:
> On 07-03-2011 16:52:23 -0500, Rich Freeman wrote:
> > In any case, I don't see poor browser design as a valid reason for
> > avoiding the use of SSL...
> 
> Please use a MUA that properly honours Reply-To: headers.  I'm on the
> list.

subscribed != receiving.  there's no way of knowing who is.  get over it.
-mike


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

Re: [gentoo-dev] Bugzilla 4 migration

[Fabian Groffen]

On 07-03-2011 16:52:23 -0500, Rich Freeman wrote:
> In any case, I don't see poor browser design as a valid reason for
> avoiding the use of SSL...

Please use a MUA that properly honours Reply-To: headers.  I'm on the
list.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Bugzilla 4 migration

[Rich Freeman]

On Mon, Mar 7, 2011 at 4:32 PM, Fabian Groffen  wrote:
> As outsider, I don't like to accept another certificate thing, just to
> view a bugtracker.

When you think about it, this is a defect with your browser, and not
so much with SSL itself.

Your browser generally doesn't complain about unauthenticated
connections.  It accepts unauthenticated connections that aren't
encrypted without any issues, despite these being completely open to
numerous attacks.  However, your browser does complain when it makes
an unauthenticated connection that IS encrypted, even though this is
vulnerable to far fewer attacks.

Browsers shouldn't bug the user about self-signed certificates - they
should simply and clearly show that the user is connected to a host
that isn't authenticated by a trusted intermediate.

Oh, and browsers shouldn't come with root certs pre-installed by the
browser distributor either, but that is about as likely to get fixed
as the problem I just described.

In any case, I don't see poor browser design as a valid reason for
avoiding the use of SSL...

Rich

Re: [gentoo-dev] Bugzilla 4 migration

[Fabian Groffen]

On 07-03-2011 15:06:25 -0500, Olivier Crête wrote:
> Maybe it's not to protect the user, but to protect the Gentoo
> infrastructure.. And really, SSL has been supported by every browser for
> the last 15 years. And it is not in any way slow or slower than non-SSL.

but the certificate security click-through-couple-of-times before you
can access bugzilla is sort of annoying

As outsider, I don't like to accept another certificate thing, just to
view a bugtracker.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Bugzilla 4 migration

[Olivier Crête]

On Mon, 2011-03-07 at 20:47 +0100, Michał Górny wrote:
> On Mon, 7 Mar 2011 15:48:19 +0100
> Tobias Klausmann  wrote:
> 
> > On Mon, 07 Mar 2011, Mike Frysinger wrote:
> > > >> If *anybody* can't use SSL for any reason please yell so that we
> > > >> can decide if we leave it as it is (plain + encrypted) or not.
> > > >
> > > > Is there any *real* reason to force SSL? It is *hell* slow.
> > > 
> > > it should of course be force for logging in
> > 
> > If it is enforced for login, it should be enforced for logged
> > in sessions, cf. Cookie stealing (for a POC: Firesheep). And no,
> > restricting the login cookie to an IP is *not* "safe enough".
> 
> Why does everyone assume it needs to be enforced? If user is interested
> in protecting his/her data, he/she can simply use https://. If he/she
> is not, there is no real reason to enforce slower (and not always
> supported) SSL.

Maybe it's not to protect the user, but to protect the Gentoo
infrastructure.. And really, SSL has been supported by every browser for
the last 15 years. And it is not in any way slow or slower than non-SSL.


-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


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

Re: [gentoo-dev] Bugzilla 4 migration

[Christian Ruppert]

On 03/07/2011 08:47 PM, Michał Górny wrote:
> On Mon, 7 Mar 2011 15:48:19 +0100
> Tobias Klausmann  wrote:
> 
>> On Mon, 07 Mar 2011, Mike Frysinger wrote:
> If *anybody* can't use SSL for any reason please yell so that we
> can decide if we leave it as it is (plain + encrypted) or not.

 Is there any *real* reason to force SSL? It is *hell* slow.
>>>
>>> it should of course be force for logging in
>>
>> If it is enforced for login, it should be enforced for logged
>> in sessions, cf. Cookie stealing (for a POC: Firesheep). And no,
>> restricting the login cookie to an IP is *not* "safe enough".
> 
> Why does everyone assume it needs to be enforced? If user is interested
> in protecting his/her data, he/she can simply use https://. If he/she
> is not, there is no real reason to enforce slower (and not always
> supported) SSL.
> 
> It's like forcing everyone to have doors with semi-automatic locks.
> 

*I* think it's ok if we're going to protect *our* data. Some user may
even benefit from it.
I don't see any disadvantages for our users.

-- 
Regards,
Christian Ruppert
Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure
member
Fingerprint: EEB1 C341 7C84 B274 6C59  F243 5EAB 0C62 B427 ABC8



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Bugzilla 4 migration

[Michał Górny]

On Mon, 7 Mar 2011 15:48:19 +0100
Tobias Klausmann  wrote:

> On Mon, 07 Mar 2011, Mike Frysinger wrote:
> > >> If *anybody* can't use SSL for any reason please yell so that we
> > >> can decide if we leave it as it is (plain + encrypted) or not.
> > >
> > > Is there any *real* reason to force SSL? It is *hell* slow.
> > 
> > it should of course be force for logging in
> 
> If it is enforced for login, it should be enforced for logged
> in sessions, cf. Cookie stealing (for a POC: Firesheep). And no,
> restricting the login cookie to an IP is *not* "safe enough".

Why does everyone assume it needs to be enforced? If user is interested
in protecting his/her data, he/she can simply use https://. If he/she
is not, there is no real reason to enforce slower (and not always
supported) SSL.

It's like forcing everyone to have doors with semi-automatic locks.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] multilib clean up

[Thomas Sachau]

Am 07.03.2011 11:24, schrieb Mike Frysinger:
> i plan on punting these (hardly used) functions from the
> multilib.eclass (once the handful of open bugs are closed):
>   get_ml_incdir
>   prep_ml_includes
>   create_ml_includes
>   create_ml_includes-absolute
>   create_ml_includes-tidy_path
>   create_ml_includes-listdirs
>   create_ml_includes-makedestdirs
>   create_ml_includes-allfiles
>   create_ml_includes-sym_for_dir
> further, the CDEFINE_xxx multilib vars will go with them
> 
> for the most part, these were really only used by the glibc ebuilds.
> for the ones that dont support multilib natively (and necessitated
> these funcs in the first place), i'll simply punt the ebuilds.  this
> will probably be just the glibc-2.5 ebuilds for now.
> 
> also, i'll be converting the glibc ebuilds do always invoke the
> multilib_env helper functions.  this will allow us to drop the
> {C,LD}FLAGS_xxx and friends from profiles since glibc was the main
> consumer.  i imagine this inadvertently break some other packages, so
> if people want to test this on their own systems before i make the
> commit, that'd be cool.  the plan would be for said breakage will go
> through bugzilla to get the ebuild updated rather than reverting the
> profile.
> -mike
> 
> 

Please leave those vars in the profile, i depend on them in multilib-portage to 
crosscompile e.g.
for x86 on the amd64 profile. If you remove them now, they would be re-added 
again once
multilib-portage (and the related EAPI) become official, so imho we can just 
leave them in for now.

-- 
Thomas Sachau

Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrite: media-libs/glitz

[Nirbheek Chauhan]

On Mon, Mar 7, 2011 at 10:57 PM, Samuli Suominen  wrote:
> # Samuli Suominen  (07 Mar 2011)
> # No longer needed package wrt #330397. Removal in 30 days.
> media-libs/glitz
>
>

And there was much celebration amongst the populi!

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

[gentoo-dev] Lastrite: media-libs/glitz

[Samuli Suominen]

# Samuli Suominen  (07 Mar 2011)
# No longer needed package wrt #330397. Removal in 30 days.
media-libs/glitz

Re: [gentoo-dev] Bugzilla 4 migration

[Donnie Berkholz]

On 16:35 Mon 07 Mar , Dirkjan Ochtman wrote:
> On Mon, Mar 7, 2011 at 15:13, Donnie Berkholz  wrote:
> > Thanks! One thing I've been very interested about in 3.x and 4.x is API
> > access that's better than screen-scraping. I tried using the
> > python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't
> > seem to work. Do we have anything available?
> 
> Is that the one you get if you emerge pybugz?

No, pybugz is a screen-scraper. We previously had Bugzilla 2 so we 
couldn't do anything else.

> The Mozilla guys made a pretty nice REST API that can be installed as a
> plugin, I think. Maybe we could run that?

I've been somewhat following that too, but I don't know if anyone's 
written a CLI client for it yet, whereas python-bugzilla already exists 
(and has an ebuild in the sabayon overlay).

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpXcCnIenCNR.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla 4 migration

[Dirkjan Ochtman]

On Mon, Mar 7, 2011 at 15:13, Donnie Berkholz  wrote:
> Thanks! One thing I've been very interested about in 3.x and 4.x is API
> access that's better than screen-scraping. I tried using the
> python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't
> seem to work. Do we have anything available?

Is that the one you get if you emerge pybugz?

The Mozilla guys made a pretty nice REST API that can be installed as a
plugin, I think. Maybe we could run that?

Cheers,

Dirkjan

Re: [gentoo-dev] Bugzilla 4 migration

[Mike Frysinger]

On Mon, Mar 7, 2011 at 9:48 AM, Tobias Klausmann wrote:
> On Mon, 07 Mar 2011, Mike Frysinger wrote:
>> >> If *anybody* can't use SSL for any reason please yell so that we can
>> >> decide if we leave it as it is (plain + encrypted) or not.
>> >
>> > Is there any *real* reason to force SSL? It is *hell* slow.
>>
>> it should of course be force for logging in
>
> If it is enforced for login, it should be enforced for logged
> in sessions, cf. Cookie stealing (for a POC: Firesheep). And no,
> restricting the login cookie to an IP is *not* "safe enough".

you're talking about two different things.  imo it's more important to
protect the credentials than spoofing/replay attacks.  the former is a
no brainer while the latter is fine to leave to the discretion of the
end user.
-mike

Re: [gentoo-dev] Bugzilla 4 migration

[Dane Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/2011 09:48 AM, Tobias Klausmann wrote:
> Hi! 
> 
> On Mon, 07 Mar 2011, Mike Frysinger wrote:
 If *anybody* can't use SSL for any reason please yell so that we can
 decide if we leave it as it is (plain + encrypted) or not.
>>>
>>> Is there any *real* reason to force SSL? It is *hell* slow.
>>
>> it should of course be force for logging in
> 
> If it is enforced for login, it should be enforced for logged
> in sessions, cf. Cookie stealing (for a POC: Firesheep). And no,
> restricting the login cookie to an IP is *not* "safe enough".
> 
> Regards,
> Tobias
> 

First off, a big thanks to infra and all involved in the migration. It
looks awesome!

As to the SSL bit, there is *no* reason not to be using SSL for anything
that requires a username / password. And I 100% agree with Tobias. If
it's necessary to use SSL to login, it's necessary to use it for the
duration of the session. I don't know how feasible it is to do, but if
normal viewing (no login) can be left SSL free, I see no issue there.
Otherwise however, SSL should be in use.

Regards,
- -- 
Dane Smith (c1pher)
Gentoo Linux Developer -- QA / Crypto / Sunrise / x86
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNdPDCAAoJEEsurZwMLhUxFtUP/istnBrfWjaj8SoHmweB5Uh8
Fblpar2tWVqqSORPV0fkXnYogXK8EbSl4eQDo6Q5LZt4OUzP2T4rLOrrexaxL2s/
GzKYHeoEsUKAfkZa5W3bmL8ZaL0ueYFqM/ucx1r9iGEqEOIr33G3eaR3AlaovmjV
Qw/r0McPFJDxqZz+79Xl/sFTFJaDHebEKiYT9Y40m3+6Ha4EqWcZ5DLX41/kfE77
Du+hCdf5J3E29vED3qtY5FBrmzG4ILBPCXbYxW8IMbpizQAzj7XzH8ZxjA9OvPOJ
S0kxrjQR9oFodiPETYf/vOpsHlp/D3+HECRo4Qa1OJBdkb70ci+5XHoY3GvdAKUe
MN3jCf94CSxlCyJcngWoyiu9j93l2Z3ctjq3cHo1dH4ETo686jyKFm4xBBkm4UrF
Co6c/pkX+78m2Py4hcWml+X2reYMurTC0dRG42YCW3dXRMJha6OZKIKXTf19FakL
bEd0adIK99t+N3i63yKIsd9p5SrU0H2ysJtX2wNyUVMAYnAad7gn7SGCKCytmvAo
4R8to3O7DitfIXAAz78Zj5vwa9VIbPu8dCTV0zo2XHE5EOXfu87YMQYKQQU1KwXK
9Rx0ZLys+vQCJL1EhezXBRcG39ksVHI1/hytD3LMTeRRXeQLJUrE3LK64mxtEARH
f7uLbv3dNgsjbhIM7jfQ
=CxR9
-END PGP SIGNATURE-

Re: [gentoo-dev] Bugzilla 4 migration

[Tobias Klausmann]

Hi! 

On Mon, 07 Mar 2011, Mike Frysinger wrote:
> >> If *anybody* can't use SSL for any reason please yell so that we can
> >> decide if we leave it as it is (plain + encrypted) or not.
> >
> > Is there any *real* reason to force SSL? It is *hell* slow.
> 
> it should of course be force for logging in

If it is enforced for login, it should be enforced for logged
in sessions, cf. Cookie stealing (for a POC: Firesheep). And no,
restricting the login cookie to an IP is *not* "safe enough".

Regards,
Tobias

-- 
Sent from aboard the Culture ship
GSV Zero Gravitas

Re: [gentoo-dev] Bugzilla 4 migration

[Donnie Berkholz]

On 09:51 Mon 07 Mar , Robin H. Johnson wrote:
> The Gentoo for the Bugzilla service went perfectly, a huge thanks to
> idl0r for the years of work he has put into them.

Thanks! One thing I've been very interested about in 3.x and 4.x is API 
access that's better than screen-scraping. I tried using the 
python-bugzilla client that accesses Bugzilla via XML-RPC but it didn't 
seem to work. Do we have anything available?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com


pgpThu2dFRGyd.pgp
Description: PGP signature

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Michał Górny]

On Mon, 7 Mar 2011 03:40:23 -0800
Brian Harring  wrote:

> On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> > This should help with all the issues mentioned, including binpkg
> > support. Moreover, user could use the tool manually to restore/reset
> > filecaps if they were lost or unapplied (e.g. due to incorrect
> > kernel config).
> 
> Every issue you've raised is addressable at the PM level- generally 
> speaking, done better at the PM level.
> 
> Basically... please fix the problem at the correct location.  
> Capabilities, xattrs, etc, are not a temporary fad- they're 
> increasingly a core requirement of a linux system (thus the PM that 
> manages it).  The place for this functionality is in the PM- more 
> importantly, trying to do it outside of it just makes a bigger mess 
> for PM/format authors when inevtiably it has to be pulled in.

Yes, you are completely right. PM should handle that, as well as it
can with current EAPIs, and even better with higher EAPI.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Bugzilla 4 migration

[Markos Chandras]

On Sun, Mar 06, 2011 at 11:55:31PM +0100, Christian Ruppert wrote:
> Dear community,
> 
> our Bugzilla (bugs.gentoo.org) will be unavailable for the next hours.
> We're going to migrate our old Bugzilla to Bugzilla-4.
> We expect our update to finish within the next hours.
> 
> Some notes:
> SSL is enabled by default now, so it's forced. Unfortunately the
> option to force SSL *only* for logged in user is no longer available in
> Bugzilla-4.x. It has been added in early 3.x AFAIR and later replaced by
> forcing SSL at all or not.
> If *anybody* can't use SSL for any reason please yell so that we can
> decide if we leave it as it is (plain + encrypted) or not.
> 
> All custom/Gentoo patches will be available *later* in a git repo[1].
> So if you'd like to fix something or improve the theme you can
> contribute patches.
> Thanks to Alex Legler (a3li) for the Bugzilla theme.
> 
> [1]
> http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-bugzilla.git;a=summary
> 
> -- 
> Regards,
> Christian Ruppert
> Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure
> member
> Fingerprint: EEB1 C341 7C84 B274 6C59  F243 5EAB 0C62 B427 ABC8
> 

Thank you very much. New bugzie looks pretty :)


Regards,
-- 
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2


pgpqdtUPg7103.pgp
Description: PGP signature

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

[Hanno Böck]

Am Sun, 27 Feb 2011 15:44:13 +0100
schrieb "Paweł Hajdan, Jr." :

> As the package seems rather unmaintained, I'm going to wait for a
> while and check in the ebuild if nobody is against that.
> 
> Any feedback is welcome, please let me know what you think.

I have a printer using foo2zjs and have my own ebuild for that. Though
my printer is black-white and thus doesn't need the whole color-profile
stuff and no firmware.

I thought about splitting the stuff to make maintaining easier. One
ebuild for the driver itself, one for the color profiles and one for
the firmwares.


-- 
Hanno Böck  mail/jabber: ha...@hboeck.de
GPG: BBB51E42   http://www.hboeck.de/

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Brian Harring]

On Mon, Mar 07, 2011 at 09:44:47AM +0100, Michaaa GGGrny wrote:
> On Sun, 6 Mar 2011 17:34:29 +0100
> Constanze Hausner  wrote:
> 
> > On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> > > * some filesystems don't support xattrs at all, and the package
> > > manager needs to support installing to them, even if the user is
> > > building on a filesystem that does support it
> >
> > While GSoC I was not able to come up with a good fallback mechanism.
> > I'm going to give the new ideas some thought over the week and
> > hopefully come up with something good :).
> 
> How about that:
> 1) src_install() installs a file, like in:
>   /var/lib/gentoo/filecaps.d/${PF}
> specifying which caps have to applied to which files,
> 
> 2) the eclass depends on an ebuild, installing a kind
> of 'filecaps-apply' tool, reading information from that file and trying
> to apply filecaps as necessary (and flipping setuid bits),
> 
> 3) the eclass calls that tool in pkg_postinst() to apply the caps
> on the target filesystem.

Exactly what benefit is derived from trying to step outside the PM for 
this, and trying to hack up what the PM already set for permissions?

General rule of thumb, the more the PM knows the better things are 
going to be for people, and for long term compatibility.  If 
in doubt consider the improvements to user experience via 
revdep-rebuild functionality making it into the PM; PM can actually 
plan for rebuilds as it goes rather than potentially blowing up a 
later build (or telling the user "go run xyz"). Consider:

1) this tool will have to grow system/user configuration for 
overrides- something the PM could fold in easily enough into it's 
existing capbilities.  If in doubt consider FEATURES=suidctl .

2) has to be prefix aware, including understanding of deprived.  This 
can be done mind you, but like #1, the bits are already there at the 
PM level.

3) the information recorded there is ultimately redundant when/if a 
sane VDB format gets created; as is this info could just as easily be 
pushed in there as a new file per CPV in the existant VDB format.

4) this requires further OOB handling for ID databases- handling that 
could've been pushed into the PM itself (admittedly a weak point since 
ID is already mildly screwed up here, but no point in making it 
worse).

5) it opens up a window in every merge where setuid binaries are on 
disk, just prior to your proposed tool getting ran.  This is annoying 
to say the least, and if the system has disabled setuid in full it's a 
window where the binaries aren't actually usable.

6) it's slower than just having the PM do it.  Specifically, the PM is 
already transfering the content to disk, and fiddling it's bits- 
adjusting the files modes and setting capability is something it can 
do on creation (eliminating #5) rather than having to shell out to 
some script.  It's important to realize that the area this slows down 
is a critical section for parallelized binpkg merging- something the 
chrome-os folk have ran into.

6) shifting it to an external tool means the format used by the tool 
needs standardization (rather than just being standardized via PMS) to 
allow interop when inevitably a PM author goes to fold the 
functionality into the PM.

7) this tool, due to it being not part of the PM, the PM has to go out 
of it's way to protect the depgraph for- something it should already 
be doing for itself.  External, it's another hardcoded constant (or 
addition to system set) the PM has to watch for- w/in the pm, it ought 
to pay attention to it as is.


> This should help with all the issues mentioned, including binpkg
> support. Moreover, user could use the tool manually to restore/reset
> filecaps if they were lost or unapplied (e.g. due to incorrect kernel
> config).

Every issue you've raised is addressable at the PM level- generally 
speaking, done better at the PM level.

Basically... please fix the problem at the correct location.  
Capabilities, xattrs, etc, are not a temporary fad- they're 
increasingly a core requirement of a linux system (thus the PM that 
manages it).  The place for this functionality is in the PM- more 
importantly, trying to do it outside of it just makes a bigger mess 
for PM/format authors when inevtiably it has to be pulled in.

~harring


pgpBqFa2A6gfT.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla 4 migration

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07-03-2011 08:51, Robin H. Johnson wrote:
> On Sun, Mar 06, 2011 at 11:55:31PM +0100, Christian Ruppert wrote:
>> our Bugzilla (bugs.gentoo.org) will be unavailable for the next hours.
>> We're going to migrate our old Bugzilla to Bugzilla-4.
>> We expect our update to finish within the next hours.
> All completed now. If you run into any problems, please file a new bug
> under the Bugzilla product.

Thank you both for all the work in the upgrade and for all the
maintenance work you've been doing for years on our Bugzilla.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNdMHeAAoJEC8ZTXQF1qEPzMwP/Rgc/F0ffJ8N5nKcW6DmcAO6
Xk8mPs7aMZ+YKdUmt0Ti67QMkGXn7UYDGqcEysKJzPY8G9aPboGZ/rrZIKU8kUtN
ddD++GO/yrqIBmMZaohXd28SSCTi7Ea+fmZSreL9Kq3Z9JSMIRNvCXKxlDVb82ll
wV44OPdrmRkTJ561fARuWxUs0NY7KnSUuBQ2Xr2dqjYQ3FsxtBK9RwDag1wFf24W
rJwoIHa9a/jRyp4eYlAErWdcQKDrdtfJWTX2gNjjp67JDO/PJBBvb2qXzGebjgra
iKpTfVKqXRt5TGWvL+UkKKi220St0C83wBXhmOSRbpaLBEq6+dvLPJT0nGEeaO1s
2dY6I1CFdW+oK8fEg+V1+4djWJ7CwRfg9uH2q9lgxZXXBw6uq4vsLjWwMr+O20hE
zwXNhHhq77VsJGENM3o+NFeiGvw4+j+1metvzsQgNQTq2gcnEeSiXxxwXWD7P2d5
QfjTlJg5Y6u6f3YnNYYNckgizeFmm5SkgKElET0wBD2ILChPMshhyB+aPnMlkzTm
DJKcwr/9C1g9pEHjoUC8uOrIGTDny/uP/IOgBlbvBFwkH9u258spI/nkHliyF0y1
xVtXveYp4k/8GCuUyGscj5oeVqTdft65x47oDRYzWw93vb1Aacenkei2RciN9ueo
nxpA5Kc0okEJVptcq1uT
=vJNK
-END PGP SIGNATURE-

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

[Duncan]

Michał Górny posted on Mon, 07 Mar 2011 09:34:55 +0100 as excerpted:

> I'd say, both to UNCONFIRMED. Before, we used to set 'NEW' for newly-
> added bugs and didn't use UNCONFIRMED often. Right now, it seems logical
> to use UNCONFIRMED for the new bugs and let devs (re-)confirm them as
> necessary.

I've wondered about that choice in the past, but tended to simply leave it 
at the default (new), figuring (while having my doubts about viability) if 
they were both available and new was the default, unconfirmed must be an 
intentional downgrade available for users who weren't sure yet, and were 
going to follow up later after further tests.

> I think it might be even a good idea to limit the possibility of setting
> 'CONFIRMED' to devs. Otherwise, I see users bumping each of their bugs
> to 'CONFIRMED' immediately.

Is it possible to leave that option for users, but block it such that the 
original filer can't flip it?  If so, IMO that would be best, as a second 
user could then "confirm" it.

If it's not possible to block, unconfirmed could at least be made the 
default and the wranglers could complain about (and change) bugs filed as 
"confirmed" as they assign them.  The message should eventually get out, 
and having a second user confirm the bug could actually be quite useful 
for busy devs trying to prioritize their bugs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] multilib clean up

[Mike Frysinger]

i plan on punting these (hardly used) functions from the
multilib.eclass (once the handful of open bugs are closed):
  get_ml_incdir
  prep_ml_includes
  create_ml_includes
  create_ml_includes-absolute
  create_ml_includes-tidy_path
  create_ml_includes-listdirs
  create_ml_includes-makedestdirs
  create_ml_includes-allfiles
  create_ml_includes-sym_for_dir
further, the CDEFINE_xxx multilib vars will go with them

for the most part, these were really only used by the glibc ebuilds.
for the ones that dont support multilib natively (and necessitated
these funcs in the first place), i'll simply punt the ebuilds.  this
will probably be just the glibc-2.5 ebuilds for now.

also, i'll be converting the glibc ebuilds do always invoke the
multilib_env helper functions.  this will allow us to drop the
{C,LD}FLAGS_xxx and friends from profiles since glibc was the main
consumer.  i imagine this inadvertently break some other packages, so
if people want to test this on their own systems before i make the
commit, that'd be cool.  the plan would be for said breakage will go
through bugzilla to get the ebuild updated rather than reverting the
profile.
-mike

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

[Brian Harring]

On Mon, Mar 07, 2011 at 08:24:46AM +0100, "Paweee Hajdan, Jr." wrote:
> On 3/6/11 1:50 PM, Brian Harring wrote:
> >>   "NEW" will become "CONFIRMED"
> > 
> > This seems mildly insane; sure you didn't mean UNCONFIRMED?
> 
> I don't understand that concern. There is UNCONFIRMED and NEW, now you'd
> get UNCONFIRMED and CONFIRMED. It seems to me it's just NEW with a
> different name, and UNCONFIRMED would still be there:
> 
> 

Re-read what he stated- it'll convert all existing NEW bugs to 
CONFIRMED upon migration.  There's a fair number of bugs that are in a 
NEW state, decent number that have sat for a long while too.  Those 
bugs aren't 'confirmed'- just like with the new work flow where the 
dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip 
the current bugs from UNCONFIRMED to CONFIRMED rather than just 
marking everything as CONFIRMED.

~harring


pgpgKP4NXfC95.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla 4 migration

[justin]

On 07/03/11 10:51, Robin H. Johnson wrote:
> The Gentoo for the Bugzilla service went perfectly, a huge thanks to
> idl0r for the years of work he has put into them.
> 

Thanks for all your work on this.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Bugzilla 4 migration

[Robin H. Johnson]

On Sun, Mar 06, 2011 at 11:55:31PM +0100, Christian Ruppert wrote:
> our Bugzilla (bugs.gentoo.org) will be unavailable for the next hours.
> We're going to migrate our old Bugzilla to Bugzilla-4.
> We expect our update to finish within the next hours.
All completed now. If you run into any problems, please file a new bug
under the Bugzilla product.

I'm sending this email as idl0r went to be after 8+ hours straight of
working on the new Bugzilla setup.

We apologize for this taking so extremely long.

Things didn't go so well at the database layer [1], and that hugely
increased the migration time. 

The Gentoo for the Bugzilla service went perfectly, a huge thanks to
idl0r for the years of work he has put into them.

> Some notes:
> SSL is enabled by default now, so it's forced.
The forcing is temporarily disabled now until we fix a possible related
performance issue, per bug 357711.

Footnotes:
[1] We discovered a potential MySQL bug with replication, where the
slaves end up truncating mediumtext columns to 1024 characters when done
with REPLACE INTO and GROUP_CONCAT. Will pursue with upstream this week.
This was only noted with mk-table-checksum, and we decided to just redo
replication from the master that was used for introducing the schema
changes. This added 3.5 hours onto the end of the migration :-(.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpWQInMnvLWm.pgp
Description: PGP signature

[gentoo-dev] Lastrite: gnome-extra/quick-lounge-applet

[Pacho Ramos]

# Pacho Ramos  (26 Jan 2011)
# It makes gnome-panel-2.32 to crash, since upstream looks dead
# any help on fixing bug 348123 is highly appreciated.
# Will be removed around 2011-04-07.
gnome-extra/quick-lounge-applet
_

Was masked since 26 Jan but upstream is still unresponsive and bug
348123 unfixed. Removal in 30 days.


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

Re: [gentoo-dev] Bugzilla 4 migration

[Robin H. Johnson]

On Mon, Mar 07, 2011 at 10:12:14AM +0100, Michał Górny wrote:
> On Sun, 06 Mar 2011 23:55:31 +0100
> Christian Ruppert  wrote:
> > SSL is enabled by default now, so it's forced. Unfortunately the
> > option to force SSL *only* for logged in user is no longer available
> > in Bugzilla-4.x. It has been added in early 3.x AFAIR and later
> > replaced by forcing SSL at all or not.
> > If *anybody* can't use SSL for any reason please yell so that we can
> > decide if we leave it as it is (plain + encrypted) or not.
> Is there any *real* reason to force SSL? It is *hell* slow.
The SSL forcing is temporarily disabled until we trace down why it's
causing slowness. Tracking is in bug 357711.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Bugzilla 4 migration

[Michał Górny]

On Mon, 7 Mar 2011 10:24:33 +0100
Dirkjan Ochtman  wrote:

> On Mon, Mar 7, 2011 at 10:12, Michał Górny  wrote:
> > Is there any *real* reason to force SSL? It is *hell* slow.
> 
> Do you mean that SSL is slow or that bugs is slow? I also noticed that
> Bugzilla is very slow right now, but it seems unlikely that it's due
> to SSL.

Both but yep, unrelated. I am just a personal SSL-forced-everywhere
hater.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Bugzilla 4 migration

[Mike Frysinger]

On Mon, Mar 7, 2011 at 4:12 AM, Michał Górny wrote:
> On Sun, 06 Mar 2011 23:55:31 +0100 Christian Ruppert wrote:
>> SSL is enabled by default now, so it's forced. Unfortunately the
>> option to force SSL *only* for logged in user is no longer available
>> in Bugzilla-4.x. It has been added in early 3.x AFAIR and later
>> replaced by forcing SSL at all or not.
>> If *anybody* can't use SSL for any reason please yell so that we can
>> decide if we leave it as it is (plain + encrypted) or not.
>
> Is there any *real* reason to force SSL? It is *hell* slow.

it should of course be force for logging in
-mike

Re: [gentoo-dev] Bugzilla 4 migration

[Dirkjan Ochtman]

On Mon, Mar 7, 2011 at 10:12, Michał Górny  wrote:
> Is there any *real* reason to force SSL? It is *hell* slow.

Do you mean that SSL is slow or that bugs is slow? I also noticed that
Bugzilla is very slow right now, but it seems unlikely that it's due
to SSL.

Cheers,

Dirkjan

Re: [gentoo-dev] Bugzilla 4 migration

[Michał Górny]

On Sun, 06 Mar 2011 23:55:31 +0100
Christian Ruppert  wrote:


> SSL is enabled by default now, so it's forced. Unfortunately the
> option to force SSL *only* for logged in user is no longer available
> in Bugzilla-4.x. It has been added in early 3.x AFAIR and later
> replaced by forcing SSL at all or not.
> If *anybody* can't use SSL for any reason please yell so that we can
> decide if we leave it as it is (plain + encrypted) or not.

Is there any *real* reason to force SSL? It is *hell* slow.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] eclass for handling of file-based capabilities

[Michał Górny]

On Sun, 6 Mar 2011 17:34:29 +0100
Constanze Hausner  wrote:

> On 17:44 Sat 05 Mar , Ciaran McCreesh wrote:
> > * some filesystems don't support xattrs at all, and the package
> > manager needs to support installing to them, even if the user is
> > building on a filesystem that does support it
>
> While GSoC I was not able to come up with a good fallback mechanism.
> I'm going to give the new ideas some thought over the week and
> hopefully come up with something good :).

How about that:
1) src_install() installs a file, like in:
/var/lib/gentoo/filecaps.d/${PF}
specifying which caps have to applied to which files,

2) the eclass depends on an ebuild, installing a kind
of 'filecaps-apply' tool, reading information from that file and trying
to apply filecaps as necessary (and flipping setuid bits),

3) the eclass calls that tool in pkg_postinst() to apply the caps
on the target filesystem.

This should help with all the issues mentioned, including binpkg
support. Moreover, user could use the tool manually to restore/reset
filecaps if they were lost or unapplied (e.g. due to incorrect kernel
config).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

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

[Michał Górny]

On Sun, 06 Mar 2011 13:22:09 +0100
Christian Ruppert  wrote:

>   "NEW" will become "CONFIRMED"
>   "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will
> be removed)

I'd say, both to UNCONFIRMED. Before, we used to set 'NEW' for newly-
added bugs and didn't use UNCONFIRMED often. Right now, it seems
logical to use UNCONFIRMED for the new bugs and let devs (re-)confirm
them as necessary.

I think it might be even a good idea to limit the possibility
of setting 'CONFIRMED' to devs. Otherwise, I see users bumping each
of their bugs to 'CONFIRMED' immediately.

> We're almost done with the preparation of bugzilla-4.x for
> bugs.gentoo.org. So, do we want the new workflow or do we want to
> keep the old?

New one. Simpler is better.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature