Re: [gentoo-dev] Re: rejecting unsigned commits

2011-03-25 Thread Antoni Grzymala
Andreas K. Huettel dixit (2011-03-25, 09:53):

  Do you want to reject signed commits if
  - keys are not publicly available [1]
 Yes, since that defies the purpose of the signature.
  - signatures are from expired keys [2]
 Yes if the signature was made after expiration. (Dont know if that is even 
 No if the signature was made while the key was valid. (Otherwise our whole 
 portage tree would time out at some point.)
  - keys are revoked [3]
  - keys are not listed in userinfo.xml (current or former devs) [4]
 However, for the former devs we might need an extra list to prevent 
 expiration on retirement, and treat the keys as if they expired on 
 retirement date (compare above).
 Does that make sense?
 Of course now we can add additional requirements:
 * The key must have an userid that refers to an official Gentoo e-mail 
 address. E.g.
 Very important and easily implemented.
 * The userid should have some specific default string in its comment field, 
 like Gentoo manifest signing key.
 Not so important but also easily implemented.
 * The key should be signed by some central instance for automated validity 
 Here things get hairy. How about having recruiter/infra team sign a dev's key 
 on completion of the recruitment process? Just a first thought...

I think this is an important requirement however it's quite difficult
to conduct reliably. A normal keysigning process usually requires
knowing one personally (and perhaps verifying fingerprints over a
phone with voice verification), seeing one's ID personally and the
like. This is probably unfeasible in the Gentoo development
environment (I'm not a dev, though, so I'm just guessing).

As a weaker but possibly useful workaround Gentoo Infra could just
publish a signed list of trusted developer keys for any given moment.

 * The central instance should be able to reliably revoke a key.
 Add a revocation list in a portage tree directory? Or is this just shooting 
 yourself into the foot backwards through the eye?

Revoking a signature on a key is possible (unless a key has been
nrsigned) and makes sense (assuming those who verify update all
relevant keys).


Description: PGP signature

Re: [gentoo-dev] Re: rejecting unsigned commits

2011-03-25 Thread Antoni Grzymala
Torsten Veller dixit (2011-03-25, 08:15):

 * Mike Frysinger
  On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
 [Manifest signing]
   Does that get us any closer to GLEPs 57, 58, 59 (or generally
   approaching the tree-signing/verifying group of problems)?
 I think, it's a no.
 The MetaManifest GLEP relies on a signed top-level MetaManifest which
 hashes all sub Manifests, whether they are signed or not doesn't matter.
 I don't see a major advantage to signed portage snapshots we already
 offer today.

It's just that for everyday use we (perspective of users, possibly
only me) would like to have the ability of easy and automated
verifying of Manifest GPG signatures whether we (r)sync, webrsync or
use a manually downloaded snapshot, with same level of assurance as in
other major distros (Debian, RH).



Re: [gentoo-dev] validity of manifest signing key

2011-03-25 Thread Antoni Grzymala
Thomas Kahle dixit (2011-03-25, 10:47):

 it says here that
 the validity should be 6 month.  What is the protocol when the expiry
 date is approaching?

“After size comes the expiration date. Here smaller is better, but most
users can go for a key that never expires or to something like 2 or 3 years.”

Can't find anything about 6 months.


Description: PGP signature

Re: [gentoo-dev] rejecting unsigned commits

2011-03-24 Thread Antoni Grzymala
Jeroen Roovers dixit (2011-03-25, 00:50):

 On Thu, 24 Mar 2011 17:59:45 -0400
 Mike Frysinger wrote:
  is there any reason we should allow people to commit unsigned
  Manifest's anymore ?  
 Funny that. I only started doing that Yesterday. It had been on my TODO
 for a couple of years. :)

Does that get us any closer to GLEPs 57, 58, 59 (or generally
approaching the tree-signing/verifying group of problems)?



Re: [gentoo-dev] Last rites: www-client/chromium-bin

