[gentoo-dev] Help offered - Portage tree
Hi all, I'm sure I'll find some sabayon-hater here, but my purpose won't be answering to them. I offer my help to fix DEPEND/RDEPEND split issues which is causing me a lot of headaches (along with localizations). For reference, please have a look here: http://planet.sabayonlinux.org/?p=105 After having discussed with one of your dev about it, he suggested me to ask here looking for a mentor. If there's anything I can do, I'm ready. Despite some of you might think, I love Gentoo since 2001 :) Cheers -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Hi Jan, I'm registered with lxnay lxnaydesign net. I know what you mean, but take into account I don't have much time left for the reporting. What I ask is either build a communication channel or getting me able to fix stuff, obviously after having contacted the respective maintainers and talked about the issue. Well, I am saying this utopic thing just because I don't even have time to track down all the issues I found and then report, most of the time I end up copying the ebuild from the tree into our overlay and fix. I tried to report a few bugs, but the response time is quite big and I always have to be quick. So, to sum up, if we can build a better communication way it could be useful for both sides. On 3/13/08, Jan Kundrát <[EMAIL PROTECTED]> wrote: > Fabio Erculiani wrote: > > I offer my help to fix DEPEND/RDEPEND split issues which is causing me > > a lot of headaches (along with localizations). > > For reference, please have a look here: > http://planet.sabayonlinux.org/?p=105 > > > "The name [EMAIL PROTECTED] is not a valid username. Either you > misspelled it, or the person has not registered for a Bugzilla > account.", that's all what our bugzilla knows about you. > > Either you're using a different e-mail address there or you really > haven't reported a single bug to us in that seven years. > > It would help if you file bugs against respective packages or provide a > list of examples mentioning what exactly needs fixing. You can't > reasonably expect us to act based on a post in $random_blog. > > With love, > -jkt > > > -- > cd /local/pub && more beer > /dev/mouth > > > -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
media-libs/x264-svn -> dev-lang/yasm dev-libs/lzo -> dev-lang/nasm sys-apps/attr -> sys-devel/autoconf x11-libs/qt:3 (I reported it a while ago and it got fixed, it was a real mess) net-dialup/capisuite -> sys-devel/autoconf dev-libs/xmlsec -> sys-devel/autoconf x11-misc/fluxbg -> sys-devel/autoconf media-video/effectv -> dev-lang/nasm net-voip/linphone -> dev-lang/nasm media-sound/gogo -> dev-lang/nasm sys-boot/lilo -> sys-devel/bin86 app-text/iso-codes -> sys-devel/automake These depend on sys-devel/bison, are they correct? app-office/mdbtools-0.6_pre1-r1 www-servers/boa-0.94.14_rc21 media-video/sswf-1.8.0-r1 net-firewall/itval-1.0 app-office/openoffice-2.3.1-r1 sci-geosciences/grass-6.0.1 sci-geosciences/grass-6.2.1 media-gfx/gliv-1.9.6 These depend on sys-devel/make sci-geosciences/grass-6.0.1 sci-geosciences/grass-6.2.1 These depend on sys-devel/gcc (remember, only RDEPENDs here) app-text/pdftk-1.41 net-irc/inspircd-1.1.14 app-benchmarks/piozone-1.0-r2 sci-chemistry/xdrawchem-1.9.9 sci-geosciences/grass-6.0.1 dev-lang/mono-1.2.6-r1 sci-geosciences/grass-6.2.1 www-apache/anyterm-1.1.16 dev-lang/ghc-6.8.2 sci-libs/hdf5-1.6.6 x11-proto/xineramaproto: gnome-extra/gnome-screensaver-2.18.2-r1 media-video/ogle-0.9.2-r1 sabayon server # python reagent database query depends --quiet x11-proto/printproto x11-libs/libXp-1.0.0 app-editors/nvu-1.0-r4 x11-libs/openmotif-2.3.0 x11-libs/openmotif-2.2.3-r9 sabayon server # python reagent database query depends --quiet x11-proto/xproto x11-libs/libXevie-1.0.2 x11-libs/libXdmcp-1.0.2 x11-plugins/asclock-2.0.12-r1 dev-libs/libstroke-0.5.1 sys-devel/gcc-3.4.6-r2 x11-libs/libXv-1.0.3 sys-devel/gcc-4.2.2 x11-libs/libXcomposite-0.4.0 x11-plugins/wmmixer-2.0_beta4-r1 x11-plugins/fsviewer-0.2.5 net-www/gnash-0.8.1-r1 x11-libs/libSM-1.0.3 dev-lang/ocaml-3.10.1 x11-libs/libXt-1.0.5 x11-libs/libXaw-1.0.4 x11-libs/libXcursor-1.1.9 gnome-base/nautilus-2.20.0-r1 media-gfx/gifsicle-1.44 x11-libs/xforms-1.0.90-r1 x11-libs/dnd-1.1-r1 x11-libs/libICE-1.0.4 x11-libs/libXft-2.1.12-r90 x11-terms/eterm-0.9.4 media-gfx/tgif-4.1.45 x11-libs/libFS-1.0.0 x11-libs/libXdamage-1.1.1 x11-libs/libXres-1.0.3 x11-libs/libXrandr-1.2.2 x11-libs/libXfont-1.3.1-r1 x11-libs/libXrender-0.9.4 x11-libs/libXau-1.0.3 app-editors/xvile-9.4d-r1 x11-libs/libast-0.7 media-plugins/vdr-xineliboutput-1.0.0_rc2_p20080120 x11-libs/libXvMC-1.0.4 x11-libs/libxsettings-client-0.10 net-dialup/isdn4k-utils-3.11_pre20071003 x11-libs/libX11-1.1.3 x11-libs/libXmu-1.0.3 x11-misc/slim-1.3.0-r1 net-mail/gnubiff-2.2.5 x11-libs/libXfixes-4.0.3 sci-mathematics/snns-4.2-r7 ^^^ do they need x11-proto/xproto as RDEPEND? My time on it for today is over. I'm busy preparing a release, sorry. Probably some of them are ok, but I don't think all. Using http://packages.sabayonlinux.org interface you can query all our bins. -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Hi Robin, first of all. What I need is _basic_ respect on #gentoo-dev You here seem all polite, but there you like playing me. This is not a good start. On 3/13/08, Robin H. Johnson <[EMAIL PROTECTED]> wrote: > On Thu, Mar 13, 2008 at 10:24:23AM +0100, Fabio Erculiani wrote: > > media-libs/x264-svn -> dev-lang/yasm > > dev-libs/lzo -> dev-lang/nasm > > I responded to you on IRC about these two, please see my message there, > as from everything I can see, the DEPs are actually correct. > (The config.log for lzo-1 indicates other reasons that it isn't using > nasm, which should probably get fixed for both x86 and amd64). > > > > sys-apps/attr -> sys-devel/autoconf > > autoconf is in the DEPEND already. > Do you want it not there? > > Not reviewing the rest right now, I'm going to bed instead (03h26 here). > > > -- > Robin Hugh Johnson > Gentoo Linux Developer & Infra Guy > E-Mail : [EMAIL PROTECTED] > GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 > > -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
[02:31] lxnay: we offer all of our work that you base your distribution off, and you don't contribute back at all, in any way. ^^ This is a really stupid sentence. It seems some of you don't even realize how many users we brought to Gentoo, and this is really sad. You see, people like Halcy0n, agaffney, zlin keep us away from interacting with you. What we do is just trying to do our best, on the desktop, aggregating new technologies and bringing them to users. If you want to stop bad press, you (all) should firstly become more gentle with users and external contributors. I am not talking to you directly Robin, but to whom are quite annoying and provocative. I know that the majority of you have been always kind, but I will never hang on #gentoo-dev anymore just to be played around giving me voice until I annoy someone with my POV. This is not a democratic way, let's talk publicly here, without hiding in a development channel, we probably get more visibility, don't we? I will review your stuff on lzo probably tomorrow, hope won't be a problem. On 3/13/08, Fabio Erculiani <[EMAIL PROTECTED]> wrote: > Hi Robin, > first of all. > What I need is _basic_ respect on #gentoo-dev > You here seem all polite, but there you like playing me. > This is not a good start. > > > On 3/13/08, Robin H. Johnson <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 13, 2008 at 10:24:23AM +0100, Fabio Erculiani wrote: > > > media-libs/x264-svn -> dev-lang/yasm > > > dev-libs/lzo -> dev-lang/nasm > > > > I responded to you on IRC about these two, please see my message there, > > as from everything I can see, the DEPs are actually correct. > > (The config.log for lzo-1 indicates other reasons that it isn't using > > nasm, which should probably get fixed for both x86 and amd64). > > > > > > > sys-apps/attr -> sys-devel/autoconf > > > > autoconf is in the DEPEND already. > > Do you want it not there? > > > > Not reviewing the rest right now, I'm going to bed instead (03h26 here). > > > > > > -- > > Robin Hugh Johnson > > Gentoo Linux Developer & Infra Guy > > E-Mail : [EMAIL PROTECTED] > > GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 > > > > > > > > -- > Fabio Erculiani > Information and Communication Technologies Consultant > Sabayon Linux Chief Architect > http://www.sabayonlinux.org > -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
[gio mar 13 2008] [02:50:43] if you want access to the tree, find a mentor and go through the recruitment process [gio mar 13 2008] [02:50:45]lxnay: Other people have to live with the changes. no-one can maintain the whole tree single handed. [gio mar 13 2008] [02:50:51] Halcy0n: because I know where to stop [gio mar 13 2008] [02:51:02] bullshit [gio mar 13 2008] [02:51:05] Betelgeuse: Apparently lxnay can [gio mar 13 2008] [02:51:11] Betelgeuse: mighty mouse could. [gio mar 13 2008] [02:51:17] agaffney: that's what I was trying to do [gio mar 13 2008] [02:51:24] Entra Tommy[D] è entrato nel canale ([EMAIL PROTECTED]/user/TommyD). [gio mar 13 2008] [02:51:47] ferringb: hah [gio mar 13 2008] [02:52:01] lxnay: again, you are working in a community environment. It is not all about you, and there are people that have much more in depth knowledge about the packages they maintain than you could. You want to compare knowledge of GCC with myself or vapier? I can tell you right now if you touch glibc or gcc, we would file a devrel bug immediately. [gio mar 13 2008] [02:52:09] lxnay == mighty mouse? [gio mar 13 2008] [02:52:18] lxnay: If you don't have time to file bugs, howdahell will you have time for recruitment? [gio mar 13 2008] [02:52:31] Entra Maxi è entrato nel canale ([EMAIL PROTECTED]). [gio mar 13 2008] [02:52:35] agaffney: you like a cow [gio mar 13 2008] [02:52:40] agaffney: happy now? [gio mar 13 2008] [02:52:50] Entra idl0r è entrato nel canale ([EMAIL PROTECTED]/idl0r). [gio mar 13 2008] [02:52:59] hparker: I could find time if this allows me to reduce time [gio mar 13 2008] [02:53:04] * Halcy0n thinks he needs to go have another shot of whiskey because this conversation is not making any sense anymore. [gio mar 13 2008] [02:53:14]Time to go to bed. [gio mar 13 2008] [02:53:17] Halcy0n: Get me one too please, I'm out [gio mar 13 2008] [02:53:20] Entra dmwaters è entrato nel canale ([EMAIL PROTECTED]/staff/gentoo.dmwaters). [gio mar 13 2008] [02:53:20] Modalità ChanServ ha dato privilegi di operatore del canale a dmwaters. [gio mar 13 2008] [02:53:24] hparker: Makers work for you? [gio mar 13 2008] [02:53:29] yup! [gio mar 13 2008] [02:53:32] Halcy0n: dibs; still haven't found my bug [gio mar 13 2008] [02:53:32] GOt a new bottle I got to crack open :) [gio mar 13 2008] [02:53:39] ;) [gio mar 13 2008] [02:53:44] Entra cilly è entrato nel canale ([EMAIL PROTECTED]/cilly). [gio mar 13 2008] [02:53:56] I alternate between Knob and Makers. [gio mar 13 2008] [02:53:57] flamefest still going on? [gio mar 13 2008] [02:54:15] dwindling [gio mar 13 2008] [02:54:16] KingTaco: I wouldn't call it a flamefest. [gio mar 13 2008] [02:54:25] lxnay: moo [gio mar 13 2008] [02:54:32] lxnay: do you really think you can insult me? [gio mar 13 2008] [02:54:39] KingTaco: The popcorn didn't get burnt, it was brought to the perfect temperature. [gio mar 13 2008] [02:54:41] Halcy0n: when did it make sense? [gio mar 13 2008] [02:54:56] agaffney: I don't think it's worth it wasting my time insulting you, I've something better to do [gio mar 13 2008] [02:54:57] agaffney: I'm not sure, but I'm thinking if I drink more, it might [gio mar 13 2008] [02:55:07] lxnay: oh, burn! [gio mar 13 2008] [02:55:11] * agaffney cries in the corner [gio mar 13 2008] [02:55:15] agaffney: you should go die alone. [gio mar 13 2008] [02:55:23] oh noes1! [gio mar 13 2008] [02:55:40] what stupid are you On 3/13/08, Ryan Hill <[EMAIL PROTECTED]> wrote: > For those of you playing along at home, the conversation went something like > this: > > hey there, i found a whole bunch of broken stuff in your tree > cool, can you file some reports in bugzilla so we can fix it? > no, i'm too busy and you guys are slow. give me cvs access. > uh no? > you're stupid. > > > > -- > fonts, gcc-porting, by design, by neglect > mips, treecleaner,for a fact or just for effect > wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 > > > -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
What I just need is respect. I might found around 150-200 bugs on (R)DEPEND. Take 200 on about 6500 packages we have in our repository, if I take 5 minutes each, I'd end up to take 16 hours. To build my previous list, I took about 30 minutes, it's not that big, but even that small. So, what I just wanted to try to build up is a fast lane. I'm sure there's something we could do to better Gentoo. When I say "I don't have time", it means that I can't waste my time fighting with some of you just because you have the knife in your hand and like to make fun of me. I really admire the commitment of some of you and it's the only thing that led me coming here to talk. BTW, It's funny to see the difference of attitudes from here and IRC, let me underline that :) So this is a neutral ground. -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
On 3/13/08, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > I'm a distro builder, too, and I haven't been hitting any of these > problems. Would you care to point out the actual problems, or will the > "close to useless" comment be our only indication of the perceived > problems? > > > -- > Chris Gianelloni > Release Engineering Strategic Lead > Games Developer > > Yeah, but IIRC you are a SOURCE distro builder. Arent't you? (I am just asking!) -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
On 3/13/08, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Thanks for reminding me once again how you like to interact with the > people that you're trying to "help" out. You wonder why people respond > negatively to your demands and this is how you react to people. > > > -- > > Chris Gianelloni > Release Engineering Strategic Lead > Games Developer Oh so the stupid is me. True true... -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Hi Joshua, I never had issues with my emails. So I don't really know what to answer you regarding to your issues :) SPLIT: Although I think it can be a suboptimal thing for us, I can understand your policy. Let me add that, to me, the biggest issue is about (R)DEPEND. Splitting packages and maintaining in an overlay it's not that hard. On 3/13/08, joshua jackson <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Fabio Erculiani wrote: > | Hi all, > | > | Cheers > > interestingly enough ixnay...I've tried contacting you about working > together with Gentoo and on things related to eapi as sabayon is one of > the more popular distributions that has somewhat of a basis on Gentoo > (I've tried approximately 3-4 times in the last year or so) . Every time > I tried from 4 different domain accounts including my Gentoo one I was > denied the ability to send you an email. > > While I'm sure many comments are going to be a bit harsh if realistic > please do feel free to talk to any of the developers. > > Splitting isn't really realistic as that is getting away from upstream. > As an organization we try to maintain the same way as upstream intends. > If they say that mysql is not a collection of server, client then its > just mysql. Xorg is a perfect example. It was a huge package, that got > split up. It took Donnie and the rest of the X team a while to get > everything ready for the tree but we followed upstream in having > individual packages for the different aspects of the larger project. > > Please feel free to contact me directly if you wish > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFH2aop2ZWR0Jhg/EsRAkppAJ0e5u5LEfrdHP/FpsgghMm0kd07mQCfRmZP > 3rMibnJCkKJih3bsz/VYGpY= > =c41u > -END PGP SIGNATURE- > > > -- > gentoo-dev@lists.gentoo.org mailing list > > -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
On 3/14/08, Pierre-Yves Rofes <[EMAIL PROTECTED]> wrote: > > You seem to know him pretty well it seems... > Come on lxnay, who are you trying to fool here? You think that just by > opening an anonymous mail account, we would be dumb enough to not > recognize you? You could at least have been a little more subtle and a > little less self congratuling, maybe it would have worked, who knows :) > > - -- > Pierre-Yves Rofes > Gentoo Linux Security Team I hope you were joking :))) -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Joshua,
I know that draft quite well, I used as reference for writing Entropy,
our binary package manager which only uses {R,P}DEPEND and not DEPEND.
So here comes the issue, when *DEPEND are not declared properly
Entropy pulls in unneeded packaged.
What you are saying is something I am already aware of :) zmedico has
been really helpful :)
On 3/14/08, joshua jackson <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Fabio Erculiani wrote:
>
> | Hi Joshua,
> | I never had issues with my emails. So I don't really know what to
> | answer you regarding to your issues :)
> | SPLIT: Although I think it can be a suboptimal thing for us, I can
> | understand your policy. Let me add that, to me, the biggest issue is
> | about (R)DEPEND. Splitting packages and maintaining in an overlay it's
> | not that hard.
> |
> |
> |
>
> I personally have no desire to follow the redhat/debian/other binary
> packaging systems which split up infinitesimally small packages. It
> causes a lot more busywork in my opinion then any potential benefits
> that it gains you.
>
> As far as the depend issue you mentioned: Having both Rdepends and
> Depends isn't as far as I'm aware part of any EAPI currently (Correct me
> if I'm wrong people). Rdepends are needed for the builds so you will
> often see either RDEPENDS=${DEPEND} or vice versa. If its not there then
> its more of a matter of accounting then anything. I would think, and
> correct me if I'm wrong again, that it would make sense that if you only
> have RDEPENDS or DEPEND, then those same applications are required in
> the runtime of the application. Does it need to be explicitly stated? So
> far the three package manager that I'm aware of all manage this fine.
> Those being portage, paludis, and pkgcore. If there are other package
> managers out there that might have issues Its a perfect example of a
> reason to be involved in the EAPI discussions to help define what is
> needed and where.
>
> So what I suggest to you is perhaps looking over the EAPI=0 draft
> documentation and proposing some additions and or modifications that
> benefit everyone (not just one person), as its designed to be a standard
> for anyone who makes use of ebuilds and beyond.
>
> http://dev.gentoo.org/~spb/pms.pdf
>
> Is the current form, but halcy0n is working on an updated version of it
> for the next council meeting.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>
> iD8DBQFH2bL22ZWR0Jhg/EsRAkduAJsGBKKl5HgR5YXziPn9yOLbi5F5MwCfacIC
> b/aqsokP3A6JFJ7hO4LGNXY=
> =BGqi
>
> -END PGP SIGNATURE-
> --
> gentoo-dev@lists.gentoo.org mailing list
>
>
--
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
I don't really want CVS access neither I care. What I want is just fixing bugs. I'll try to file a huge bug on all the broken RDEPENDs I'll found. I'll try to find a free slot during the end of the next week for the hunting. Then, we'll see how long it will stay open, just one evidence here: http://bugs.gentoo.org/show_bug.cgi?id=125728 :) I've also found a lot of files collisions, especially on scientific applications. I'll try to file a huge bug for that too, but it'll take a lot of time. -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] The KDE overlay moves forward
On 3/17/08, Wulf C. Krueger <[EMAIL PROTECTED]> wrote: > - USE dependencies, including some special operators > - ranged dependencies > - :* and := slot dependencies > - PDEPEND "suggested:" label Nice, is there any example in the kde overlay? I'm interested in implementing the points above but I couldn't find any relevant example to make sure I understood all properly. Example: x11-libs/qt:* In that case, what Paludis will pull? x11-libs/qt:3 or x11-libs/qt:4 ? Is my understanding right? Also, could you make an example for the ":= slot dependency" syntax? > > -- > Best regards, Wulf > (Gentoo KDE Project lead) > > Thanks in advance -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] The KDE overlay moves forward
On 3/18/08, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 18 Mar 2008 10:21:49 +0100 > > > See the section "Slot Dependencies" in chapter 9 of > http://www.mailstation.de/pms.pdf . Yeah I was already reading the updated parts, thanks > > In non technical terms: > > :* means, effectively, that the slot isn't locked at compile time, and > that if you build a package against foo:2, it will work at runtime > with foo:1 or foo:3 instead. Examples of this are many things that don't > do C-style linking. > > := means, effectively, that the slot is locked at compile time. An > example of this is a package that can use any version of 'db' -- the > package can often compile against any version of db, but if you remove > the slot of the db version against which the package was built, the > package will break. > > It's used by Paludis as a hint to --uninstall and --uninstall-unused. > For normal dependencies, Paludis takes the safe option and assumes that > if something has a run dep upon foo, all installed slots of foo are > used. Using :* dependencies relaxes that restriction to any slot. > Using := dependencies changes that restriction to one specific slot. Ok thanks, is there any specific GLEP already? Or is it just a Paludis proposal? I am just wondering when this stuff will hit the tree. Thanks for the explanation > > -- > > Ciaran McCreesh > > -- Fabio Erculiani Information and Communication Technologies Consultant Sabayon Linux Chief Architect http://www.sabayonlinux.org -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Goodbye
On Tue, May 13, 2008 at 8:33 AM, Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > Hello, > > I guess I am tired of fighting with people here. I am too old for this > crap. > [...snip...] > > Have fun, > Alon. > -- > gentoo-dev@lists.gentoo.org mailing list > > I fully agree with what you wrote. Hope to see you here back again, btw net-misc/openvpn made my day a lot of times :) -- Fabio Erculiani http://www.sabayon.org Si vis pacem, para iustitiam
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
We may want to see if it's possible to make each ( pull & push ) transaction mutually exclusive one another (forcing repoman as git wrapper and playing with git hooks? I don't know). At first sight, it looks like a simple starvation problem, and there are several anti-starvation protocols out there, the problem is if these protocols can be applied to the git workflow. Just brain-dumping... -- Fabio Erculiani
Re: [gentoo-dev] ebuild laziness and binpkg overhead
Anything build-time related should not be placed into pkg_setup (I am pointing the finger to those build-related die() that are breaking binpkgs support). There's src_prepare() and src_configure() nowadays. -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
I like this as well. However, since we're going to introduce a *DEPEND split, how about splitting PDEPEND as well? As far as I've seen, PDEPEND has two (or more?) different meanings: - advisory (for instance, informing users about plugins) - cycle-breaking to help the dependency solver Would it be possible to add support for ODEPEND (as in "optional" dependencies -- I don't really care about the variable name) as well? This would be quite beneficial under certain circumstances. One of these is when ebuilds are shipped with PDEPENDs which are not required at runtime nor for cycle-breaking... Another scenario in where ODEPEND would be nice to have is with systemd init files pulled in by USE=systemd (and generally use? ( sys-apps/systemd ) in *DEPEND). Providing full systemd support for all the packages without forcing users to have it installed, given that openrc is the de-facto standard init system in Gentoo (and we don't have any openrc? ( sys-apps/openrc )), would be a nice features for binpkg repos. Users could then choose to enable or disable ODEPEND during dependencies calculation via make.conf or argv. I don't want to diverge too much from the HDEPEND discussion, but I think that if we're going to split *DEPEND, it might be a good opportunity to do it right _once_ and _for all_. -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Fri, Aug 31, 2012 at 11:58 PM, Zac Medico wrote: > > For optional dependencies, I'm pretty happy with the "runtime-switchable > USE flags" proposal: > > https://gist.github.com/2945569 runtime-switchable USE flags for optional dependencies o.O? It sounds like using a spoon to eat spaghetti to me. I think SDEPEND is a much simpler approach to the issue, why introducing a new kind of USE flags to address what really belongs to *DEPEND? > -- > Thanks, > Zac > -- Fabio Erculiani
[gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
Hi, this is actually a fork of the HDEPEND thread (sorry for having diverged that much there). As I wrote in the other thread, the problem with PDEPEND is that there are two (or more) semantics: - PDEPENDs used as "suggestions" but yet being considered in the depgraph and actually installed. Usually "suggestion" PDEPENDs are just packages providing extra features, not strictly required for the package to work at all. - PDEPENDs used for breaking dependency cycles (no problem with that). That is why I'd like to propose to introduce SDEPEND, with the following, simple, semantics: dependencies listed in SDEPEND are not required at build time nor strictly at runtime and they just enable more features in the installed application. There can be "use?" literals and by default, PMS should not pull them in in the dependencies calculation if not specifically asked (through argument or configuration file or else -- like it happens with binpkgs and --with-bdeps). A bunch of advantages over GLEP 62: - Simplicity (really, as in KISS). SDEPENDs are easier to understand and deal with, both at PMS (code) and user levels. They are also straightforward to use in ebuilds (dev) and through emerge (user). [1] - The USE flags meaning doesn't really get "stretched" introducing obscure, unknown and dangerous possible side effects when deployed in the real(tm) world. I understand that there is some level of risk with SDEPENDs as well, but we've seen them already in Exherbo and they seem to work fine there (I've been told this). - Doesn't preclude the implementation of GLEP 62 anyway. SDEPENDs are just "suggested" dependencies after all! - No need to introduce funky cache invalidation logic for PMS aggressively using caching at several layers of their stack and that guarantee a consistent depgraph for the installed pkgs repository as well [2]. - Fixes the "dissociative identity disorder" of PDEPEND ;-). Disadvantages: - If SDEPEND contains USE flags, these are written in stone and cannot be changed without a rebuild. This is generally fine for source packages, a bit less for binpkgs, but not really a big deal IMO. - Not as "elastic" as GLEP 62 USE flags, but neither *DEPENDs are - mgorny will hate me (eheheheh) Discuss. [1] It took me more than 5 minutes to understand how GLEP 62 works in practice and this is not really good to me, for a simple feature like this. [2] From GLEP 62 page: "and it is not strictly required that a package manager must ensure that the dependency graph is still consistent afterwards". -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote: > > > Why not introduce a global useflag such as "suggested-deps" which > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. > How do you manage to fix the PDEPEND "identity disorder" problem then? Teaching devs to move to GLEP 62 is much harder than just telling them to move dep strings to more appropriate locations. Moreover, your solution just makes the USE flags abuse situation worse: there are packages that use USE flags just to include extra, optional packages in the dependencies... See USE=bluetooth in net-misc/networkmanager for example (this is what I mean with USE flags abuse, actually). I'm not saying that SDEPEND is the best one-size-fits-all solution but you may agree that's the simplest and most effective one. -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny wrote: > On Sun, 2 Sep 2012 17:09:22 +0200 > Fabio Erculiani wrote: > >> On Sun, Sep 2, 2012 at 4:57 PM, hasufell wrote: >> > >> > >> > Why not introduce a global useflag such as "suggested-deps" which >> > complies with GLEP 62 meaning it will be in IUSE_RUNTIME. >> > >> >> How do you manage to fix the PDEPEND "identity disorder" problem then? >> Teaching devs to move to GLEP 62 is much harder than just telling them >> to move dep strings to more appropriate locations. > > Much harder? So, devs today don't know how USE flags work? Or do you > implying that devs should know bare technical details of package > manager implementation? Or is it just an-ass argument to support > an ass-thesis? For instance, the amount of devs still improperly using pkg_setup for build-time stuff, after years that they've been told to not do that, is a good example of how, while we're great, we tend to be resilient to change. This goes beyond software engineering, this is about psychology. The more one thing is simple, the faster is recognized and properly used by people. Not to mention that I am one of the PMS writers here (Entropy cough), and I know how much harder implementing runtime-switchable USE flags is, compared to a simple SDEPEND solution. > >> Moreover, your solution just makes the USE flags abuse situation >> worse: there are packages that use USE flags just to include extra, >> optional packages in the dependencies... See USE=bluetooth in >> net-misc/networkmanager for example (this is what I mean with USE >> flags abuse, actually). > > No, it fixes it. It enables those packages to use the same solution, > fixing its downsides. It looks like it just tries to workaround the issue, not fix it to its roots (PDEPEND is ill!). > >> I'm not saying that SDEPEND is the best one-size-fits-all solution but >> you may agree that's the simplest and most effective one. > > pkg_postinst() is simpler. USE flags are simple and very effective, yet > incorrect. Could you tell me how would you plan to implement so API to read "suggested" dependencies from pkg_postinst() output? I understand that being API-friendly is not really the best feature of Portage and ebuilds in general (one reason why our PackageKit backend is a bit sucky) but this is not a good reason to keep doing things like they've been always done. (Information printed at pkg_postinst() is another interesting problem, wrt API consumers, and this includes PackageKit, but I don't want to drift away too much from the topic). > > An effective SDEPEND implementation is definitely nowhere close > to simple. Nor is presenting those dependencies to users. As I mentioned above, I know what it simple and what not, from a Software Engineering point of view. And SDEPENDs are much simpler than GLEP 62, and GLEP 62 does not fix the PDEPEND issue because individuals will keep using it because at the end of the day, it is order of magniture simpler than obscure new variables and USE flags. As a rule of thumb, "simple" always shines over the complex and convoluted in the long run. > > -- > Best regards, > Michał Górny Peace & love! -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh wrote: > and we have worked out all the difficulties. Please elaborate. What difficulties? What did you implement other than plain SDEPEND? With what features? Lots of detail missing. > > Having said that, if we're going with suggested dependencies for EAPI 5 > (which I strongly suspect won't happen, since we seem to be wanting > EAPI 5 now rather than in several years time...) then there's a lot > more to getting it right than is mentioned in the original post, and it > needs to be written up properly. Well, this depends on the quality of the PMS architecture, I am not familiar with Paludis tho. I don't remember to have listed anything about what needs to be done at the implementation level actually, nor I really wanted to. I always use the 5 minutes "rule of thumb" strategy to understand the complexity of proposals: if it takes me more than 5 minutes to understand it, then users (!= devs) will have to go through the same or more "wtf-period". And the probability of them "giving up / getting sick / ignoring it" is linear with the wtf-period. > > -- > Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh wrote: > On Sun, 2 Sep 2012 20:46:19 +0200 > Fabio Erculiani wrote: >> On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh >> wrote: >> > and we have worked out all the difficulties. >> >> Please elaborate. What difficulties? What did you implement other than >> plain SDEPEND? With what features? Lots of detail missing. > > The big issues you're ignoring: And you call them "big issues"? Ah, the "you're ignoring" part looks a bit arrogant, are you short with arguments ;-) ? > > -- > Ciaran McCreesh -- Fabio Erculiani
Re: [gentoo-dev] [RFC] EAPI 5+: split PDEPEND introducing SDEPEND
s/with/on/ -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Wed, Sep 5, 2012 at 2:06 AM, Jorge Manuel B. S. Vicetto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 31-08-2012 20:46, Ciaran McCreesh wrote: > > > >> Also, we're getting rather a lot of *DEPEND variables here... If >> we're making people make major changes to their deps, which for >> HDEPEND we definitely would be, then the "it's expensive since >> people would have to redo their deps" argument against a combined >> DEPENDENCIES variable goes out of the window, so we should rethink >> that too. > > I have to agree with Ciaran, instead of multiplying DEPEND variables, > it's probably time we move to a single DEPENDENCIES variable. So, let's say that I only want to apply a filter function against the buildtime dependencies, in that case I'd need to parse *all* the dependencies anyway? The complexity would become: O((b + r + p) * P) b = amount of buildtime dependencies r = amount of runtime dependencies p = amount of post-dependencies P = amount of packages i need to apply the filter to Instead of just: O(b * P) It sounds like a good "dis-optimization". Some pkgs have really long list of *DEPEND. > > - -- > Regards, > > Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org > Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJQRpeVAAoJEC8ZTXQF1qEP/UgQALd+7oqAODQA5bXdyqV+Qix+ > mDN66c/6UO4VS2dyhfCEyA3osJzFS4u6mIuR7uFpXoKXGGs+MYdl7EG9C0k48zUu > YLCDD56oyk6wACxBk7EHWVql1rvFoFemMUw5YUVq71w3FU9hrpBi/DXKsoAlCRyw > 4B2p6t8p6efll3vzbcz7M0LZseiox4GBTFCrtxR5zwgvx3b0gKvgU1Pv+AT3SBQK > J3IOxb09GSLCJKo56+iDHGuS5RwBBmdWP9l3+AdbjR2LoQ05f8o8a7/geg1Qqg/Z > gVVSo4WDN2kIDJOvCBuXuo95a0KKFt/zUgfwjsqe02fRu2mDiWAju4L6vk2WE316 > 4yfMULI6HrVUk3ra+O4ZW7eoOuRvPVDpr4vyCVetFe4bx+zmlo/CmzOg/2teMyoc > rlMvOigR/4D+wxX7mbw/0fwZ5tVUbZ2pkdEhKetlpDe+xbWY0LhaczKdizwF7BrT > d+BeazPGWBP/muY0s3VDu3KV/3TRS0tME8GRsDevA9nCfA2plU0ZmmZnTB69tLc+ > /dgdexHhc3IuA5eMObwOfSK6r9Jozlrv09TDvb6kHXm+0kqhV/W/aaS1qT4Bjlxd > psMjf9lSJHLcXuhtOz9OW4qmhp4BGCA8Rgeoq25Yw8E2eH0abvDbHR5U7u1hEpnQ > j6rJ0fZ27tfbMecd5i8b > =Zv/I > -END PGP SIGNATURE- > -- Fabio Erculiani
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Wed, Sep 5, 2012 at 12:44 PM, Rich Freeman wrote: > On Wed, Sep 5, 2012 at 3:19 AM, Fabio Erculiani wrote: >> The complexity would become: >> O((b + r + p) * P) >> b = amount of buildtime dependencies >> r = amount of runtime dependencies >> p = amount of post-dependencies >> P = amount of packages i need to apply the filter to >> >> Instead of just: >> O(b * P) > > Well, actually, in both cases the complexity is O(n), assuming you > only need to make a constant number of passes through the deps per > package. > > The whole point of O notation is that it is about how it scales, not > how long it takes. An O(n) algorithm can actually be slower than an > O(n^n) algorithm even on a large dataset. However, the key is that at > some point if the dataset gets large enough the O(n) algorithm will > always become faster. > > I tend to agree with Cirian though - the time for some code to run > through the dependencies array and do something isn't going to be very > high. If a piece of code has to do it many times there is nothing > that says the package manager can't index it. I don't want to diverge (again) from the main topic, but I think that you're just oversimplifying it. If you consider parsing an ebuild something hidden behind a lot of abstraction layers, O(n) vs O(n/2) is a big difference, even if both, normalized, are still O(n). And I would never design an API which assumes that O(n/2) equals to O(n), because you don't know how that is going to be used in upper layers, today, tomorrow and in 5 years. > > Rich > -- Fabio Erculiani
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
It depends on who is actually laughing I'd say. just my 0.01c. -- Fabio Erculiani
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
In my humble opinion, the real question is: why systemd got merged into udev? I would love to hear a clear technical reason for that. -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I hope this is going to be binary package manager friendly. In Sabayon for instance, kernel sources are not even installed and at the same time, /proc/config.gz may not even be available. There were some corner cases in where pkg_setup failed because this kernel config check stuff was trying to be "smarter" than the user. -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I think that the problem is that it is trying to be smart when it's not really possible (unless you want to cover all the corner cases, which is a pain). -- Fabio Erculiani
Re: [gentoo-dev] RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
On Thu, Jan 24, 2013 at 1:10 AM, Robin H. Johnson wrote: > On Wed, Jan 23, 2013 at 12:32:40PM +0000, Fabio Erculiani wrote: >> I hope this is going to be binary package manager friendly. >> In Sabayon for instance, kernel sources are not even installed and at >> the same time, /proc/config.gz may not even be available. >> There were some corner cases in where pkg_setup failed because this >> kernel config check stuff was trying to be "smarter" than the user. > That was before we made it possible to have CONFIG_CHECK="~FOO" without > /proc/config.gz, for the bugs you yourself submitted, and I fixed years > ago. > > I would expect that ALL Sabayon users would have CONFIG_CHECK_FATAL=0, > because they run your kernel (if you have your kernel in a package, > maybe even distribute a file that triggers it, so anybody else with > their own kernel still has the default CONFIG_CHECK_FATAL=1). But we cannot assume that the environment in where packages are built is the same as the environment in where packages are installed and run. > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Trustee & Infrastructure Lead > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > -- Fabio Erculiani
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
I am starting to think that the real problem is that Gentoo does not have ebuilds for building kernels (binary kernels). At that point, it would be easy to add USE flags and virtual packages to solve the config check problem at the dependencies level once and for all. -- Fabio Erculiani
Re: [gentoo-dev] Re: RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
What I always wondered is why we have ebuilds for every kind of binary except for kernels, yet we build official kernels with official configs for our livecds. -- Fabio Erculiani
Re: [gentoo-dev] splashutils needs a maintainer
On Mon, Jan 28, 2013 at 7:26 PM, Pacho Ramos wrote: > El lun, 28-01-2013 a las 00:25 +0100, Alex Legler escribió: > > Then, looks like no alternative is in good shape on Gentoo. What is > Sabayon using? They look to have plymouth ebuilds in their overlay (but > not in "for-gentoo" one, then, it probably has some incompatibility > Gentoo :/) > Officially, we have always used fbsplash + splashutils. I have no experience with dracut/plymouth though. -- Fabio Erculiani
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
Well done! Binary packages is now broken :-/ >>## SPM: post-install phase * ERROR: x11-misc/bumblebee-3.0.1-r2 failed (postinst phase): * README.gentoo wasn't created at src_install! * * Call stack: * ebuild.sh, line 93: Called pkg_postinst * environment, line 2080: Called readme.gentoo_pkg_postinst * environment, line 2230: Called readme.gentoo_print_elog * environment, line 2245: Called die * The specific snippet of code: * die "README.gentoo wasn't created at src_install!"; * * If you need support, post the output of `emerge --info '=x11-misc/bumblebee-3.0.1-r2'`, * the complete build log and the output of `emerge -pqv '=x11-misc/bumblebee-3.0.1-r2'`. * The complete build log is located at '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/temp/environment'. * Working directory: '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2' * S: '/var/tmp/entropy/packages/amd64/5/x11-misc_bumblebee-3.0.1-r2_0.tbz2/portage/x11-misc/bumblebee-3.0.1-r2/work/bumblebee-3.0.1' -- Fabio Erculiani
Re: [gentoo-dev] readme.gentoo.eclass: Add a readme.gentoo_force_print_elog function to force elog printing
No FILESDIR nor T in pkg_* phases please! -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Sun, Feb 10, 2013 at 4:49 PM, Dirkjan Ochtman wrote: > On Sun, Feb 10, 2013 at 4:05 PM, Pacho Ramos wrote: >> I agree as I have also needed to google and search in forums to get >> proper firmware installed in the past in some machines :/ > > +1 from me; I've had a few machines break on kernel upgrades because I > didn't have the proper firmware installed (I guess older kernel > sources came with the firmware?). This is another problem, namely dependency level problem. I don't see how having kernel sources ebuilds providing /lib/firmware would fix any of the listed issues without causing other "side effects". For starters, if kernel sources provide /lib/firmware, how do you deal with file collisions? > > Cheers, > > Dirkjan > -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
I am starting to believe that this is yet another good reason for having official ebuilds building binaries off gentoo-sources through genkernel. Pretty much the same I do in Sabayon since 2007. -- Fabio Erculiani
Re: RFC: install linux-firmware with kernel sources (was Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1)
On Tue, Feb 12, 2013 at 7:47 PM, Pacho Ramos wrote: > El mar, 12-02-2013 a las 19:43 +0000, Fabio Erculiani escribió: >> I am starting to believe that this is yet another good reason for >> having official ebuilds building binaries off gentoo-sources through >> genkernel. Pretty much the same I do in Sabayon since 2007. >> > > I think shouldn't have any problems on providing them also as an > alternative, the problem is who would maintain that builds (as I guess > Sabayon is using different sources than gentoo and, then, probably not > all chosen options for Sabayon will work on Gentoo :/) If the goal is providing a general purpose kernel that's based on genpatches (plus BFQ and aufs3) and could be used in official live images, the current sabayon kernels could work just fine for Gentoo. They are coming directly from Linus' (or gregkh for stable releases) git repo. Upstreaming sabayon-kernel.eclass and kernel binary ebuilds is something I'd be interested in, as long as other devs here are willing to help me out as well. But I don't want to go off-topic too much. -- Fabio Erculiani
Re: [gentoo-dev] [fyi] lddtree magic
It looks like you're not using a standard style guide for Python but rather this one [1]. I suggest you to use something closer to PEP8. [1] https://code.google.com/p/google-styleguide/ -- Fabio Erculiani
Re: [gentoo-dev] [fyi] lddtree magic
On Wed, Apr 10, 2013 at 5:33 PM, Mike Frysinger wrote: > On Wednesday 10 April 2013 06:04:00 Fabio Erculiani wrote: >> It looks like you're not using a standard style guide for Python but >> rather this one [1]. >> I suggest you to use something closer to PEP8. > > no Good arguments! As usual I'd say. > -mike -- Fabio Erculiani
Re: [gentoo-dev] [fyi] lddtree magic
On Wed, Apr 10, 2013 at 6:32 PM, Mike Frysinger wrote: > On Wednesday 10 April 2013 12:42:14 Fabio Erculiani wrote: >> On Wed, Apr 10, 2013 at 5:33 PM, Mike Frysinger wrote: >> > On Wednesday 10 April 2013 06:04:00 Fabio Erculiani wrote: >> >> It looks like you're not using a standard style guide for Python but >> >> rather this one [1]. >> >> I suggest you to use something closer to PEP8. >> > >> > no >> >> Good arguments! As usual I'd say. > > sorry, but i didn't think stating the obvious was necessary. i authored the > entire tool, and the one maintaining the code, so yes, i get the liberty to > use whatever coding style pleases me. you provide no reasoning whatsoever as > to why PEP8 is "better". i doubt the style choice is going make any > difference > whatsoever to contributions for people including yourself. I guess that you're new to Python then. Anyway, mine was just an advice, yours was just the same old rude answer. > > don't like it ? fork it and write your own. > -mike -- Fabio Erculiani
Re: [gentoo-dev] [PATCHES] kernel-2.eclass: Various changes requested by users. + [STABLEREQ?] sys-kernel/gentoo-sources-3.8.7: Any objections against stabilizing?
On Fri, Apr 12, 2013 at 10:41 PM, Tom Wijsman wrote: > Hello everyone > > > Attached you will find the various changes I plan to apply to > kernel-2.eclass after a week if there are no objections, feel free to > take a look at them. A summary of the changes: > > - Added a warning after the variables that modifying other variables in > the eclass is not supported, there is a chance that we will not fix > resulting bugs. Fixes bug #421721. Why? Just to annoy people who have successfully used kernel-2.eclass until now, and in my case for half a decade (or even more)? If you need help with maintaining the current eclass functionality, I'd be more than happy. I don't really want to fork it myself :-). > [..] > > - Kernel sources and (gen)patches now use xz instead of bz2. Fixes bug > #421721. As I said in the bug, next time you plan a migration like that, it would be nice to send an heads up on the ML beforehand. Like you did in this case, but actually, _beforehand_ and not ~one month later. [...] > > Have a nice day. :) > > -- > With kind regards, > > Tom Wijsman (TomWij) > Gentoo Developer > > E-mail address : tom...@gentoo.org > GPG Public Key : 6D34E57D > GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D -- Fabio Erculiani
[gentoo-dev] Making systemd more accessible to "normal" users
PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. THIS IS NOT A POST AGAINST OPENRC. With the release of Sabayon 13.04 [1] and thanks to the efforts I put into the systemd-love overlay [2], systemd has become much more accessible and easy to migrate to/from openrc. Both are able to happily coexist and logind/consolekit detection is now done at runtime. It is sad to say that the "territoriality" in base-system (and toolchain) is not allowing any kind of progress [3] [4]. This is nothing new, by the way. There are several components that need patching in order to work as expected with systemd: - polkit needs a patch that enables runtime detection of logind/consolekit - pambase needs to drop USE=systemd and always enable the optional module pam_systemd.so - genkernel needs to migrate to *udev (or as I did, provide a --udev genkernel option), mdev is unable to properly activate LVM volumes and LVM is actually working by miracle with openrc. Alternatively, we should migrate to dracut. - networkmanager need not to install/remove files depending on USE=systemd but rather detect systemd at runtime, which is a 3 lines script. - openrc-settingsd needs to support eselect-settingsd, which makes possible to switch the settingsd implementation at runtime, between openrc and systemd. This also removes the silly conflict between openrc-settingsd and systemd friends. - genkernel should at least support plymouth (work in progress my side) - other ~490 systemd units are missing at this time and writing them could also be a great GSoC project (don't look at me, I'm busy enough). All this would come with no cost for the current openrc state (actually, my initramfs speed improvements patches in genkernel.git also benefit openrc). If Gentoo is about choice, we should give our users the right to choose between the init system they like the most. It looks like there is some consensus on the effort of making systemd more accessible, while there are problems with submitting bugs about new systemd units of the sort that maintainers just_dont_answer(tm). In this case, I am just giving 3 weeks grace period for maintainers to answer and then I usually go ahead adding units (I'm in systemd@ after all). The only remaining problem is about eselect-sysvinit, for this reason, I am probably going to create a new separate pkg called _sysvinit-next_, that contains all the fun stuff many developers were not allowed to commit (besides my needs, there is also the need of splitting sysvinit due to the issues reported in [4]). I am sure that a masked alternative sysvinit ebuild won't hurt anybody and will make Gentoo a bit more fun to use. The final outcome will hopefully be: - easier to migrate from/to systemd, at runtime, with NO recompilation at all (just enable USE=systemd and switch the device manager from *udev to systemd -- unless somebody wants to drop the udev part from systemd, if at all possible) - we give the users the right to choose without driving them nuts with weird emerge-fu. - we make possible to support new init systems in future, and even specific init wrappers (bootchart anyone?) - we prepare the path towards a painless migration from consolekit (deprecated for long time now) to logind (we probably need to fork it off the systemd pkg -- upstream projects are _dropping_ consolekit support right now!) - we put back some fun into Gentoo If you want to see a working implementation of my systemd-love efforts, just go download [1] and see things working yourself. [1] http://www.sabayon.org/release/press-release-sabayon-1304 [2] https://github.com/Sabayon/systemd-love [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236 [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615 Cheers, -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos wrote: > El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió: > [...] >> - other ~490 systemd units are missing at this time and writing them >> could also be a great GSoC project (don't look at me, I'm busy >> enough). > [...] > > Can't them be stolen from other distros running systemd? Sure, Arch and Fedora repositories are a good source. > > [...] >> The only remaining problem is about eselect-sysvinit, for this reason, >> I am probably going to create a new separate pkg called >> _sysvinit-next_, that contains all the fun stuff many developers were >> not allowed to commit (besides my needs, there is also the need of >> splitting sysvinit due to the issues reported in [4]). I am sure that >> a masked alternative sysvinit ebuild won't hurt anybody and will make >> Gentoo a bit more fun to use. >> > > I am unable to find exact advantage of changing init system without > rebooting :/, what is the advantage of booting with an init.d and > shutting down with a different one? No, you don't boot with A and shutdown with B. B is loaded by the kernel at the next boot. Switching init system is the only way to roll out a migration path, among other things I already wrote about on the eselect-sysvinit bug. > >> The final outcome will hopefully be: >> - easier to migrate from/to systemd, at runtime, with NO recompilation >> at all (just enable USE=systemd and switch the device manager from >> *udev to systemd -- unless somebody wants to drop the udev part from >> systemd, if at all possible) > > Are udev and systemd-udev-part really equivalent? I mean, since they are > maintained by different people downstream, I am not sure if there would > be differences in how udev from udev ebuild and udev from systemd ebuild > will behave. This needs investigation. > > Best regards and thanks for your work! > > -- Fabio Erculiani
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, May 1, 2013 at 2:54 PM, Steven J. Long wrote: > On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote: >> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. >> THIS IS NOT A POST AGAINST OPENRC. >> >> With the release of Sabayon 13.04 [1] and thanks to the efforts I put >> into the systemd-love overlay [2], systemd has become much more >> accessible and easy to migrate to/from openrc. Both are able to >> happily coexist and logind/consolekit detection is now done at >> runtime. > > That's great: well done :-) > > Can I just check: what about people not using consolekit nor logind? This has nothing to do with it. If you don't want consolekit nor logind just USE="-consolekit -systemd". It looks like you haven't clear what I'm writing about, though. > >> It is sad to say that the "territoriality" in base-system (and >> toolchain) is not allowing any kind of progress [3] [4]. This is >> nothing new, by the way. > > I don't think you help yourself by making that kind of remark: when I read > those bugs I see some valid concerns being raised, which you just ignore. > For instance, wrt "nonsensical blockers" I too would like to know some > examples, as was queried in comment 27 [3]. In fact it was the first thing > that came to mind when reading your post, as I thought where possible things > were just installed for systemd (such as unit files) even when the user > is not using it. Have you ever tried to fully migrate to systemd from openrc? Clearly not. > > > There are several components that need patching in order to work as >> expected with systemd: >> - polkit needs a patch that enables runtime detection of logind/consolekit >> - pambase needs to drop USE=systemd and always enable the optional >> module pam_systemd.so > > Again, what about people not using consolekit, nor logind, with no intention > of ever installing systemd? I've got nothing against this so long as it > is guaranteed not to break my pam setup. As-is I feel *very* wary of a change > that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile > to your aims: I am merely seeking reassurance. Do you know how pam works? And did you understand the meaning of my words? Do you know what optional means in this context? > >> - genkernel needs to migrate to *udev (or as I did, provide a --udev >> genkernel option), mdev is unable to properly activate LVM volumes and >> LVM is actually working by miracle with openrc. > > Why is that such a "miracle"? openrc has worked with lvm since the beginning > afair, and is both clean, portable C, and modular. Do you know how LVM and udev and systemd interact wrt volumes activation? > >> Alternatively, we should migrate to dracut. >> - networkmanager need not to install/remove files depending on >> USE=systemd but rather detect systemd at runtime, which is a 3 lines >> script. > > Sounds reasonable; since I don't use it, that can't affect me in any case. My goal wrt openrc is to keep the current level of support and just make systemd users' life easier. > >> - openrc-settingsd needs to support eselect-settingsd, which makes >> possible to switch the settingsd implementation at runtime, between >> openrc and systemd. This also removes the silly conflict between >> openrc-settingsd and systemd friends. >> - genkernel should at least support plymouth (work in progress my side) >> - other ~490 systemd units are missing at this time and writing them >> could also be a great GSoC project (don't look at me, I'm busy >> enough). >> >> All this would come with no cost for the current openrc state >> (actually, my initramfs speed improvements patches in genkernel.git >> also benefit openrc). >> If Gentoo is about choice, we should give our users the right to >> choose between the init system they like the most. > > I must be missing something as I thought they already had that choice. Please, write about something you actually manage to _know_. And also, please do read my post title. This is not a flamewar topic, I want to discuss about improving the systemd experience. > > From reading the bug, the only pro of your approach is that the user > does not have to edit the kernel command-line to try out a new init. > Initially, you tried to sell this as "lowering the bar" which is actually > a con afaic: if someone is trying to run Gentoo and is incapable of > dealing with the kernel command-line, it's likely they won't be able to > install it; they certainly won't be able to maintain it, ime. > > Later, we get
Re: [gentoo-dev] Making systemd more accessible to "normal" users
There is no tracker yet. But it may be very well materialize at some point. -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, May 1, 2013 at 9:52 PM, "Paweł Hajdan, Jr." wrote: > On 5/1/13 3:04 AM, Fabio Erculiani wrote: > > As far as I read the bug, Mike (vapier) is doing the right thing. > Distros doing lots of custom changes can only add more chaos to the picture. We are a distribution, we have our own goals, thus we change the code to better integrate with our ecosystem. That's part of the game. If we don't want to do that, we shouldn't be running a distro in the first place. > > Have you reached out to relevant upstreams? If they refuse to make > changes, that's a different story. So far I think it's reasonable to go > to upstreams first. For just a symlink swap and some file moves? (re: sysvinit) We don't need to bless upstream first for such small changes. > > Paweł > > -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Thu, May 2, 2013 at 5:26 AM, Kent Fredric wrote: > [snip] > > Against, the symlink may introduce parts that are breakable, like if user > messes up and places the destination of the symlink on a different partition > ( shouldn't be a problem, but might be ), or if you're doing an initird that > has init baked into it, you'd have to regenerate that initrd after changing > the symlink ( I think, maybe not, its probably not even a problem, its just > something I'd have to check ) eselect-sysvinit handles symlink swapping among files in /sbin/init.d. So you cannot run into partitioning issues directly. > > And also, if for whatever reason systemd becomes "unbootable" it might be > slightly hard to boot with the "right" init if you can't change kernel > parameters during boot time. The same happens if you change the boot arguments and reboot. This is not something eselect-sysvinit is supposed to solve. But anyway, eselect-sysvinit is a marginal thing and can be supported by just providing a more experimental, perhaps masked, sysvinit ebuild. I am more concerned about the rest of the story. > > But noted, those last 2 "against" reasons are "edge cases", where the > arguments for it are "majority cases", so collectively I'm still in favour > of the eselect + symlinks approach. > > > -- > Kent -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert wrote:
>
> If you manually write your own configuration for GRUB2, it is no more
> convoluted than for GRUB Legacy.
>
> If you use grub-mkconfig to generate a configuration file, you can
> append the init option by setting
> GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
> /etc/default/grub.
Not all the Gentoo users are as skilled as you (a developer). Having a
programmatic, bootloader agnostic way to swap /sbin/init is useful for
the reasons I explained. Yet I haven't read any solid reason not to do
that.
>
> Either way, it's pretty simple.
>
If it's that simple, why on earth do we have all the eselect modules we have!?
Extra modules:
audicle Manage /usr/bin/audicle audio engine
bashcomp Manage contributed bash-completion scripts
binutils Manage installed versions of sys-devel/binutils
blas Manage installed BLAS implementations
bzimage Switch bzImage default kernel by updating
/boot/bzImage symlink
cblas Manage installed CBLAS implementations
cdparanoiaManage /usr/bin/cdparanoia implementation
chuck Manage /usr/bin/chuck audio engine
ctags Manage /usr/bin/ctags implementations
ecj Manage ECJ targets
editorManage the EDITOR environment variable
emacs Manage /usr/bin/emacs version
env Manage environment variables set in /etc/env.d/
esd Select esound daemon or wrapper
etags Manage /usr/bin/etags implementations
fontconfigManage fontconfig /etc/fonts/conf.d/ symlinks
gnat Manage the installed gnat compilers
gnome-shell-extensionsManage default settings for systemwide
GNOME Shell extensions
infinalityManage the /etc/fonts/infinality/conf.d symlink
java-nsplugin Manage the Java plugin for Netscape-like Browsers
java-vm Manage the Java system and user VM
kernelManage the /usr/src/linux symlink
lapackManage installed LAPACK implementations
lcdfilter Manage the /etc/env.d/99lcdfilter symlink
lightdm Switch between LightDM greeters
localeManage the LANG environment variable
maven Manage Maven targets
mesa Manage the OpenGL driver architecture used
by media-libs/mesa
miniaudicle Manage /usr/bin/miniAudicle audio engine
modules Query eselect modules
mpg123Manage /usr/bin/mpg123 implementation
mpost Manage /usr/bin/mpost implementations
news Read Gentoo ("GLEP 42") news items
notify-send Manage /usr/bin/notify-send implementation
nxserver Manages the configuration of NX servers
oodictManage the configuration of dictionaries
for OpenOffice.Org.
openclManage the OpenCL implementation used by your system
openglManage the OpenGL implementation used by your system
package-manager Manage the PACKAGE_MANAGER environment variable
pager Manage the PAGER environment variable
pdftexManage /usr/bin/pdftex implementations
php Manage php installations
pinentry Manage /usr/bin/pinentry implementation
postgresqlManage active PostgreSQL client
applications and libraries
profile Manage the make.profile symlink
pythonManage Python symlinks
qtgraphicssystem Manage the system-wide active Qt Graphics System
rails Manage Ruby on Rails versions
rcManage /etc/init.d scripts in runlevels
ruby Manage Ruby symlinks
settingsd Switch between settingsd implementations
shManage /bin/sh (POSIX shell) implementations
sndpeek Manage /usr/bin/sndpeek audio engine
sysvinit Switch between sysvinit implementations
timidity Select default system patchset for TiMidity++
unisonManage /usr/bin/unison versions
vdr-pluginManage VDR plugins
viManage /usr/bin/vi implementations
visualManage the VISUAL environment variable
wxwidgets Manage the system default wxWidgets profile.
xvmc Manage the XvMC implementation used by your system
Why aren't we telling people to just edit config files!?
--
Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Sat, May 4, 2013 at 12:42 PM, Luca Barbato wrote: > On 05/01/2013 12:04 PM, Fabio Erculiani wrote: >> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST. >> THIS IS NOT A POST AGAINST OPENRC. > > Amen > >> With the release of Sabayon 13.04 [1] and thanks to the efforts I put >> into the systemd-love overlay [2], systemd has become much more >> accessible and easy to migrate to/from openrc. Both are able to >> happily coexist and logind/consolekit detection is now done at >> runtime. >> It is sad to say that the "territoriality" in base-system (and >> toolchain) is not allowing any kind of progress [3] [4]. This is >> nothing new, by the way. >> >> There are several components that need patching in order to work as >> expected with systemd: >> - polkit needs a patch that enables runtime detection of logind/consolekit >> - pambase needs to drop USE=systemd and always enable the optional >> module pam_systemd.so >> - genkernel needs to migrate to *udev (or as I did, provide a --udev >> genkernel option), mdev is unable to properly activate LVM volumes and >> LVM is actually working by miracle with openrc. Alternatively, we >> should migrate to dracut. > > [unrelated] Do you have more insights about this part? mdev MUST work, > lots of thin recovery options are based on busybox. Scenario: - you have an initramfs with mdev, your pivot_chroot system runs udev. - you have a LVM volume group, containing the lvm volume for / and /home, and perhaps you also have swap on another volume. - you boot using the current genkernel initramfs, which uses mdev and comes with lvm support The initramfs code activates your lvm volumes, lvm itself may or not may be compiled with udev support. In the former case, nothing gets written onto /run/udev (and devtmpfs), in the latter case, lvm writes metadata that are useful to lvm itself to udev. mdev is not udev, doesn't deal with udev rules so the metadata is either pristine or completely unavailable. busybox switches root and the boot starts: you obviously have lvm compiled with udev there, since you're using udev (or systemd-udevd, or gudev). The lvm there is either unable to find valid metadata so it doesn't automatically activate the volumes (note: /home does not get activated by the initramfs code) or, until some time ago but now defaulted to off, lvm itself creates the device nodes (which should have been created by udev + udev rules if lvm is compiled with udev support). If it's not enough, our current genkernel initramfs code (I fixed this as well, it's in the systemd-love overlay) doesn't mount --move /run to /newroot before switching root, so /run/udev is not ported over, which means that even if mdev would have been able to do do all the udev magic, things wouldn't work anyway. Long story short, we should: 1) give up with cross compiler support in genkernel, which has been anyway in a broken state for ages. Nobody is using it anyway. 2) make possible to optionally use udev in the initramfs (compiling just for it is a pita and the trend here [dracut and others do this] is to copy udevd from the system) 3) default to udev? > >> - networkmanager need not to install/remove files depending on >> USE=systemd but rather detect systemd at runtime, which is a 3 lines >> script. > > Sounds sensible. Also, I forgot that I wrote a NetworkManager patch that makes it able to detect logind/consolekit at runtime. It works and is in the systemd-love overlay (it's a git format-patch patch). > >> - openrc-settingsd needs to support eselect-settingsd, which makes >> possible to switch the settingsd implementation at runtime, between >> openrc and systemd. This also removes the silly conflict between >> openrc-settingsd and systemd friends. > > Would make sense merge init and settingsd in a single eselect or at > least make so switching init would warn if the settingsd doesn't match? They are really two separate things, even though I agree that it should be made even easier. I don't think it's hard though. > >> - genkernel should at least support plymouth (work in progress my side) > > Looking forward to it. I should have something ready soon. > >> - other ~490 systemd units are missing at this time and writing them >> could also be a great GSoC project (don't look at me, I'm busy >> enough). > > Hopefully we might have a gsoc student volunteering to make a > runscript/lsb-script/systemd-unit compiler and a small abstraction so we > write a single init.d script and generate what's needed. > Probably we might even support pure-runit that way with minimal effort. > >> It looks like there is some consensus on the effort of making systemd >&g
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Sat, May 4, 2013 at 3:05 PM, Fabio Erculiani wrote: > > Scenario: > - you have an initramfs with mdev, your pivot_chroot system runs udev. > - you have a LVM volume group, containing the lvm volume for / and > /home, and perhaps you also have swap on another volume. > - you boot using the current genkernel initramfs, which uses mdev and > comes with lvm support > > The initramfs code activates your lvm volumes, lvm itself may or not > may be compiled with udev support. In the former case, nothing gets > written onto /run/udev (and devtmpfs), in the latter case, lvm writes > metadata that are useful to lvm itself to udev. > mdev is not udev, doesn't deal with udev rules so the metadata is > either pristine or completely unavailable. > busybox switches root and the boot starts: you obviously have lvm > compiled with udev there, since you're using udev (or systemd-udevd, > or gudev). The lvm there is either unable to find valid metadata so it > doesn't automatically activate the volumes (note: /home does not get > activated by the initramfs code) or, until some time ago but now > defaulted to off, lvm itself creates the device nodes (which should > have been created by udev + udev rules if lvm is compiled with udev > support). > If it's not enough, our current genkernel initramfs code (I fixed this > as well, it's in the systemd-love overlay) doesn't mount --move /run > to /newroot before switching root, so /run/udev is not ported over, > which means that even if mdev would have been able to do do all the > udev magic, things wouldn't work anyway. > > Long story short, we should: > 1) give up with cross compiler support in genkernel, which has been > anyway in a broken state for ages. Nobody is using it anyway. > 2) make possible to optionally use udev in the initramfs (compiling > just for it is a pita and the trend here [dracut and others do this] > is to copy udevd from the system) > 3) default to udev? > I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working "by miracle for now". mdev is not future proof wrt lvm support. > > -- > Fabio Erculiani -- Fabio Erculiani
[gentoo-dev] Re: Making systemd more accessible to "normal" users
Tracker bug: https://bugs.gentoo.org/show_bug.cgi?id=468898 -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: > On 1 May 2013 18:04, Fabio Erculiani wrote: >> It looks like there is some consensus on the effort of making systemd >> more accessible, while there are problems with submitting bugs about >> new systemd units of the sort that maintainers just_dont_answer(tm). >> In this case, I am just giving 3 weeks grace period for maintainers to >> answer and then I usually go ahead adding units (I'm in systemd@ after >> all). > > In my opinion you should not be asking maintainers to add systemd > units to their packages. They most likely do not have systems on which > they can test these, and very few users would need them anyway. I > would think it is better to add them to a separate systemd-units > package. This sounds really wrong (tm) to me. It took me two weeks to kill that silly systemd-units pkg. All the distros around here do install systemd units with their packages and I believe that the council has already spoken about this. > > -- > Cheers, > > Ben | yngwin > Gentoo developer > Gentoo Qt project lead, Gentoo Wiki admin > -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn wrote: > Ben de Groot schrieb: >> On 1 May 2013 18:04, Fabio Erculiani wrote: >>> It looks like there is some consensus on the effort of making systemd >>> more accessible, while there are problems with submitting bugs about >>> new systemd units of the sort that maintainers just_dont_answer(tm). >>> In this case, I am just giving 3 weeks grace period for maintainers to >>> answer and then I usually go ahead adding units (I'm in systemd@ after >>> all). >> In my opinion you should not be asking maintainers to add systemd >> units to their packages. They most likely do not have systems on which >> they can test these, and very few users would need them anyway. I >> would think it is better to add them to a separate systemd-units >> package. > > Note that a similar thing is already done with the selinux policy packages. Upstreams will _DO_ ship systemd units at some point in future. It's a completely different thing. Don't compare oranges to apples. > > Mostly the complaints against adding systemd units are that it would > unnecessarily clutter non-systemd installs. Users who complain are told > to set INSTALL_MASK but that is somewhat unwieldy. Cluttering a system by just installing 4kb files? The council has spoken. If you don't like the decision, I am sorry. I can say the same for init scripts, they are freaking cluttering my system and they're all over. Or perhaps all these man pages, I don't need man pages locally but still most ebuilds do install them. What do we do? Let's be serious here. > > A separate package for the unit file would solve this problem nicely. No, it will generate a gazillion of other problems. Like conflicts arising every single day, just to name one. Is that hard to do it right, as everybody else in this world does, and move on? > Another option would be to add a "dounit" command to a future EAPI (like > doinitd today) and make portage install them unless FEATURES="nounit" > (like nodoc/noinfo/noman today). Why all this mess!? > > > Best regards, > Chí-Thanh Christopher Nguyễn > > -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
On Wed, May 8, 2013 at 5:49 PM, Ben de Groot wrote: > On 8 May 2013 23:39, Fabio Erculiani wrote: >> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot wrote: >>> On 1 May 2013 18:04, Fabio Erculiani wrote: >>>> It looks like there is some consensus on the effort of making systemd >>>> more accessible, while there are problems with submitting bugs about >>>> new systemd units of the sort that maintainers just_dont_answer(tm). >>>> In this case, I am just giving 3 weeks grace period for maintainers to >>>> answer and then I usually go ahead adding units (I'm in systemd@ after >>>> all). >>> >>> In my opinion you should not be asking maintainers to add systemd >>> units to their packages. They most likely do not have systems on which >>> they can test these, and very few users would need them anyway. I >> >>> would think it is better to add them to a separate systemd-units >>> package. >> >> This sounds really wrong (tm) to me. It took me two weeks to kill that >> silly systemd-units pkg. >> All the distros around here do install systemd units with their >> packages and I believe that the council has already spoken about this. > > It sounds more wrong to me to be asking normal package maintainers to > test and maintain unit files, while they don't use systemd themselves, > nor have it installed. Nor would most of our users need this. Nobody is asking maintainers to test units. The systemd team is responsible for them. > > And I believe the council has only spoken out against using a useflag > for installing such files. Afaik they haven't spoken out against a > systemd-units package. Please refer me to their decision if I'm wrong. I was referring to that. We never mentioned a possible systemd-units package in any council meeting I believe. I hardly believe that the systemd team would accept such choice. > > -- > Cheers, > > Ben | yngwin > Gentoo developer > Gentoo Qt project lead, Gentoo Wiki admin > -- Fabio Erculiani
Re: [gentoo-dev] Making systemd more accessible to "normal" users
Are we realizing that in order to keep systemd out of our way, we're currently writing and maintaining drop-in replacements for the features that systemd is already providing in an actively maintained state? openrc-settingsd was the first thing that we as Gentoo developers (Pacho?) had to write in order to merge GNOME 3.6 into our tree. And now that GNOME 3.8 is out, the game starts over again: logind is a hard requirement, logind is part of systemd, starting logind (which replaces consolekit) is not that trivial as you may think (and is the thing I started to work on anyway). And if this wasn't enough, it means that if you want GNOME 3.8, you need to get logind, which may or not may get included in our udev ebuild and if it won't, it means that you will be forced to use systemd as device manager if you want GNOME 3.8, which is believe it or not, the thing that Ubuntu did. The problem will only increase in size as the clock moves. And (and!) how does all this fit together with eudev? If the idea is to either put logind in udev (thus, not creating a separate logind ebuild), it means that eudev is already a dead end for GNOME users, unless the eudev team is going to provide logind as well. I don't want to start a flamewar here, I was the one who called Lennart software lennartware, but science is science, and a reality check had to be done: at some near point in the future, our users will be forced to replace udev/eudev with systemd. Like it. Or not. While I successfully use both openrc and systemd, I _do_ think that (and expect to see) more and more users (and developers) will be switching to systemd. Is there anything we can do? Besides "being prepared", I don't think so. Do we control upstreams? No, sorry. So what do we want to do then? Isolate from the rest of the world? (It's not a sarcastic question). I hope that everybody does their own reality check. -- Fabio Erculiani
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
Good news. I've been able to make logind work with OpenRC and GNOME 3.6 (which means that GNOME 3.8 can work as well). Disclaimer: I use systemd as device manager. I don't know if my logind (there is a bug about it) works with udev without further hacking. See: https://plus.google.com/u/0/107663298003289209275/posts/TxjqZkniR9f Now, the problem is that, as I wrote before, we're more and more drifting away from what upstream is supporting. Today the source of all our troubles is just GNOME, I am afraid that tomorrow it will expand beyond it. There are technical advantages for both distro makers and desktop environment makers in using systemd (besides the disadvantages). For instance, having a centralized tool for collecting system and user logs is certainly something that would make our job easier, having working (or mostly working) "init scripts" provided directly by upstream projects would reduce our maintenance burden in the long run. Anyway, I'm not trying to convince anybody in using either init systems, I am just suggesting that you should try both and decide yourself. Which translated, is the same goal as making systemd more accessible to you. -- Fabio Erculiani
Re: [gentoo-dev] Re: Re: eselect init
On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long wrote: > [...] > The whole symlink/boot/fallback thing is simply a waste of technical effort. > And blanket "your opinion" and "you didn't comment a week ago, so I don't > have to deal with the substance of your points" don't change that. Waste? We have multiple use cases for that as stated in several places (here, bugzilla, IRC, etc). If such use cases are of no interest for you, then you shouldn't be bothered. > > Please, make a better case next time. > > -- > #friendly-coders -- We're friendly, but we're not /that/ friendly ;-) > -- Fabio Erculiani
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
The final outcome I would love to see is that everybody eventually graduates from kindergarten :-) And perhaps introduce a "culture-fit" score in the recruiting, mentoring process. -- Fabio Erculiani
Re: [gentoo-dev] eselect init
There is a new version of eselect-init in the systemd-love overlay to play with. The new version saw the following major changes: - the /sbin/init (aka the symlink that eselect-init handles) can be changed to whatever one wants through make.conf [1] (this is a compile time option, as documented in the eclass) - only init is currently handled by eselect-init, which is now using a very small wrapper POSIX shell script to redirect the calls to the currently running init [2] - the wrapper and its code paths are now documented in the eselect-init eclass [2] [3] You need systemd and sysvinit from the same overlay for it to work. If you intend to use switch between systemd to openrc (and vice versa), make sure to install the rest of the packages in that overlay. At the moment, if you want to switch, you also need to use eselect-settingsd. However, I am planning to drop eselect-settingsd: openrc-settingsd and systemd share the same settingsd dbus interface while they call different executables, systemd initializes its dbus services without relying on dbus activation, so the Exec= part of the service descriptor file is currently set to /bin/false, this rings a bell :D, because it is possible to replace /bin/false with a script that starts the respective services when dbus activation is used (which means that systemd hasn't booted the system). This would make possible to remove the blocker dependency in openrc-settingsd and systemd somehow. [1] https://github.com/Sabayon/systemd-love/commit/ced29311348a81a2573b030b1316f1c3a0335c5b [2] https://github.com/Sabayon/systemd-love/commit/9eea3ff713c8fa0391e7b1bfa494d533dc21c0be [3] https://github.com/Sabayon/systemd-love/blob/master/eclass/eselect-init.eclass -- Fabio Erculiani
Re: [gentoo-dev] Temporary DevRel actions for CoC violations
Thanks for the offer, I appreciate it, but I have to decline this time. -- Fabio Erculiani
Re: [gentoo-dev] eselect init
For me, the big selling points of eselect-init are: 1. as release engineer, i can prepare images that use either systemd or openrc (at present time these are the two supported options) and do it reliably, programmatically. 2. as distro maintainer, i can roll out a migration path from openrc to systemd (or vice versa). The properties of this migration path I am looking for are reliability and "atomicity". Basically, once you move logind/consolekit detection to runtime (and believe it or not, many upstream just get it wrong), and have feature parity in the systemd units available (wrt openrc initscripts), switching over is a matter of 2 (soon 1) commands. Both of them are quite important, because there are scenarios in where systemd fits better than openrc, and scenarios in where openrc is a better fit (older kernels, production system with custom init scripts that are not worth the porting, etc). Making the switch between openrc and systemd easy is a big win (for both developers, distro maintainers, users) and makes Gentoo more attractive, but this is another topic... -- Fabio Erculiani
Re: [gentoo-dev] eselect init
Fix the reason why the wrapper got broken then. If the wrapper broke, it is most likely a symptom of a bigger problem. I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit (or /bin/sysvinit?), anyway... -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
I believe that end users would benefit more from kernel binary ebuilds (ebuilds building an actual kernel with an official config), rather than all this. -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 9:59 PM, Pacho Ramos wrote: > El lun, 01-07-2013 a las 21:55 +0200, Fabio Erculiani escribió: >> I believe that end users would benefit more from kernel binary ebuilds >> (ebuilds building an actual kernel with an official config), rather >> than all this. >> > > I don't see them exclusionary, look different issues to me :/ (with > completely different solutions I think) Of course I'm not saying that they're not orthogonal. OTOH I believe that the complexity of supporting something like this (the original proposal) is not linear. However, I don't see any problem with people implementing it btw... it's their time. > > -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 10:14 PM, Markos Chandras wrote: > [...] > It's really scary to have the BFQ in a stable gentoo-sources ebuild. BFQ is not that scary, it's "just" an iosched (and it's quite easy to write an iosched), what could possibly go wrong? Jokes apart, I've been using it in production for almost 2 years now (can't remember exactly). > > -- > Regards, > Markos Chandras - Gentoo Linux Developer > http://dev.gentoo.org/~hwoarang > -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 10:24 PM, Christoph Junghans wrote: > 2013/7/1 Fabio Erculiani : >> I believe that end users would benefit more from kernel binary ebuilds >> (ebuilds building an actual kernel with an official config), rather >> than all this. > +1 > > The "binary" use flag for sys-kernel/*-sources in Funtoo implements > exactly that. [OT] And why should you throw kernel sources at people as well? Separate pkgs is much better. I don't want to have kernel sources on my servers (for the same reason I don't want to have a compiler, and I've been able to sort this out as well). [/OT] Sorry for the OT. > >> >> -- >> Fabio Erculiani >> > > > > -- > Christoph Junghans > http://dev.gentoo.org/~ottxor/ > -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
On Mon, Jul 1, 2013 at 11:26 PM, Anthony G. Basile wrote: > > > I'm pretty sure I hit a genuine deadlock with it. I've been trying to > reproduce with debugging on but nothing yet. > > But, having said that: > > BFQ [Experimtental] > > This introduced an experimental io scheduler. Have fun with it, but don't > dare use it in production else we will laugh. Don't trust outdated documentation. http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php There is nothing about it in the latest BFQ patchset. > > >> >>> -- >>> Regards, >>> Markos Chandras - Gentoo Linux Developer >>> http://dev.gentoo.org/~hwoarang >>> >> >> > > > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail: bluen...@gentoo.org > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > > -- Fabio Erculiani
Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.
On Tue, Jul 2, 2013 at 9:36 AM, Sergei Trofimovich wrote: > [ sorry, a lot to quote ] > > What upstream do you plan to report bugs when user possibly mixes > all of it in one mess? Each of those is known to be unstable. The mix > is just a disaster. > > Is gentoo's kernel team able to resolve user's OOpsen? > >> ### ... and configuration. ### >> >> This problem is not only visible for patches, but also in the config. > > Insane :] > >> Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're >> telling users to enable it in some places, in the handbook it's a single >> line you must read, on the Wiki it's kind of missing unless you are >> luckily on the right page, on the Quick Install book it is missing too. > > Forbid users install udev to ROOT=/ if running kernel does not support > devtmpfs > (easy to check by /proc/filesystems) No. As explained multiple times, this check is not reliable and doesn't work (chroot, binpkgs, containers without kernel, and so on...). Making sure that the user doesn't build an unbootable kernel is the way to go. > > -- > > Sergei -- Fabio Erculiani
Re: [gentoo-dev] Running tests using virtualx.eclass should be allowed to be forced to run in virtual X always
On Fri, Jul 19, 2013 at 1:40 PM, Diego Elio Pettenò wrote: > [...] > And non-deterministic tests are stupid, useless, broken tests. Amen. Even though there is that 1% of cases in where you want to have non-deterministic tests. For instance, if you want to run the same test thousands of times and randomly pick an initial state to see if you spot a "scenario" in where you have problems (concurrency problems)... :-) > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ -- Fabio Erculiani
Re: [gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
Some time ago I was also thinking about writing a test framework for testing live images through kvm. Of course I didn't manage to find time to try to arrange something in the end, but the idea is still popping up in my mind every now and then. -- Fabio Erculiani
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 1:49 AM, Patrick Lauer wrote: > > Seeing the noise in #gentoo from people getting whacked in the kidney by > the systemd sidegrade ... that's a very optimistic decision. Yes it is, because our policy has always been to follow upstream as much as possible. So your sarcasm is not fun. > > It'll cause lots of pain for users that suddenly can't start lvm > properly and other nasty landmines hidden in the "upgrade path". By > stabilizing this early you're causing lots of extra work for others. How much time did you spend on trying to make GNOME 3.8 work with openrc? Because I spent so much that I ended up suggesting the GNOME team to require systemd. And systemd is the only thing that at this time, properly works with current and future GNOME releases. And GNOME 3.8 is at this time, only fully working with systemd (fully: if you don't think you need to be able to shutdown your computer and have proper session management... well, I'd remove the "fully" word myself.) Moreover, the lvm problem is caused by a very ancient and ill decision about doing what upstream tells you to avoid: have mdev in the initramfs and udev on the final pivot rooted system. This was just looking for troubles but the smarties at the time decided that they knew better... And now, tadam, the bug is served... People can use genkernel-next, which comes with _proper_ udev support (see --udev). > > I hope you understand that some of us will be very rude and just suggest > to unmerge gnome on all support requests as it now moves outside our > support range ... > > Have a nice day, > > Patrick > > -- Fabio Erculiani
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 4:10 PM, Alon Bar-Lev wrote: > On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani wrote: >> Moreover, the lvm problem is caused by a very ancient and ill decision >> about doing what upstream tells you to avoid: have mdev in the >> initramfs and udev on the final pivot rooted system. This was just >> looking for troubles but the smarties at the time decided that they >> knew better... And now, tadam, the bug is served... >> People can use genkernel-next, which comes with _proper_ udev support >> (see --udev). > > I won't comment about the entire gnome monolithic windows like, vendor > controlled system that we cooperate with. > > But the above statement is way too much... there should be nothing > wrong in having mdev during boot. initramfs should be simple as > possible and busybox provides this functionality well. The problem is > in udev not in any other component, that probably expects now to run > first and have total control over the boot process. I hope eudev does > not suffer from this. > > If genkernel will start using udev instead of busybox, it will > probably be the last day of me use it. Fellow developer, let me tell you one thing, go clone the git repo and see how --udev is implemented and realize that mdev is still supported as it was before. > > I am just waiting for the point in which you claim that systemd should > be run at initramfs, because of the dependency lock-in, so you have > almost the entire system within initramfs. While it may have several advantages, there is no pressing need in supporting systemd in the initramfs for now. > > Regards, > Alon > -- Fabio Erculiani
Re: [gentoo-dev] Re: [gentoo-user] OpenRc-0.12 is coming soon
On Fri, Aug 16, 2013 at 4:09 PM, Markos Chandras wrote: > On 14 August 2013 16:43, Keith Dart wrote: >> Re , William Hubbs said: >>> All, >>> >>> This message is an announcement and a reminder. >>> >>> OpenRc-0.12 will be introduced to the portage tree in the next few >>> days. >>> >>> If you are using ~arch OpenRc, the standard disclaimer applies: >>> remember that you might be subject to breakage. >> >> I just got around to upgrading to it. When I did my /etc/conf.d/net >> file disappeared, and my network interface would not come up. There is >> not even a sample net file any more. I had to manually add it back, >> using a syntax I found on the wiki site. >> >> > > The package is now masked (openrc-0.12) because quite a few people > lost their net configs I wonder if this has to do with bug #462674 which was about to generate a disaster on one of my old servers as well. Thankfully, the net config was stored in a local git repo and I just had to reset the its state to HEAD. Now I need to go sacrifice a cow to Linus to demonstrate my gratitude. > > So yep, ~arch being *this* broken is not so nice > > -- > Regards, > Markos Chandras - Gentoo Linux Developer > http://dev.gentoo.org/~hwoarang > -- Fabio Erculiani
[gentoo-dev] Doing and then undoing slotmoves
Hi, 6 days ago gienah committed a bunch of slotmoves for the haskell glib/gtk stuff [1], basically moving the pkgs to slot 0 (from slot 2). This was done in file 4Q-2013. It turns out that the same gienah moved those pkgs to slot 2 (from slot 0) in 2Q-2013 [2]. I have never seen something like that and this generated an interesting bug in entropy (well, I fixed it...). What I am asking is quite simple though. Is this allowed? Should the previous slotmove be removed? Thanks, [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/updates/4Q-2013?view=log [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/updates/2Q-2013?r1=1.1&r2=1.2 -- Fabio Erculiani
Re: [gentoo-dev] Doing and then undoing slotmoves
On Wed, Dec 18, 2013 at 1:13 PM, "Paweł Hajdan, Jr." wrote: [ snip ] > > Finally, do we have a good way now to automate checks against this? The current PMS spec, as you quoted, allows one way moves only. For this reason, I guess that simulating the updates twice should result in no applicable updates on the second pass, unless a "circular dependency" is found. Assuming that the simulation step is more or less constant time (is it?), this could only take O(2n), O(n) normalized. I implemented something along these lines in entropy and it spotted the faulty slotmove lines. > > Paweł > -- Fabio Erculiani
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
On Mon, Jan 13, 2014 at 10:15 AM, "C. Bergström" wrote: > On 01/13/14 03:43 PM, Alexander Berntsen wrote: > Where I work uses pkgcore[1], but not the areas which are generally > beneficial to the whole community. (We use it as part of a web application > to handle testsuites which have build dependencies.) We can blah blah about > performance of resolving package dependencies all day long, > [...] Not sure about what you mean with "blah blah". But given the amount of both disk caches (metadata, vdb cache) and memory caches (the in-memory aux_db cache that portage loads using pickle (it's a dict) takes like 70-100Mb of RAM on an average desktop system), Portage can still take *minutes* to calculate the merge queue of a pkg with all its deps satisfied. Ironically, launching the same emerge command twice, will take more or less the same time. Yeah, this is probably bad design... -- Fabio Erculiani
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
On Mon, Jan 13, 2014 at 5:49 PM, Alec Warner wrote: [...] > > This is not meant to imply that portage is always fast; there are plenty of > other modules (such as the aforementioned backtracking) that can take a long > time to find solutions. That is partially why you see Tomwij turning off > that feature. It is helpful for users cause it can automatically find > solutions for users that are otherwise unsolvable (and thus avoids the user > having to find a solution to the depgraph manually.) Yeah, correct. But it would be nice if Portage backtrack_depgraph() would memoize (asynchronously serializing to disk, for instance) partial results for later use. AFAIR, last time I checked, it wasn't doing that. Also, it would be nice if the aux_db cache of the vdb could be stored in a sqlite3 db rather than in RAM. This dict is consuming a huge cut of memory for little reason (a single vdb.dbapi.match() can eat 100MB of RAM). We know how Python deals with freed memory... Sigh... > > -A > >> >> >> -- >> Luis Ressel >> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD > > -- Fabio Erculiani
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
configs should have never gotten into genkernel in the first place. it's each kernel pkg (or even version) that owns a valid config of itself. I am part of genkernel@ but I have no will nor time to fix it. And when I have, I'd rather work on genkernel-next, that comes with a much more readable initramfs code (that I managed to rewrite myself). Wiping the whole config files has been on my agenda for very long time already. On Fri, May 30, 2014 at 6:32 PM, Rich Freeman wrote: > On Fri, May 30, 2014 at 1:02 PM, Ben Kohler wrote: >> As nice at it sounds to just DROP these configs, that option is not really >> feasible considering the way we currently use genkernel in our handbook. >> Relying on the kernel's own defconfig, "genkernel all" will NOT produce the >> same mostly-usable-on-any-hardware result that we now rely on. > > Considering that the configs are more generically useful than > genkernel, having them separately maintained sort-of makes sense. > Then genkernel is a kernel build/install/initramfs tool, not a config > management tool. > > I'd stick them someplace where any dev can get to them, and separate > them from the genkernel functional code base. > > As far as who takes care of them goes - I suggest that this stuff > comes out of the devmanual unless somebody steps up to take care of > them. Those who take care of them become those who want to keep them > around. You can't toss out a tool and ask for it to be a > recommendation but point to others that you think need to maintain its > configuration. > > Rich > -- Fabio Erculiani
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On May 31, 2014 8:42 PM, "Robin H. Johnson" wrote: > > On Fri, May 30, 2014 at 06:10:40PM +0300, Samuli Suominen wrote: > > I can't find anyone with access that actually replies to mails, pings, > > ... to genkernel repository for: > > > > https://bugs.gentoo.org/show_bug.cgi?id=461828 > > > > I'll p.mask it on amd64 profiles if noone replies soon :( > My excuse is AFK baby, literally sleeping on me right now, and not even > 2 months old. > > I saw floppym's original comment opening the bug, but none of the > followups due to baby eating my life. > > I'll apply this patch later today if I have a chance, but I do agree > with the general sentiment of this thread that the kernel configs NEED > to get out of genkernel; so that arches can touch them at will, and > other initramfs/kernel build tools can start to use them. > > In the absence of any other prompt complaints, I'll create a > kernel-configs repo, and move the configs there. It would be better if those would be put in individual source pkgs in a way that they can be picked up by genkernel. Kernel config belongs to kernel pkgs, pretty much like init scripts or config files belong to their own project pkgs. > > The one thing that WILL have to be maintained in genkernel still, and > in-sync with kernel changes, are the modules_load files, esp when new > common stuff is added to the kernel (disk controllers & filesystems most > commonly). > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Infrastructure Lead > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 >
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, May 31, 2014 at 9:06 PM, Robin H. Johnson wrote: > No, I don't agree that kernel configs "belong" to kernel packages. In > general, barring the crazy option explosion, these are meant to be stock > working configs that should in combination with ANY kernel package, > produce a working kernel. > Then you are just moving the problem around. I believe that kernel configs should be provided by their own kernel packages (and there are some, not just gentoo-sources) because it is much easier to keep them in sync on every new release and deal with each version separately if/as needed (including testing!). How are you dealing with config var name changes between different kernel versions or just different pkgs then? You cannot possibly support all kernel versions for all kernel pkgs available in tree with just one single config file in a sane, clean and maintainable way, hoping that a change in this file will not affect previous or future kernel releases. How are you going to test your config changes against old kernel pkgs? Each test is quite expensive to run. Good luck with that :-) [...] > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Infrastructure Lead > E-Mail : robb...@gentoo.org > GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 > -- Fabio Erculiani
[gentoo-dev] Packages up for grabs
Due to permanent lack of time, I'm unable to properly maintain the packages below. Feel free to take them over. I'll remove myself from metadata.xml in 14 days. app-admin/389-admin-console app-admin/389-console app-admin/389-ds-console app-admin/aws-as-tools app-admin/aws-elb-tools app-admin/aws-iam-tools app-admin/aws-rds-tools app-emulation/edumips64 dev-java/idm-console-framework dev-libs/389-adminutil dev-libs/mozldap dev-libs/svrcore dev-perl/perl-mozldap net-nds/389-admin net-nds/389-ds-base net-libs/libgrss www-apache/mod_nss www-apps/389-dsgw x11-apps/ardesia x11-apps/spotlighter x11-apps/python-whiteboard x11-apps/whyteboard x11-drivers/cwiid -- Fabio Erculiani
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
If only libav and ffmpeg developers would stop breaking their API on every release... Just break it once and for all. It's so sad that I still can't upgrade from libav-9 because of this. Feature request: could you stop breaking the API for a couple of years? Thanks. If you say that you have to, well, I won't believe you.
Re: [gentoo-dev] Re: [gentoo-project] New developer: Fabio Erculiani (lxnay)
Thanks to everybody involved in the process and in building up good relationships firstly between Gentoo and Sabayon and secondly among their devs. I am looking forward to contribute to Gentoo KDE and Portage Projects with my knowledge and ideas. In particular, I am looking forward to merge the good part of Sabayon directly, back into Gentoo (where applicable), making it shining and rocking like in the early days (eheh). I hope to be able to rectify false rumours surrounding my name (they're funny btw) and have fun with everybody. I'm not here to conspirate or whatever, I'm here to fix bugs, communicate with other developers, and race with ssuominen and patrick. I will demonstrate my committment through commits, that's the best I could say. Thanks to Samuli, Patrick and Tomas for having convinced me to join. A special thank goes to Betelgeuse and his patience. Regards, -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Documentation
On Mon, Dec 28, 2009 at 3:43 AM, Richard Freeman wrote: > [..] > > Don't get me wrong - the QA team is doing a great job and I love Diego's > work on the tinderbox. I've had a bug or two filed by them, and I've found > that they've only been helpful when somebody actually bothers to try to > resolve them. > > Just to let you all know, we have two build servers since 2007 in where we compile Portage ~arch (x86, amd64) and produce binary packages through Entropy for Sabayon (http://sabayon.org/packages). In 2010 we plan, with some students from the University of Milano-Bicocca to add some static analysis bits into the workflow. Maybe, there are some commonalities between the two ideas (tinderbox vs what Sabayon is doing already). -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 8:24 PM, Samuli Suominen wrote: > [...snip...] Samuli I know, but actually Zac told me that as of now RDEPENDs are not considered that way. I knew that you were going to comment here (hence why I posted), maybe it's a good time to clear out our mind and eventually decide how to deal with those. Because most of the ebuilds don't seem to follow your logic. -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
I discussed this a few weeks ago with some devs on IRC and the general answer was, file bugs. I filed bugs. About the rest, I decline any comment. Have fun. -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 8:15 PM, Jeroen Roovers wrote: > On Mon, 28 Dec 2009 10:10:48 +0100 (CET) > lx...@gentoo.org wrote: > >> let's discuss concerns here (actually I don't see any and I am >> willing to fix all the ebuilds and close all my bugs if you ack). > > If they are genuine bugs, then there isn't anything to discuss. Thanks, I will also create a tracker bug next time. > >> List of Gentoo bugs: > > Tracker bug is #298759[1] > > > Regards, > jer > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=298759 > > > -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 9:06 PM, Rémi Cardona wrote: RESOLVED -> WONTFIX Others and myself have spent considerable time making those deps the way they are because : 1) upstream packaging is a bit uncommon 2) ebuild deps don't fit with upstream deps 3) a few embedded devs told me they wiped /usr/include when making images What all this has to do with the fact that they are just build dependencies? Just wondering. So if you want to fix this properly, a new DEP variable needs to be cooked up : "add the following deps to ebuilds' DEPEND when those ebuids DEPEND on this ebuild". Other package managers out there have explicit build dependency lists, so, if DEPEND is not really a list of build dependencies, yeah, I agree, we need a list describing "strict" build dependencies. Until such a variable exist, having the protos in both DEPEND and RDEPEND is the only _valid_ solution. Thanks Others here gave opposite opinion by the way. Rémi -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 9:51 PM, David Leverton wrote: > On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: >> What all this has to do with the fact that they are just build >> dependencies? Just wondering. > > They're not just build dependencies. They're required to use the library in a > certain way, namely to compile other programs against it. As long as we > don't have compile-against dependencies, the only correct way to express that > is RDEPEND (and also DEPEND because they're /also/ needed to build the > library itself). To me you are saying that DEPEND would work just fine. No? > > -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Sorry, some more bits here: AFAIK, Portage considers DEPEND when used as "source-based package manager" (and emerge --depclean stuff) while it ignores them when binpkgs come into play. So, (I ask Zac to correct me), putting x11-protos to DEPEND doesn't really change much for 99% of Portage users (those who are using it to *compile* pkgs). While it changes a lot for binary package managers, which hopefully don't consider DEPEND at all (at least this was the initial idea). The fact is, since Portage binary package management is really and unfortunately a "joke" as of today, the amount of people using it versus the amount of people not using it is really big (that's why I wrote a separate app). Thus, many ebuilds have broken RDEPEND/DEPEND and as you (all) have proven, there is not even a real "container" of build dependencies nor a clear idea among developers (my initial email wanted to bring devs to this exact point, it seems I did it). Moreover, the amount of legacy, undocumented, perhaps *workaroundish* solutions inside Portage codebase are not really helping in fixing this situation. I say, unfortunately, not to blame anybody. A lot of work is being done lately to try to improve it. -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 10:32 PM, Samuli Suominen wrote: On 12/28/2009 10:51 PM, David Leverton wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). That's what I've been trying to say (also with my example). That is, they are more than DEPENDs. How comes, this is the list of files owned by xproto: /usr/include/X11/extensions/dmxext.h /usr/include/X11/extensions/dmxproto.h /usr/share/doc/dmxproto-2.2.2/ChangeLog.bz2 /usr/lib64/pkgconfig/dmxproto.pc /usr/include/X11/DECkeysym.h /usr/include/X11/Xos.h /usr/include/X11/HPkeysym.h /usr/include/X11/Xosdefs.h /usr/include/X11/Xwinsock.h /usr/include/X11/Xos_r.h /usr/include/X11/Xalloca.h /usr/include/X11/Xatom.h /usr/include/X11/Xfuncproto.h /usr/include/X11/Sunkeysym.h /usr/include/X11/Xdefs.h /usr/include/X11/ap_keysym.h /usr/include/X11/Xarch.h /usr/include/X11/keysymdef.h /usr/include/X11/Xw32defs.h /usr/include/X11/Xprotostr.h /usr/include/X11/keysym.h /usr/include/X11/X.h /usr/include/X11/Xwindows.h /usr/include/X11/Xproto.h /usr/include/X11/XWDFile.h /usr/include/X11/Xthreads.h /usr/include/X11/Xpoll.h /usr/include/X11/Xmd.h /usr/include/X11/Xfuncs.h /usr/include/X11/XF86keysym.h /usr/share/doc/xproto-7.0.16/ChangeLog.bz2 /usr/lib64/pkgconfig/xproto.pc How can a bunch of .h and pkgconfig files *do* all that magic you are talking about? Thanks, You are more than welcome, Samuli -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
In any case, I think that this situation should be addressed, and perhaps a comment from PMS might help. Regards, -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 10:48 PM, Gokdeniz Karadag wrote: > > X preprocesses some files at each startup(using the C preprocessor(cpp) via > xrdb configuration tool) Strange but true. > > Macros defined by these .h files might be used during this configuration. That's the missing bit! Thanks for the answer. > > -- > Gokdeniz Karadag > > > -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Interesting, eventually somebody gave me a detailed and technical explanation without [bla bla snip]. Thanks Rémi. Yes, I agree with you that the best (and the one I would go for, too) solution is adding support to a new *DEPEND, perhaps one that could "host" build-deps only. It looks weird that other PMs out there do that since 1994 (replace 1994 with older value). Perhaps adding a big fat # XXX somewhere in ebuilds would have helped us all in saving some time today. So, at least for now, I suspect I have to give up and close my shiny 27 bugs. Right? -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
[gentoo-dev] [looking-for-man-power] Packaging RedHat/Fedora tools and libs
I'm in the process of porting (once again) a new Anaconda snapshot to Sabayon (thus, to Gentoo-land). I spent several hours creating ebuilds (basic, not fully integrated yet) for the following pkgs: app-admin/authconfig app-admin/firstboot app-admin/system-config-date app-admin/system-config-date app-admin/system-config-keyboard app-admin/system-config-users app-cdr/isomd5sum dev-python/pyblock dev-python/python-cryptsetup dev-python/python-meh dev-python/python-nss dev-python/python-report dev-util/pykickstart net-misc/dcbd net-misc/fcoe-utils sys-apps/hbaapi sys-block/open-iscsi (see extra patches) sys-libs/libuser They are available in the "sabayon" overlay. Is there anybody interested in helping me out for the integration and, perhaps, merge-into-Portage part? For the record, nowadays the Anaconda architecture is very clean and allows non-rpm distros to build custom installation profiles and backends quite easily. I'm really really impressed by the amazing work RedHat guys did during last years. Regards, -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] [looking-for-man-power] Packaging RedHat/Fedora tools and libs
On Fri, Apr 9, 2010 at 9:24 PM, Zac Medico wrote: > On 04/09/2010 04:34 AM, Fabio Erculiani wrote: >> They are available in the "sabayon" overlay. Is there anybody >> interested in helping me out for the integration and, perhaps, >> merge-into-Portage part? > > That sounds interesting. I was planning to add public apis for the > packagekit portage backend to use soon, and I guess those apis > should also be useful for an anaconda portage backend. [semi-OT] Since I am (together with volkmar) one of the PK Portage backend maintainers, let me know once you have interesting APIs implemented for that. The backend itself would also require testing and some profiling sessions to spot annoying speed issues. [/semi-OT] > -- > Thanks, > Zac > > -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
