[gentoo-dev] Re: RFC: remove ldap from desktop profiles use flags
On Sun, 6 May 2012 15:25:02 +0100 Ciaran McCreesh wrote: > On Sun, 6 May 2012 07:33:59 -0400 > Rich Freeman wrote: > > Some other questionable ones: > > emboss - Adds support for the European Molecular Biology Open > > We've had this discussion before... The question is not "are people > likely to want emboss?". The question is "of people who use packages > that have an emboss use flag, are those people likely to want emboss?". The question is "why aren't those packages using IUSE="+emboss" instead of cluttering up the profiles with obscure USE flags?". -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Recruitment process is moving back to quizzes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/15/2012 06:15 AM, Ben de Groot wrote: > On 15 July 2012 04:46, Peter Stuge wrote: >> Markos Chandras wrote: >>> understand that quizzes is not an ideal way to "hire" people >>> either, but they worked ok for all these years >> >> I don't know.. Subjectively I don't think they work ok at all, >> since I still haven't finished them even after many years. > > I agree that they don't work "ok" -- it only seems that way because > people are still joining us. > > The first time I did the quizzes, it took me 9 months. After having > been away for a couple of years, I recently returned as Gentoo dev, > and the second time I did the quizzes it took me 3 months. I've > seen others take a long time doing them as well. Davide (pesa), one > of our most valued contributors in the Qt team, took close to two > years I think. > > I think this way we lose much valuable developer time. These > people could have had commit access and done much valuable work so > much earlier, if there wasn't this obstacle of the quizzes... > > We should think about what kind of people we want to attract as > future Gentoo contributors, and what are the best ways of > introducing them to the tasks they would need to perform, and the > knowledge they would need to have. > > I'm happy to see that some effort was made, and we now know that > the web app is not working. What other ways can we think of that > might improve the recruitment process? > >> But it's totally possible that they actually *do* work ok, and >> that I really absolutely *must* know everything they ask about >> before starting recruitment. Not sure. > > The topics touched in the quizzes are things that a Gentoo > developer should know. I just don't think the way they work is > conducive to a good learning experience for most people. > >>> and it is the only alternative we have at the moment. >> >> Thinking outside of the quiz^Wbox and getting to know people is a >> good alternative. It takes time too of course, but no quiz or web >> app can replace it. > > What I noticed in my own experience as lead of our Qt team, is > that getting people started on the real work, being part of the > developer community and process, is a good way to introduce them > to how we do things in Gentoo. The Qt team has its official > overlay, and it is easy for us to give new contributors access to > it. That way they can learn to write ebuilds and eclasses, and how > to improve them, commit them, and get used to a good workflow. > Hanging out in the IRC channel and taking part in discussions is > an invaluable part of this as well. > > I'm sure a lot of mentors do things in similar ways. And maybe > others have things to add to this. > > We could have a portal page (e.g. on the wiki) with links to all > the relevant documentation for new developers (dev handbook, > devmanual, foundation info, gleps, etc) that they should have > knowledge of. Then recruits can read these while they are doing > work with their mentor, in an overlay (either an official team > overlay, or betagarden). > > We could also develop a collection of tasks that a mentor can > choose from to give their recruits to do. Hopefully this way we > can train people in a more organic way. > > Then when the mentor deems a recruit ready, they could have an > interview with one of the recruiters, and get commit access to the > official tree as usual. > > Anyway, these are some of my ideas. What do you think? > Hi, Thank you for the feedback. Let me clarify a few bits though. In my opinion, the quizzes contain all the knowledge that is required for someone to start developing for Gentoo. Yes, maybe it requires too much knowledge but this is because we are not sure that the mentors have done their work properly so we don't have to go over the same steps again during the recruitment process. Like you said, working in an overlay is a very important part of the process but I don't think every mentor out there does that for his recruits. So we can't rely on that. On the other hand, after having some experience as recruiter, and looking at the status of each recruit when I pick them up, I can say which mentors are doing their work properly and who don't. But this would require constant mentor evaluation which adds an extra overhead in the process. Also the recruitment team is (as always) understaffed, meaning it is highly unlikely for us to spend energy and time to come up with a new recruitment process whilst trying to keep the recruitment queue short. However, I can counter-propose the following: 1) Have a chat with the mentor. Find out what he did with his recruit, and maybe we can be more relaxed during the quiz review process if the recruit has enough experience to join the developer community. The recruiter could side-step part of the quizzes and ask different questions based on recruits background and interests. This however, would still requir
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Saturday 14 of July 2012 10:32:04 Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Gentoo Community, > > If you are not a recruit, mentor, or wannabe mentor you may stop > reading now. > > We (recruiters) decided to revert back to the quizzes for the > recruitment process. The web application does not work as we expected. > There are a few open bugs, nobody is working on improving this > application and it's been quite a bit of pain to use it during the > (long) recruitment process. We understand that quizzes is not an ideal > way to "hire" people either, but they worked ok for all these years > and it is the only alternative we have at the moment. Hopefully, we > will manage to improve the web application on a future GSOC project. > > If you have already submitted your answers on the web application, > that is fine. However, I would strongly advise future recruits to > complete the quizzes instead. If you don't, we will ask you to do so > when we pick you up. Obviously, this will lead to extra delay and > frustration. > > This does not apply to Arch Testers. The recruitment process for Arch > Testers will still be through the web application Hello, for the past two years I am constantly mentoring two-three people at the same time at least. Here is my feedback about the webapp: 1) It needs many UI improvements. But every thing that needs improvement (along with possible solutions) is already reported in bugzilla 2) Despite its UI being not good, the webapp has proven a way better medium for mentor-mentee communication. With the quizes as text files I had to deal with random text files spread around (and try to find the most recent one), with discussion being split in IRC, various mails etc. Now with the webapp I can easily leave my comment there (which is better as there is more async communication now), I have consistent history of our discussion, and I have all the answers of all my mentees in one page, which is awesome because I can compare answers and say quickly to my mentee what he forgot to write down. With that being said, I am proposing the following: 1) I'll announce a call for volunteers, we really need a web designer on the project. 2) Please keep the questions in sync between the text quizes and the webapp. I'll continue to use the webapp to communicate with my mentees (as it is doing more good than harm), and will write a script to extract the answers in the text files so you can be happy as well. Theo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Recruitment process is moving back to quizzes
(Please consider quoting only what is relevant. Thanks!) Markos Chandras wrote: > In my opinion, the quizzes contain all the knowledge that is > required for someone to start developing for Gentoo. Yes, maybe > it requires too much knowledge So which is it? "All that is required" or "too much?" Also, what exactly do you refer to by "Gentoo?" The distribution or the foundation? I've been managing my own overlay and a few private ones for a few years now, all while using catalyst to build more or less customized Linux systems for me and for others. I dive into bugzilla when a bug bites, and I'll usually generate a patch. Am I actually developing for Gentoo Linux already? //Peter
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny wrote:
> On Sat, 14 Jul 2012 12:29:59 +0200
> Davide Pesavento wrote:
>
>> On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
>> wrote:
>> > On Fri, 13 Jul 2012 15:26:58 +0200
>> > Davide Pesavento wrote:
>> >
>> >> > [...]
>> >> >> + # backward compatibility for non-array variables
>> >> >> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS 2>/dev/null
>> >> >> 2>&1)" != "declare -a"* ]]; then
>> >> >> + dodoc ${DOCS} || die "dodoc failed"
>> >> >> + fi
>> >> >> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p HTML_DOCS
>> >> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
>> >> >> + dohtml -r ${HTML_DOCS} || die "dohtml failed"
>> >> >> + fi
>> >> >> }
>> >> >
>> >> > maybe issue an eqawarn in that case telling people to convert to
>> >> > arrays; some time later make this an ewarn telling non-array
>> >> > support will be removed and again later make this a die :)
>> >> > (if you take that route i would expect you to start converting
>> >> > packages to use arrays)
>> >> >
>> >>
>> >> We have no intention of deprecating non-array variables in qt4-r2
>> >> eclass.
>> >
>> > why ? having two codepaths for the same thing, one being inferior,
>> > sounds like a good reason to deprecate the inferior one :)
>> >
>> > A.
>> >
>>
>> Maintaining these two codepaths has practically zero cost, while
>> forcing every ebuild using qt4-r2 to switch to arrays would waste
>> developers' time which is better spent elsewhere.
>>
>> Furthermore, the non-array variant is not necessarily inferior,
>> because it allows you to use bash globbing, brace expansion, etc...
>
> And arrays stopped to allow that overnight?
>
I mean that the following won't work as you might expect:
DOCS=("*.txt")
Thanks,
Pesa
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Sun, 15 Jul 2012 13:15:26 +0800 Ben de Groot wrote: > The first time I did the quizzes, it took me 9 months. After having > been away for a couple of years, I recently returned as Gentoo > dev, and the second time I did the quizzes it took me 3 months. > I've seen others take a long time doing them as well. Davide (pesa), > one of our most valued contributors in the Qt team, took close > to two years I think. If it's taking you that long, you're doing something wrong... The quizzes are pretty easy, and only test the bare minimum of what you should know. They shouldn't take you more than a couple of hours. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: udev <-> mdev
On Sat, Jul 14, 2012 at 9:02 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted: >> >> I doubt anybody has tried it, so you'll have to experiment. > > "Anybody" /anybody/, or "anybody" on gentoo? FWIW, there are people > running it in general (IIRC much of the discussion was on Debian, some on > Fedora/RH), but I didn't see anything out there written from a gentoo > perspective. I'd think that a source vs binary distro wouldn't matter much as far as a tmpfs-based root goes. That is, if you're taking about an empty root that you just mount stuff on top of. >> I imagine you could do it with a dracut module. There is already a >> module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is >> that you need to create the root filesystem and the mountpoints within >> it first. The trick will be how dracut handles not specifying a root >> filesystem. > > While I do know dracut is an initr* helper, you just made me quite aware > of just how much research I'd have to do on the topic. =:^\ I wasn't > aware dracut even /had/ modules, while you're referring to them with the > ease of familiarity... See: http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ Much of dracut's power comes from its modules. Again, I'm not sure how it handles not being given a root at all. You'd have to build a root, or extract it from a tarball/etc. Looking at the docs it seems like you'd need a hook for the cmdline stage that sets rootok (assuming it gets that far without a root, or if you set it to something like root=TMPFS). Then you'd install a hook to mount to mount the tmpfs, and then use the fstab-sys module to mount everything else. You'd need to create mountpoints for everything of course, and not just the boot-critical stuff, since otherwise openrc won't be able to finish mounting mounting everything. > > The big problem with btrfs subvolumes from my perspective is that they're > still all on a single primary filesystem, and if that filesystem develops > problems... all your eggs/data are in one big basket, good luck if the > bottom drops out of it! Maybe, but does it really buy you much if you only lose /lib, and not /usr? I guess it is less data to restore from backup, but... The beauty of btrfs subvolumes is that it lets you manage all your storage as a single pool, even more flexibly than LVM. Sure, chopping it up does reduce the impact of failure a bit, but I'd hate to have to maintain such a system. Filesystem failure should be a very rare occurance for any decent filesystem (of course, this is why I won't be using btrfs in production for a while). Rich
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Sun, Jul 15, 2012 at 6:11 AM, Peter Stuge wrote: > I've been managing my own overlay and a few private ones for a few > years now, all while using catalyst to build more or less customized > Linux systems for me and for others. > > I dive into bugzilla when a bug bites, and I'll usually generate a > patch. > > Am I actually developing for Gentoo Linux already? I think most would say yes - you just don't have official recognition, or commit access. I think that this would be a benefit of moving to git - anything which reduces the need to have commit access but do useful work is a good thing in my mind. Tools like gerrit and github will also facilitate this. That said, none of this will eliminate the need to have more people merging commits. Right now our model is that the dev who merges the patch is the one to blame when things go wrong. While that works better than a "merge whatever you want - blame the contributor" model, there does need to be some balance. There are tons of patches in bugzilla for stuff that isn't well-maintained, and perhaps a little more freedom to improve packages without having to take full responsibility for them would be a good thing. The all-or-nothing model too often turns out to be nothing. Rich
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Sun, Jul 15, 2012 at 7:56 AM, Ciaran McCreesh wrote: > On Sun, 15 Jul 2012 13:15:26 +0800 > Ben de Groot wrote: >> The first time I did the quizzes, it took me 9 months. After having >> been away for a couple of years, I recently returned as Gentoo >> dev, and the second time I did the quizzes it took me 3 months. >> I've seen others take a long time doing them as well. Davide (pesa), >> one of our most valued contributors in the Qt team, took close >> to two years I think. > > If it's taking you that long, you're doing something wrong... The > quizzes are pretty easy, and only test the bare minimum of what you > should know. They shouldn't take you more than a couple of hours. I'd be interested in why it was taking so long as well. I took the quizzes first when becoming an AT, and later when becoming a dev. The level of rigor was much higher of course when becoming a dev - which was appropriate. I did struggle because policies were not always spelled out, so many of the questions took interaction with my mentor to resolve. Sometimes the indirectness of some of the questions was frustrating, but it didn't take more than maybe 8 hours in total with revisions/etc. I'd give it my best shot, my mentor would review and offer hints/suggestions, and we'd iterate. I learned quite a bit in the process. Random thought here - it probably wouldn't hurt to have some kind of ebuild tutorial that works through a few examples to explain how ebuilds work, and demonstrate good technique. That could be useful not just for developer candidates, but for the community in general. Our ebuild docs aren't bad at all actually, but they're mainly in the form of reference now, and something that was more oriented to teaching might be useful. Maybe we need something that starts with "hello world" and goes from there... Rich
Re: [gentoo-dev] Re: RFC: remove ldap from desktop profiles use flags
On Sun, Jul 15, 2012 at 3:59 AM, Ryan Hill wrote: > On Sun, 6 May 2012 15:25:02 +0100 > Ciaran McCreesh wrote: > >> On Sun, 6 May 2012 07:33:59 -0400 >> Rich Freeman wrote: >> > Some other questionable ones: >> > emboss - Adds support for the European Molecular Biology Open >> >> We've had this discussion before... The question is not "are people >> likely to want emboss?". The question is "of people who use packages >> that have an emboss use flag, are those people likely to want emboss?". > > The question is "why aren't those packages using IUSE="+emboss" instead of > cluttering up the profiles with obscure USE flags?". Agreed, IF anybody using that package is likely to want that flag on any profile. Package defaults are good for the case when anybody using that package on any profile is likely to want that flag. Profile defaults are good for the case when anybody using that profile is across-the-board likely to want or not want that flag. In the case of emboss setting it (or not) at the package level would seem to make sense. I can't see how having support for some particular scientific application suite is going to vary depending on whether the package is installed on a desktop vs server, or with hardened vs non-hardened. I could see overriding it on hardened making sense if it didn't build on that profile. Rich
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Sun, 15 Jul 2012 13:00:47 +0200
Davide Pesavento wrote:
> On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny
> wrote:
> > On Sat, 14 Jul 2012 12:29:59 +0200
> > Davide Pesavento wrote:
> >
> >> On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
> >> wrote:
> >> > On Fri, 13 Jul 2012 15:26:58 +0200
> >> > Davide Pesavento wrote:
> >> >
> >> >> > [...]
> >> >> >> + # backward compatibility for non-array variables
> >> >> >> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS
> >> >> >> 2>/dev/null
> >> >> >> 2>&1)" != "declare -a"* ]]; then
> >> >> >> + dodoc ${DOCS} || die "dodoc failed"
> >> >> >> + fi
> >> >> >> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p HTML_DOCS
> >> >> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
> >> >> >> + dohtml -r ${HTML_DOCS} || die "dohtml failed"
> >> >> >> + fi
> >> >> >> }
> >> >> >
> >> >> > maybe issue an eqawarn in that case telling people to convert
> >> >> > to arrays; some time later make this an ewarn telling
> >> >> > non-array support will be removed and again later make this a
> >> >> > die :) (if you take that route i would expect you to start
> >> >> > converting packages to use arrays)
> >> >> >
> >> >>
> >> >> We have no intention of deprecating non-array variables in
> >> >> qt4-r2 eclass.
> >> >
> >> > why ? having two codepaths for the same thing, one being
> >> > inferior, sounds like a good reason to deprecate the inferior
> >> > one :)
> >> >
> >> > A.
> >> >
> >>
> >> Maintaining these two codepaths has practically zero cost, while
> >> forcing every ebuild using qt4-r2 to switch to arrays would waste
> >> developers' time which is better spent elsewhere.
> >>
> >> Furthermore, the non-array variant is not necessarily inferior,
> >> because it allows you to use bash globbing, brace expansion, etc...
> >
> > And arrays stopped to allow that overnight?
> >
>
> I mean that the following won't work as you might expect:
>
> DOCS=("*.txt")
I doubt anyone would expect quoted string to be evaluated as glob.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On 15 July 2012 21:27, Rich Freeman wrote: > On Sun, Jul 15, 2012 at 7:56 AM, Ciaran McCreesh > wrote: >> On Sun, 15 Jul 2012 13:15:26 +0800 >> Ben de Groot wrote: >>> The first time I did the quizzes, it took me 9 months. After having >>> been away for a couple of years, I recently returned as Gentoo >>> dev, and the second time I did the quizzes it took me 3 months. >>> I've seen others take a long time doing them as well. Davide (pesa), >>> one of our most valued contributors in the Qt team, took close >>> to two years I think. >> >> If it's taking you that long, you're doing something wrong... The >> quizzes are pretty easy, and only test the bare minimum of what you >> should know. They shouldn't take you more than a couple of hours. > > I'd be interested in why it was taking so long as well. I took the > quizzes first when becoming an AT, and later when becoming a dev. The > level of rigor was much higher of course when becoming a dev - which > was appropriate. I did struggle because policies were not always > spelled out, so many of the questions took interaction with my mentor > to resolve. Sometimes the indirectness of some of the questions was > frustrating, but it didn't take more than maybe 8 hours in total with > revisions/etc. It's not that it takes all that much time. It can be done in say one or two workdays. But you need to set aside a block of time (and usually two, one for each of the quizzes, or more if you need to break it up or iterate over it after feedback) in which you can be relatively distraction-free and well concentrated. You need to make sure to check the documentation to find the wanted answers, and word your answers carefully to be precise and cover all angles. Since it is a low-urgency and low-fun task, most of us will end up doing other things on our to-do list, or simply being distracted. It then gets postponed again and again and again. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Sun, 15 Jul 2012 21:45:25 +0800 Ben de Groot wrote: > It's not that it takes all that much time. It can be done in say one > or two workdays. But you need to set aside a block of time (and > usually two, one for each of the quizzes, or more if you need to > break it up or iterate over it after feedback) in which you can be > relatively distraction-free and well concentrated. You need to make > sure to check the documentation to find the wanted answers, and word > your answers carefully to be precise and cover all angles. ...and you don't need to be able to put in that level of attention every now and again when you're a developer? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Recruitment process is moving back to quizzes
Ciaran McCreesh wrote: > > you need to set aside a block of time (and usually two > > ...and you don't need to be able to put in that level of attention > every now and again when you're a developer? Not the same amount of meta time, no. I agree with the estimate of about two days for the quizzes. This might not seem much, but I think that the idiots that the quizzes are designed to keep out can spend two (or four/eight if they need) days to pass anyway with a little dedication, while less idiotic idiots such as perhaps myself need years because we're doing whatever work as opposed to learning foundation bylaws by heart. I am exaggerating on purpose but maybe you get the point. Really good recruitment basically has a different process for every recruit. That obviously does not scale. //Peter pgp44UydcPYlJ.pgp Description: PGP signature
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On 15 July 2012 21:50, Ciaran McCreesh wrote: > On Sun, 15 Jul 2012 21:45:25 +0800 > Ben de Groot wrote: >> It's not that it takes all that much time. It can be done in say one >> or two workdays. But you need to set aside a block of time (and >> usually two, one for each of the quizzes, or more if you need to >> break it up or iterate over it after feedback) in which you can be >> relatively distraction-free and well concentrated. You need to make >> sure to check the documentation to find the wanted answers, and word >> your answers carefully to be precise and cover all angles. > > ...and you don't need to be able to put in that level of attention > every now and again when you're a developer? Certainly. But it is likely much more interesting work and has considerably more impact. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Last rites: net-misc/ssh-installkeys
# Michael Palimaka (15 Jul 2012) # Bundles dev-python/pexpect (bug #315843) # Replaced by ssh-copy-id from net-misc/openssh. # Removal in 30 days. net-misc/ssh-installkeys
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Sun, Jul 15, 2012 at 10:32 AM, Peter Stuge wrote: > less idiotic > idiots such as perhaps myself need years because we're doing > whatever work as opposed to learning foundation bylaws by heart. Well, I don't think the bylaws are a terribly important topic for the quizzes, and unless something has changed I don't think they were a topic in the past. Sure, developers should understand the role of the council and the trustees, but that doesn't mean that they need to be qualified to BE a trustee. However, I think that it is important to include a fair bit of "meta" in the quizzes. In fact, I'd consider this almost more important than the technical content. A developer who doesn't understand some nuance of ebuild development, and recognizes this, and therefore acts with maturity in asking for help and review before doing commits isn't much of a danger to the distro. A developer who is a technical wizard and creates bots that do massive tree-wide commits to correct some perceived problem without gaining consensus from the community is a danger to the distro, even if most of the time they are completely right. I think it is more important that a developer be able to work with others and recognize their own limitations, than to worry about what those limitations are exactly. When I look at most of the issues impacting Gentoo over the years, rarely are they caused by some bug in an ebuild. They happen, and they get fixed, and usually the impact is very minor. What really causes havoc around here is when people change ebuilds without consulting with the maintainer, or when they go tweaking system packages without a great deal of care and being part of the appropriate team, and so on. Lack of respect on mailing lists has caused no small number of problems either. Many of these issues have dwindled in recent years, and I think it is precisely because teams like the recruiters have been paying more careful attention to them. Anybody can write good code. You don't need to be a Gentoo developer to do that, and if somebody lacks maturity and social skills they're probably better off doing their work on the side with a proxy maintainer pulling it in. Calchan had both, and he still ended up being more successful with OpenRC from the outside. The KDE team has in the past made use of bleeding-edge portage (or even non-portage) features in overlays for development purposes, driving PM development in the distro to yield an improved result when everything got merged back in. The bottom line is that you don't need commit access to do great things with and for Gentoo. What the Gentoo devs really need to be about is making all that great code work nicely together. That requires coordination and an eye to quality. That requires working well with those who differ in opinion. That said, I don't want to diminish the importance of technical skills too much. I think Gentoo has created some really good infrastructure that rivals what has been done with much larger distros. Rich
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Sun, Jul 15, 2012 at 3:42 PM, Michał Górny wrote:
> On Sun, 15 Jul 2012 13:00:47 +0200
> Davide Pesavento wrote:
>
>> On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny
>> wrote:
>> > On Sat, 14 Jul 2012 12:29:59 +0200
>> > Davide Pesavento wrote:
>> >
>> >> On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
>> >> wrote:
>> >> > On Fri, 13 Jul 2012 15:26:58 +0200
>> >> > Davide Pesavento wrote:
>> >> >
>> >> >> > [...]
>> >> >> >> + # backward compatibility for non-array variables
>> >> >> >> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS
>> >> >> >> 2>/dev/null
>> >> >> >> 2>&1)" != "declare -a"* ]]; then
>> >> >> >> + dodoc ${DOCS} || die "dodoc failed"
>> >> >> >> + fi
>> >> >> >> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p HTML_DOCS
>> >> >> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
>> >> >> >> + dohtml -r ${HTML_DOCS} || die "dohtml failed"
>> >> >> >> + fi
>> >> >> >> }
>> >> >> >
>> >> >> > maybe issue an eqawarn in that case telling people to convert
>> >> >> > to arrays; some time later make this an ewarn telling
>> >> >> > non-array support will be removed and again later make this a
>> >> >> > die :) (if you take that route i would expect you to start
>> >> >> > converting packages to use arrays)
>> >> >> >
>> >> >>
>> >> >> We have no intention of deprecating non-array variables in
>> >> >> qt4-r2 eclass.
>> >> >
>> >> > why ? having two codepaths for the same thing, one being
>> >> > inferior, sounds like a good reason to deprecate the inferior
>> >> > one :)
>> >> >
>> >> > A.
>> >> >
>> >>
>> >> Maintaining these two codepaths has practically zero cost, while
>> >> forcing every ebuild using qt4-r2 to switch to arrays would waste
>> >> developers' time which is better spent elsewhere.
>> >>
>> >> Furthermore, the non-array variant is not necessarily inferior,
>> >> because it allows you to use bash globbing, brace expansion, etc...
>> >
>> > And arrays stopped to allow that overnight?
>> >
>>
>> I mean that the following won't work as you might expect:
>>
>> DOCS=("*.txt")
>
> I doubt anyone would expect quoted string to be evaluated as glob.
>
It depends on when the expansion is performed, although in the
base.eclass case, DOCS=(*.txt) doesn't work either, because the
quoting happens inside the eclass function.
Anyway, I was just explaining why I argued that "the non-array variant
is not necessarily inferior". Using DOCS="*.txt" is actually a
supported use case and a valid reason not to deprecate non-array
variables.
Regards,
Pesa
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Sun, 15 Jul 2012 17:36:05 +0200
Davide Pesavento wrote:
> On Sun, Jul 15, 2012 at 3:42 PM, Michał Górny
> wrote:
> > On Sun, 15 Jul 2012 13:00:47 +0200
> > Davide Pesavento wrote:
> >
> >> On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny
> >> wrote:
> >> > On Sat, 14 Jul 2012 12:29:59 +0200
> >> > Davide Pesavento wrote:
> >> >
> >> >> On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
> >> >> wrote:
> >> >> > On Fri, 13 Jul 2012 15:26:58 +0200
> >> >> > Davide Pesavento wrote:
> >> >> >
> >> >> >> > [...]
> >> >> >> >> + # backward compatibility for non-array variables
> >> >> >> >> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS
> >> >> >> >> 2>/dev/null
> >> >> >> >> 2>&1)" != "declare -a"* ]]; then
> >> >> >> >> + dodoc ${DOCS} || die "dodoc failed"
> >> >> >> >> + fi
> >> >> >> >> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p
> >> >> >> >> HTML_DOCS
> >> >> >> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
> >> >> >> >> + dohtml -r ${HTML_DOCS} || die "dohtml
> >> >> >> >> failed"
> >> >> >> >> + fi
> >> >> >> >> }
> >> >> >> >
> >> >> >> > maybe issue an eqawarn in that case telling people to
> >> >> >> > convert to arrays; some time later make this an ewarn
> >> >> >> > telling non-array support will be removed and again later
> >> >> >> > make this a die :) (if you take that route i would expect
> >> >> >> > you to start converting packages to use arrays)
> >> >> >> >
> >> >> >>
> >> >> >> We have no intention of deprecating non-array variables in
> >> >> >> qt4-r2 eclass.
> >> >> >
> >> >> > why ? having two codepaths for the same thing, one being
> >> >> > inferior, sounds like a good reason to deprecate the inferior
> >> >> > one :)
> >> >> >
> >> >> > A.
> >> >> >
> >> >>
> >> >> Maintaining these two codepaths has practically zero cost, while
> >> >> forcing every ebuild using qt4-r2 to switch to arrays would
> >> >> waste developers' time which is better spent elsewhere.
> >> >>
> >> >> Furthermore, the non-array variant is not necessarily inferior,
> >> >> because it allows you to use bash globbing, brace expansion,
> >> >> etc...
> >> >
> >> > And arrays stopped to allow that overnight?
> >> >
> >>
> >> I mean that the following won't work as you might expect:
> >>
> >> DOCS=("*.txt")
> >
> > I doubt anyone would expect quoted string to be evaluated as glob.
> >
>
> It depends on when the expansion is performed, although in the
> base.eclass case, DOCS=(*.txt) doesn't work either, because the
> quoting happens inside the eclass function.
>
> Anyway, I was just explaining why I argued that "the non-array variant
> is not necessarily inferior". Using DOCS="*.txt" is actually a
> supported use case and a valid reason not to deprecate non-array
> variables.
So, you're saying that you're going to support two different variants
of the variable which work two different ways?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: using array variables in qt4-r2.eclass
On Sun, Jul 15, 2012 at 5:53 PM, Michał Górny wrote:
> On Sun, 15 Jul 2012 17:36:05 +0200
> Davide Pesavento wrote:
>
>> On Sun, Jul 15, 2012 at 3:42 PM, Michał Górny
>> wrote:
>> > On Sun, 15 Jul 2012 13:00:47 +0200
>> > Davide Pesavento wrote:
>> >
>> >> On Sat, Jul 14, 2012 at 4:00 PM, Michał Górny
>> >> wrote:
>> >> > On Sat, 14 Jul 2012 12:29:59 +0200
>> >> > Davide Pesavento wrote:
>> >> >
>> >> >> On Fri, Jul 13, 2012 at 3:50 PM, Alexis Ballier
>> >> >> wrote:
>> >> >> > On Fri, 13 Jul 2012 15:26:58 +0200
>> >> >> > Davide Pesavento wrote:
>> >> >> >
>> >> >> >> > [...]
>> >> >> >> >> + # backward compatibility for non-array variables
>> >> >> >> >> + if [[ -n ${DOCS} ]] && [[ "$(declare -p DOCS
>> >> >> >> >> 2>/dev/null
>> >> >> >> >> 2>&1)" != "declare -a"* ]]; then
>> >> >> >> >> + dodoc ${DOCS} || die "dodoc failed"
>> >> >> >> >> + fi
>> >> >> >> >> + if [[ -n ${HTML_DOCS} ]] && [[ "$(declare -p
>> >> >> >> >> HTML_DOCS
>> >> >> >> >> 2>/dev/null 2>&1)" != "declare -a"* ]]; then
>> >> >> >> >> + dohtml -r ${HTML_DOCS} || die "dohtml
>> >> >> >> >> failed"
>> >> >> >> >> + fi
>> >> >> >> >> }
>> >> >> >> >
>> >> >> >> > maybe issue an eqawarn in that case telling people to
>> >> >> >> > convert to arrays; some time later make this an ewarn
>> >> >> >> > telling non-array support will be removed and again later
>> >> >> >> > make this a die :) (if you take that route i would expect
>> >> >> >> > you to start converting packages to use arrays)
>> >> >> >> >
>> >> >> >>
>> >> >> >> We have no intention of deprecating non-array variables in
>> >> >> >> qt4-r2 eclass.
>> >> >> >
>> >> >> > why ? having two codepaths for the same thing, one being
>> >> >> > inferior, sounds like a good reason to deprecate the inferior
>> >> >> > one :)
>> >> >> >
>> >> >> > A.
>> >> >> >
>> >> >>
>> >> >> Maintaining these two codepaths has practically zero cost, while
>> >> >> forcing every ebuild using qt4-r2 to switch to arrays would
>> >> >> waste developers' time which is better spent elsewhere.
>> >> >>
>> >> >> Furthermore, the non-array variant is not necessarily inferior,
>> >> >> because it allows you to use bash globbing, brace expansion,
>> >> >> etc...
>> >> >
>> >> > And arrays stopped to allow that overnight?
>> >> >
>> >>
>> >> I mean that the following won't work as you might expect:
>> >>
>> >> DOCS=("*.txt")
>> >
>> > I doubt anyone would expect quoted string to be evaluated as glob.
>> >
>>
>> It depends on when the expansion is performed, although in the
>> base.eclass case, DOCS=(*.txt) doesn't work either, because the
>> quoting happens inside the eclass function.
>>
>> Anyway, I was just explaining why I argued that "the non-array variant
>> is not necessarily inferior". Using DOCS="*.txt" is actually a
>> supported use case and a valid reason not to deprecate non-array
>> variables.
>
> So, you're saying that you're going to support two different variants
> of the variable which work two different ways?
>
Basically yes. As yngwin said, we're introducing support for array
variables to be more in line with other eclasses. People do expect
DOCS to be an array variable, and I've already been asked a few times
for this kind of support.
Thanks,
Pesa
Re: [gentoo-dev] Recruitment process is moving back to quizzes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/15/2012 11:11 AM, Peter Stuge wrote: > (Please consider quoting only what is relevant. Thanks!) > > Markos Chandras wrote: >> In my opinion, the quizzes contain all the knowledge that is >> required for someone to start developing for Gentoo. Yes, maybe >> it requires too much knowledge > > So which is it? "All that is required" or "too much?" > These are two different things. The required knowledge is "a lot" of knowledge. Don't forget you will most likely be responsible for thousands of systems out there. > > Also, what exactly do you refer to by "Gentoo?" The distribution or > the foundation? As a whole, including official and unofficial projects/repositories. > > Am I actually developing for Gentoo Linux already? You do. But how can we know if your ebuilds are ok or not? A mentor has to review them first. Do we trust mentors that much? That is a different question I believe. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJQAvx9AAoJEPqDWhW0r/LCcRcP/1oGE1kHF7+YVaAYztsSx0hm flubFKrYvJ3zO0ihCwEseHBqk0be9whUddXXuh1YRV51+mGYREU/V7Eujasw6y+n F0b0o+Z65CmXdBrOpIFsP5O1+yZrNGF3k5upJz9T8XLexJDlKjH1fHNwQq2MOGRm wVGFSMnGc32zpzrwQPS/lDRG0p76zhDPUNrfNq3D5GXw5MxBjD0uo+XpjK/48IfE +ZrdHYebGxUpuoLnkem9Sb4vN1L02MC7Pb5PUC3m5BDgV2DjbvTuCNhyepNgnrwh iiVvn/PCJZm17IzxEVsfU50drovd+ywgyh99ONnFBs0U6IwPgMoHXYarbagZsq8L 04AAD/yfq5sdo6xhlw4yOGY0P0IiNIz624+xNi+CWxN0kGiR2DvTCVl0SSNY0xXo x2I/QXeoT75r6aBf10yOFkQI8j40u81wVHE+aQM3Nfdtb6mbSaHDS5q40T+jy35o VVZ+piJylfHu6VxB/r4ZCAuMrrsSrCGUbpM0bGeYdBWwQqnbgy7wn+nfpnPWvIux zjwNeQpo6YCeNtuNMt2mpXjyiT3Hrx2u52gPfbP/YNEdv1MjsyEx5F31NhuRATnT /PHJ4m7C5OYlOrXyjyfA94fMIrgCIX0B0zcu6kgdw37csYc4g6qEotDYF2HnQK6F iNwJGwmh2kO3ibFiufxy =SQLo -END PGP SIGNATURE-
Re: [gentoo-dev] Recruitment process is moving back to quizzes
On Sun, Jul 15, 2012 at 9:08 AM, Ben de Groot wrote: > Certainly. But it is likely much more interesting work and has > considerably more impact. The mentoring period and the review have considerable impact too. Whether you think one is more important than the other depends on you thinking short or long term. The quizzes are no more than a tool, and us arguing over them shows we're focusing on the wrong things. Denis.
[gentoo-dev] Re: udev <-> mdev
Rich Freeman posted on Sun, 15 Jul 2012 08:30:31 -0400 as excerpted: > Looking at the docs it seems like you'd need a hook for the cmdline > stage that sets rootok (assuming it gets that far without a root, or if > you set it to something like root=TMPFS). Then you'd install a hook to > mount to mount the tmpfs, and then use the fstab-sys module to mount > everything else. You'd need to create mountpoints for everything of > course, and not just the boot-critical stuff, since otherwise openrc > won't be able to finish mounting mounting everything. The last bit I had already anticipated, as I'm doing something similar with my tmpfs-based /tmp and /var/tmp (symlinked to /tmp). Nothing mounted on top, but I'm creating subdirs inside it, setting permissions, etc. A critical difference is that this is on a full rootfs so I don't have to worry about not having the necessary tools available yet, but I do have the general ideas down. And I'm doing some bind-mounts as well, which require a remount to let all the options take effect, and of course there's mount ordering to worry about, etc. So I have the general idea, but doing it from an initr* with limited tools available will be interesting. As for the tmpfs rootfs itself, I have the vague idea that I'd "simply" (note the scare-quotes) use what's normally the initial root that's essentially thrown away, only I'd not throw it away, I'd just mount everything on top, keep using it, and /somehow/ ensure that anything running from it directly terminates one way or another, so that I don't have old processes stuck around using the mounted-over points. >> The big problem with btrfs subvolumes from my perspective is that >> they're still all on a single primary filesystem, and if that >> filesystem develops problems... all your eggs/data are in one big >> basket, good luck if the bottom drops out of it! > > Maybe, but does it really buy you much if you only lose /lib, and not > /usr? I guess it is less data to restore from backup, but... Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, tho the traditional /usr/src/, /usr/local, and /usr/portage are either pointed elsewhere with the appropriate vars or mountpoints/symlinks to elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, since /lib64, /usr and /etc would obviously be mounted from elsewhere, but they could still be either symlinked or bind-mounted to the appropriate location on the single (read-only) system-filesystem. FWIW I remember being truly fascinated with the power of symlinks when I first switched from MS. Now I consider them normal, but the power and flexibility of bind-mounts still amazes me, especially since, as with symlinks, it's possible to bind-mount individual files, but unlike symlinks (more like hard-links but cross-filesystem), it's possible to have some of the bind-mounts read-write (or dev, exec, etc) while others are read-only (or nodev, noexec...). > The beauty of btrfs subvolumes is that it lets you manage all your > storage as a single pool, even more flexibly than LVM. Sure, chopping > it up does reduce the impact of failure a bit, but I'd hate to have to > maintain such a system. Filesystem failure should be a very rare > occurance for any decent filesystem (of course, this is why I won't be > using btrfs in production for a while). Very rare, yes. Hardware issues happen tho. I remember the a/c failing at one point, thus causing ambient temps (Phoenix summer) to reach 50C or so, and who knows how much in the computer. Head-crash time. But after cooling off, the unmounted-at-the-time filesystems were damaged very little, while a couple of the mounted filesystems surely had physical grooves in the platter. Had that been all one filesystem, the damage would have been far less confined. That's one example. Another one, happened back when I was beta testing IE4 on MS, was due to a system software error on their part. IE started bypassing the filesystem and writing to the cache index directly, but it wasn't set system attribute, so the defragger moved the file and put something else in that physical disk location. I had my temp-inet-files on tmp, which was its own partition and didn't have significant issues, but some of the other betatesters lost valuable data, overwritten by IE, which was still bypassing the filesystem and writing directly to what it thought was its cache index file. So it's not always filesystem failure, itself. But I tried btrfs for a bit just to get an idea what it was all about, and agree totally with you there. I'm off of it entirely now, and won't be touching it again until I'd guess early next year at the earliest. The thing simply isn't ready for the expectations I have of my filesystems, and anybody using it now without backups is simply playing Russian Roulette with their data. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree pro
Re: [gentoo-dev] Re: udev <-> mdev
On Sun, Jul 15, 2012 at 2:25 PM, Duncan <1i5t5.dun...@cox.net> wrote: > So I have the general idea, > but doing it from an initr* with limited tools available will be > interesting. > Dracut modules can specify any tools they need, and they will be loaded into the initramfs. Obviously you'll want to use some discretion here. > As for the tmpfs rootfs itself, I have the vague idea that I'd > "simply" (note the scare-quotes) use what's normally the initial root > that's essentially thrown away, only I'd not throw it away, I'd just > mount everything on top, keep using it, and /somehow/ ensure that > anything running from it directly terminates one way or another, so that > I don't have old processes stuck around using the mounted-over points. I suspect you could do that, but you'd probably have to change the cleanup code, and you need to keep in mind that the initramfs runs on ramfs and not tmpfs. While similar there are a few important differences. Ramfs does not support size limits, so you can extinguish all of your ram easily enough. Ramfs also does not swap, which means that any actual content in that filesystem will waste ram, whether it is used or not. Anything that writes to it could wipe out all your memory even if you have swap available. The design of ramfs is designed for simplicity rather than robustness (you can support an initramfs on a system that otherwise lacks the drivers for tmpfs. > Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently, > tho the traditional /usr/src/, /usr/local, and /usr/portage are either > pointed elsewhere with the appropriate vars or mountpoints/symlinks to > elsewhere. Of course that'd have to change a bit for a tmpfs rootfs, > since /lib64, /usr and /etc would obviously be mounted from elsewhere, > but they could still be either symlinked or bind-mounted to the > appropriate location on the single (read-only) system-filesystem. Giving it a little thought, the simplest tmpfs-based root would be one that defines a tarball as a the root. The system would create a tmpfs, extract the tarball to it, and then use the existing fstab-sys module to mount stuff on top of that. This gives you the option of actually putting some content in the tarball, or just storing an empty directory structure in it. A tarball would let you set permissions/etc and be a bit more generic than writing a custom script. If you wrote a module to do this I wouldn't be suprised if upstream let you merge it. You'd just need to define some kind of sane syntax for it (root=TAR=path...to...tarball - though how a path works with nothing mounted you'd have to define). Maybe you define the tarball at initramfs creation (as is done with fstab.sys and mdadm.conf). > > FWIW I remember being truly fascinated with the power of symlinks when I > first switched from MS. Now I consider them normal, but the power and > flexibility of bind-mounts still amazes me, especially since, as with > symlinks, it's possible to bind-mount individual files, but unlike > symlinks (more like hard-links but cross-filesystem), it's possible to > have some of the bind-mounts read-write (or dev, exec, etc) while others > are read-only (or nodev, noexec...). Yup, my /usr and /var are bind-mounts - I was following the pre-initramfs raid guide and had my root on a raid1, and wanted to keep it minimal. However, rather than having 47 individual filesystems in lvm I only defined a few and bind-mounted half the tree off of one of them. Fstab.sys seems to handle that just fine (mounting the main mountpoint first, and the bind mounts afterwards). Rich
[gentoo-dev] multiple package moves into one
Is it valid to do something like: move media-plugins/mytharchive media-plugins/mythplugins move media-plugins/mythbrowser media-plugins/mythplugins move media-plugins/mythgallery media-plugins/mythplugins move media-plugins/mythgame media-plugins/mythplugins move media-plugins/mythmovies media-plugins/mythplugins move media-plugins/mythnews media-plugins/mythplugins move media-plugins/mythweather media-plugins/mythplugins Thanks. -- Doug Goldstein
Re: [gentoo-dev] multiple package moves into one
On Sun, 15 Jul 2012 17:08:45 -0500 Doug Goldstein wrote: > Is it valid to do something like: > > move media-plugins/mytharchive media-plugins/mythplugins > move media-plugins/mythbrowser media-plugins/mythplugins > move media-plugins/mythgallery media-plugins/mythplugins > move media-plugins/mythgame media-plugins/mythplugins > move media-plugins/mythmovies media-plugins/mythplugins > move media-plugins/mythnews media-plugins/mythplugins > move media-plugins/mythweather media-plugins/mythplugins Nope. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] multiple package moves into one
On 07/15/2012 03:08 PM, Doug Goldstein wrote: > Is it valid to do something like: > > move media-plugins/mytharchive media-plugins/mythplugins > move media-plugins/mythbrowser media-plugins/mythplugins > move media-plugins/mythgallery media-plugins/mythplugins > move media-plugins/mythgame media-plugins/mythplugins > move media-plugins/mythmovies media-plugins/mythplugins > move media-plugins/mythnews media-plugins/mythplugins > move media-plugins/mythweather media-plugins/mythplugins No, that's not really how it's intended to be used. You'll probably have to put blockers in media-plugins/mythplugins to block all the old packages that install the same files. -- Thanks, Zac
Re: [gentoo-dev] multiple package moves into one
On Sun, Jul 15, 2012 at 5:14 PM, Ciaran McCreesh wrote: > On Sun, 15 Jul 2012 17:08:45 -0500 > Doug Goldstein wrote: >> Is it valid to do something like: >> >> move media-plugins/mytharchive media-plugins/mythplugins >> move media-plugins/mythbrowser media-plugins/mythplugins >> move media-plugins/mythgallery media-plugins/mythplugins >> move media-plugins/mythgame media-plugins/mythplugins >> move media-plugins/mythmovies media-plugins/mythplugins >> move media-plugins/mythnews media-plugins/mythplugins >> move media-plugins/mythweather media-plugins/mythplugins > > Nope. > Dang. Didn't think so but I figured I'd ask. Thanks for the quick reply. -- Doug Goldstein
Re: [gentoo-dev] Re: udev <-> mdev
On Fri, Jul 13, 2012 at 05:58:25AM +, Duncan wrote > They're seriously thinking about (and may be planning on) removing > that option from the kernel entirely, to keep people configuring > their first kernels from getting themselves in trouble, but of > course that's now part of the kernel/userspace interface, so it > isn't allowed to just disappear like kernel/kernel interfaces can. A couple of points... 1) Your "argument" applies to just about anything in the kernel configuration process. If you don't follow instructions, the kernel will encounter anything from partial loss of functionality to possibly failing to boot at all. I'm a big boy. If I foul up, I'll admit that I goofed. 2) Full disclosure; I do have an interest in retaining the hotplug pointer mechanism. I have mdev set up on my machines as per https://wiki.gentoo.org/wiki/Mdev Going one step further, I have auto(un)mount working on my machines as per https://wiki.gentoo.org/wiki/Mdev/Automount_USB and https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount This has been working OK for me for a few weeks, and I've asked others to test on their machines. I'll still consider it beta (Work In Progress) until other people confirm it works for them. Once that's done, my next project might be "custom mdev rules", similar to "custom udev rules". -- Walter Dnes
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-07-15 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-07-15 23h59 UTC. Removals: net-misc/remmina-plugins2012-07-09 02:47:44 floppym gnustep-apps/projectmanager 2012-07-09 08:42:59 voyageur gnustep-apps/keyarcher 2012-07-09 08:44:36 voyageur gnustep-apps/plconv 2012-07-09 08:45:23 voyageur gnustep-libs/wizardkit 2012-07-09 08:47:06 voyageur dev-embedded/qvfb 2012-07-09 12:01:58 yngwin media-plugins/mytharchive 2012-07-10 04:18:04 cardoe media-plugins/mythbrowser 2012-07-10 04:18:04 cardoe media-plugins/mythgallery 2012-07-10 04:18:05 cardoe media-plugins/mythgame 2012-07-10 04:18:05 cardoe media-plugins/mythmovies2012-07-10 04:18:05 cardoe media-plugins/mythmusic 2012-07-10 04:18:05 cardoe media-plugins/mythnetvision 2012-07-10 04:18:05 cardoe media-plugins/mythnews 2012-07-10 04:18:05 cardoe media-plugins/mythweather 2012-07-10 04:18:05 cardoe dev-python/apiextractor 2012-07-11 14:18:04 pesa dev-python/generatorrunner 2012-07-11 14:18:04 pesa dev-perl/Tie-RegexpHash 2012-07-15 17:33:06 tove net-proxy/vulture 2012-07-15 17:34:02 tove dev-perl/CPAN-Mini-Phalanx 2012-07-15 17:34:47 tove dev-perl/gimp-perl 2012-07-15 17:35:25 tove dev-perl/XML-Sablot 2012-07-15 17:36:11 tove dev-perl/Devel-Profiler 2012-07-15 17:36:49 tove dev-perl/Cflow 2012-07-15 17:37:39 tove dev-lang/eleven 2012-07-15 17:38:52 tove net-im/silc-client 2012-07-15 17:39:40 tove Additions: media-plugins/mythplugins 2012-07-09 00:05:18 cardoe sci-libs/adolc 2012-07-09 18:45:48 bicatali sys-apps/idle3-tools2012-07-09 21:58:09 sbriesen sys-apps/rigo-daemon2012-07-11 18:37:57 lxnay app-admin/rigo 2012-07-11 18:40:33 lxnay x11-misc/magneto-gtk3 2012-07-11 19:07:27 lxnay media-sound/bempc 2012-07-12 11:29:15 yngwin media-libs/qt-gstreamer 2012-07-12 21:35:43 johu net-libs/telepathy-logger-qt2012-07-12 21:41:55 johu app-text/fbless 2012-07-13 07:48:38 yngwin net-im/ktp-contact-runner 2012-07-13 14:30:31 johu net-im/ktp-call-ui 2012-07-13 14:30:31 johu www-misc/torbrowser-profile 2012-07-14 16:57:17 hasufell app-misc/screenfetch2012-07-14 21:56:46 hwoarang media-sound/id3ted 2012-07-14 22:43:13 hasufell app-emacs/xclip 2012-07-15 18:03:56 ulm -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-misc/remmina-plugins,removed,floppym,2012-07-09 02:47:44 gnustep-apps/projectmanager,removed,voyageur,2012-07-09 08:42:59 gnustep-apps/keyarcher,removed,voyageur,2012-07-09 08:44:36 gnustep-apps/plconv,removed,voyageur,2012-07-09 08:45:23 gnustep-libs/wizardkit,removed,voyageur,2012-07-09 08:47:06 dev-embedded/qvfb,removed,yngwin,2012-07-09 12:01:58 media-plugins/mytharchive,removed,cardoe,2012-07-10 04:18:04 media-plugins/mythbrowser,removed,cardoe,2012-07-10 04:18:04 media-plugins/mythgallery,removed,cardoe,2012-07-10 04:18:05 media-plugins/mythgame,removed,cardoe,2012-07-10 04:18:05 media-plugins/mythmovies,removed,cardoe,2012-07-10 04:18:05 media-plugins/mythmusic,removed,cardoe,2012-07-10 04:18:05 media-plugins/mythnetvision,removed,cardoe,2012-07-10 04:18:05 media-plugins/mythnews,removed,cardoe,2012-07-10 04:18:05 media-plugins/mythweather,removed,cardoe,2012-07-10 04:18:05 dev-python/apiextractor,removed,pesa,2012-07-11 14:18:04 dev-python/generatorrunner,removed,pesa,2012-07-11 14:18:04 dev-perl/Tie-RegexpHash,removed,tove,2012-07-15 17:33:06 net-proxy/vulture,removed,tove,2012-07-15 17:34:02 dev-perl/CPAN-Mini-Phalanx,removed,tove,2012-07-15 17:34:47 dev-perl/gimp-perl,removed,tove,2012-07-15 17:35:25 dev-perl/XML-Sablot,removed,tove,2012-07-15 17:36:11 dev-perl/Devel-Profiler,removed,tove,2012-07-15 17:36:49 dev-perl/Cflow,removed,tove,2012-07-15 17:37:39 dev-lang/eleven,removed,tove,2012-07-15 17:38:52 net-im/silc-client,removed,tove,2012-07-15 17:39:40 Added Packages: media-plugins/mythplugins,added,cardoe,2012-07-09 00:05:18 sci-libs/adolc,added,bicatali,2012-07-09 18:45:48 sys-apps/idle3-tools,added,sbriesen,2012-07-09 21:58:09 sys-apps/rigo-daemon,added,lxnay,2012-07-11 18:37:57 app-admin/rigo,added,lxnay,2012-07-11 18:40:33 x11-misc/magneto-gtk3,added,lxnay,2012-07-11 19:07:27 media-sound/bempc,added,yngwin,2012-07-12 11:29:15 media-libs/qt-gstreamer,added,johu,2012-07-12 21:35:43 net-libs/telepathy-logger-qt,added,johu,2012-07-12 21:41:55 app-text/fbless,added,yngwin,2012-07-13 07:48:38 net-im/ktp-cont
[gentoo-dev] Re: udev <-> mdev
Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted: > Giving it a little thought, the simplest tmpfs-based root would be one > that defines a tarball as a the root. The system would create a tmpfs, > extract the tarball to it, and then use the existing fstab-sys module to > mount stuff on top of that. This gives you the option of actually > putting some content in the tarball, or just storing an empty directory > structure in it. A tarball would let you set permissions/etc and be a > bit more generic than writing a custom script. If you wrote a module to > do this I wouldn't be suprised if upstream let you merge it. You'd just > need to define some kind of sane syntax for it > (root=TAR=path...to...tarball - though how a path works with nothing > mounted you'd have to define). Maybe you define the tarball at > initramfs creation (as is done with fstab.sys and mdadm.conf). Tarball is an interesting idea I hadn't considered. At first blush I like it. =:^) Thinking in that direction does stimulate yet another idea, tho. What about a squashfs root? AFAIK squashfs is read-only at use time, thus enforcing actually mounting something else to write anything, eliminating many of the down sides of sticking with the initial ramfs root, but it would allow the same flexibility in terms of sticking whatever into it at create-time, while only taking the memory necessary for what's actually stuck in it at create-time. I /think/ it's swappable, too, which would give me some flexibility in terms of letting more stuff be added at create-time without having to worry about it being locked in memory. And I think squashfs is reasonably tested territory for this sort of thing, given its use for live-media, etc. And it's in mainline now, too, which is nice. =:^) I'll have to do some research and think about that a bit more... Definitely thanks for the tarball idea, as otherwise I'd probably have not got out of my "box" and thought about squashfs. I'm probably missing its downsides ATM, but you still broke my thinking out of the box! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: udev <-> mdev
On Sun, Jul 15, 2012 at 8:30 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Rich Freeman posted on Sun, 15 Jul 2012 14:48:55 -0400 as excerpted: > >> Giving it a little thought, the simplest tmpfs-based root would be one >> that defines a tarball as a the root. The system would create a tmpfs, >> extract the tarball to it, and then use the existing fstab-sys module to >> mount stuff on top of that. This gives you the option of actually >> putting some content in the tarball, or just storing an empty directory >> structure in it. A tarball would let you set permissions/etc and be a >> bit more generic than writing a custom script. If you wrote a module to >> do this I wouldn't be suprised if upstream let you merge it. You'd just >> need to define some kind of sane syntax for it >> (root=TAR=path...to...tarball - though how a path works with nothing >> mounted you'd have to define). Maybe you define the tarball at >> initramfs creation (as is done with fstab.sys and mdadm.conf). > > Tarball is an interesting idea I hadn't considered. At first blush I > like it. =:^) > > Thinking in that direction does stimulate yet another idea, tho. What > about a squashfs root? AFAIK squashfs is read-only at use time, thus > enforcing actually mounting something else to write anything, eliminating > many of the down sides of sticking with the initial ramfs root, but it > would allow the same flexibility in terms of sticking whatever into it at > create-time, while only taking the memory necessary for what's actually > stuck in it at create-time. I /think/ it's swappable, too, which would > give me some flexibility in terms of letting more stuff be added at > create-time without having to worry about it being locked in memory. And > I think squashfs is reasonably tested territory for this sort of thing, > given its use for live-media, etc. And it's in mainline now, too, which > is nice. =:^) I'll have to do some research and think about that a bit > more... > > Definitely thanks for the tarball idea, as otherwise I'd probably have > not got out of my "box" and thought about squashfs. I'm probably missing > its downsides ATM, but you still broke my thinking out of the box! This is sounding closer and closer to an on-disk liveCD. -- :wq
Re: [gentoo-dev] Re: udev <-> mdev
On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Thinking in that direction does stimulate yet another idea, tho. What > about a squashfs root? AFAIK squashfs is read-only at use time, thus > enforcing actually mounting something else to write anything, eliminating > many of the down sides of sticking with the initial ramfs root, but it > would allow the same flexibility in terms of sticking whatever into it at > create-time, while only taking the memory necessary for what's actually > stuck in it at create-time. It is possible, see: https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init https://github.com/mkdesu/liberte/blob/master/src/etc/fstab The setup above is somewhat different from what you have in mind (SquashFS image is located on disk, and contains the complete live filesystem, not just a skeleton), so mounting read-writable branches can be deferred to the regular post-initramfs services (such as localmount) — on the other hand, maybe you want to do the same (mount branches read-only in initramfs, and remount them read-write in an init.d service). -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