2011-03-04 Thread Antoni Grzymala
Alex Alexander dixit (2011-03-05, 01:46):

 On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote:
  Hash: SHA1
  Dne 4.3.2011 10:35, Paweł Hajdan, Jr. napsal(a):
   # Pawel Hajdan jr (04 Mar 2011)
   # Masked for removal in 90 days.
   # Multiple hard to fix and time consuming maintenance problems:
   #  - history of bugs (bug #304527, bug #335101, bug #347175,
   #bug #349249, bug #356609)
   #  - upstream's binary builds cannot be used on Gentoo
   #as easily as other -bin packages (ubuntu-specific
   #library names that require compatibility symlinks,
   #bundling libraries, mirror/redistribution policy, and so on)
   #  - dependencies for the -bin package are harder to manage;
   #often we have source compatibility, but not binary compatibility
  Well I can't afford to compile it for 3 hours. Could you at least make
  it compile against system webkit?
  That would save so much time i would not complain :)
 What system webkit? Chromium has its own version of webkit :)
 Anyway, compilation on a modern system shouldn't take more than an
 hour. ~15-20 minutes on a quad i5.

Takes ~32 minutes on my i7 (dual core @2.67 ghz).


Description: PGP signature

Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib

2011-02-22 Thread Antoni Grzymala
Tomáš Chvátal dixit (2011-02-22, 19:39):

  On Tue, 22 Feb 2011, Francesco R wrote:
  Build gnuplot with USE=cairo and you can get PDF output with the
  pdfcairo terminal.
  Last time (many moons ago) I've checked cairo did not generated pdf
  it did generated raster images and wrapped them in a thin pdf layer.
  pdflib is generating vector pdf which is a different thing.
  You should check again.
  are you saying that because you know cairo has fixed itself, or because you 
  dont know the answer yourself ?
 To my best knowledge cairo can do proper pdf files.
 Courtesy of 12 lines of python, see the attachment, both vector curves
 and normal text in one fancy pdf file.

I don't see any curves (in any pdf viewer), only some ZOMG_TEXT. I
always thought Python was suspicious :).


Description: PGP signature

Re: [gentoo-dev] Gentoo Installer (text-based)

2011-02-10 Thread Antoni Grzymala
Fabian Groffen dixit (2011-02-10, 10:39):

 On 10-02-2011 07:54:16 +0100, Fabio Erculiani wrote:
  The only way to avoid epic failures is to keep the whole thing simple,
  without trying to fit everybody. An installer that would cover a
  standard install, newbie-oriented scenario would be definitely good.
  Experienced people won't use it anyway, so why bothering trying to
  cover their needs, it would be a straight way to fail again.
 Just FYI:
 Interestingly, it were the power/experienced users that requested a
 simple installer, because they got tired of copypaste-ing the same
 commands from the manual over and over again.

Actually power users install Gentoo from memory, it's really not much
more, than untarring two tarfiles, editing a few configs, making the
kernel and installing the bootloader.


Re: [gentoo-dev] Gentoo Installer (text-based)

2011-02-10 Thread Antoni Grzymala
Konstantin Tokarev dixit (2011-02-10, 13:01):

 10.02.2011, 12:56, Antoni Grzymala
  Fabian Groffen dixit (2011-02-10, 10:39):
   On 10-02-2011 07:54:16 +0100, Fabio Erculiani wrote:
   The only way to avoid epic failures is to keep the whole thing simple,
   without trying to fit everybody. An installer that would cover a
   standard install, newbie-oriented scenario would be definitely good.
   Experienced people won't use it anyway, so why bothering trying to
   cover their needs, it would be a straight way to fail again.
   Just FYI:
   Interestingly, it were the power/experienced users that requested a
   simple installer, because they got tired of copypaste-ing the same
   commands from the manual over and over again.
  Actually power users install Gentoo from memory...
 dd if=/dev/brain of=/dev/hda1

