Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to upstreams homepage [1], the current tagged v1.99.09 does support xulrunner 11.0. @dirtyepic: Any chance to bump the version in portage? I can take a look (and grab this package). Is there any state-of-the-art(tm) alternative to read .chm ebooks? I wouldn't want to loose this possibility. Thanks, Michael [1] http://code.google.com/p/chmsee/ On 04/22/2012 08:21 AM, Samuli Suominen wrote: > # Samuli Suominen (22 Apr 2012) # One of the > last packages still using the obsolete pyxml package # Masked for > removal in 30 days wrt bug 367739 > > # Samuli Suominen (22 Apr 2012) # Masked for > removal in 30 days for using the obsolete xulrunner # package wrt > #412875 and #403415 app-text/chmsee > - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+bw9MACgkQknrdDGLu8JA92AD+OX0PrpAfmeBnYTZX2N50FKPb eWM/uueFFhBS9EFQxvUA/0vZkVfz2G/wdx7q9SQ8Vzx3ImomMbyOJc1iWn7lofxe =IzMJ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/03/2012 05:39 AM, Ryan Hill wrote: > On Sat, 28 Apr 2012 12:17:55 +0200 Michael Weber > wrote: >> Is there any state-of-the-art(tm) alternative to read .chm >> ebooks? I wouldn't want to loose this possibility. > > I also maintain kchmviewer and xchm and I think there are a couple > other non-dedicated readers that support it. Are there any features > chmsee has that these are missing? I added chmsee to replace gnochm > but I don't think I've ever used it. I use xchm for my collection. > It's tech books and manuals though, nothing too extravagant. It > doesn't release often but upstream is responsive. xchm looks good, thanks for the hint. - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+i8D0ACgkQknrdDGLu8JBvpQEAmuVY1ngQQPjnflJvJDVoYjM6 byeXXZtqxQLo5PgFR24BAIXc0RSeqZt4lwxZc76rwaNoACnJWHkRll2adNBAOjIN =x8Ua -END PGP SIGNATURE-
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/04/2012 09:37 PM, Mike Gilbert wrote: > On Fri, May 4, 2012 at 3:25 PM, Johannes Huber > wrote: >> Am Freitag, 4. Mai 2012, 14:41:42 schrieb Mike Gilbert: >>> On Fri, May 4, 2012 at 2:29 PM, hasufell >>> wrote: I think that as an argument pro CMAKE_VERBOSE=1 because that would cover 100% instead of 95-99. ++ There was a similar rumor about VERBOSE=1 V=1 and the (`emerge -j 2` induced emerge `--quiet-build`). But build.log files will get larger and bugzie has this 1MB upload limit. "File: Enter the path to the file on your computer (1000 KB limit) (or paste text as attachment)." We should add an hint to atach compressed build logs (or raise this limit). > It would be nice to avoid having to wait for the user to respond > with the updated build log. Which may take ages and lead to "RESO/NEEDINFO". Not good. Greetings, Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+k+g8ACgkQknrdDGLu8JDmMAEAi8vT95lr5K2DkgxZUThy/Yh5 IgfVEVqpm+A3vcBgSZwA/A756k6/WVrJwh2lADr8Sly7hbOpoXYkTkHRO9iu/OVc =cJST -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: remove ldap from desktop profiles use flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/05/2012 09:55 PM, Dale wrote: > Not to mention, you add the possibility that the user may miss the > change since they are not expecting it. I would expect it when I > was changing profiles but not so much just coming out of the blue. We should make emerge -v (display USE flags) non-optional. Users should be trained to recognize the green/red use flag changes. Do whatever you what, I've set make.conf:USE=ldap on machines relying on it. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+lkR4ACgkQknrdDGLu8JAOCgEAkb2E7jA8j5XFsxrZfBFQqIRt Vy4W74nRfvLI5HT/N+sA/3SEZFOA94shWc98c9aYfPEQpSIJi402HuUZenTdPvEN =ULqw -END PGP SIGNATURE-
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/06/2012 05:35 PM, Pacho Ramos wrote: > Well, in tree versions are still buggy and outdated, I would vote > for either: 1. Mask them for removal (server is already hardmasked, > but client not). 2. Proxy maintain them if anyone volunteers. I would proxy maintain. Feel free to send me a pm on #irc.freenode.net, user xmw. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+mqR0ACgkQknrdDGLu8JAtEAD+PnlLNWhp7xYmD/UAePOnTnxQ Emeh3NCZExK62gaIQBkBAINCB0vxpFn3APnyGk3Ohsnrg5KBHqk1AVfxdGo3IZtY =wBk/ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: check for enewuser, enewgroup outside of pkg_setup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/19/2011 11:44 PM, Mike Frysinger wrote:
> this is why we allow people to pick the appropriate step. ebuilds
> should be using pkg_{pre,post}inst unless the user/group is needed
> at src_* time. -mike
I noticed a rather annoying test inside enewuser for existence of the
provided "shell" path in the filesystem ( user.eclass lines 153-156 ).
If you want to create an user and set the shell variable to an program
you just emerge, you have to call it from pkg_postinst.
(The example was a trivial desktop manager x11-misc/trivdm in [1])
[1]
http://git.overlays.gentoo.org/gitweb/?p=dev/xmw.git;a=tree;f=x11-misc/trivdm
- --
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAk+u6KAACgkQknrdDGLu8JA+awD+K7HLWLkd+6eF+uNteODtIJxC
rM46lOPUc7WDf3TXkHoA/job97V3eGMSamAHKp2+kgh7nz1z0VmmNqKxxyD26UE7
=zq6G
-END PGP SIGNATURE-
Re: [gentoo-dev] Do we need games group and all that game prefixes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2012 07:22 PM, Dan Douglas wrote: > I'd put money on there not being a single admin who has ever used > the games group to control access to games. Games really have no > business being on a system where anything like that is a > requirement to begin with. We (students council) use pam_ldap for users and primary groups and pam_group w/ /etc/security/group.conf for secondary groups like video,sound,games. We actually considered restricting the games group to certain login times (i.e. after 18 pm ) to prevent our fellow students from gaming during office hours, but that just lead to long time sessions over-night. Since group memberships are evaluated on session creation. I can imagine some multi-user setups (parents/children) were some user shouldn't play games-fps/* at all. But who actually shares a computer these days. One real benefit of extra groups is some chmod g+s hack for e.g. skype in combination with firewall rules restricting outbound connections. http://soup.xmw.de/post/151673185/Restricting-Skype-on-Gentoo Have a nice day ... - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+5VCgACgkQknrdDGLu8JB8SwD+JARCPBmK13Sl2/n3dsWWx/8p LBH6j18YbfD1+IWpXaUA/iWCgTS3TI78kSTwe0hnASc+7wTygiWvIcxlPmcv9LtQ =XXxi -END PGP SIGNATURE-
[gentoo-dev] Lastrite x11-wm/parti (replaced by x11-wm/xpra)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 # Michael Weber (22 May 2012) # Masked for removal in 30 days. # Replaced by x11-wm/xpra. x11-wm/parti - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+7S+cACgkQknrdDGLu8JAs5wD+MjEzgayDdXwJs9r7MZ04Uc/M xLL5p9AZ72UbNqWy+hcA/RsclJgM2GbwMUmXpcebDPyzeufeZ0jPo9NNlu8cXy3p =gf7r -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: package.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 fixed. On 05/22/2012 10:48 AM, Samuli Suominen wrote: > Missing ChangeLog entry; echangelog works in profiles/ > > On 05/22/2012 11:16 AM, Michael Weber (xmw) wrote: >> xmw 12/05/22 08:16:33 >> >> Modified: package.mask Log: mask x11-wm/parti >> >> Revision ChangesPath 1.13781 >> profiles/package.mask >> >> file : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13781&view=markup >> >> >> plain: >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13781&content-type=text/plain >> >> >> diff : >> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.13780&r2=1.13781 >> >> >> >> Index: package.mask >> === >> >> RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v >> retrieving revision 1.13780 retrieving revision 1.13781 diff -u >> -r1.13780 -r1.13781 --- package.mask22 May 2012 05:09:29 >> -1.13780 +++ package.mask22 May 2012 08:16:32 - >> 1.13781 @@ -1,5 +1,5 @@ >> >> >> - -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13780 >> 2012/05/22 05:09:29 dirtyepic Exp $ +# $Header: >> /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13781 >> 2012/05/22 08:16:32 xmw Exp $ # # When you add an entry to the >> top of this file, add your name, the date, and # an explanation >> of why something is getting masked. Please be extremely @@ -31,6 >> +31,11 @@ >> >> #--- END OF EXAMPLES --- >> >> +# Michael Weber (22 May 2012) +# Masked for >> removal in 30 days. +# Replaced by x11-wm/xpra. +x11-wm/parti + # >> Samuli Suominen (20 May 2012) # Still >> using vulnerable net-libs/xulrunner wrt bug 412341 # Build >> problems wrt bug 390325 >> >> >> >> > - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+7VXcACgkQknrdDGLu8JAl3gD+LVcdhSBAw3t55C+3RXySdH38 bTqP30X+ffJgWXCxhDMA/3fwxRaqCXI/hzsrK6r80p1lJRsHIe9AVzdhl4gbNrcQ =0YuH -END PGP SIGNATURE-
Re: [gentoo-dev] Remove eclass/ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2012 03:55 PM, Andreas K. Huettel wrote: > Am Sonntag 20 Mai 2012, 15:30:45 schrieb Nirbheek Chauhan: >> On Sun, May 20, 2012 at 6:55 PM, Michał Górny >> wrote: >>> I will repeat once again: autogenerate them. >> >> +1 for this, seriously. +1 and consider profiles/**/package.mask, too. - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+7VfAACgkQknrdDGLu8JAClQD/SVh+bstPurUReBipvCeGPYfE ZIGHcSs8Wt7HH0dy/YcA/iB2TRcd3BlcVy4O6v5wmf52s4UtCNnpYOL+RpD3O/in =uZ6k -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Can we bump our gentoo-x86/skel.metadata.xml and app-vim/gentoo-syntax:/usr/share/vim/vimfiles/plugin/newmetadata.vim files to display some upstream+remote-id lines to make these tags more prominent? On 04/19/2012 05:31 PM, Corentin Chary wrote: > Add rubygems, github, gitorious, pecl, pear, bitbucket. All of them > are handled by my remoteids.py script. > > ref: https://bugs.gentoo.org/show_bug.cgi?id=406287 ref: > https://github.com/iksaif/portage-janitor/blob/master/remoteids.py > > --- a/metadata/dtd/metadata.dtd 2010-03-02 18:52:11.0 > +0100 +++ b/metadata/dtd/metadata.dtd 2012-04-19 14:22:14.077954310 > +0200 @@ -61,7 +61,7 @@(#PCDATA)> - (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran) > #REQUIRED> + (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran|rubygems|github|gitorious|pecl|pear|bitbucket) > #REQUIRED> > > > - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+7n6IACgkQknrdDGLu8JB0bwEAlh9AilEx700DVEwQYD2KJxtc nLrzXyCrZZLZLE6cpX8BAJIj05i+LN8ZLJOH3bAtcSp41YG4EarviiKTdEpy2Yon =CQje -END PGP SIGNATURE-
[gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, i've looked at the blockers of "[TRACKER] portage migration to git" [1] and want to discuss "testing git-cvsserver" [2]. There are two proposed scenarios how to migrate the developers write access to the portage tree. "Clean cut" turns of cvs access on a given and announced timestamp, rsync-generation/updates is suspended (no input -> no changes), some magic scripts prepare the git repo (according to [3], some hours duration) and we all checkout the tree (might be some funny massive load). "testing git-cvsserver" proses "Clean cut" with the additional ability to continue using cvs update/commit, - in best case - on the old checkout w/o alteration on the developers side. "Clean cut" forces us to clean up out dirty checkouts (I have some added directories, added ebuilds i hesitated to `repoman commit`). Plus we have to alter all our hot-wired portage mangling scripts from cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs checkout + egencache for checkout) and have an automated google-chrome bump script). But this can be accomplished on a per developer basis, and slackers don't stall the process. "testing git-cvsserver" forces us all to test these cvs'ish scripts and behaviours against a git-cvsserver and report. We all know that this test-runs will never happen, stalling this bug till infinity. Plus infra/"subset of devs marshalling the migration" get stuck between fixing git issues and git-cvsserver. *if you still read this* *wow* Please discuss my arguments and come to the conclusions to RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove this bug from the blockers of "[TRACKER] portage migration to git". My lengthy 2 cents. [1] https://bugs.gentoo.org/333531 [2] https://bugs.gentoo.org/333699 [3] https://bugs.gentoo.org/333705#c2 - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW =jXLQ -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 06:58 PM, Justin wrote: > Was this a vote for or against a quick proceeding towards git? No, just to decide if git-cvsserver (providing cvs access) should be part of an "git master tree" szenario. In bugzie: Should https://bugs.gentoo.org/333699 stay a blocker of https://bugs.gentoo.org/333531. No flame about "git over cvs" in general, whether or not sparse checkouts (i.e. w/o kde-*,gnome-* categories) make sense. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9SfMACgkQknrdDGLu8JCGtQEAiS3Wcsll94w2rqlMP2WpSypU fLdxa2wjstJ5Y/2iXCcA+wX/p+OwBzjLAxiwKnSl98XlLSIT/Qsxm5H1TvEEJ71w =k8j9 -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 07:06 PM, Alexey Shvetsov wrote: > Isnt cvs too sloow on mips? git is much more faster. Same for arm. > About big repos, well why not use shallow cloned repo. It will work > with plane history Can we please cut that out. I do/did arch testing on arm5, ppc, sparc on rsync trees and committed the changes from my shiny 2007s notebook. I did hesitate to spread my commit credentials over all these machines. Michael - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9Sv8ACgkQknrdDGLu8JBFLAEAghjKAQwckMndZfO/gGQyVI3N butEASSJZYQetyNthUgA/3e5Sf9B93ED/wDSDflKP7YwTVwiFOe5c65Md4vdEsQs =FW7S -END PGP SIGNATURE-
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/23/2012 11:14 PM, Dan Douglas wrote: > On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote: >> 2. rsync generation is NOT going away. Users will still be using >> it. First, I'd stick with the current rsync to spread the tree (mirror work and mirrors+regular rsync users shouldn't notice any backend switch at all). > Would users have a way of gaining read-only access? This would be > EXTREMELY helpful. Sure, this would be possible like any other git checkout (layman-git-overlays, github.com, etc.). Please compare (browsing source and access description) http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh =dvFZ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/24/2012 03:37 PM, Kent Fredric wrote: Kent, this is of topic, stop it. - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk++PO8ACgkQknrdDGLu8JC2cAD/WknV6DJEzYEsuXJD0TuDU99I arDTkrBHNXydYVdaxGoBAJmmVm3o7YWlMAvFBz2Eu4ma/VXEHdqocFwl0NK+FEAh =Esu3 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Enable FEATURES="userpriv usersandbox" by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/28/2012 11:34 PM, Zac Medico wrote: > I've been using FEATURES="userpriv usersandbox" for years, and I > don't remember experiencing any problems because of it, so I think > that it would be reasonable to have it enabled by default. > Objections? It was/is default on default/linux/amd64/10.0/developer (the one we all should use ?) +1 - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/EB5EACgkQknrdDGLu8JBVyAD/a/Szj+swzSIkAgZv2bGzezIQ M/2+tZUUk+ZE6HlkDrsA/RufmJGlAEa9MJtImaTo/h9svEG/BhioQNvo49nT2ssi =IRjv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/31/2012 02:04 PM, Aaron W. Swenson wrote: > The 6 hours it takes to clone the repo. afaik it's 6 hours to transform the whole cvs history into a git repo. Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and 22 minutes of 3.4GHz cpus). [1] git clone git://git-exp.overlays.gentoo.org/exp/gentoo-x86.git [2] http://lore.xmw.de/gentoo/gentoo-exp/notes Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/JKucACgkQknrdDGLu8JAIxAEAhLZ4Tk6rXy1qAUbDDHS4UYiL gGUPj5PKUKSS1YJp6hkA/R9aEqjSNr/8iZ2novNFGjvbJ5CtDkvI+PsvMTUNDoDo =3t+7 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Is there any way to verify the data? What programs/scripts use these fields btw? I could imagine a test like (i.e. $a ) does http://www.fs.net/$a exist. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/KTbwACgkQknrdDGLu8JC47wD/WhUl5SqDnd9SZM7xyYWE3NG6 GN/lt6/0J+7W070szVYA/00BA1r0jBA3i93FpvobgvFiKlZSTLPaN5sJCJrrqULR =Uufg -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/default/linux: package.use.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/2012 07:47 PM, Samuli Suominen wrote: > I think you meant base/package.use.mask correct, fixed. > and how about using ChangeLog? I did that in gentoo-x86/base (theres an ChangeLog file) but I didn't see anu ChangeLog in gentoo-x86/profiles/default/linux . michael@x linux 127 % echangelog "dev-db/firebird client: moved to base/package.use.mask" This should be run in a directory with ebuilds... michael@x linux 255 % pwd /usr/portage/profiles/default/linux Sorry and thanks for your pair of eyes. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/KaWMACgkQknrdDGLu8JCqDAD/eRqx+QRCjgsbNMq9JKDs1SlU IJyyRWiS5E6G61NZs/kA/ioCDq2m/52qsDfg6kG+o+FKHpabMxBcYMZlPD0LHtZS =Mb66 -END PGP SIGNATURE-
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/03/2012 12:22 PM, Andreas K. Huettel wrote: > ( What I'd ask for is as "raw data" - take all commits (say, for > the last year), filter out Manifest-only stuff, make a text file > with only the timestamps for each commit, ideally one per line and > already in "seconds in epoch" format... > > This, being pretty similar to whatever comes out in our labs, could > then be postprocessed and visualized... :) ) > > Cheers, Andreas > robbat2 zipped gentoo-commits-ml for me to dev.g.o:/space/temp/gentoo-commits-20120602T221900Z.tar.bz2 I'll take a look at the data this afternoon. - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/LPjIACgkQknrdDGLu8JDGCQD/dAoCqzzp2thApJtNyQ1EsSQl AQx4OzTQ5Oy/iT9CSCMA/0j1YuuIXhouRRdbRHNYVhu0oBNbCVLOVGpDsHxRtRHB =31xY -END PGP SIGNATURE-
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/04/2012 03:25 PM, Brian Harring wrote: > While I do grok the potential issue of someone being a hog > (specifically via blasting commit by commit rather than building up > work locally, then pushing it in chunks), frankly... I'm not that > concerned about it, and would rather deal w/ it if/when it occurs. > The nature of our commits for the most part are standalone from > others- that's not true of the kernel/mozilla, thus why I don't > think their issues are necessarily ours. True. We already have maintainers and herds as responsible (sole editors) entities for locations (packages). But, we have arch teams editing ebuild/KEYWORDS, which alters Manifest/EBUILD lines. Resulting in potential clashes (not fast-forwardable), if the herd or maintainer does bumps or cleanups. Will these Manifest lines (and the arch team inflicted Manifest changes)? And we have orphaned (maintainer-needed) and "everyone can fix it" herds like desktop-*). This results in a large group of potential bug-fixers (committers) and the potential of concurrent edits. This can be managed by using bugzilla IN_PROGRESS as a lock state, but I thats not very practicable/needs disciplin/is annoying. But this is no regression compared to CVS, we just need to signal clashed. Last assumed hot spot imho is package.mask with ~700 commits in the last 4.5 months (one every 4.6 hours) and ~620 commits in **/package.use.mask. Not that much. According to robbat2 data (gentoo-commit tarball) we have ~400k commits in gentoo-x86 (w/o proj,xml) in 4.7 years, that's 6.2 per hour averaged. But I've to look into the data to see trends (# developers, daylight). Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/NOFQACgkQknrdDGLu8JARlwEAldk7GAEqCrd5mSsDgC69e5uQ aqivvwbDpNWSgfwJqwUA/jjlByEncXXPVia11BALSdDf1elrL/3qAf5ktCtxx/m0 =pJFc -END PGP SIGNATURE-
Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/05/2012 02:44 PM, Aaron W. Swenson wrote: > "There's never anything important in all that text." - Anonymous > Gentoo User The bad part is, that even reading of these messages can result in a breakage. I update a bunch of machines with these steps (maybe we should place instructions like these on a prominent place). (this is multi user, multi session). #preparations eix-sync cd /etc/portage git pull ; [ git stash ; git pull ; git stash pop ; git commit -a ; git push ] #on kernel updates emerge -av1 --nodeps gentoo-sources cd /usr/src/linux ; zcat /proc/config.gz > .config make oldconfig time ( make -j8 && make install_modules && make install && module-rebuild -X rebuild && eclean-kernel -n 2 -x config && grub2-config -o /boot/grub2/grub2.cfg ) #regular packages emerge -avuND world dispatch-conf/etc-update emerge -a --depclean revdep-rebuild --ignore -- -av revdep-rebuild --ignore -- -av (second run) #on xorg-server updates emerge -av1 $(qlist -IC x11-drivers) Nice, isn't it? [1] if you forget the -X on module-rebuild, you might no longer have the virtualbox-modules version installed in the tree (no packages satisfy ...). virtualbox does remove old versions real quick. The fun part comes with non-root users trying to log in: [2] You've updated nvidia-drivers (kernel module providers in general) userland and kernel modules, but forget to `rmmod nvidia`, or you can't without terminating user sessions, it impossible to start new X servers due to version mismatch between userland and kernel (applies for virtualbox as well) [3] You've updated zlib, but failed to recognize it in the emerge -av output. You get angry reports about broken luatex and inkscape (imagemagik) because of some nasty zlib abi version mismatch, hidden from revdep-rebuild. [5] lafilefixer (funny) [4] python-updater (rare) [6] ocaml gets broken after update w/o lablgl rebuild https://bugs.gentoo.org/385869 Well, I'm lazy, and do this in the backgound, half asleep. And I admit that [1] and [2] are my faults, but [3] is very annoying (just like libdl related stuff) and esp. kernel+module updates take a lot more than just a few 'REBUILD' packages. Is there any chance to detect this ZLIB_VERSION problem with revdep-rebuild (worst case: add a list of possibly broken packages with tests)? = I understand the urge for `eupdate` but that needs an agreement on the implementation, and I see some rought edges here, where unattended script magic most likely fails. Michael -- half asleep - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF0EAREIAAYFAk/OqZ4ACgkQknrdDGLu8JCZTgD2MXNld64l2D9jdko5sDQ1RedO hDDGT1frS210sIkG5AD+M0N08Ru0FrVmqarkxec6N71egAmrmRUmcMMhtWCcUK0= =0Xwl -END PGP SIGNATURE-
Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/08/2012 01:36 PM, Rich Freeman wrote: > I doubt any dev checks the signatures on manifest files before > they overwrite them with a new signature. If they did it wouldn't > matter since those signatures aren't even mandatory anyway. > Certainly it isn't intuitive to me that when I perform a signature > on changes I make that I'm also vouching for work committed by > somebody else before me. I'm trying to do this, but first we need an keyring with all dev gpg keys - securely distributed - to verify the signatures. We (amost all) have gentoogpg key-ids in ldap, most have fingerprints in gentoofingerprint in ldap, but we have to download these keys from public keyservers. And its not mandatory to either sign at all or sign with keys mentioned in ldap. Someone pointed me on tove's list of gpg keys used for signing [1]. I'd suggest to generate an tarball (containing an keyring) to sign by an master key (member of trustee/council/..) to be deployed on all systems (like it's done on archlinux and debian). But the current vulnerability is exporting/importhing these keys to pgp.mit.edu et al. Suggestions? Michael [1] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/keys_in_use.txt - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/SAOkACgkQknrdDGLu8JBWywD/e4kT9jUt3CFFMZgMla14zdwT dmZZs4R5to9CikKAFqwA/1dcXV9/8H/qrW0q8yO7pEIdCdr8RD2d0mochceEeyxd =+k9D -END PGP SIGNATURE-
[gentoo-dev] Fwd: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 FYI, after talking to radhermit and hwoarang on #gentoo-dev, I masked these two versions. See my comments on https://bugs.gentoo.org/416081 for details. Michael Weber - Original Message Subject: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask Date: Sat, 9 Jun 2012 10:49:07 + (UTC) From: Michael Weber (xmw) Reply-To: gentoo-dev@lists.gentoo.org, x...@gentoo.org To: gentoo-comm...@lists.gentoo.org xmw 12/06/09 10:49:07 Modified: ChangeLog package.mask Log: Masking =sys-fs/mdadm-3.2.4 and =sys-fs/mdadm-3.2.5 for bug 416081 Revision ChangesPath 1.6651 profiles/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?rev=1.6651&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?rev=1.6651&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/ChangeLog?r1=1.6650&r2=1.6651 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v retrieving revision 1.6650 retrieving revision 1.6651 diff -u -r1.6650 -r1.6651 - --- ChangeLog 8 Jun 2012 18:37:58 - 1.6650 +++ ChangeLog 9 Jun 2012 10:49:07 - 1.6651 @@ -1,11 +1,14 @@ # ChangeLog for profile directory # Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2 - -# $Header: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v 1.6650 2012/06/08 18:37:58 tove Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/ChangeLog,v 1.6651 2012/06/09 10:49:07 xmw Exp $ # # This ChangeLog should include records for all changes in profiles directory. # Only typo fixes which don't affect portage/repoman behaviour could be avoided # here. If in doubt put a record here! + 09 Jun 2012; Michael Weber package.mask: + Masking =sys-fs/mdadm-3.2.4 and =sys-fs/mdadm-3.2.5 for bug 416081 + 08 Jun 2012; Torsten Veller package.mask: Mask dev-perl/CPAN-Mini-Phalanx for removal (#420075) 1.13840 profiles/package.mask file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13840&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?rev=1.13840&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/package.mask?r1=1.13839&r2=1.13840 Index: package.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.13839 retrieving revision 1.13840 diff -u -r1.13839 -r1.13840 - --- package.mask 8 Jun 2012 18:37:58 - 1.13839 +++ package.mask9 Jun 2012 10:49:07 - 1.13840 @@ -1,5 +1,5 @@ - -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13839 2012/06/08 18:37:58 tove Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.13840 2012/06/09 10:49:07 xmw Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -31,6 +31,17 @@ #--- END OF EXAMPLES --- +# Michael Weber (9 Jun 2012) +# The mentioned versions fail to assemble raid 0/1/5 devices. +# As reported in bug 416081 users end up with multiple raids +# all consiting of single drives. disk/by-uuid is preseved +# for single disks, so users end up with auto-mounted raids +# effectivly running on single disks. +# @base-system feel free to re-evaluate the severeness of this +# regression and drop the mask. Masked for now. +=sys-fs/mdadm-3.2.4 +=sys-fs/mdadm-3.2.5 + # Torsten Veller (08 Jun 2012) # Masked for removal (#420075) # The Phalanx Project is finished and no longer active - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/TKrIACgkQknrdDGLu8JBNKAD/Y80SjlzvUjG1nC0FTGoQSNGO 0VaypBDvIVqWzqXqmdcA+gLTkNgiYIW4fitSyyCXO55iP0uN/4qql44E31QIgzd/ =Af73 -END PGP SIGNATURE-
[gentoo-dev] Github.com tarballs eclass idea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi folks,
i've some packages fetching SRC_URI from github.com
tarballs/tags/files like x11-misc/trayer-srg.
Fortunately, github.com provides (mostly) stable tarballs that are fit
for manifestations (file sizes and checksums don't change).
There is no need to create/host tarballs to be picked up by mirrors.
Unfortunately, these tarballs contain $author-$repository-$commitidabrev
(e.g. sargon-trayer-srg-5353f80) ad top directory.
One approach is to define ${S} to match these additional data, but to
easy version bumps, I've started to rename the extracted directory
within src_unpack, to avoid mentioning the $author, $commitid and
modifying ${S}.
"""
SRC_URI="https://github.com/sargon/${PN}/tarball/${P/-srg/} ->
${P}.tar.gz"
src_unpack() {
unpack ${A}
mv *-${PN}-* ${P} || die
}
"""
I wonder if others have similar workarounds?
And does this src_unpack qualify for an eclass or being added to an
existing one, to avoid code replication?
Maybe fetch filename " -> ${P}.tar.gz" can be mangled into SRC_URI by
this eclass/function, too.
Michael
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAk/V9YwACgkQknrdDGLu8JBbzgD/aZ0USZEnfa2bQaoHOjKglMN/
BJHuAOv0At95B4ARSXkA/A79qARFSCCAryjv55A1f6+3LafaRJlP0QKLp+zHoKvq
=W1YG
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/11/2012 04:25 PM, Michał Górny wrote: > > Committed onto vcs-snapshot.eclass after fixing all in-tree users. > Thanks for the update. One suggestion: Have you thought about using bsdtar from app-arch/libarchive instead of GNU ones? You'll need an additional dependency, but it has zip file support and I've verified the options you use work [1]. To be clear, I prefer tar over zip, too, but you can restore do not prefer zip over tar, but you can restore the lost zip functionality (plus others i assume). Michael [1] bsdtar -C /tmp/xxx -x --strip-components 1 -f ~/keithw-mosh-mosh-1.2.1-0-g778b5af.zip - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/XP6IACgkQknrdDGLu8JBx4QD/dcCp2zdAAjz0kMEVmmdIgQn3 dqU6wv4vBhipVrlaJRYA/R1LAd8lfPBh3uiUEvJ7MY/m1ExTkDXA64QQ5LC61jOA =CAmK -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - From the eclass: # XXX: check whether the directory structure inside is # fine? i.e. if the tarball has actually a parent dir. This should work with gnu and bsd tar, and sed+sort+wc from sys-apps/coreutils as well as busybox. [ $(bsdtar -t -f ~/keithw-mosh-mosh-1.2.1-0-g778b5af.zip \ | sed 's:/.*::' | sort -u | wc -l) == 1 ] I'm totally sure if we have to handle leading slashes and ./ in obscure tars/zips but I'd say this tests qualifies for an || ewarn "Please check $f for an single parent directory" or something like that. My 2 cents - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/XQ6IACgkQknrdDGLu8JCXrQD/esMpA3z4jiZIsI3qkiz3zM7X 0I2ck7tG6WHGqTP/HEQA/jCAxkDt2hUXM+govuZaKrNHj5pBNvJIQNUF7VnzYKYr =Lf4O -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: vcs-snapshot-r1.eclass -- a better eclass for VCS snapshots (and others)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/12/2012 04:46 PM, Michał Górny wrote: > Well, I was hoping to come up with something which doesn't involve > running additional 'tar -t', to be honest. I have to think about > it some more time. > FTR, filelist=$(tar xvC /tmp/xxx --strip-components 1 \ -f ~/keithw-mosh-mosh-1.2.1-0-g778b5af.tar.gz 2>&1) || die [ $(echo $filelist | sed 's:/.*::' | sort -u | wc -l) == 1 ] \ || ewarn "..." does work with GNU tar, but not with bsdtar, which displays the stripped filenames, plus an leading "x ". Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/XrOwACgkQknrdDGLu8JCbwwD+InGUaLTki1W6gYwy+O2zAEek peIoy1cjDig3EWqRtacA/RVFf3P5y8MBRKaE7yeyzypTUomvXq6tWqVZSUywnjYL =3Zw6 -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs due cla retirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/16/2012 10:13 AM, Pacho Ramos wrote: > net-misc/balance i'll take this one - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/cReMACgkQknrdDGLu8JCKPAD/Yd7v9s6XGvel2dS10Ibu3hHA Y1sucB1jKEE5f/DnqJABAJfm6YXj/nA3nfnlU5B0CO1ZLFQbbq1bseMhEwQA7El/ =N6mI -END PGP SIGNATURE-
Re: [gentoo-dev] Bugzilla whine mail "spam"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/23/2012 09:59 PM, Christian Ruppert wrote: > Again: Don't take it too serious, if it helps to remind you that's > fine but ignore anything else. It'd be cool to exclude STABLEREQs, but I support the reminder characteristic. - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/mKAIACgkQknrdDGLu8JCfLAD+PwgOeBcsslpq/xNB4nBy6VvK 9AaFw3pCU3xVT6K7818A/0F0NqL0sF0iBlO1ic9zsGySFCv8xtQdNeMOA3YABE2j =NOoJ -END PGP SIGNATURE-
Re: [gentoo-dev] euscan GSoC project - requesting feedback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/27/2012 10:00 AM, Dirkjan Ochtman wrote: > On Wed, Jun 27, 2012 at 9:51 AM, Federico "fox" Scrinzi > wrote: >> The main question is: what would you like to have on this >> dashboard? Currently (in the development version) there's the >> possibility to login and watch/unwatch >> packages/categories/herds/... and see the watched stuff in the >> account dashboard. We're planning on implementing a weekly(?) >> custom newsletter based on the packages you're watching, which >> features would you like? > > - The ability to pick what overlays I care about - Ignore > alpha/beta versions if the current gentoo-x86 version is not > alpha/beta - Candidates for stabilization > - - a request rescan button - - a Report problem machanism. i.e. on http://euscan.iksaif.net/maintainers/48/ there's an inconsistency between both "upstream" and "version in gentoo" being 2012.2.0 but there's still a light red marker. Great tool, thanks. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/q0o0ACgkQknrdDGLu8JB9/gD/QpQE9ezi3wMBKTgLfyT1oTEk +4SxawZ5to7cdnI06q8BAJPdcxzuU+4AG05rTPzuPBfaDz4Xz7t7Xc9Bj+JsSN9W =eV1X -END PGP SIGNATURE-
Re: [gentoo-dev] Kernel compiles and you
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/04/2012 08:56 PM, William Hubbs wrote: > On Wed, Jul 04, 2012 at 02:20:36PM -0400, Rick "Zero_Chaos" Farina > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 07/04/2012 01:58 PM, Michał Górny wrote: >> We could allow writes in the directories but not to the kernel >> source files themselves... that seems moderately sane even as the >> source files don't need to be written to be compiled, only the >> dir's need write permissions... > > Actually the directories do not need write permissions either. Take > a look at the O= option documented in /usr/src/linux/README. > > William > Um, well, users can then write the the compiled files (.o in the tree). You can also set `chmod -R g+w /` and gave everyone full access. I think running kernels from non-root checkouts is a pretty big security hole. Michael - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/0lFQACgkQknrdDGLu8JD3AwD8CWdFJemXSh4O4xS94AXfo1Bw 6XwIhGspPvP/EGI/+7cBAI486fBSopMQxB/IaFyDnwVxriLZxOan5SrqMJXWa8b5 =+ocR -END PGP SIGNATURE-
[gentoo-dev] enewuser: home beloning $user:root inset of $user:$group
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
is it intentional behavior, that home directories created by enewuser
belong to $user:root (or pwd group) instead of $user:$group ?
I recently set net-misc/minidlna to run as non-root and ended up with
minidlna:minidlna, see [1] for implementation details (and my
workaround) and [2,3] for the discussion leading to the situation.
p.s. I aware that chown/chmod and missing ${EPREFIX} makes this a bad
hack and fails on Prefix.
Michael
[2] https://bugs.gentoo.org/394373
[3] https://bugs.gentoo.org/426726
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iF4EAREIAAYFAlAJF5YACgkQknrdDGLu8JAoQQD/U2vrcw/bOuGtmcKelM7gbfh9
aV+Nqk89M7re+gYLhY8A/RLSaNztCvQ+ti/ZYeETDEcui7wmT1kEuilxjwz1RrPV
=9ogI
-END PGP SIGNATURE-
Re: [gentoo-dev] enewuser: home beloning $user:root inset of $user:$group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/20/2012 06:44 PM, Maxim Kammerer wrote: > I think that a --do-not-create-homedir (or a shorter equivalent) is > a good idea. Yeah, just allow optional arguments to useradd like (useradd --help) -m, --create-home create the user's home directory -M, --no-create-home do not create the user's home directory I would prefer an behavior similar to regular `useradd -m -g $group` calls. - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlALVegACgkQknrdDGLu8JCucAD9GN0ZSVQxoTSkf+usb+9aybpH Q1Sa8MJck/QXhzj+BPEBAISzuqa4sM/+eh3PJEBJ3JwtVNwrNWhLv0eRiF9sWiz5 =zYTB -END PGP SIGNATURE-
FIXED Re: [gentoo-dev] net-misc/aiccu - maintainer needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/01/2012 11:17 AM, Maciej Grela wrote: ... consider this handled. - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlAY9gEACgkQknrdDGLu8JAzrgD/ZU9OLn9Kz2eKNDwdUiAt33We lHZ/4CZGoUcV2EmZdw0A/jGY8y3RypAd7zkKUfXrUIbIGO3S68FsyrynrAR5/f1L =P+A9 -END PGP SIGNATURE-
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 05/08/2017 09:13 PM, David Seifert wrote: If all of this ends in one big bikeshedding fest again, I will start dekeywording packages. Fortunately for me, I won't get any complaints (because the arch teams are dead). formal complaint, powerpc team is alive, and I'm lead. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 05/14/2017 12:44 PM, David Seifert wrote: On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote: On 05/08/2017 09:13 PM, David Seifert wrote: If all of this ends in one big bikeshedding fest again, I will start dekeywording packages. Fortunately for me, I won't get any complaints (because the arch teams are dead). formal complaint, powerpc team is alive, and I'm lead. https://bugs.gentoo.org/show_bug.cgi?id=546082 You call that alive? Well, I'm working on stabilization for some months and started keywordings just recently. FTR, nobody saw the need to migrated this bug Component:Keywording (was [old] ...) and it didn't show up on my radar, nor on x86s. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
On 05/14/2017 01:05 PM, Michał Górny wrote: On nie, 2017-05-14 at 12:52 +0200, Michael Weber wrote: On 05/14/2017 12:44 PM, David Seifert wrote: On Sun, 2017-05-14 at 12:38 +0200, Michael Weber wrote: On 05/08/2017 09:13 PM, David Seifert wrote: If all of this ends in one big bikeshedding fest again, I will start dekeywording packages. Fortunately for me, I won't get any complaints (because the arch teams are dead). formal complaint, powerpc team is alive, and I'm lead. https://bugs.gentoo.org/show_bug.cgi?id=546082 You call that alive? Well, I'm working on stabilization for some months and started keywordings just recently. FTR, nobody saw the need to migrated this bug Component:Keywording (was [old] ...) and it didn't show up on my radar, nor on x86s. Why would you expect to developers spend their effort on moving bugs to new keywording workflow *after* the arch teams have been neglecting them for 1.5 years? Because we (or some subset) agreed on the "new keywording workflow" and we all obliged to play by the rules? -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Some packages up for grabs
On 12/12/2012 06:21 PM, Matthew Thode wrote: > I'll take net-misc/radvd Welcome, co-maintainer ;-) -- Michael Weber Gentoo Developer
Re: [gentoo-dev] glibc-2.17: nscd is optional
On 12/30/2012 02:24 AM, Mike Frysinger wrote: > rough poll: how many people actually care about nscd ? I use it for some pam_ldap machines > ... it'd default to off. fine with me, I'll turn it on / need it for `ls -l /home` not taking ages. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass
Hi folks,
this commit changes the set of USE flags on the just stabled gcc-4.6,
running a huge number into an rebuild of an freshly updated package.
(emerge --newuse recaclulates from "go disabled" to "go missing")
Wouldn't it be possible to
a) refrain from this change (really, who has USE=go turned on?)
b) handle this with package.use.mask,
c) figure it out before stabilization
I see the point in nobody beeing perfect, but these recurring
effect-less rebuilds of widespread base packages set me up.
Imho, editing /var/db/pkg/sys-devel/gcc-4.6.3/USE is not a recipe to be
carried out to the user. But can we do stuff like this in profile
updates? Without hurting system with USE=go activated, which need
actually need the recompile.
my 2 cents
Michael
Original Message
Subject: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog
toolchain.eclass
Date: Tue, 15 Jan 2013 02:30:53 + (UTC)
From: Ryan Hill (dirtyepic)
Reply-To: gentoo-dev@lists.gentoo.org, dirtye...@gentoo.org
To: gentoo-comm...@lists.gentoo.org
dirtyepic13/01/15 02:30:53
Modified: ChangeLog toolchain.eclass
Log:
Drop go support for 4.6 - broken by newer glibc versions and upstream
recommends it not be used.
Revision ChangesPath
1.615eclass/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?rev=1.615&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/ChangeLog?r1=1.614&r2=1.615
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v
retrieving revision 1.614
retrieving revision 1.615
diff -u -r1.614 -r1.615
--- ChangeLog 13 Jan 2013 22:35:28 - 1.614
+++ ChangeLog 15 Jan 2013 02:30:53 - 1.615
@@ -1,6 +1,10 @@
# ChangeLog for eclass directory
# Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.614 2013/01/13
22:35:28 eva Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/ChangeLog,v 1.615 2013/01/15
02:30:53 dirtyepic Exp $
+
+ 15 Jan 2013; Ryan Hill toolchain.eclass:
+ Drop go support for 4.6 - broken by newer glibc versions and upstream
+ recommends it not be used.
13 Jan 2013; Gilles Dartiguelongue gnome2.eclass:
Allow ebuild override of eclass generated econf.
1.567eclass/toolchain.eclass
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567&view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?rev=1.567&content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.566&r2=1.567
Index: toolchain.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v
retrieving revision 1.566
retrieving revision 1.567
diff -u -r1.566 -r1.567
--- toolchain.eclass29 Dec 2012 06:45:06 - 1.566
+++ toolchain.eclass15 Jan 2013 02:30:53 - 1.567
@@ -1,6 +1,6 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.566
2012/12/29 06:45:06 vapier Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/toolchain.eclass,v 1.567
2013/01/15 02:30:53 dirtyepic Exp $
#
# Maintainer: Toolchain Ninjas
@@ -115,7 +115,7 @@
tc_version_is_at_least "4.3" && IUSE+=" fixed-point"
tc_version_is_at_least "4.4" && IUSE+=" graphite"
[[ ${GCC_BRANCH_VER} == 4.5 ]] && IUSE+=" lto"
- tc_version_is_at_least "4.6" && IUSE+=" go"
+ tc_version_is_at_least "4.7" && IUSE+=" go"
fi
fi
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: [gentoo-dev] call for testers: udev predictable network interface names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, I respect both sides of the discussion, because: a) I once set up an old P3-700 with 5+1 eth cards in 6 different networks as (bridging)router and truly benefited from the ability to change a broken NIC - which happened quite often due scrap-metal hardware - without ending up with martian packages, dhcp service on the wrong places. But that was 1 incident in 10 years. b) I use multi-nic servers, some with onboard and extention NICs c) I tend to move my setups (esp. my laptop) around between different hardware (nearly identical thinkpad R61/X61), and I _share_ my installation with other/new users by cloning my disc (well rsync), lets call this stageN installation. d) I abuse an old multiport GBit card as GBit switch in my desktop, besides an onboard one. e) Some distro/driver constellations (archlinux?) tend to name their wireless lan eth*. This resulted in one decision per setup, whether or not to set /etc/conf.d/udev's > persistent_net_disable="yes" persistent_cd_disable="yes" Either to avoid random names due hardware replacement (a) or changed module loading order (b, inside debian initrd) or to just use kernel names (eth0, wlan0) because no other cards present (c) or the NIC drivers compiled into the kernel (d). e) never happened to me. It always bugged me to fix/reboot systems which needlessly end up with eth1/wlan1 because some stupid pre-persistent_net_disable did not recognize beeing run on an entirely different hardware. So can we just watch out for the disable="yes" setting and migrate it during udev's pkg_install phases __and__ post an big fat warning (elog, news item) on the wall? I assume most linux users do not operate servers/multi-nic/multi-networking setups, do not clone their setups to other hardware. Given that, these user will almost only see the 'my nics changed names and i cannot connect to the internet' errors due some moronic or unavoidable change in initrd/module loading. That might be the driving force behind udev persistence in the first place. I'd be glad if I we respect setups w/ custom-built kernels, w/o initrds, roots capable of choosing network-name-persistence iff needed, users adoring the possibility of just dd(1)'ing installations to new hardware without reinstalling or entering an new product code. rant=1; And I'd like to avoid dozends of conversations like "Yeah, your setup/firewall/rouing/... command no longer works, eth0 is no enp0xx2_at_home_lid_open or was it _bluetooth_turned_off. Didn't you read the post on some derps mailing list." with haunted people not knowing better than asking me about their problems. Not to mention all online documentation/forum posts referring to eth0. rant=0; Keep up the good work! Michael - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD1FmAACgkQknrdDGLu8JA68wD/Vuw8mL7O0T398QR7OetqDoLN pQ7kJz9nveemDxw7o9MBAJSsyQ/DWIKLsqudXjlXhTPQEd0Od6vDBEL6IeFtXCjc =AfSI -END PGP SIGNATURE-
Re: [gentoo-dev] call for testers: udev predictable network interface names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, "This can have serious security implications" [1] For whom? The often cited end user not running any network service, not even sshd? Without firewalls, routing or dhcp_d_? Some avahi-discovery woodoo stuff unaware of network topology at all? Maybe the M$/Windows mechanism asking the user to classify an newly discovered network as (and shutting down network communication until done so) isn't the worst solution at all. (Well, that would need an dbus like service to pop up this box *hihi*) [Generally speaking] Linux developed from an highly specialized group of users to an broad spectrum from "I have control, leave my unique setup alone" to "I have no idea what I'm doing/I'm unwilling to read/Lets sudo random search results" kinda users. Not all are enlightened. Good part is the media coverage, money invested/wasted/... Hard part is to find an compromise for all users. So lets provide something that works w/o interaction or master knowledge and not annoys the crap out of users - for all users. [about NIC names] Changing the netdev names way from eth*/wlan*/wwan*/ results in a hell of obsolete documentation. Opt-out urges users into either adapt their setups or disable the rules. This LAN/WLAN eth0/eth1 mess could be fixed by assuring Wi-Fi NICs being called wlan*, and running WPA stuff just there. The upcoming UMTS/broadband interfaces are called wwan*? *duck* Last point - as long as identification of LAN networks isn't handled properly, the consistency of NIC names it the lesser security concern for users carring around their laptops. Enough! Michael [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames On 01/09/2013 11:13 PM, William Hubbs wrote: > All, > > as you probably know by now, udev-197 has hit the tree. > > This new version implements a new feature called predictable > network interface names [1], which I have currently turned off for > live systems, because it will require migration on the part of the > user. > > When you upgrade to this new version of udev, you will find a file > /etc/udev/rules.d/80-net-name-slot.rules on your system. It > currently has comments explaining what is happening. > > As long as this file is in place, this feature is not activated. > That is why there is not a news item. If you do nothing, nothing > changes. > > What I would like to do is find some people who are willing to > migrate and report any issues they find. > > I would like this to be the default for everyone at some point, so > I want to document the migration process and find out if there are > any bugs in tools because they expect the eth* names. > > Thoughts? > > William > > [1] > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames > > - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD1HmkACgkQknrdDGLu8JDLRQD+P0pO8z0WHnELVYOgQrEQi0wm Xp1kG1pQhYTCN271T6EBAJvRSacaBE7hdIaTCRH7VUoeugWdktQaXE935kqhFCNV =BWkO -END PGP SIGNATURE-
Re: [gentoo-dev] January stabilization candidates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/12/2013 11:49 PM, "Paweł Hajdan, Jr." wrote: > Please review attached automatically generated stabilization > candidates for January. cool > I don't want to annoy people with automatically filed bugs, and at > the same time I also received lots of positive feedback about the > effort to keep the stable tree more up-to-date. you can add me to the whitelist for bug filing. Would you mind adding my # xmw app-laptop/thinkfan-0.8.1-r1 Thanks! > I think the best way to proceed is to listen to that feedback and > continue the effort, while also keeping an updated list of > exclusions for packagers/herds that are actively stabilized by > maintainers. Do you/we have any ready-to-use script to file stable requestst? I know it's just dome lines of python but I'm lazy. To lazy to get all these 10-something clicks'n'paste right to file such bugs on first attempt. Michael - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD2tEgACgkQknrdDGLu8JCXjwEAmnSj0mvW7hxJgNHSux+P0P/I ikSyI6XM357KIvU7DX0BAI1Nb6IyKJUq2GNhJCMUaX9RAEL1BvZLczPq+uCAkPvU =X8G6 -END PGP SIGNATURE-
Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes
On 01/15/2013 09:51 PM, Dirkjan Ochtman wrote: > On Tue, Jan 15, 2013 at 9:18 PM, Peter Stuge wrote: >> emerge --sync layman -S eix-sync #layman... porticron # from porticron update-gentoo # cvs setup https://xmw.de/dotfiles/bin/update-gentoo >> emerge --upgrade with a predefined EMERGE_UPGRADE_OPTS in make.conf (where EMERGE_DEFAULT_OPTS lives). But ++ on that -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] call for testers: udev predictable network interface names
On 01/16/2013 05:25 PM, Mike Gilbert wrote: >> It has been rather nifty that if I walk up to a random machine >> with exactly one NIC (that I've been asked to examine/fix), I >> _know_ that there will be eth0 and only that. ++ > I would actually like to see iproute2 added to the system set. ++ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/16/2013 06:33 PM, Michael Orlitzky wrote: > Yes, sorry for the confusion. I use more than one package manager, > and when doing an "update" or "upgrade" I'm basically flipping a > coin. hehe, as long as we don't --dist-upgrade ;-) the g was intentional. how does portage @preserved-libs work? maybe we could emerge @update[s] and @glsa. https://wiki.archlinux.org/index.php/Pacman_Rosetta - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD3PyYACgkQknrdDGLu8JDKOAEAlSRRrurL7VWpeMMtB2sVZeH4 Ik+D3d5LL1Nahflz+PIBAIWVFvyuNmzgnvE+wOpU70AIacTbprFcFJFOe9JaVBVr =gKRT -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
On 01/17/2013 11:42 PM, Maxim Kammerer wrote: > The journal is not cleared. On ext3/4, this usually means metadata — > see [1] for more details. All in all, secure-delete has its uses. What > are people supposed to use instead, dd if=/dev/zero > of=/media/sdcard/naked_gf_0001.jpg? Besides, there are complementary > tools in the package, like sfill. ++ for the VFAT/non-ext[34]/ argument Personally I use shred from sys-apps/coreutils, shred -uvxz /mnt/cf/naked_gf_0001.jpg which might qualify for an alias, but it's good. I'd grab this package, if thats the point. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org
On 01/17/2013 11:36 PM, Robin H. Johnson wrote: > On Sat, Jan 12, 2013 at 10:36:31PM +, Robin H. Johnson wrote: >> If there are no problems reported by Jan 17th, I'm going to complete the >> DNSSEC configuration on gentoo.org and remaining delegated sub-domains. > Everything is in place except the final trust binding from the org. zone > to gentoo.org, that will take a couple of hours, but I'm holding off to > detect more breakage. > ++ for DNSSEC, Regarding ssh support, can you take a look at [1], please. And I can't see SSHFP record on dev.g.o. Thanks -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/08/2013 12:39 AM, Benjamin Lee wrote: > On 01/07/2013 06:34 AM, Maxim Kammerer wrote: >> browser plugins? Also, how widespread is client DNSSEC support? >> E.g., I enabled DNSSEC for my domain, but not sure yet whether >> DNS resolution anywhere will fail in case DNS responses are >> spoofed. > > Comcast runs dnssec-failed.org, which is convenient for testing out > some DNSSEC validation failure cases. Using a validating resolver, > my client sees SERVFAIL: > > $ host dnssec-failed.org. Host dnssec-failed.org not found: > 2(SERVFAIL) The AD flag is missing on the answer (see bottom). Programs don't really use that lack of coping with that information. Openssh works, Firefox has an plugin http://www.dnssec-validator.cz/ I don't think SERVFAIL or NXDOMAIN is the right way to communicate an validation order. Michael p.s. there's dnssec-system-tray to have an eye on the unbound log. I can provide you with a setup description iff you like. michael@x ~ % dig dnssec-failed.org ; <<>> DiG 9.9.2 <<>> dnssec-failed.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62274 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;dnssec-failed.org. IN A ;; AUTHORITY SECTION: dnssec-failed.org. 7200IN SOA dns101.comcast.org. dnsadmin.comcast.net. 2010101559 900 180 604800 7200 ;; Query time: 1852 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Jan 18 00:38:07 2013 ;; MSG SIZE rcvd: 117 michael@x ~ % dig xmw.de ; <<>> DiG 9.9.2 <<>> xmw.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30196 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;xmw.de.IN A ;; ANSWER SECTION: xmw.de. 42 IN A 176.9.87.236 ;; Query time: 1 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Jan 18 00:39:53 2013 ;; MSG SIZE rcvd: 51 - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD4jLMACgkQknrdDGLu8JAAEAD8CYwlaeOcfZGIqwDurx4Bnhf8 H9+T1yirfVh/V9njmQUA/jCXhbi0MuLcQJeopyGT/xwR1EUlS1llH4pF8uAh29F8 =Mr9O -END PGP SIGNATURE-
Re: [gentoo-dev] DNSSEC (w/ DLV) live on *.dev.gentoo.org
https://bugs.gentoo.org/show_bug.cgi?id=435372 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass
Hi, I'd like to drop one strong suggestion about configuration management that might be beneficial here: use version control software! Some machines (esp. those with shared administration) have /etc/portage under git [1] with - /var/lib/portage/world symlinked to /etc/portage/world - PORTDIR_OVERLAY=/etc/portage/local-overlay Basically, we have 4 roots fiddling with 4 machines and different behaviours. Some forget --oneshot (-1) on broken-libs rebuilds, some forget to mark packages in world file after successful tests. Some forget the second > on `echo foo-bar/blub > /etc/portage/package.keywords/global` Some forget to commit+push their changes. All these "problems" esp. the mentioned world file pollution is documented quite well in the git log, or doesn't get committed at all. I check `cd /etc/portage ; git stash show ; git diff` on a regular basis o keep it all together. The update is almost unattended with [2]. General benefits: - You can recover from moronic file handling - The changes to the machines get documented (and announced by mail) - Config changes and updates can be made w/o all machines being up. - It feels like an normal machine, no need to run any deployment tool to just test-install a package. Down drafts: - Doesn't handle layman repo list - Git merge is bad on two changes adding a new last line - autoupdate.sh doesn't handle error exit codes. So, __USE__ an version control, even when you're just running `cd /etc/portage ; git commit -a -m "randoom updates"` from time to time. Bye [1] http://git.fs.lmu.de/gaf-etc-portage.git/ [2] http://git.fs.lmu.de/gaf-etc-portage.git/blob/HEAD:/bin/autoupdate.sh -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass
On 01/18/2013 08:36 AM, Benedikt Böhm wrote:
> On Fri, Jan 18, 2013 at 8:27 AM, Michael Weber <mailto:x...@gentoo.org>> wrote:
> I'd like to drop one strong suggestion about configuration management
> that might be beneficial here: use version control software!
> or even /etc/.git ... it saved my life on numerous occasions
Sure, bit thats's the point were diversity (hostnames, ssh_host_keys)
kicks in (which has been eliminated in mentioned example) and
the repo carries confidential information.
(Well, if somebody places an compromised update in the
local-overlay, i'd blindly install anything)
I even have / inside git for testing, with excludes on /opt/ /usr
/{s,}/bin /etc/ssl and so on.
It works and is handy to easily add apache config, web-app-config
installed roundcube, layman overlay list, but the maintenance of the
.gitignore raises and hardlink solutions like dirvish make more sense
for being complete backups (LD_LIBRRY_PATH=/backup/.../tree/usr/lib).
> for reference, here is my updateworld script, which also handles python,
> ruby, perl, revdep-rebuild and all that
> crap:
> https://github.com/zenops/cookbooks/blob/master/cookbooks/portage/files/default/scripts/updateworld
cool.
So basically everyone uses personal `apt-get update` (cvs co, porticron,
emerge+layman, eix-sync) strategies and even more
funny little scripts for `apt-get upgrade` (-avuND world, aliases,
scripts).
I wonder if anybody uses unattended [backup+]emerge as cron job.
I'm really temped to do so, but with users relying on these machines I'm
always chicken-out.
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: update commands / world file pollution Re: [gentoo-dev] Stable sys-devel/gcc USE flag changes WAS: [gentoo-commits] gentoo-x86 commit in eclass: ChangeLog toolchain.eclass
On 01/18/2013 09:28 AM, Benedikt Böhm wrote: > i've refrained from doing unattended upgrades for a long time, but i'm > quite confident in updateworld these days and i usually test it on 2-3 > machines and then let the other 50+ machines do it unattended and it has > been working fine so far ... good strategy. > but - and that's quite important i guess - i only use my own clone of > the portage tree which i sync from time to time and i also keep > different versions stable, etc. HEAVY USER! But you have full control. Do you have any sophisticated mechanism to detect tree breakage (i.e. us f*** up), like Samuli replying -commit to -dev or irc activity? Or do you simply delay commit? (re-schedule on weekends/nights) Delaying stabilization seems legit, but on Gentoo-stable ?! -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/12/2013 09:47 PM, Andreas K. Huettel wrote: > 10) add "13" to the selectable Versions in Bugzilla. Not that anybody cares, but 10 and 10.1 are in there. Maybe we could drop these values (dropping the field might need a change in the code) to reduce the number of selection a newbie reporter is faced. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlD5KUQACgkQknrdDGLu8JBmIwD/QGdNkWVAM5JsIDIXV9SGyNeC lkxm02p8qpbnCE+ZAuYA/3Gdf9xh6OMcCz5OAuTNnUcNrJ5JhtFMPBodqOC9lF0b =9c48 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new "qt" category
On 01/19/2013 03:14 PM, Ben de Groot wrote: > On 19 January 2013 21:46, Patrick Lauer wrote: >> Maybe lib-qt ? dev-qt sounds confusing to me too, what's "dev" about it? > > These are libraries and applications that are used by developers of > end-user applications. And so is vim, which is used as editor, by devs. My initial reading of the posted line "categories are foo[-]bar" reminded me of some discussion with archlinux enthusiasts which find them stupid. It all boils down to: Do we want categories or not? Categories are nasty, I always fail on `emerge -av1 screen` which resolves to app-misc/screen and app-vim/screen. Besides the limitation, categorization creates structure, Does it belong to gnome or kde? is it an x11 app? is it an application or just an library? and so on .. We have a fixed number of exact 2 tags (foo and bar), This limitation has proven it's usability in the past of Gentoo, but there are reasons to break it up (Like making up funny points like regex and it has always been this way). foo-bar-baz might be usefull, too. But it's plain redundacy to in insist on *qt*/qt-*. Either reject using an appropriate category and place it as misc-randoom/qt-* or use a category and strip the "qt-" prefix. I'm fine with qt/core, my preference would be lib-qt/core or lib/qt-core. But please don't double the qt. Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] Fwd: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail-rssyl: ChangeLog claws-mail-rssyl-0.34.ebuild
Hello Christian, it looks like you accidentally choose the latest stable version 0.34 for removal instead of the older 0.33 [1]. I assume this happened in error and I revert the commit. (The 0.33 version downgrade does not build) This is reported as [2], too. Bye, Michael [1] https://bugs.gentoo.org/show_bug.cgi?id=448968 [2] https://bugs.gentoo.org/show_bug.cgi?id=453298 Original Message Subject: [gentoo-commits] gentoo-x86 commit in mail-client/claws-mail-rssyl: ChangeLog claws-mail-rssyl-0.34.ebuild Date: Sun, 20 Jan 2013 21:56:35 + (UTC) From: Christian Faulhammer (fauli) Reply-To: gentoo-dev@lists.gentoo.org, fa...@gentoo.org To: gentoo-comm...@lists.gentoo.org fauli 13/01/20 21:56:35 Modified: ChangeLog Removed: claws-mail-rssyl-0.34.ebuild Log: clean up (Portage version: 2.1.11.31/cvs/Linux i686, signed Manifest commit with key 2B859DE3) Revision ChangesPath 1.120mail-client/claws-mail-rssyl/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog?rev=1.120&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog?rev=1.120&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog?r1=1.119&r2=1.120 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog,v retrieving revision 1.119 retrieving revision 1.120 diff -u -r1.119 -r1.120 --- ChangeLog 20 Jan 2013 10:24:05 - 1.119 +++ ChangeLog 20 Jan 2013 21:56:35 - 1.120 @@ -1,6 +1,10 @@ # ChangeLog for mail-client/claws-mail-rssyl # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog,v 1.119 2013/01/20 10:24:05 ago Exp $ +# $Header: /var/cvsroot/gentoo-x86/mail-client/claws-mail-rssyl/ChangeLog,v 1.120 2013/01/20 21:56:35 fauli Exp $ + + 20 Jan 2013; Christian Faulhammer + -claws-mail-rssyl-0.34.ebuild: + clean up 20 Jan 2013; Agostino Sarubbo claws-mail-rssyl-0.34.ebuild: Stable for alpha, wrt bug #448968 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Hi, On 01/23/2013 04:04 PM, Rich Freeman wrote: > System seems to work fine, so I'm not sure how essential that line is. > The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. udev/openrc stopped re-mounting /dev that last year. Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] DNSSEC errors on *.bugs.gentoo.org
Hello Robin, looks like we have an little issue using DNSSEC for bugs.gentoo.org, but not signing 339761.bugs.gentoo.org `dig does-not-exist.bugs.gentoo.org @8.8.8.8` returns A record with AD flag. `dig 339761.bugs.gentoo.org @8.8.8.8` returns A record w/o AD flag Both work with local unbound resolver with forwarders removed. It looks like stale, unsigned entries. Did you change anything in the last n days? Or is the cache of 141.1.1.1 and 8.8.8.8 really compromised? How do you sign these wildcards anyway? Would be interested. Michael [1] http://domainincite.com/2361-dnssec-to-kill-the-isp-wildcard -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] DNSSEC errors on *.bugs.gentoo.org
On 01/24/2013 09:02 AM, Michael Weber wrote: > Did you change anything in the last n days? > Or is the cache of 141.1.1.1 and 8.8.8.8 really compromised? Me culpa. Looks like these do not support AD now (or never did) And my unbound always used the first resolver, which has AD. As antarus pointed out, [1] and [2] report positive validation. Michael [1] http://dnssec-debugger.verisignlabs.com/339761.bugs.gentoo.org [2] http://dnsviz.net/d/339761.bugs.gentoo.org/dnssec/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)
On 01/24/2013 02:45 AM, »Q« wrote: > On Wed, 23 Jan 2013 13:49:09 -0800 > Christopher Head wrote: > >> On Wed, 23 Jan 2013 17:03:15 +0100 >> Michael Weber wrote: >>> udev/openrc stopped re-mounting /dev that last year. >> >> Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled, latest stable >> udev (197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet >> my /dev is still a devtmpfs with a proper set of device nodes. > > Me too. It looks like /etc/init.d/udev-mount mounts it if the kernel > hasn't, but I'd like to know more about whatever best practice is. Mind the _re_-mount, if udev discovers /dev not being mounted, udev does. if udev discovers /dev mounted, no mount action is taken. Earlier versions remounted /dev regardless. My best practice is to have CONFIG_DEVTMPFS_MOUNT enabled: I don't use initrd (except for disk encryption) and I still find my disks during init=/bin/bash recovery. and it does not hurt, anymore. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
What's the primary Idea behind multilib at all?
Isn't it just a workaround to keep prebuild software
from lazy/incapable/dead upstreams working (skype, ...)?
Is there any other real use besides bragging about processor
capabilities and compiling an stage1 boot loader?
Please don't get me wrong. I honor the whole effort done to bring this
magic into portage/..., but I see limits in the underlying file system.
The current solution suggested by FHS-2.3 [1] is to use
/lib and /usr/lib, which works for runtime emul- packages,
since software either installed to /opt/{${PN},bin} or had no
alternative in /bin or /usr/bin.
On 01/27/2013 02:40 PM, Thomas Sachau wrote:> 2. How do you handle
other abi-specific files like headers or binaries
> and cases like binaries with abi-specific content? Is it possible
> to preserve them for all requested abis or to preserve them for an
> non-default abi?
On 01/27/2013 05:08 PM, Pacho Ramos wrote:> Maybe installing headers
in other place would be interesting :/
This is getting wired now, when we get an x86, x86_64 and x86_32
(srsly?) implementation of cp(1).
Either we avoid collision python style with /bin/${PN}- and some
link magic, to select the "best" according to moon phases.
In the spirit of FHS, I thought about introducing /bin for some
time, but this continues with other dirs.
We would need /var/lib as well (/var/lib/munin/ has ABI specific
.rrd files),
/usr/include/ ... wait a minute.
What about separating these ABIs on top dir and keeping the respective
sub-trees clean, like //{,usr/}{bin,lib}?
// could be realised by one of these systems
- - chroot (just like / chroots), needs root.
- - Gentoo/PREFIX style
- - modified runtime linker to pic correct LD_LIBRARY_PATH.
These // can be anything, like different ABIs,
different libc implementations, different keyword (stable, testing),
different Distros, - as long as it runs with the current kernel.
Well, thin-provisioning, qemu, *random virtualization*.
One ABI, maybe the one that can run/chroot all others sould be defined
as qual="", just like non-multilib systems.
Replication of //{home,usr/portage} can be avoided by symlinks
or bind-mounts, or hardlinks.
(Srsly, /usr/portage/"ebuilds,profiles,metadata,caches" has to be in
/var/portage.)
It'd be a pretty good solution for restraining mentioned (malicious)
software, /skype/ for example.
Some roundups have to be made for exhausive $PATH, X11 .desktop files,
to enable starting other //
Comments?
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlEI20AACgkQknrdDGLu8JAGBAD+MPkmNxKSCrHcAnj5PUaxyTM1
Hhymj3cHaxBuTFHlK78A/2t5qJNyg1c0nc6FSePKXq+MXWp/RVDWMb5XCpfEh4dR
=xmPN
-END PGP SIGNATURE-
Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/30/2013 09:35 AM, Michael Weber wrote: > These // can be anything, like different ABIs, different libc > implementations, different keyword (stable, testing), different > Distros, - as long as it runs with the current kernel. Well, > thin-provisioning, qemu, *random virtualization*. Did I ever mention, you can boot into these //!?! initrd context: "mount root partition $ROOTDEV at $TARGET" mkdir /fun mount -o bind $TARGET/ /fun exec switch_root /fun /sbin/init Mount output get's confusing about multiple lines mentioning $ROOTDEV, esp. for init.d/fsck, but IMHO fsck should be done in initrd, and not single-user mode with read-only mount and with binaries from that broken partition. - - other story. Or have it on separate partition - like the traditional "I switch distros" aproach. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEI3zEACgkQknrdDGLu8JBrLgEAgI2m92etcKYF7/5wWEmJc1DZ 3apcjuDokN3WxUcxDdIA/A67DJBV5OKmVxX9wSaeomakg8Ql5oCqETXM6b9n1uy+ =Lkq3 -END PGP SIGNATURE-
Re: Multilib approach(es) Re: [gentoo-dev] The gx86 multilib project -- masterplan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/30/2013 10:58 AM, Michał Górny wrote:
> On Wed, 30 Jan 2013 09:35:12 +0100 Michael Weber
> wrote:
> We don't want 32-bit cp. Thomas likes to support every weird idea
> coming from a random user, I don't.
What is wrong with "random" or "user"? Should I take "random user"
personally? Honestly, I have no idea.
Where do you want to draw the line?
How would you handle library packages shipping binaries?
Just `rm "${D}"/usr/bin`?
>> In the spirit of FHS, I thought about introducing /bin for
>> some time, but this continues with other dirs.
>
>> What about separating these ABIs on top dir and keeping the
>> respective sub-trees clean, like //{,usr/}{bin,lib}?
> No. 32-bit chroot is an old idea and has nothing to do with
> multilib.
Right, that was the intent of my mail.
Not to question some multilib internal stupidity like how to handle
clashing pkg-config files but to question the approach in common.
Maybe FatELF would work with this multilib/USE approch w/o cluttering
the file system [1].
Multilib: funny clashes all over the tree, partial blessed by FHS.
Emul- packages, frozen, incapable of compiling and adding additional
stuff - collision avoidance by upstream.
Separated trees/chroots/... to be merged in $PATH et. al.
Is there any consent on how to proceed?
I support an slim solution, but as it turns out "architecture
independent" from FHS is just a lie. Or handled very badly.
[1] http://en.wikipedia.org/wiki/Fat_binary
> It's an alternative to multilib and there's no point in reinventing
> it.
Yeah, did not reinvent it, just want to re-think it's validity.
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlEJBGsACgkQknrdDGLu8JDMWAD+Ksp5FmqOKgHxuLtR/smWJCgU
SjnM/V64GFnGrCtSqdoA/32BHJdFrO/6YzUZTMhHp+o9u/QgAEjgbKRutdptqZwQ
=dSTv
-END PGP SIGNATURE-
[gentoo-dev] "frozen" overlay Re: Please stop useless removals
On 02/01/2013 09:21 AM, Alec Warner wrote: > On Thu, Jan 31, 2013 at 11:36 PM, Vaeth > wrote: >> >>>># Upstream is dead and gone. >>>># Masked for removal on 20130302 >>> >>> >>> Erm, so this is the _only_ reason - dead upstream? >> > If folks do not want to maintain it anymore, then it will be removed. > Feel free to contribute to Gentoo and maintain the packages. Hereby done, becoming a dev is a big step for just one package a user would keep. Ihmo, what you call "upstream dead" is a kind of positive situation. If the author has no longer time to contribute (we all have a real life) then it's ok, no need to wipe his contribution from the face of the world. If the software is just working as the author intendend, and it has no major bugs, then there's no need to do further trivial releases just to keep the disto maintainers busy. If it's broken, uncompatible and nobody steps up, drop it, agreed. >> You are destroying the charme of gentoo by systematically >> removing all these little tools and toys. The availability >> of a lot of software was once a strength of gentoo, so removing >> these things is really bad, especially if it happens for no >> real reason. We need to maintain a certain quality. Sheer mass does has no charm, if nothing works. But I'd rather like to see gentoo as a broad selection of tools, that build. maybe some really cool stuff nobody else has. > Gentoo is not a software archival service. >> I was understanding if e.g. someting was removed which needs >> the > a dead upstream. But just needing a small tool like imake (xboing) >> or having open feature requestes (epm) or even nothing and >> just dead upstream is IMHO really not a reason. >> >> If something really does not compile anymore and nobody cares, >> then remove keywords (or, for god's sake, mask it); >> if something might theoretically become a security issue (xpdf) >> then it should be masked. >> >> But please do not throw things out of the tree unless >> really necessary: >> >> It does not hurt anybody to have such package in the tree, >> but removing it - especially if upstream is dead - means >> that the tarbalös will be removed from the mirrors and thus >> nobody is able anymore to install it (even if he would care and >> fix some minor issues) unless he had kept a copy on >> his local machine (which will mean in the future that he can only >> do it if he had used gentoo already many years ago and cared >> during the time of the removal). > > Again I highly recommend archiving the software yourself; but I don't > think Gentoo should be doing it. It costs resources: - distfiles and all their mirrors accumulate - emerge dependency calculation If it's out-waged by increasing disc capacity and processor power is up to discussion. Last but not least, we have gattered some extra info besides the tarballs, our precious ebuild scripts. Which is why I started my involvement with Gentoo (maybe somebody should have told me about BSDs tree before that). As Martin said, tarballs get lost. I steal them from debian mirror on a regular basis, maybe we should contribute ourselves. PROPOSAL Let's create an overlay "frozen stuff" which contains all the software no longer developed with following features: Users showed interest in having them Web-presence to be picked up on Google search. (viewvc.cgi show dead is kinda hidden [1]) Separate distfile mirror no need to stress our mirror peers make it a sepearate repo, feed by upstream and mirror://gentoo I can contribute the space/bandwith. Feedback/Bugs/Voting can be handled inside b.g.o no need for extra login, frozen-bugs can be auto-generated, whitelist [frozen] just like the sunrise tracker bugs. BENEFIT User can choose whether or not layman -a frozen. Non-trivial ebuilds are preserved. Tarballs are preserved. Nobody gets hurt. Comments? [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] "frozen" overlay Re: Please stop useless removals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/01/2013 10:35 AM, Dennis Lan (dlan) wrote:> HI Michael:
> I can think of it's almost kind of a staging area, some package
> may be partial broken(or partial functional), but still useful for
> user.
Please see [1] for the proposal of betagarden overlay, which might
grab attention by posting a project page, @sping *plz*
> Generally speaking, It should be a good idea! The end users will
> benefit a lot.
thanks.
On 02/01/2013 10:30 AM, Sergey Popov wrote:
> Well, we can move such software to sunrise, can't we? But
> proposition of splitted mirrors makes sense, cause quite often dead
> upstream means dead links to original tarballs too.
Maybe betagarden/sunrise would benefit from mirror-coverage,
hosting situation is a recurring question on #-sunrise. Votes?
Sunrise commit access is limited to sunrise devs. And I see the _rise_
in context of software and devs.
I don't say sundown, cause for mentioned arguments, I just wanna have
functioning/maybe superseeded software around, regardless of it's
commit-frequency, author involvement or century of creation.
Again: We need to proceed as a contemporary distribution ("Does not
build with latest ~** gcc/" argument), but we can preserve our trail
for those who like.
The line between removed packages and obsoleted slots has to be drawn.
I'm in a tension between overlay scatter and providing an automated
time capsule (that certainly will mess up any of the aforementioned
repos).
[1]
http://archives.gentoo.org/gentoo-dev/msg_384ad55a02bf02154397f29d10a0f68e.xml
- --
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREIAAYFAlELnq4ACgkQknrdDGLu8JAY3gD/TOifKZZNqVb6VJkfp/VLGaGT
MZzWVOYVsPPAQi0B+voA/3D8afTh5TjxeWJvAKIZwIG6O/rwVrVBAI4YHgC4T59x
=bnDb
-END PGP SIGNATURE-
Re: readme.gentoo.eclass: use echo -e instead of plain echo (Was: Re: [gentoo-dev] readme.gentoo.eclass: Add a DISABLE_AUTOFORMATTING variable=
On 02/01/2013 10:55 AM, Ben de Groot wrote: > On 1 February 2013 02:59, Pacho Ramos wrote: >> El dom, 27-01-2013 a las 18:47 +0100, Pacho Ramos escribió: >>> El dom, 27-01-2013 a las 15:00 +0100, Pacho Ramos escribió: >>>> Currently, when people uses DOC_CONTENTS variable to place their desired >>>> messages, they are automatically reformatted by "fmt" to get proper >>>> messages (for example, splitting long lines). >>>> >>>> But, in some cases, may be useful to disable this behavior and respect >>>> strictly how DOC_CONTENTS was formatted, for example in that kind of >>>> messages telling people to run a command and, then, requiring a new line >>>> to be used. This can also be useful to append extra information to >>>> DOC_CONTENTS when, for example, additional info is needed when enabling >>>> a USE flag. >>>> >>>> >>> >>> Well, after reading man echo I see all this is not needed, I simply need >>> to use echo -e to get it understand "\n" to create new lines >>> >>> New patch attached >> >> This will add an option to disabling autoformatting to let people get >> their doc_contents 100% respected if they want > > How about using an "as-is" argument to readme.gentoo_create_doc? > That would be more concise. :-) > PLEASE, add "define DOC_CONTENTS in an non-global scope, use src_prepare/pkg_setup instead" to the eclass documentation of readme.gentoo_print_elog, Thanks ++ for the eclass, the README.gentoo might submerge into the users handling of Gentoo Systems. (I always laughed about README.Debian) [1] show an report about exactly the non-atomar situation of elog and application usage. While [2] complained about elog cluttering, I try to migrate x11-wm/xpra-0.8.0 (upcoming), am I doing it right? DOC_CONTENTS=""" please make your Xorg binary readable for users of xpra chmod a+r /usr/bin/Xorg and think about the security impact A copy at ~/.xpra/Xorg matching the current modules is sufficient. """ ^^ clearly would benefit from non-formatting. repoman full complains about "Ebuild contains leading spaces on line". [1] https://bugs.gentoo.org/show_bug.cgi?id=448588 [2] https://bugs.gentoo.org/show_bug.cgi?id=440464 -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: Please stop useless removals
On 02/01/2013 12:20 PM, Diego Elio Pettenò wrote: > On 01/02/2013 12:11, Rich Freeman wrote: >> I do think it is a loss for Gentoo if we start removing packages >> simply because they don't change (which is all a dead upstream means - >> it isn't always a bad thing). > > The problem is that a package that doesn't change _will_ bitrot. Full stop. > > Trying to pretend that the problem does not exist, that an unmaintained > package is just as fine as a maintained one is stupid and shortsighted, > and explains why I have 1600 bugs open... Making up new situations up like cross-dev, Gentoo/Prefix, or jet another cluttered C compiler should not doom working software. I agree on your testing effort and practice, but compliance with the weirdest of all setups shouldn't be ultimate reason. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: Please stop useless removals
On 02/01/2013 01:22 PM, Diego Elio Pettenò wrote:
> On 01/02/2013 13:07, Michael Weber wrote:
>> Making up new situations up like cross-dev, Gentoo/Prefix, or jet
>> another cluttered C compiler should not doom working software.
>
> Which would be all fine and dandy
>
>> I agree on your testing effort and practice, but compliance with the
>> weirdest of all setups shouldn't be ultimate reason.
>
> ... if you had a clue on what you were saying.
>
> The tinderbox _by design_ is not testing "weirdest of all setups", it's
> testing baseline.
Yeah, but test for /usr/share/doc/${PF} (random to irrelevant),
$CFLAGS/$LDFLAGS/$AR (enable these miraculous setup), automake-1.12 (at
what point in future do you see that as oldest in-tree) last are no
statement regarding a packages functionality on a plain system.
>And if nobody's interested in getting (example)
> media-video/w3cam working (#247917 — last activity on the bug by me on
> 2010; last activity by someone else in 2008!), I don't see why it should
> be kept in tree.
*insert random example here*
I did not argue to keep these in tree, or to label them a+++.
Martin and I did not argue that there are no circumstances an software
should be left alone. We both said, that not working with qt3/... may be
a strong argument.
> Bloody hell, I wonder how many people complaining about removing
> packages are actually using said packages, rather that complaining on
> principles!
Keep on the ground.
I rather prefer a combined discussion on "principles" or workflow, than
bringing up this discussion for every single package.
This is a general Gentoo list, so the mails might get some kind of
"general".
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: [gentoo-dev] Packages up for grabs due lack of time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2013 12:44 PM, Pacho Ramos wrote: > Due tester lack of time the following packages are up for grabs: > app-admin/tmpreaper mine. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEPV7kACgkQknrdDGLu8JDNzAD/b2/0fwNsD9pJnr82PPHUp1E8 0wq/ELBJMIk5gssxlRcA/ivb2vdEwFzjo1ptXmBAe+P9D7NC5RsO8AVfax0xd0hD =kJ6I -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs due lack of time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2013 09:56 PM, Tim Harder wrote: > On 2013-02-03 Sun 04:46, Pacho Ramos wrote: >> net-dns/ldns-utils net-dns/unbound net-libs/ldns > > I'll help maintain these. > > Tim @Tim: you can add me there, too. Michael - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEPk1oACgkQknrdDGLu8JDGnwD/V3iu0OSElPK83CWl3I38SHZZ j4HbkuGOTlcss9SNDz4A/0KFwP6Se5hi7NOuEeShFKPCVtZyxxkozLDVmC+jpFcS =OQ9n -END PGP SIGNATURE-
Re: [gentoo-dev] meaning of EROOT
On 02/03/2013 12:07 PM, heroxbd wrote:
> self.eroot = self.target_root.rstrip(os.sep) + self.eprefix + os.sep
wouldn't be this more robust
>>> import os
>>> os.path.normpath('/some/' + os.path.sep + '/stuff/') + os.path.sep
'/some/stuff/'
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: [gentoo-dev] Removals reply
On 02/03/2013 07:07 AM, Alexandre Rostovtsev wrote: > We the Gentoo developers strongly believe that this project is not fun > and not important. veto. a) there is no "we", b) there are conrary posts on this list. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Packages up for grabs due lack of time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2013 02:27 PM, Pacho Ramos wrote: > Due leio lack of time the following packages are up for grabs: > app-benchmarks/gtkperf mine. just fixed https://bugs.gentoo.org/show_bug.cgi?id=428652 - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlERl/gACgkQknrdDGLu8JBGQwEAjU+yc8/aNFKMdOYUTbJZcvyj DoCW+OEAD3RnA4bqWUUA/jXEg/lz9FoWR7UjggZIukGjTRK3POqlVs0IZfj4nJ3U =eFSz -END PGP SIGNATURE-
Re: [gentoo-dev] SRC
On 02/09/2013 12:26 AM, Alec Warner wrote: > On Fri, Feb 8, 2013 at 3:18 PM, Stefan Ehret wrote: >> >> * * >> * PLEACE SAFE THE SOURCE * >> * * >> >> >> > > Annnd banned. > > -A > at __second__ incident, slacker! ;-) -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Gentoo email address in VCS. Re: [gentoo-dev] Last rites: dev-ruby/rails:3.0
On 02/11/2013 09:39 PM, Hans de Graaff wrote: > # Hans de Graaff (11 Feb 2013) What about using your gentoo email address? One mapping less, please. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2013 10:14 PM, William Hubbs wrote: > as preparation for the up-coming cvs->git migration of the portage > tree, the council is strongly suggesting that from this point > forward all developers sign their manifests with their gpg key as > described in the developer's manual [1]. ++ We should all put these data into LDAP, too. on dev.gentoo.org .. perl_ldap -b user -M gpgkey perl_ldap -b user -M gpgfingerprint At least have some lose binding between tree signing keys and dev identities. Or put the whole public key into the ldap. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEax6cACgkQknrdDGLu8JAHmgD/fMVoUUO5g7iYeFobMy6rWBW8 mVIAoCe2BWZ6XOfPEvEBAI1Ny0ruWaRjI+HEStU3omgNVPUddeLoKJMyK5r0pJiX =37sv -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: install linux-firmware with kernel sources (was Re: Lastrite: Firmware cleanup, part #1)
On 02/12/2013 09:43 PM, Duncan wrote: > Christopher Head posted on Tue, 12 Feb 2013 11:39:57 -0800 as excerpted: > >> On Sun, 10 Feb 2013 14:49:03 -0800 Alec Warner >> wrote: >> >>> Most external firmware is not needed to boot. If you need it to boot, >>> you will have to stow it in the initramfs. or the kernel itself ... >> >> For those of us who prefer monolithic kernels, virtually all firmware is >> needed to boot. Even if a network interface doesn't need to be >> operational for boot, the kernel insists that the firmware be available >> right at boot or else it will fail and the interface will never appear. > > I'm a monolithic kernel guy myself, and I simply build-in the firmware I > need (three radeon firmware files, IIRC, used to be tg3 as well until > that mobo died). dito. > And FWIW, I didn't really know about linux-firmware either, but google > knew when I asked it about the files the kernel errors spit out. =:^) > And I didn't actually install it, either. I simply grabbed the tarball > and extracted the files I needed, placing them where the kernel could > find them. from cross distro source etc. I wonder how that linux-firmware serves it all will handle different versions of one firmware-filename with disjunct sets of supported hardware revisions. Random files in /lib/firmware out of packet manager space it is (form me). -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2013 10:14 PM, William Hubbs wrote: > If you have any questions on this, please feel free to let us > know. What is the rotation strategy for (near) outdated keys? Alter the key or create a new one? Sign the new with the old one? IMHO the answer to these questions is not obvious nor given by (our) docu [1]. Maybe, add "keep ldap id/fingerprint synchronized" there, too. > [1] > http://devmanual.gentoo.org/general-concepts/manifest/index.html - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEazGMACgkQknrdDGLu8JBXygD8CalxwI4y7kxbqYwyXcyohtbW 7xICGdFgIDA8jH7v4poA/RrtQTxwmmzE4g53Eyg8RBKxEIa0BmAZUaAMIyM9ntdq =XOfU -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 02/13/2013 12:28 AM, Robin H. Johnson wrote: > On Wed, Feb 13, 2013 at 12:12:35AM +0100, Michael Weber wrote: >> On 02/12/2013 10:14 PM, William Hubbs wrote: >>> If you have any questions on this, please feel free to let us >>> know. >> What is the rotation strategy for (near) outdated keys? >> Alter the key or create a new one? Sign the new with the old one? > If your keysize is still good, you should ideally update the expiry on > the key and re-upload it to keyservers. Can you commit this to the document, please? >> IMHO the answer to these questions is not obvious nor given by (our) >> docu [1]. > I'm pretty sure it was in the devrel developer handbook at one point, > along with instructions to create your key, but I can't find it now. > >> Maybe, add "keep ldap id/fingerprint synchronized" there, too. > http://www.gentoo.org/proj/en/infrastructure/ldap.xml#doc_chap3 That does tell how to update the data, but does not suggest to do so. My main concern is the cross-referencing of our documentation. I'm aware that there is a ton of documentation splattered all over the place and outside our infra. But besides the "non-trivial" step to become a dev (as mentioned last week) there is a certain non-trivial step to keep one, esp. by gathering the non-routine informations and fast-forward developments. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 02/13/2013 11:55 AM, Markos Chandras wrote: > http://www.gentoo.org/doc/en/gnupg-user.xml > still no hint what to do on expiration (as every single other "gpg howto"). -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/13/2013 06:22 PM, Aaron W. Swenson wrote: > There's nothing Gentoo specific about it. I don't see why we would > need to officially document an official document. The most we > should do is point people to the resource. So, please link to this page and drop out fractional/incomplete version. > [1] http://www.gnupg.org/gph/en/manual.html#AEN329 > - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlEb62sACgkQknrdDGLu8JAZeQD+M8+z4/LicZnWLOf+mwXcqFEM qwuAFjeV5XN+KoDehn8A/1IE9ane4mN5dTFSPRgArTghBUgJ1hXhfIcDdCcukB0N =24Uj -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 02/13/2013 09:07 PM, Agostino Sarubbo wrote: > As most of us do, I do the commit from another machine, not mine. So, for ssh > I'm using ssh -A to forward the key and I'm interested to find a way to do it > for the gpg key. > > I found an how-to that uses socat ( http://superuser.com/questions/161973/how- > can-i-forward-a-gpg-key-via-ssh-agent ) but does not work as expected. GPG agents do not transport keys, just passphrases. I once used a patch against openssh to enable forwarding of domain sockets, it applies to current 6.1_p1. http://www.25thandclement.com/~william/projects/streamlocal.html Maybe we should add this to our openssh version, I'd appreciate it. > This is an example: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo- > x86/app-portage/splat/Manifest?revision=1.45&view=markup > > The manifest apparently is signed, but there is no really gpg sign. look closely to the output of repoman commit, there is a small "gpg failed" or somethink like that. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 02/13/2013 09:23 PM, Peter Stuge wrote: > Rather than creating a TCP socket I would look into using the ssh -W > option. gpg agent works with unix domain sockets. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On 02/13/2013 09:30 PM, Michael Weber wrote: > GPG agents do not transport keys, just passphrases. To stress that, my passphrased key resides on my remote build-box, gpg just askes my local gpg agent for the passphrase. ssh -R /root/.gnupg/S.gpg-agent:/tmp/keyring-michael/gpg b-4 with a persistent location of the unix socket assured by https://xmw.de/dotfiles/bin/new-keyring -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
U folks are aware of the fact that installed sources is rather vaguely coupled with running kernel, right? No, I'm not running archkernel on gentoo, but it would be possible. It's also fine to poke around in linus' sources and cross compile w/o ever running the damn thing or needing firmware from /lib/firmware. Anyway, please do not force-reinstall of about 400k kernel source files to just fix any USE flag constellation. I'm not saying --newuse, just people forgetting to set the flag. Last thought, we have maintainer-needed in bugzilla to handle unmaintained packages (and I'm looking at these from time to time, maybe I should start a maintainer-needed herd). /$(get_libdir) vs /lib is the wrong method without effect, non-multilib/x86 installs to /lib, multilib is linked to /lib. So please, stop using dramatizing this and use it as alibi for your otherwise justified plans. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: Graveyard overlay (was: Re: [gentoo-dev] last rites: games-strategy/x2, games-strategy/x2-demo)
On 02/14/2013 06:09 AM, Ben de Groot wrote: > I need two things: > > 1. Users volunteering some time to keep this running > 2. Agreement on a place to host tarballs no longer hosted upstream i'm all in. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] Fwd: [gentoo-commits] gentoo-x86 commit in x11-terms/st: st-0.4.ebuild ChangeLog st-0.3.ebuild
@ago: Why did you remove the 0.3 version of the ebuild? The bug requested keywording, so, just add ~x86 to the latest version. Was there an problem with version 0.3? Non-maintainer commits should have good explanations, and the resons for removing version 0.3 is not documented in your commit/echangelog message. Be verbose. Original Message Subject: [gentoo-commits] gentoo-x86 commit in x11-terms/st: st-0.4.ebuild ChangeLog st-0.3.ebuild Date: Tue, 2 Apr 2013 23:33:56 + (UTC) From: Agostino Sarubbo (ago) Reply-To: gentoo-dev@lists.gentoo.org, a...@gentoo.org To: gentoo-comm...@lists.gentoo.org ago 13/04/02 23:33:56 Modified: st-0.4.ebuild ChangeLog Removed: st-0.3.ebuild Log: Add ~x86, remove old, wrt to bug #464252 (Portage version: 2.1.11.55/cvs/Linux ppc64, signed Manifest commit with key 7194459F) Revision ChangesPath 1.2 x11-terms/st/st-0.4.ebuild file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-terms/st/st-0.4.ebuild?rev=1.2&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-terms/st/st-0.4.ebuild?rev=1.2&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-terms/st/st-0.4.ebuild?r1=1.1&r2=1.2 Index: st-0.4.ebuild === RCS file: /var/cvsroot/gentoo-x86/x11-terms/st/st-0.4.ebuild,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- st-0.4.ebuild 2 Apr 2013 07:11:39 - 1.1 +++ st-0.4.ebuild 2 Apr 2013 23:33:56 - 1.2 @@ -1,6 +1,6 @@ # Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/x11-terms/st/st-0.4.ebuild,v 1.1 2013/04/02 07:11:39 xmw Exp $ +# $Header: /var/cvsroot/gentoo-x86/x11-terms/st/st-0.4.ebuild,v 1.2 2013/04/02 23:33:56 ago Exp $ EAPI=5 @@ -12,7 +12,7 @@ LICENSE="BSD" SLOT="0" -KEYWORDS="~amd64" +KEYWORDS="~amd64 ~x86" IUSE="savedconfig" RDEPEND="media-libs/fontconfig 1.14 x11-terms/st/ChangeLog file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-terms/st/ChangeLog?rev=1.14&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-terms/st/ChangeLog?rev=1.14&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-terms/st/ChangeLog?r1=1.13&r2=1.14 Index: ChangeLog === RCS file: /var/cvsroot/gentoo-x86/x11-terms/st/ChangeLog,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- ChangeLog 2 Apr 2013 07:11:39 - 1.13 +++ ChangeLog 2 Apr 2013 23:33:56 - 1.14 @@ -1,6 +1,9 @@ # ChangeLog for x11-terms/st # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/x11-terms/st/ChangeLog,v 1.13 2013/04/02 07:11:39 xmw Exp $ +# $Header: /var/cvsroot/gentoo-x86/x11-terms/st/ChangeLog,v 1.14 2013/04/02 23:33:56 ago Exp $ + + 02 Apr 2013; Agostino Sarubbo -st-0.3.ebuild, st-0.4.ebuild: + Add ~x86, remove old, wrt to bug #464252 *st-0.4 (02 Apr 2013) -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Pass "${@}" in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
Hi,
I'm not sure if it's a sane way to push make -j1 via
src_compile() {
cmake-multilib_src_compile -j1
}
but I detected a lack of functionality in the current
cmake-multilib.eclass. Both cmake-utils.eclass and multilib-build.eclass
have it, so it might be sound to continue with this behavior.
Comments, pls.
Michael
Index: cmake-multilib.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/cmake-multilib.eclass,v
retrieving revision 1.1
diff -u -B -r1.1 cmake-multilib.eclass
--- cmake-multilib.eclass 10 Feb 2013 11:44:55 - 1.1
+++ cmake-multilib.eclass 13 Apr 2013 00:58:17 -
@@ -33,24 +33,24 @@
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
cmake-multilib_src_configure() {
- multilib_parallel_foreach_abi cmake-utils_src_configure
+ multilib_parallel_foreach_abi cmake-utils_src_configure "${@}"
}
cmake-multilib_src_compile() {
- multilib_foreach_abi cmake-utils_src_compile
+ multilib_foreach_abi cmake-utils_src_compile "${@}"
}
cmake-multilib_src_test() {
- multilib_foreach_abi cmake-utils_src_test
+ multilib_foreach_abi cmake-utils_src_test "${@}"
}
cmake-multilib_src_install() {
cmake-multilib_secure_install() {
- cmake-utils_src_install
+ cmake-utils_src_install "${@}"
# Make sure all headers are the same for each ABI.
multilib_check_headers
}
- multilib_foreach_abi cmake-multilib_secure_install
+ multilib_foreach_abi cmake-multilib_secure_install "${@}"
}
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: Pass "${@}" in phase functions Re: [gentoo-dev] [PATCH] Introduce cmake-multilib wrapper for cmake-utils.
On 04/13/2013 05:50 PM, Michał Górny wrote:
> That's my mistake most likely. Please commit the patch.
done.
+ 13 Apr 2013; Michael Weber cmake-multilib.eclass:
+ Pass ${@} in phase functions. Approved by author on dev-ml.
+
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: [gentoo-dev] Should mirror restriction imply bindist restriction?
On 04/26/2013 09:23 PM, Ulrich Mueller wrote: >>>>>> On Fri, 26 Apr 2013, Mike Frysinger wrote: > >>> Currently RESTRICT=mirror and RESTRICT=bindist are independent of >>> each other. I wonder if the former should imply the latter. >>> >>> Is there any package where the files in SRC_URI cannot be mirrored >>> (i.e., redistributed), but where the built package can be >>> distributed? > >> i've used RESTRICT=mirror in the past when the files were really >> large (like games or toolchain source tarballs) and upstream already >> had a good mirroring system. in both cases, there was no binary >> redistribution restrictions. > >> so my answer would be no: we have two independent knobs and let's >> keep them that way. > > Right. And as was pointed to me on IRC, another legitimate case for > mirror restriction are packages in overlays whose distfiles are not on > mirrors. Then it obviously makes no sense to check mirrors for it. And sunrise suggested to not set it, to make the move into main tree less error prone. I think, all the legal terms "no mirror" and "no branded redistribution" are clear, but portage might get problems to check/recognise "within a legal entity". DNS zones, netblocks and so on are all optional and do not necessarily represent these boundaries. trusted computing platform ... please no. GPG keys sets with encrypted tarballs would raise the awareness, all of them bypass-able In the end, legally speaking, it's the user pushing buttons and portage is no licensed lawyer. Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2013 08:29 PM, Tom Wijsman wrote: > We have `iamlate` for this in app-portage/gentoolkit-dev. /usr/bin/imlate , nice ;-) - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlGlyLAACgkQknrdDGLu8JDJ3QEAhYrgzLHT5NCINaXBVYCNs1PH 12+nHNMy9V+6BQ4EMi8A/RLvadt7RndQPk8m5BuDlzRuwaO05WNVfkArMOxovd1v =7eoE -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote: > It's just not going to happen as long as I got CVS access, it's not a?T > threat or a grandstanding, it's a simple boolean logic statement. Step away then. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote: > On 15/06/2013 22:15, Michael Weber wrote: >>>> It's just not going to happen as long as I got CVS access, it's not a?T >>>> threat or a grandstanding, it's a simple boolean logic statement. >> Step away then. > > You know what? I really should just leave and see how people who think > that a live ebild is a nice idea will ruin it. It's not like I depend on > Gentoo for my work anymore. Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/2013 05:12 PM, Rick "Zero_Chaos" Farina wrote: > There is currently no need for improvement in my eyes, and I'm not > sure this could be considered improvement anyway. i.e. git-2.eclass provides support for environment override (and variables) for branches, commits and repos, for example EGIT_REPO_URI= Hard to cover/encode this functionality in your proposed urls. These look - by the way - a lot like the "new" packer-4.something git url in Archlinux/AUR. "our" VCS eclasses should still be superior in functionality. ++ for global RESTRICT="fetch|mirror" with overrides in both ways on per url basis as prefix to the protocol, like nomirror+http:// and fetch+git:// . But this needs tivial (?) adaption in every VCS eclass. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlG83TcACgkQknrdDGLu8JAq/wEAmUQkeQaLY8FVGZpO9YNShR43 DQ4hrgT1TNSnUQcwzZQBAImK9nurCVcUn4LJSBD0mtCQah2VVo1VfTUzeoMJs1Tt =B9vk -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 11:24 PM, Markos Chandras wrote: > Please both of you. Stop it now and take it elsewhere. Consider this a > friendly warning. Agreed. Sorry for my impulsive response. I don't say thanks for the warning, but for your counseling of the mailing list. I'm on a borderline between advocation against "abusive" or "destructive" behavior leeding to the last two retirements and just leaving these people. I hate the overlay/fork symptomatic, and I have put a lot of effort into making Gentoo into my personal understanding of Linux, but i'm considering stepping down to a overlay basis and avoid all the bitching and alpha-male stupidity. Bye, Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
[gentoo-dev] netsurf.eclass proposal
Hello,
I'd like to add a new eclass for www-client/netsurf related ebuilds and
seek your review and approval. I'll add it in two days, if unchallenged.
=== Motivation ===
The browser projects started out as a stray set of components [1], some
without releases.
In the meantime, all stuff is presented on one web-git [2] and
download page [3]. The browser components is available as bundled tar
[4] and solo [5].
[1] http://www.netsurf-browser.org/projects/
[2] http://git.netsurf-browser.org/
[3] http://download.netsurf-browser.org/libs/releases/
[4] http://download.netsurf-browser.org/netsurf/releases/source/
[5] http://download.netsurf-browser.org/netsurf/releases/source-full/
Handling this the "Gentoo way" I added all components as single
packages. All relying on the same - separate - buildsystem tarball.
The presented eclass is intended to master this buildsystem for
- binary components (www-client/netsurf, dev-libs/nsgenbind)
- shared and static library components
- multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
- verbose building
- repecting FLAGS, warn about stray -O? and -g flags in components.
and reduce code duplication within the ebuilds.
=== Eclass consumers (flattened DEPENDS tree) ===
dev-libs/libwapcaplet-0.2.0
dev-libs/libparserutils-0.1.2
dev-libs/libcss-0.2.0
net-libs/libhubbub-0.2.0
net-libs/libdom-0.0.1
dev-libs/libnsfb-0.1.0
dev-libs/nsgenbind-0.0.1
media-libs/libnsbmp-0.1.0
media-libs/libnsgif-0.1.0
media-libs/librosprite-0.1.0
media-libs/libsvgtiny-0.1.0
www-client/netsurf-3.0
=== Implementation ===
see attachment
[future] add live git multiple repo fetch voodoo.
=== Concerns ===
This eclass relies on multilib-minimal and the "inherit" tree
netsurf -> multilib-minimal -> multilib-build -> multibuild might be a
little fragile.
Only 12 consuming packages. No other rdeps, yet, so the whole set could
have been done in one ebuild.
*My first eclass* so there might be issues with bash array quoting.
Are the DEPEND and IUSE inside the eclass added to the ebuilds?
It looks ok, but I'd better ask.
Any good way to disable the CFLAGS sanity check on
(dev-libs/nsgenbind should be relocated to dev-utils)
( www-client/netsurf[abi_x86_32] on amd64 misses working curl version. )
=== TL;DR ===
see attachment for the real thing.
Constructive feedback is very welcome.
Thanks
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
=== eclass/netsurf.eclass ===
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: netsurf.eclass
# @MAINTAINER:
# Michael Weber
# @BLURB: Handle buildsystem of www.netsurf-browser.org components
# @DESCRIPTION:
# Handle unpacking and usage of separate buildsystem tarball and manage
# multilib build, static-libs generation and debug building.
#
# Supports PATCHES and DOCS as in base.eclass
case ${EAPI:-0} in
0|1|2|3|4) die "this eclass doesn't support EAPI<5" ;;
*) ;;
esac
inherit base toolchain-funcs multilib-minimal
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install
LICENSE="MIT-with-advertising"
# @ECLASS-VARIABLE: NETSURF_BUILDSYSTEM
# @DESCRIPTION:
# Select version of buildsystem tarball to be used along the component
# defaults to buildsystem-1.0
NETSURF_BUILDSYSTEM="${NETSURF_BUILDSYSTEM:-buildsystem-1.0}"
# @ECLASS-VARIABLE: NETSURF_BUILDSYSTEM_SRC_URI
# @DESCRIPTION:
# Download link for NETSURF_BUILDSYSTEM, add to SRC_URI iff set explicitly.
NETSURF_BUILDSYSTEM_SRC_URI="http://download.netsurf-browser.org/libs/releases/${NETSURF_BUILDSYSTEM}.tar.gz
-> netsurf-${NETSURF_BUILDSYSTEM}.tar.gz"
# @ECLASS-VARIABLE: NETSURF_COMPONENT_TYPE
# @DESCRIPTION:
# Passed to buildsystem as COMPONENT_TYPE, valid values are
# lib-shared, lib-static and binary. Defaults to "lib-static lib-shared"
NETSURF_COMPONENT_TYPE="${NETSURF_COMPONENT_TYPE:-lib-static lib-shared}"
# @ECLASS-VARIABLE: SRC_URI
# @DESCRIPTION:
# Defaults to http://download.netsurf-browser.org/libs/releases/${P}-src.tar.gz
# and NETSURF_BUILDSYSTEM_SRC_URI.
if [ -z "${SRC_URI}" ] ; then
SRC_URI="http://download.netsurf-browser.org/libs/releases/${P}-src.tar.gz
${NETSURF_BUILDSYSTEM_SRC_URI}"
fi
IUSE="debug"
if has lib-static ${NETSURF_COMPONENT_TYPE} ; then
IUSE+=" static-libs"
fi
DEPEND="virtual/pkgconfig"
# @FUNCTION: netsurf_src_prepare
# @DESCRIPTION:
# Run base_src_prepare for PATCHES support and multilib_copy_sources for
# in-source build.
netsurf_src_prepare() {
base_src_prepare
multilib_copy_sources
}
# @ECLASS-VARIABLE: netsurf_makeconf
# @DESCRIPTION:
# Configuration variable bash array to be passed to emake calls.
# Defined at netsurf_src_configure and can be altered afterwards.
# @FUNCTION: netsurf_src_configure
Re: [gentoo-dev] netsurf.eclass proposal
On 06/19/2013 02:16 PM, Michał Górny wrote:
> Dnia 2013-06-19, o godz. 14:09:26
> Michael Weber napisał(a):
>
>> - multilib builds and rename non-DEFAULT_ABI $bins to $bin.${ABI}
>
> And why exactly do you need multilib for a web browser?
>
No need for the browser package (just fun) but I'd like to provide it
for the ten library packages.
--
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber
Re: [gentoo-dev] repoman commit unexpectedly drops FEATURES="sign" on error
On 06/20/2013 05:27 AM, Zac Medico wrote: > On 06/19/2013 08:25 PM, Zac Medico wrote: >> On 06/19/2013 07:59 PM, "Paweł Hajdan, Jr." wrote: >>> I was surprised by repoman just dropping FEATURES="sign" . I'm aware >>> that at that time it has to commit an updated Manifest to prevent >>> breakages, so if gpg fails it proceeds, but is there something it could >>> do to check gpg sanity before committing anything? Failing at the password prompt (two chances on regular pinentry) also results in this behaviour. >> It seems the simplest way to go would be to do a test signature before >> commit, as suggested here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=298605 >> >> Is it okay to assume that everyone uses gpg-agent, so they won't have to >> enter the passphrase more than once? I have a remote (ssh) test-box to work on the tree, I don't want to cache my decrypted key there. Having the crypted version there is bad enough, but GPG_AGENT protocol only exchanges passwords (unlike SSH_AGENT). GPG_AGENT forwarding over SSH can be done with a general unix domain socket forwading hack [1]. > Or, we could skip the test signature if the GPG_AGENT_INFO variable is > not set? It's a clue, but the key-cache can be expired and a bad password entry can still result in failure. [1] http://25thandclement.com/~william/projects/streamlocal.html -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber
