Re: [gentoo-dev] Re: rejecting unsigned commits
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 possible.) 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] Yes. - keys are not listed in userinfo.xml (current or former devs) [4] Yes. 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. dilfri...@gentoo.org 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 check. 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). -- [a] pgpZbkdFEvCEY.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
Torsten Veller dixit (2011-03-25, 08:15): * Mike Frysinger vap...@gentoo.org: 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)? yes 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). Regards, -- [a]
Re: [gentoo-dev] validity of manifest signing key
Thomas Kahle dixit (2011-03-25, 10:47): it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 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. -- [a] pgpOdw1UNZ1IL.pgp Description: PGP signature
Re: [gentoo-dev] rejecting unsigned commits
Jeroen Roovers dixit (2011-03-25, 00:50): On Thu, 24 Mar 2011 17:59:45 -0400 Mike Frysinger vap...@gentoo.org 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)? Regards, -- [a]
Re: [gentoo-dev] Last rites: www-client/chromium-bin
Alex Alexander dixit (2011-03-05, 01:46): On Sat, Mar 05, 2011 at 12:32:15AM +0100, Tomáš Chvátal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 4.3.2011 10:35, Paweł Hajdan, Jr. napsal(a): # Pawel Hajdan jr phajdan...@gentoo.org (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 www-client/chromium-bin 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). -- [a] pgpsOhkMX68V6.pgp Description: PGP signature
Re: [gentoo-dev] Pending removal(?) of media-libs/pdflib
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 ? -mike 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 :). -- [a] pgpbeRCIEtHeg.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Installer (text-based)
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. -- [a]
Re: [gentoo-dev] Gentoo Installer (text-based)
Konstantin Tokarev dixit (2011-02-10, 13:01): 10.02.2011, 12:56, Antoni Grzymala awa...@chopin.edu.pl: 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=∞ :) -- [a]
Re: [gentoo-dev] Lastrite: lince and slmodem
Samuli Suominen dixit (2011-02-01, 21:09): # Samuli Suominen ssuomi...@gentoo.org (01 Feb 2011) # Masked for QA because the package has not been installable for an year now. # See http://bugs.gentoo.org/show_bug.cgi?id=302456 # Removal in 30 days net-dialup/slmodem “Thanks Lech, works again! Now, can we get this update to portage ASAP... please, Gentoo devs???” -- [a]
Re: [gentoo-dev] Rail Model font for coders
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com 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: tea_party@mad_hatter.uk? -- [a]
Re: [gentoo-dev] Adding postfix-2.8 experimental releases to the tree
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 release. 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 laptop. Regards, -- [a]
Re: [gentoo-dev] Message could not be delivered
Patrick Nagel dixit (2010-10-29, 15:26): On 2010-10-29 18:05 UTC cl...@jhcloos.com 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 :) -- [a] pgp1IXoRbBvJh.pgp Description: PGP signature
Re: [gentoo-dev] openrc: oldnet vs newnet
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). Best, -- [a] pgpXv3A85gPdT.pgp Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
Tobias Klausmann dixit (2010-09-20, 20:34): On Mon, 20 Sep 2010, Benedikt Böhm wrote: On Mon, Sep 20, 2010, Tobias Klausmann klaus...@gentoo.org 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 192.168.0.254 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. -- [a]
Re: [gentoo-dev] QA last rites for dev-lisp/cl-smtp; dev-lisp/cl-pop
Diego E. Pettenò dixit (2010-05-26, 14:54): # Diego E. Pettenò flamee...@gentoo.org (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 dev-lisp/cl-smtp dev-lisp/cl-pop 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. Best, -- [a]
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
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 ebuilds: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect7 . . . 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 http://www.gentoo.org/doc/en/xml-guide.xml, or the monospace font used for filesystem paths. [...] Has anyone considered the immensely powerful twiki? -- [a]
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Ben de Groot dixit (2010-04-04, 14:31): On 4 April 2010 10:48, Antoni Grzymala awa...@chopin.edu.pl 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 performance. 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™) [1] http://www.twiki.net/blog_2008-03-25.html -- [a]
Re: [gentoo-dev] Re: Python 3.1: Stabilization and news item
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? best, -- [a] pgpQJOsKfpDsQ.pgp Description: PGP signature
Re: [gentoo-dev] New category for version control
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 :)). -- [a]
Re: [gentoo-dev] Building custom package for multi-arch/system
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. [1] http://docs.rpath.com/conary/Conaryopedia/sect-flavors.html -- [a]
Re: [gentoo-dev] Re: [rfc] layman storage location (again)
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 like. 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 all. 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/ /var/portage/tree /var/portage/layman /var/portage/overlays (non-layman managed, layman could also be in here) /var/portage/distfiles /var/portage/packages or %s/var/usr/ Very much +1. -- [a] pgpqiAFGepd8h.pgp Description: PGP signature
Re: [gentoo-dev] [rfc] layman storage location (again)
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
/var/spool/layman
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}).
Best,
--
[a]
pgp5UItcwFkYo.pgp
Description: PGP signature
Re: [gentoo-dev] [rfc] layman storage location (again)
Ben de Groot dixit (2010-01-16, 00:41): 2010/1/15 Dawid Węgliński c...@gentoo.org: On Friday 15 January 2010 20:44:43 Alex Legler wrote: /var/lib/layman do well? +1 -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. -- [a]
Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
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: http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml Hi! 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 deployments. I can devote some time to helping with the matter. Regards, Antoni Grzymała -- [a]
Re: [gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
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: http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml Hi! How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort [...] Forgot the URL, of course: [1] http://www.gentoo.org/proj/en/glep/glep-0057.html -- [a]