bs=512 count=∞ :)


Re: [gentoo-dev] Lastrite: lince and slmodem

2011-02-01 Thread Antoni Grzymala
Samuli Suominen dixit (2011-02-01, 21:09):

 # Samuli Suominen (01 Feb 2011)
 # Masked for QA because the package has not been installable for an year
 # See
 # Removal in 30 days

“Thanks Lech, works again! Now, can we get this update to portage
ASAP... please, Gentoo devs???”


Re: [gentoo-dev] Rail Model font for coders

2011-01-20 Thread Antoni Grzymala
 dixit (2011-01-20, 15:06):

  please fix your stupid e-mail
 Meeku:  Very good email address.

Since we're onto hares why not shorten it to:


Re: [gentoo-dev] Adding postfix-2.8 experimental releases to the tree

2010-12-09 Thread Antoni Grzymala
Tim Harder dixit (2010-12-09, 15:26):

 For those of you running postfix, I was wondering if there is any
 interest in having the 2.8 experimental releases added to the tree.
 According to upstream [1] they are production quality so they should run
 as expected but the config setup may change a lot compared to the final
 Anyway, I'm considering adding them, masked of course, if there is
 interest in using them for testing purposes.

Certainly, I don't mind doing some pre-production testing on my



Re: [gentoo-dev] Message could not be delivered

2010-10-29 Thread Antoni Grzymala
Patrick Nagel dixit (2010-10-29, 15:26):

 On 2010-10-29 18:05 UTC wrote:
 [garbage, malware attached]
 Wow, that's a first, I think ;) Mydoom worm sent to the gentoo-dev list.

I only got information from spamassassin on my server. Was actually
quite surprised to see the sender :)


Description: PGP signature

Re: [gentoo-dev] openrc: oldnet vs newnet

2010-09-20 Thread Antoni Grzymala
William Hubbs dixit (2010-09-20, 11:16):

 I want to start a new thread since the discussion on openrc is
 centering on whether we should use oldnet, newnet, or keep both.
 The drawback I see for newnet is that it does not allow the user to
 control each interface separately, so if you want to cycle one
 interface for some reason, this is not doable in that setup.  I
 agree this is a serious drawback.  Oldnet addresses this by having a
 separate script for each interface.
 The thing I do not like about oldnet is the way it handles wifi and
 dynamic interfaces by running dhcpcd and wpa_supplicant on each
 interface instead of running a global instance of them so that they
 can control the interfaces themselves.
 On my laptop, I have net.lo in the boot runlevel, and I start
 wpa_supplicant and dhcpcd in the default runlevel.  In that setup,
 there is no need for any net.wlan* interface scriptss, because
 dhcpcd and wpa_supplicant manage everything.

Does that support configurations where I set static addresses
(including ipv6) and routes (also including ipv6) based on the SSID as
is allowed by the oldnet scheme of things? I (and probably lots other
“power users”) rely on those features extensively and I thank whoever
came up with the idea of actually configuring that in a pretty simple
way (compared to other distros and OS'es where it is more complicated
or plain impossible sometimes).



Description: PGP signature

Re: [gentoo-dev] openrc stabilization update

2010-09-20 Thread Antoni Grzymala
Tobias Klausmann dixit (2010-09-20, 20:34):

 On Mon, 20 Sep 2010, Benedikt Böhm wrote:
  On Mon, Sep 20, 2010, Tobias Klausmann wrote:
   who runs servers: DHCP is uncommon there, WLAN is very unusual,
   as a result, they would not only have to switch the way they
   configure their nets (people don't like that kind of stuff if the
   machine is 400 miles away); they would also have to find a way to
   build their setups in the new language. Servers tend to have
   more complicated setups network-wise than workstations (think
   firewalls, VPN endpoint, traffic observation, ...).
  the same is true for everyone who already runs newnet (like me). in
  fact, i do not even use the newnet conf.d stuff, but rather take
  advantage of support for /etc/ifup.eth* in /etc/init.d/network. that
  way i can configure the networking with iproute2 or any other tool
  that i already know the syntax of. no need to learn ridiculously
  convoluted array syntax foo for /etc/init.d/net.eth*.
  so please just keep the network init script as a use flag or extra
  package or something, so that one is not forced to use the old net
  stuff (again).
  P.S.: newnet does not in any way force you to use DHCP or WLAN or
  anything like that, so please stop spreading misinformation.
 Still, newnet is geared towards such setups and it is reflected
 in the way it handles things. /This/ I meant by language. And
 yes, going from complicated arrays to iproute2 syntax *is* a
 change that may blow up in your face, if you don't use those
 tools every day.

As far as I can see, oldnet (at least if you do modules=iproute2
which most sane users probably do) is *also* basically iproute2
syntax, only wrapped in some arrays:

routes_Okno=( default via
  default via 2001:foo:bar::1 )

I could add other typical iproute2 clauses to that config, like src
ip, or metric n. Same with the IP address clause.

Flexible, already documented. +1 for keeping oldnet.


Re: [gentoo-dev] QA last rites for dev-lisp/cl-smtp; dev-lisp/cl-pop

2010-05-26 Thread Antoni Grzymala
Diego E. Pettenò dixit (2010-05-26, 14:54):

 # Diego E. Pettenò (26 May 2010)
 #  on behalf of QA team
 # cl-smtp fails to fetch since at least September 2007
 # (bug #193627); cl-pop needs the former.
 # Removal on 2010-07-25

cl-smtp has just fetched perfectly for me using the ebuild in the lisp
overlay... May I humbly suggest a bump instead of treecleaning?

On the other hand – I think most CL packages should either get dumped
from gentoo proper and people should be advised to use the overlay for
most their CL needs today or the overlay should make its way into the
main portage tree.

Please note that this is just a user's POV – I may not be aware of some
important reasons for keeping the somewhat sorry status quo.



Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

2010-04-04 Thread Antoni Grzymala
Joshua Saddler dixit (2010-04-04, 00:31):

 Show me a wiki that has the flexibility of our handbook, which can be
 a huge printer-friendly all-in-one doc, or an as-you-need-it doc with
 one page per chapter.
 Show me a wiki that has built-in intradoc linking to every paragraph,
 chapter, subchapter, code sample, etc.
 Show me a wiki that produces such beautiful code samples (with
 titles). Show me a wiki that can produce the following formatting for
 . . . or a wiki that makes it super-easy to add all sorts of
 additional in-line formatting to regular paragraphs, for example all
 the blue highlighting for code used throughout, or the monospace font used
 for filesystem paths.


Has anyone considered the immensely powerful twiki?


Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki

2010-04-04 Thread Antoni Grzymala
Ben de Groot dixit (2010-04-04, 14:31):

 On 4 April 2010 10:48, Antoni Grzymala wrote:
  Has anyone considered the immensely powerful twiki?
 No. So tell us why we should. Specifically, how does it compare to
 MediaWiki in terms of features and performance?

I don't have any particular claims on performance at hand. TWiki stores
the data in plaintext files which may or may not be beneficial depending
on various scenarios, the code is very mature but that of course does
not say anything on whether the performance is good or not compared to,
say, MediaWiki. Here [1] is a reasonably recent writeup on TWiki's

As to the features, I (contrary to sebastian in an earlier answer) quite
like the syntax, I think it's a bit more comfortable the MediaWiki in
popular scenarios.

There's a good ACL system, it's got an integrated ticket system, a
mobile-version plugin, and I too think the whole concept of Webs is
neat. The search system is extensive and includes regex searching.

And yeah, it's not PHP :) (no flame intended™)



Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item

2010-03-08 Thread Antoni Grzymala
Matti Bickel dixit (2010-03-08, 10:39):

  A stable user who doesn't want python 3 installed shouldn't have it
  forced on them.  If something is pulling in python-3 then that
  package needs to have its dependencies fixed.  IIRC Portage isn't
  greedy wrt. SLOTs like it was before (unless you use @installed) so
  it shouldn't be pulled in by anything that doesn't require it.
 +1 on that. If your program is only tested with python-2 or has
 regressions with python-3 (e.g. performance loss), a maintainer can and
 should mark that package as python-2 only. For new systems, the only
 must have python user i can think of is portage. And that has an
 explicit USE=python3 and as Zac outlined takes DEPEND-pains to ensure
 python-2.* is pulled in if available. So you're starting with python-2.*
 and every program not explicitly pulling in python-3.* should be happy
 with that.
  I think that is being said is, due to python 3 being unnecessary for
  majority of users, due to a small number of applications actually
  using it, it should be in ~arch.
 You're actually damning most of the tree to be ~arch, if that's the
 criterion for stable.
  Of course an application that depends on python 3, but is entirely
  stable should not be marked testing (to my reckoning at least). I
  think the best way to go about it is to set python-3 in ~arch.
 These are contradicting statements. Repoman will and should kill anyone
 attempting to do that. All [R,]DEPENDS of an ebuild must be stable, if
 that ebuild is to be marked stable, too.
 So b/c i still can't understand what's so horrible about python-3 going
 into stable (even if p.mask'ed, if that's the consensus), my vote goes
 to mark it stable already.

Sorry guys if I missed something crucial in this lengthy thread, but
from what I'm understanding:

if python-3 goes stable (and unmasked):

- it is a separate, slotted version
- it generally shouldn't get pulled in (current portage non-greedy
  behaviour on slots)
- if it does get pulled in by, say, and old portage version, or a
  package with badly defined deps, it shouldn't do any harm because it
  will just sit quietly in its slot and old packages will still
  compile/run against (already installed) python-2.x

or not?

PS. one thing I realize I may be missing is the /usr/bin/python symlink
and the /usr/bin/python-wrapper to which it points. Will the default
change to python31 upon python-3 installation?



Description: PGP signature

Re: [gentoo-dev] New category for version control

2010-03-04 Thread Antoni Grzymala
Ulrich Mueller dixit (2010-03-04, 10:32):

  On Thu, 4 Mar 2010, Christian Faulhammer wrote:
  My proposal would be to call it dev-scm and put all version
  controls, direct frontends, plugins and the like into that.
 Better call it dev-vcs to avoid confusion with both the Scheme
 language and with software configuration management.

+1 for vcs for the above reason. Also, I think vcs is a more popular
acronym than scm (don't quote me on this, though :)).


Re: [gentoo-dev] Building custom package for multi-arch/system

2010-01-29 Thread Antoni Grzymala
Max Arnold dixit (2010-01-29, 12:24):

 On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote:
  So, do you guys plan to implement a such thing ? That's one of the
  features that is mostly missing imho. The principal miss in on
  client side as I have tools to manage packages but would like to not
  have too much specific scripts on client side.
 I like the way it done in OpenEmbedded. You have the tree of recipes
 (think of portage tree) and bunch of targets. For each target BitBake
 can generate binary release and package feed. Client package
 management is lightweight and does not require BitBake, recipes tree
 and even python. At least this is my lame interpretation of how it
 works :)
 Maybe this metadistribution approach is cleaner than binary package
 support in emerge. If user wants to compile packages on the client, he
 uses portage. If not - he can setup build server for multiple targets
 and completely drop portage from client machines. The only thing
 client should know is feed url with full list of binary packages. And
 I do not think client should deal with USE flags - for large
 installations unification is the only sane way to scale.

I think something similar is very nicely done on R-Path based
distributions (with flavours [1]). Conary itself also seems to be a
pretty well thought out package manager.



Re: [gentoo-dev] Re: [rfc] layman storage location (again)

2010-01-18 Thread Antoni Grzymala
Alex Alexander dixit (2010-01-18, 11:07):

 On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
  I sometimes think the main problem is the tree itself. Portage really
  should had a directory of its own, but maybe with anoher structure,
  like /var/portage, /var/portage/tree (the current
  PORTDIR), /var/portage/distfiles (i.e. split out distfiles from the tree
  itself), /var/portage/overlays/layman or /var/portage/layman.
  I of course realize that change the structure of the whole portdir would
  had inresting complications, so take this comment just as serious as you
  But overlays really was an afterthought?
 I like this suggestion, it certainly makes the whole folder structure
 cleaner. If we're going to fix stuff, lets do it properly once and for
 Some compatibility code that checks and uses the old default locations
 while printing out warnings would help existing users with the
 transition without breaking current systems. Users with custom PORTDIR
 and friends could be notified through a news item.
 /var/portage/overlays (non-layman managed, layman could also be in here)
 or %s/var/usr/

Very much +1.


Description: PGP signature

Re: [gentoo-dev] [rfc] layman storage location (again)

2010-01-16 Thread Antoni Grzymala
Mike Frysinger dixit (2010-01-15, 20:45):

 On Friday 15 January 2010 20:24:38 Sebastian Pipping wrote:
  On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
   - From the alternatives, /var/lib/layman doesn't sound right. If
   /var/cache/layman doesn't work, what about /var/spool/layman instead?
  Okay, how about
  then?  Any objections?
 /var/spool/ is a terrible idea -- these are not jobs being queued waiting to 
 be processed by a daemon and then removed.
 if you want to keep all of layman's stuff together, then about your only 
 option is to create your own tree at like /var/layman/.  the better idea 
 though would be to split your stuff along the proper lines.
 cache files = /var/cache/layman/
 config files = /etc/layman/

Layman-added trees are not much different altogether from the main
portage tree. Putting it in a location *totally* unrelated to the main
portage tree is, to put it mildly, *strange*. We still haven't heard in
this thread what was wrong with the original (${PORTDIR}/local/)
location. Despite all the propositions in the thread it still feels like
a best place to me. I'm sure the change to /usr/local/portage has been
discussed elsewhere previously, but maybe a pointer to some older
discussion would be handy.

I'm all for going back to the original location (based on ${PORTDIR}).



Description: PGP signature

Re: [gentoo-dev] [rfc] layman storage location (again)

2010-01-16 Thread Antoni Grzymala
Ben de Groot dixit (2010-01-16, 00:41):

 2010/1/15 Dawid Węgliński
  On Friday 15 January 2010 20:44:43 Alex Legler wrote:
   do well?
  -1, /usr/local/layman?
 /usr/local/ is a location the system should avoid. Somewhere in /var/
 seems to be the logical place.

I always thought /usr/portage/local was the logical place. If not, I'd
also say, that /var/layman/whatever makes sense.


Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC

2009-11-30 Thread Antoni Grzymala
Denis Dupeyron dixit (2009-11-25, 14:50):

 The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
 us to discuss things please let us know in reply to this email. What
 is already known is we'll talk about mtime preservation and prefix.
 You can find threads about those at:


How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort
a year ago to summarize the then-current state of things regarding tree
and package signing, however the matter seems to have lain idle and
untouched for more than a year since.

I reckon that missing GPG infrastructure is one of the greatest problems
of the Gentoo distribution esp. regarding serious corporate and academic

I can devote some time to helping with the matter.


Antoni Grzymała


Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC

2009-11-30 Thread Antoni Grzymala
Antoni Grzymala dixit (2009-11-30, 12:30):

 Denis Dupeyron dixit (2009-11-25, 14:50):
  The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want
  us to discuss things please let us know in reply to this email. What
  is already known is we'll talk about mtime preservation and prefix.
  You can find threads about those at:
 How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort


Forgot the URL, of course: