Re: [oi-dev] Resignation
On 8 October 2014 23:36, Nikola M. minik...@gmail.com wrote: On 10/ 8/14 08:19 PM, Alasdair Lumsden wrote: Talk is cheap, and people should have to earn the right to have an opinion on how the project is run. Back when I was project lead, I made the mistake of soliciting input from all interested parties, which resulted in enormous weekly meetings with lots of talk and no action. It killed the project, as it became mired in indecision and a total lack of focus. What is needed is a single minded lazer sharp focus. [snip] It was probably lack of organization that killed many efforts before. From my experience trying to walk a mile in his shoes, I fully endorse Alasdair's observation that a clearly established historical problem for OI was having meetings to talk about organisation and process with people in the hope that they might contribute. When it comes to established practice, there is nothing novel about the proposition that one earns a say in the workings of an open-source community with sweat equity. One encourages people to contribute rather than bargains. If you think this claim is simply polemical, you might as well argue with the wind. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SSD-based pools
General warning: have a look at power safety issues before building all-SSD
pools. Unless the drive is power-safe, you may find that writes
acknowledged by the controller that are meant to be flushed aren't. There's
been a reasonable amount of research, published on this, including one
paper by Luke Kenneth Casson Leighton and another supported by HP presented
at FAST, and the general conclusion is that consumer SSDs don't get this
right. Intel had some models that did this, but these features now appear
to be exclusive to their data center products. Hitachi does not claim that
the 850s are power safe, so they are only suitable for L2ARC.
Have you had a look at FMA telemetry for the devices?
Cheers,
Bayard
On 25 September 2014 23:46, Andrew M. Hettinger ahettin...@prominic.net
wrote:
I'm presently running tests on a pool using 3x Samsung 850 SSDs on a
LSI-9211-8i (IT) contoller. I thought I'd try seperating the intent log to
see if lowering the write amplification on the pool-drives would help, so I
added another matching SSD for that, but under load I still seem to get
extensive checksum errors. Does anyone have any ideas as to what would be
causing this?
pool: test-array
state: DEGRADED
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are
unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://illumos.org/msg/ZFS-8000-9P
scan: scrub repaired 0 in 0h0m with 0 errors on Wed Sep 24 18:20:56 2014
config:
NAME STATE READ WRITE CKSUM
test-array DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c0t50025388700060D4d0 DEGRADED 0 0 155 too many
errors
c0t50025388700060AEd0 DEGRADED 0 0 149 too many
errors
c0t50025388700060C2d0 DEGRADED 0 0 174 too many
errors
logs
c0t50025388A067DBE9d0ONLINE 0 0 0
errors: No known data errors
errors ---
s/w h/w trn tot device
0 2 6 8 c0t50025388700060D4d0
0 0 0 0 c0t50025388700060AEd0
0 0 0 0 c0t50025388700060C2d0
0 0 0 0 c0t50025388A067DBE9d0
Andrew Hettinger
http://Prominic.NET | Skype: AndrewProminic
Tel: 866.339.3169 (toll free) -or- 1.217.356.2888 x. 110 (int'l)
Fax: 866.372.3356 (toll free) -or- 1.217.356.3356(int'l)
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
This is about as useful a conversation as talking about comparative constitutional law as a problem to be solved by exporting good constitutions to somewhere suffering from political problems. Constitutions and licenses are foundational documents that express a way of proceeding in pursuit of shared values and objectives. A great license or constitution can't be transplanted or otherwise adopted if it doesn't in fact meet a development community where it is and move it where it wants to go. It's why there will never be one license to rule them all: because there will always be interesting opportunities in playing the game by different rules that better suit a productive grouping that generally gets along. It's why there will always be forks and schisms, even if you can agree on licenses. You aren't talking at all about OI's challenges, such as technology debt or strategic direction for issues that OI cares about (such as desktop technology) analytically. (For example: technology debt in build systems is very much a reason why developers are a reasonable first-order community consideration at the moment--you can't get to reasonable development cadence when you've got a lot of movement in upstreams and a great deal of time spent fighting the build system.) I don't see reasoning offered for why governance is even the question being posed for the OI community, let alone why you need to follow the Debian model, as well as it works for Debian. Cheers, Bayard On 13 September 2014 01:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. That will put your patches on an equal footing as those with commercial interests. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. Debian's constitution is minimal and a similar structure will lend strength to all your interests. Why not base your project on one of the most successful free community projects? Regards, Peter. - Original message - On 12 September 2014 10:24, Nikola M. minik...@gmail.com wrote: illumos is a project payed by several companies that employed fully payed employees to develop it. We have a mixture of commercial interests and unpaid, or at least unaffiliated, contributors. The obvious examples to cite are Rich Lowe in general, or Saso Kiselkov when he was adding LZ4 support to ZFS. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code upstream and hope it gets integrated. It is actually the case that, whether or not you work for one of those companies, it is _not_ enough to just send some code. If you are an engineer, regardless of your employer or your motivations, we expect you to provide evidence of several things: - that you have done a full build of the software, and that you have not induced compiler warnings or code style issues - that you have received code review from at least one person who has worked in similar parts of the code base already - that you have tested the software you added or changed, and any software the behaviour of which you may be altering - that you are not breaking public interfaces we expose to users, so that they can expect at least binary compatibility If you work for one of those companies, or not, you are expected to provide the above. If you provide the above, and the advocates are satisfied that you are maintaining the quality of code in the gate, then your changes will be put back. It's as simple as that. What is _not_ simple is that from time to time, people propose and submit changes for review that will break other users of the software. Or, people propose and submit changes that have received insufficient review and testing. Just because it's open source, community-developed software does not mean that we should be lax on quality, or reckless with respect to backwards compatibility. For better or for worse, that's why we accept changes the way we do today. People need to form clusters of users, Admins, Hosting and companies using distributions , to , again, employ their people , pay them or inspire existing employees or Members to contribute to make their job easier. More people join such clusters, it is better , not to let just a few companies move illumos to ,say x86-only , killing SPARC or something else. If (or, frankly, when) we kill SPARC support, it will be because _years_ have passed without any real
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 12:26, Joerg Schilling wrote: Alasdair Lumsden alasdai...@gmail.com wrote: Date: Wed, 19 Feb 2014 12:42:53 +0100 From: joerg.schill...@fokus.fraunhofer.de snip Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. illumos is collaborative. In the past year there has been around 50 contributors all working on the code: It may be that this is your personal impression, but this is not usable for a general statement. From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. This is tiresome and unreasonable, Joerg. It's been pointed out that your definition of collaboration is that your contribution not be evaluated by the same process that applies to anyone else attempting to contribute, and your complaint is that, before this process was established, you felt work you offered for contribution wasn't accepted. When this point is raised, you don't address it head-on, your responses are stuck on an impasse you hit with Garrett in 2010 rather than dealing with the community and contribution process as it's actually functioned for the last three years. Garrett isn't the illumos community, and I, like everyone else in the community, have no reason to take a position on what happened between the two of you four years ago or see that as relevant to what's happened since Garrett shepherded illumos to a collaborative community with collective technical direction. You may not like hearing this, but what you consider dispositive is generally not taken as relevant. If that's something you can't get past, that's a matter of your choice rather than ongoing problems with the illumos community. On top of that, over the course of several years numerous people in the community have given you feedback about shortcomings in your own responses to offered contributions to help you offer feedback that is constructive for those contributors and the community, and you've shown no interest in taking or addressing that feedback. The observed pattern is that you object to contributions without offering a clear problem definition that can process a better solution either immediately or as a later change. Call it open source liberalism as a community value: people don't want to be told simply that what they've got isn't sufficient as a contribution, they want to be given a clear definition of what needs to be resolved so that they receive criticism they can address, and your feedback is often disregarded because you articulate criticism that is simply negative. I don't see that you fundamentally appreciate that otherwise valid criticism that has only negative expression is not satisfactory in community collaboration and may therefore be set aside. You haven't taken any of this feedback, which I take to be offered in the hope and expectation that collaboration is possible, on board. I'm not trying to say that the illumos community is perfect, but you've been repeatedly unwilling to demonstrate that you're willing to self-scrutinise and compromise on the question of collaboration, even as you loudly complain about others, which itself becomes a further obstacle. If you're surprised that the result is that you therefore lack credibility, that's ultimately your problem and deficit. When you add to that claims that the community isn't trustworthy, that's offensive, and that's the point at which I feel compelled to write a public response like this one. It's not that anyone doubts your fundamental ability as an engineer, but anyone who wants to be part of a community has to expect to participate by the standing conventions of that community. I've taken you seriously enough to read back through mail archives to look at the interactions you've had with the community over the years, and what I see is that there are serious problems on your end that you do not acknowledge. There are certainly communities whose product I like and use but whose process I don't care to engage, and I'm able to reconcile myself to that. If you don't want to work by other people's rules, the result may be unfortunate, but it's not fundamentally a question of other's willingness or integrity. I'd certainly be happier if you'd begin to deal with this. I should add that, as long as your responses continue the pattern I describe, I have no intention of or interest in responding. Kind regards, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 14:27, Igor Kozhukhov wrote: Hi All, it is thread about OI , but let me provide additional info. We are talking about illumos, but I think, we have to understand, that illumos based on sponsors who are using it for business and depend on it. Take a look list of advocates: all advocates from companies who are using illumos for business and invest to devs/env. Not true. Please review the advocates list, which shows that Rich Lowe remains without commercial affiliation: http://wiki.illumos.org/display/illumos/RTI+Advocacy___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 15:19, Joerg Schilling wrote: Bayard Bell buffer.g.overf...@gmail.com wrote: From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. This is tiresome and unreasonable, Joerg. I am not sure what you call unreasonable…. The rest of my e-mail was quite explicit on this point. If you're nevertheless not sure, I take this as a sign that you will continue to complain about the lack of reasonable interlocutors whom you ignore when they address you and ask you what you'll do today to collaborate rather than what are your preferred conclusions and consequences of a personal dispute from four years ago. A promise is a promise and as Illumos broke that, this is a problem initiated by Illumos. I am not unforgiving, so it would be simple to just implement the promise to come out of the current situation. illumos never made any promises to you, so when this promise further implicitly exempts you from the current contribution process, it's a non-starter. In fact, Garrett does not have the authority to say that a contribution can bypass the contribution process, and such an exemption would violate the fundamental integrity of the process. If it's simple, it's as simple as that, and this isn't the first time this has been said directly--I could post the mail thread we had some time ago with the advocates list that went precisely to these points. Further, I checked the archives a year ago, and I don't recall finding any contribution you submitted to the community under the current process, only complaints about not being able to have work accepted by telephone call to Garrett immediately after the fork, while the process was still largely undefined. If you don't take the option to break the circle where it's available, that's the definition of what can be done and entirely up to you. The further hypothesis this suggests is that you have settled on fixating on this previous incident because the contradiction which has been brought to your attention in fact relieves you of dealing with or accepting any criticism of your work or forms of participation. I don't think you've attempted to address this fundamental contradiction when it's been brought to your attention: you continue to define equal treatment as preferential treatment in explicit violation of standards that apply to everyone else. You use the word collaboration a great deal--in the concrete practice of it for the illumos community, I think you either don't know what it means or are yourself averse to it. I do not know whether you aware of this evasion, but when you cast its lack of acceptance as a character deficit of others, I feel compelled to raise this publicly. Anyway, that you've replied to the first line of what I said and professed that you don't understand what's been said before that you very evidently don't want to hear, is a sign that this won't be a dialogue, which is an expected disappointment and already more than needs to be said. I appreciate that this is a difficult position for you, but as long as your basic premise for talking about this is that there's no problem on your end, this is going nowhere. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] INTEL, IA32, i80686, AMD64 *is* *well* *supported* by OpenSXCE: Some run it on theit Netbook! - OR: The ability to read a text and absorb information
The noise-to-signal ratio on these posts to world+dog is deeply inconsiderate. Please set up a distro-specific list and invite those who are interested. On 8 Jun 2013, at 23:51, G B g_patri...@yahoo.com wrote: I downloaded and went to install OpenSXCE and chose not to proceed when I was prompted with the language. Being from the United States of America I selected English, but there was no option for US, but there was Canada, New Zealand, Britain, Australia, and maybe another I'm missing. If this was an oversight on your behalf, then my apologies, but if it was intentional because of your dislike of the USA for some personal reason, then I'm not going to bother with your operating system. I served in the US Air Force, my uncle was a navigator on a B-52 during Vietnam, my mother's husband was in the US Air Force in Vietnam, my grandfather was in the US Army in the Pacific during WWII, another uncle served 30 years in the US State Dept. A good friend of mine served in the US Navy in Vietnam. You see, my blood doesn't bleed red, it bleeds Red, White, Blue. Your largest user base would likely be the USA, but by neglecting to add the country to the language during installation it seems you are making a statement, and so am I. I refuse to use it. If you add the USA then I may look at it, but won't go out of my way. As I said before, if this was just an oversight then you have my apologies. Otherwise, good luck with your endeavor. -- *From:* Martin Bochnig mar...@martux.org *To:* Discussion list for OpenIndiana openindiana-disc...@openindiana.org; OpenIndiana Developer mailing list oi-dev@openindiana.org; develo...@lists.illumos.org; disc...@lists.illumos.org; Martin Bochnig mar...@martux.org *Sent:* Saturday, June 8, 2013 11:26 AM *Subject:* [oi-dev] INTEL, IA32, i80686, AMD64 *is* *well* *supported* by OpenSXCE: Some run it on theit Netbook! - OR: The ability to read a text and absorb information Unfortunately I was forced to re-join and then re-unsubscribe to finally debunk some neverdying MYTHS. INTEL, IA32, i80686, AMD64 *is* *well* *supported* by OpenSXCE: Some run it on theit Netbook! - OR: The ability to read a text and absorb information I followed the discussion from the archives at http://openindiana.org/pipermail/openindiana-discuss/2013-June/date.htmland I'm shocked about all the nonsense that people can claim uncorrected, about what OpenSXCE is all about. I have always re-iterated all these technical aspects over and over again, when I was still on the Illumos and OI lists. To me it looks as if few ever read even the subject line. I also wrote all this to twitter.com/martinbochnig, twitter.com/opensxce, facebook.com/opensxce, facebook.com/martinbochnig, OpenSXCE's blog http://opensxce.blogspot.de/ as well as to contributors in probably hundreds of private messages and skype calls, plus google chats. It is a real mystery, why such NONSENSE can be claimed days-long without being corrected by or understood by the majority (BIG THANKS TO THE GOOD SOULS, who tried it) : OpenSXCE is SPARC-only: WRONG OpenSXCE is not based on Illumos: WRONG OpenSXCE will in the future not (indirektly) be based on Illumos modified OS/Net: WRONG OpenSXCE is Desktop-only: WRONG OpenSXCE is instable crap: WRONG OpenSXCE has no users: WRONG Igor's DilOS.org OS/Net doesn't update itself to incorporate always the most recent stuff from Illumos (except where he has implemented things better, as you can read on his site or my blog) : WRONG MartinBochnig never works together with others: WRONG MartinBochnig never writes technical details to these technical lists: WRONG See my the OpenSXCE Blog, for example: OH “DilOS brings in the waffle cones” - Ken Mays / PLUS: *Hypocrisy* http://opensxce.blogspot.de/2013/06/oh-dilos-brings-in-waffle-cones-ken.html DilOS-OS/Net: The more I learn from and about Igor, the more I have to wonder why nobody ever put attention to him! But: He avoids fights. He rather writes code, code, code http://opensxce.blogspot.de/2013/06/dilos-osnet-more-i-learn-from-and-about.html Will you ever notice, that x86/x64 is also supported? what OpenSXCE actually is about: IA32, AMD64, sun4u, sun4v. You and everybody could read this from the beginning on (in bold letters: *COULD*). [OpenIndiana-discuss] A potential new Illumos reference distro candidate: IA32, AMD64, sun4u, sun4v http://openindiana.org/pipermail/openindiana-discuss/2012-December/010922.html I do not bitch around because nobody uses my distro, because - believe it or not: That's not the case. I simply think, that if somebody talks about me or my work, he should at least have a clue, what he is talking about. And YES: I guess I do have this humble right, as anybody has and should have. If you (most at OI and Illumos) never read what I write, maybe it is easier to watch my x86 screenshots: http://www.flickr.com/photos/96825400@N05/sets/72157633874850547/ To avoid ambiguity I should
Re: [oi-dev] Compiler migration #2
Folks, what we're talking about here is migrating from Studio to gcc on a version we already have. Updating to the latest and greatest GCC can happen subsequent to that. OI needs people who contribute code a lot more than it needs people with strong opinions about what someone else should do, so I take Adam to be owed code review or coded alternatives more than anything else. I, for one, will respond to the CR request within the next few days. Cheers, Bayard On 26 Jan 2013, at 12:31, Luca De Pandis lucadepan...@gmail.com wrote: I think it would be better to use, for now, a specific version of GCC for Illumos development (4.4.4) and a later version of that for userland tools and other stuff. Basically, it's the same concept that Illumos and OI have now: GCC 4.4.4 for the kernel and GCC 3.x for the rest. But, instead of use a very very obsolete and (in most cases) useless version (some applications need a recent version of the compiler, i.e. aMule, GNUstep etc.), we could use one of the latest releases. Solaris 11 ships with GCC 4.5 compiler/runtime in their publisher. So, i think it's time to going forward also for Illumos and related distributions. Maintaining an obsolete version of the compiler is not a good thing. Best regards, Luca De Pandis In data sabato 26 gennaio 2013 13:59:40, Adam Števko ha scritto: Hi Peter, On Jan 26, 2013, at 1:01 PM, Peter Tribble peter.trib...@gmail.com wrote: Adam, Just one question - why gcc44? In other words, why not jump straight to gcc 4.7? Getting new compiler into oi-build would be nice, but it doesn't solve the problem with migrating stuff away from Sun Studio. Once, we are sure, that everything is buildable by GCC 4.4 (which we have already packaged), I have no doubt that transitioning to newer GCC painless. Correct me if I am wrong. Yes, I know that Illumos has 4.4.4, but that's a custom version specific to building Illumos. I think SmartOS has gone to 4.7, and for Tribblix I went straight to 4.7.2. As I said, I am using GCC 4.4 because it is available. Cheers, Adam ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ATI Radeon 7.0.0 driver Intel 2012Q4 graphics package
I think he indicated some time ago that he was having problems for lack of illumos driver development experience and hoped to host a hackathon with some experienced people to nurse the project along. On 5 Jan 2013, at 03:09, Milan Jurik milan.ju...@xylab.cz wrote: Hi, that repo looks like not active for 5 months. Best regards, Milan On út, 2013-01-01 at 07:58 -0800, ken mays wrote: Hello, The Illumos kernel DRM/KMS (kernel mode setting) is being worked on from a student at the Chalmers University of Technology in Sweden: Robin Axelsson. His current KMS work is here: https://github.com/raichoo/illumos-gate/commits/kms ~ Ken Mays ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [userland] Re: Extracting archives to a source subdirectory
I'm +1 on both the mechanics and the objective. On Sat, May 5, 2012 at 5:56 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi Sriram, On 5 May 2012, at 17:53, Sriram Narayanan wrote: Assuming a spec file based approach, wouldn't the SOURCES folder already take care of this ? illumos-userland is more like pkgsrc/FreeBSD ports tree in its layout/structure. It doesn't follow spec file conventions. Cheers, Alasdair --- illumos-userland Archives: https://www.listbox.com/member/archive/191052/=now RSS Feed: https://www.listbox.com/member/archive/rss/191052/22060881-a272e333 Modify Your Subscription: https://www.listbox.com/member/?member_id=22060881id_secret=22060881-240063c0 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Downloading archives to a common area
I think this is better than setting ARCHIVE_MIRROR, which may be useful for other purposes--it's even more handy for managing our source archive if you can populate what's current with a global gmake download to one directory and then rsync that to dlc. As you say, with multiple workspaces, you can simply symlink this to a single copy of the archives, and with this done, you don't have to copy to pop into the workspace; you get archive dedup for free with nearly zero effort. The only downside is that userland-fetch might blow away your only copy because of digest mismatches in the component Makefiles, so you probably want to use snapshots a bit more than you might have done. People like me doing development on laptop SSDs get a big win for the reduced storage overhead. On Sat, May 5, 2012 at 5:35 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi All, One improvement we added to s10-userland, was to download archives to a single top level archives directory instead of into the component directory. We used: $(WS_TOP)/archives We did this by defining USERLAND_ARCHIVES?= $(WS_TOP)/archives in shared-macros.mk and fixing up prep.mk. There are a few benefits to this, one is that if you have lots of illumos-userland workspaces, they can all share a single archive directory. It can be NFS or lofs mounted, and it makes rsyncing the contents of that directory up to our mirror archive a lot easier than manually picking through all the component directories. It also lets us add $(WS_TOP)/archives to .hgignore and no longer have to put up with seeing downloaded archives in the hg status output. Before I begin work on this changeset for illumos-userland, does anyone have any feedback? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Downloading archives to a common area
On Thu, May 10, 2012 at 1:20 AM, Gordon Ross gordon.w.r...@gmail.com wrote: On Wed, May 9, 2012 at 7:42 PM, Bayard Bell buffer.g.overf...@gmail.com wrote: It also lets us add $(WS_TOP)/archives to .hgignore and no longer have to put up with seeing downloaded archives in the hg status output. Before I begin work on this changeset for illumos-userland, does anyone have any feedback? I'd like to see some caution against blowing away archives in there, if possible. Otherwise sharing it gets quite difficult. Yes. Can someone [else--it's not so hard, and I'm happy to help someone else through it, but I'm already a blocky resource] scope changes in userland-fetch? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] illumos-userland hackathon May 22 in Amsterdam
We're looking at a change of venue to include accommodation (i.e. apartment with WiFi as place both to crash and to hack), courtesy of Nexenta. If you're interested and particularly if you'd like accommodation, please RSVP by private mail to me ASAP. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Amsterdam userland hackathon interest
From a brief survey, I've got the sense that the cost of staying in Amsterdam has some people on the fence. Alternate arrangement for the hackathon would be to rent an apartment with wifi and hold the hackathon there instead of paying for a hotel conference room. Accommodation would thus be covered for participants, but it would be a something of a slumber party. I'd need to move fast to make arrangements for this on new terms, so please reply privately ASAP if interested. On Apr 22, 2012, at 6:19, Bayard Bell buffer.g.overf...@gmail.com wrote: If you're interested in attending the hackathon but have not yet RSVP'ed, please drop me a line by private e-mail. We're looking at finding group accommodation to help people with expenses, so the sooner you get back to me, the better. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] How to properly contribute 3rd party software packages for illumos and/or OpenIndiana?
On Sat, Apr 21, 2012 at 8:02 PM, Garrett D'Amore garr...@damore.org wrote: On Apr 21, 2012, at 11:16 AM, Jim Klimov wrote: Hello all, May I ask some questions on how I could help with integration of popular software with illumos and/or openindiana? Some of my bugs/rfes deal with I'd like to have such-and-such software in OI repo out of the box; recent examples include NUT and OpenVPN. Say I did this and tested on my systems - compiled, made SMF methods, maybe some lower-level OS changes (i.e. shutdown handlers for NUT, drivers/tuning for OpenVPN), and personally liked the result. Probably this is stuff that should be in OpenIndiana, rather than illumos core. The first step is to post some kind of review so that other people can look at what you have already done. Then we can advise further as to where and how to integrate it. Not in illumos-gate != belongs in OpenIndiana. If it's about porting and packaging, it probably belongs in illumos-userland, which would get it into OI. For information about the illumos-userland contribution process, see: http://wiki.openindiana.org/oi/Building+with+illumos-userland ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Amsterdam userland hackathon interest
If you're interested in attending the hackathon but have not yet RSVP'ed, please drop me a line by private e-mail. We're looking at finding group accommodation to help people with expenses, so the sooner you get back to me, the better. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Are there any active healthchecks for SMF in general?
tl;dr Seems like an upstream question (illumos-gate and/or illumos-userland). Even in terms of the upstream, we don't really do RFEs unless there's enough interest in the issue that someone's likely to write some code. On Wed, Apr 18, 2012 at 12:37 PM, Jim Klimov jimkli...@cos.ru wrote: Hello all, I wonder if there are any RFEs or on-going works regarding proactive health-checks for SMF services (test routine to be defined by the service author or packager and/or by local system admin)? I think that just like there are start, stop, refresh methods and so on, there could also be a healthcheck method with its associated timeouts, as well as frequency of tests, tolerable amount of test failures in a row and/or within a given time range, etc. There could also be a policy to choose what to do if the healthcheck fails (too many times): offline the service, set it to maintenance, restart it, or smth else? In fact, if the healthcheck method is validly defined, it should be fired after running the start method and only after a successful test the SMF service state should transfer from offline* to online. Some service methods exit as soon as the target daemon has started, even though the service becomes useful after a few minutes. I've had to script clutches like that for many different projects, usually involving a test routine fired from crontab or crafting a specialized startup script which includes needed checks on prerequisite services as well as startup real results. As an example, think Apache Tomcat with its default start scripts - they exit after spawning JVM, but the user-required webapps can take minutes to initialize and start up. Currently SMF would online the service as soon as the script exited, and proceed to starting up the dependent services. However, the method is actually online for us generically when the servlet container has *logged* that its startup routine is complete. If other SMF services do depend on this Tomcat (say, it is running an OpenDJ LDAP server), it is online only when it responds correctly to LDAP queries, and not before. In case of webserver SMF-services the tests usually request a healthcheck page or some other page and compare it with the expected healthy template. For DBMS or LDAP services that would be an SQL or ldapsearch query. In case of crontabs there are tricks (i.e. lockfiles) to forbid the test script from running in numerous parallel invokations if the tested service takes too long to respond. Recently (in my vboxsvc[1] project for controlling the VirtualBox VMs as SMF service instances), I've taken a different approach and made a background loop initiated and executed by the service method script; part of that loop's job is to check whether the VM is not only running as a process on the Solaris host, but also provides the service it was booted for (if the test method was validly defined and configured and enabled). Originally the loop got there because the service is transient (due to VirtualBox internals) and SMF does not monitor the service's child processes, but we needed to monitor anyway whether the VMs are running or not, and stop the VM processes gracefully when the SMF service is stopped. Then things got expanded a bit... ;) I wonder if it would be useful to generalize the solution and/or recode it in some more efficient manner to be available for all SMF services as an optional part of the framework? Theoretically it is there, somewhat - SMF already checks that child processes exist for contract/wait type of services, and none died on bad signals like coredumping. What do you think? Would that logic be useful as generic part of SMF? Can it be left as (includable?) shell scripts and/or rewritten into perl for efficiency? Would anyone undertake to revise and rewrite the logic into C? ;) [1] http://sourceforge.net/projects/vboxsvc - my VBoxSvc project which controls VMs as SMF service instances, with optional healthchecks. [2] http://vboxsvc.svn.sourceforge.net/viewvc/vboxsvc/lib/svc/method/vbox.sh?content-type=text%2Fplain The main script (keywords: KICKER vmsvccheck monitoring hook). Thanks for any ideas, //Jim Klimov ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Are there any active healthchecks for SMF in general?
On Wed, Apr 18, 2012 at 4:00 PM, Jim Klimov jimkli...@cos.ru wrote: 2012-04-18 18:33, Bayard Bell написал: tl;dr Seems like an upstream question (illumos-gate and/or illumos-userland). Even in terms of the upstream, we don't really do RFEs unless there's enough interest in the issue that someone's likely to write some code. tldr is my problem of sorts ;) I have the same problem at times. Still, this was not so much an RFE per se, but rather a statement that I have to make such-and-such workaround too often, so I do have solutions to the problem. I wonder if the problem annoys/bugs others too, if they want the solution, and if my approach is sane and/or acceptable. Factor into distinct and clear problems; circulate those to upstream developer lists for the referenced project and ask whether there's interest in taking solutions on board. If you already have code written, so much the better, but it's still better to explain what problem you're trying to solve if you want to upstream it. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] userland history has changed
The changed history is now in place, both on hg.illumos.org (available by anonhg ssh) and hg.openindiana.org (available by ssh). You will need to clone from scratch. I'll reiterate from a previous mail: If you have clones out there for issues, what I'd suggest is waiting until there's an illumos/illumos-userland to clone from. Take what you've got in your issue clone, push it to bitbucket for backup (hg push ssh://h...@bitbucket.org/userid/illumos-userland-issue), export the changes (e.g. hg export -g -o ~/illumos-userland.issue tip--you will need to do this for additional revisions between the canonical tip and the local if you have multiple changesets for the issue), stomp the local repo (hg strip 0), re-path it to the canonical (edit .hg/hgrc off the top of the clone to set default = ssh://h...@bitbucket.org/illumos/illumos-userland), sync to the local clone (hg fetch; if you haven't enabled the fetch extension, add fetch = in the [extensions] section of ~/.hgrc), and then import your changes back in (hg import ~/illumos-userland-issue). Do an hg outgoing ssh://h...@bitbucket.org/illumos/illumos-userland to confirm that the changes you've imported all show up. To confirm that you've got a clean clone, the current head is: changeset: 492:feb4ae69ab0d bookmark:master tag: tip user:Andrew Stormont andrew.storm...@nexenta.com date:Sun Mar 11 22:49:55 2012 + summary: 2192 userland-fetch can't handle FTP link. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
A version of 3.6.4 is pending for the illumos-userland head. On Sun, Apr 15, 2012 at 1:44 PM, Martin Walter m...@uni-freiburg.de wrote: Hi, yesterday I updated to oi_151a3 and saw: # pkg list | grep samba library/samba/libsmbclient 3.5.5-0.151.1.3 i-- service/network/samba 3.5.5-0.151.1.3 i-- Is there any newer version without the security bug from https://www.samba.org/samba/security/CVE-2012-1182 ? Best regards, Martin ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] userland history problems
I've got a cleaned up repo ready and will push it to the canonical later. A summary of changes: 1) this is based off the userland-gate/oi-build history (that's where revision 0 now starts) 2) the history has been made linear; for three out of four merges in the history, this was a no-op; for the fourth (rev 445 in the new history was previously part of a merge but is not an initial import of changes for the illumian build system, which still requires issue 2160/rev 448 for clean-up) 3) Nexenta copyrights were written twice to cpan2ips and py2ips; these have been de-duped (rev 464) 4) changes that were backed out (and obviously the backouts were removed, as these simply make for noise in a lot of places when trying to read back through annotations) 5) two userland-gate changes that were lacking a space separator between name and address in the user field have been fixed (revisions 359 and 404) 6) the one tag assignment subsequent to these changes has been altered to reflect the altered change signatures (build-170 assigned to rev 378 via rev 380) I've confirmed via hg fetch from the current illumos-userland and then hg-recommit that there are no unaccounted-for differences (the only differences are the difference in .hgtags resulting from signature differences and an extraneous line feed removed as part of the Nexenta copyright de-dup). I've also gotten peer review on the rebuild from andy_js. I'm going to confirm that everything is good to go for git by building hg-git/dulwich, importing, running git fsck, and pushing to github. The mirror on hg.oi.o will lag somewhat behind cleaning the canonical, as it will need to be stomped and re-cloned before mirroring can be resumed. At that point the illumos-infra folks can provide github mirroring for us. If you have clones out there for issues, what I'd suggest is waiting until there's an illumos/illumos-userland to clone from. Take what you've got in your issue clone, push it to bitbucket for backup (hg push ssh://h...@bitbucket.org/userid/illumos-userland-issue), export the changes (e.g. hg export -g -o ~/illumos-userland.issue tip--you will need to do this for additional revisions between the canonical tip and the local if you have multiple changesets for the issue), stomp the local repo (hg strip 0), re-path it to the canonical (edit .hg/hgrc off the top of the clone to set default = ssh://h...@bitbucket.org/illumos/illumos-userland), sync to the local clone (hg fetch; if you haven't enabled the fetch extension, add fetch = in the [extensions] section of ~/.hgrc), and then import your changes back in (hg import ~/illumos-userland-issue). Do an hg outgoing ssh://h...@bitbucket.org/illumos/illumos-userland to confirm that the changes you've imported all show up. Please note that ssh://h...@bitbucket.org/illumos/illumos-userland does not yet exist, and it shouldn't exist until the canonical's been sorted. Cheers, Bayard On Thu, Apr 12, 2012 at 11:12 PM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi Bayard, Sorry for not getting back to you sooner - I think the answer is go for it. We only get this opportunity once, so lets take it. The hassle factor is worth it, checking out the tree again is trivial. Cheers, Alasdair On 12 Apr 2012, at 22:03, Bayard G. Bell wrote: Unless I hear any compelling objection, I'm going through with this this weekend. On Tue, 2012-04-10 at 18:51 +0100, Bayard G. Bell wrote: In the course of fulfilment of my request for git mirroring, I've learned that we have a slight problem in our history: someone forgot to put a space between their name and the angle brackets surrounding their e-mail address. There are two ways to fix this: one is to ask github to disable validation of this data, the other is to fix the history, which is a destructive change. Since we're just getting on our feet, I'm inclined to make two substantial clean-ups in the history, one is to fix these commit records, and the other is to remove backed out changesets so they don't show up in annotations (which seems reasonable, given that the net effect is that no change happened, which to my mind shouldn't have two records against it for most repository contents). That means everyone using illumos-userland will need to re-clone for both mercurial and git. I know it's ugly, but I think this is pretty much the last point at which we can bite the bullet and clean this up properly--the other option is a workaround, whereas this is a painful fix. On the plus side, we'll finally have mirrors of the canonical available as illumos/illumos-userland. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] First illumos-userland hackathon
Thanks to Linda Kateley, Nexenta's community manager, we are holding a hackathon for illumos-userland in Amsterdam on May 23, alongside the European Open Storage Summit: http://www.meetup.com/illumos-User-Group/events/56953802/ Closer to the date we will be putting up an ideas page. If you're interested in contributing to this porting and packaging project, join us on the userland list: https://www.listbox.com/subscribe/?listname=userl...@lists.illumos.org We're currently spinning up our first dev cycle with our revised development and contribution process: http://strictlygeeking.blogspot.com/2012/03/new-development-and-contribution-model.html If you haven't been previous involved in development, please have a look at our documentation, which will be improving in the next month as we pick up the pace: http://wiki.openindiana.org/oi/Building+with+illumos-userland If there are things you'd like to see added or updated in userland, please see if it's already in our tracker and submit a new issue if it isn't already: https://www.illumos.org/projects/illumos-userland/issues/ Hope to see you there. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] First illumos-userland hackathon
On Fri, Mar 23, 2012 at 4:41 PM, Garrett D'Amore garr...@damore.org wrote: I'm glad to see this, although a little disappointed that its strictly an illumos userland bit -- why not also include some opportunity for illumos-gate. I've definitely been encouraging people with a primary interest in porting and packaging who are interested in distro development to get more involved with illumos-gate as our closest upstream. I've done a scan of issues in the OI tracker recently, and there's a decent amount of stuff that needs upstream resolution, so one of the things I might do is create upstream issues for that and walk people through fixing as many of those as possible. The distros are definitely one place where the rubber hits the road for illumos-gate, and I'd like to see more of that fed back into illumos-gate for resolution. If people in the community are willing to use our stuff in anger, we should oblige them with a measure of support. One of the things that's on my list to get going is a community backline, which would pull issues from all the distros (SmartOS, illumian, OI), get them proposed diagnosed, identify already existing fixes (Joyent's way ahead on this with SmartOS), and drive resolution in illumos-gate. If I were putting this in a larger context, I'd say we've addressed our first challenge as a community, which is showing that we can have a critical mass of developers successfully working under distributed ownership, moving our codebase forward. Our next challenge seems to me to be providing processes for maintaining production quality, including providing a degree of shared risk management for distro support, emphasizing the ever-moving target that is working code without getting caught up in the kings and presidents governance questions. If we mean to embrace the devops concept, this seems a strategic way to do it. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Support OI and illumos for GSoC 2012
Thanks for jumping on this (note to those who responded privately: unless you hear otherwise, we can consider the issue resolved and avoid duplicate effort). If I create a Dropbox folder for you, could you upload it there? Cheers, Bayard On Mon, Mar 19, 2012 at 8:16 AM, Gary gdri...@gmail.com wrote: I've created an Open Virtualization Format image using VMware's conversion tools. Although OVF is supposed to be platform agnostic, I've found it not to be the case when converting between VirtualBox and VMware products. I've no idea about any other products that support OVF will work with this or not but I was able to get this working with VMware Player under Windows 7. It's a fresh install of 64-bit OI151a server but if there's another release that you'd like, please let me know. The download link below will expire after 14 days so if you find it useful, please find it a permanent home. -Gary size: 781 MB file: oi151a.ova root pwd: 0p3n1nd14n4 md5sum: e7ae3c02e9ccee7e134694a4a96acc0a download: http://www.adrive.com/public/Cj3Uus.html ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Support OI and illumos for GSoC 2012
On Sun, Mar 18, 2012 at 4:11 AM, Alasdair Lumsden alasdai...@gmail.com wrote: Hi Bayard, What are the plans regarding recruiting students onto GSoC? I'm not familiar with how the whole process works. Is this something we need to advertise to Universities/Students? Here's an overview of GSoC I provided in announcing our application: http://strictlygeeking.blogspot.co.uk/2012/03/illumos-applying-for-gsoc-2012.html If you want to advertise our involvement to students, please distribute the URL for our GSoC page: http://www.google-melange.com/gsoc/org/google/gsoc2012/illumos There's also a main GSoC page at illumos.org (the previous URL links to it and, more importantly, is the page students used to apply): https://www.illumos.org/projects/illumos-gate/wiki/Google_Summer_of_Code ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 2218 update perl512 with oracle-userland patches (actually perl512 to 5.12.4)
This has been updated. The chief difference is a patch that supports SONAME for libperl across compilers. In the interim Oracle have themselves moved to 5.12.4, so I've cross-checked my changes against theirs. On Fri, Mar 2, 2012 at 11:50 PM, Bayard Bell buffer.g.overf...@gmail.com wrote: I've provided an update to 5.12.4 instead of the Oracle patches to 5.123, although actually performed that build and tested it before rolling forward to 5.12.4 and stripping the patches. The relevant perldata shows the diff to be minimal, and I believe two of the three changes would otherwise be provided by the Oracle patches: http://search.cpan.org/dist/perl-5.12.4/pod/perl5124delta.pod https://www.illumos.org/issues/2218 https://bitbucket.org/buffyg/illumos-userland-2218/compare/..buffyg/illumos-userland Since there are some pretty serious issues with perl5.10, I'd like to suggest a follow-on change to un-comment the default links and make this the default perl in OI 151, which has been done previously for illumian. Not sure if a separate package is available to manage the default links, but I believe igork had suggested something like that on developer@ at some point. If such a change has already been committed, it should have some mechanics that I'd like to use to split the defaults out of the gcc44-runtime package. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] RFC: new meeting time Thursdays at 7PM UK time
Or I did but couldn't see until after I sent this. Well, I'd like to finalize this, so please provide feedback if this looks to be a problem. Otherwise, see you Thursday. On Sun, Mar 18, 2012 at 9:58 PM, Bayard Bell buffer.g.overf...@gmail.com wrote: Thought I had sent this previously, but seemingly not. That's UK time, which varies from UTC (or not) according to European rules. I know that's not great for people in the US or some people in the UK, particularly those who tend to leave the office late, but it's an arrangement that allows us to include people from St. Petersburg to Boston and NYC. I'm open to negotiating the time slot, but, as we have people with conflicts for Tuesdays, I'd like to hash something out to put into effect this week. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Support OI and illumos for GSoC 2012
Milan, The basic checklist includes build from source. Students are doing that on VBox (because it's free) and coming back very confused because it's not fit for purpose. We're simply providing students with known-good configs so that they can spend their time actually looking at code and picking up bite-sized bugs when they are still weighing whether to get involved in our project. I see providing alternate distribution formats such as vmWare and KVM images as legitimate general aims that complement student recruitment. We have a sufficient diversity of interested students (GSoC is a global program, and the stipend is worth considerably more in terms of spending power in economies that are less likely to have deep broadband penetration to provide access to hosted solutions or spare affordable hardware capacity that can support illumos development) that expecting people to source kit for bare metal installs or deal with mismatched virtualization solutions is a highly counter-productive barrier. More development-appropriate installation options are will be defined by project, and accepted students will be expected to negotiate those during the bonding period from late April until project work officially commences in late May. We are not going to emulate certain Zen practices by punching young monks bordering on enlightenment in the face to help them to get them the rest of the way there, even if the technique has been known to work (you could argue that we're saving the punches until enlightenment is at hand rather than when someone first shows up at the door). Without putting too fine a point on this, I'm happy to explain the position I'm taking on this as the illumos org admin, but this isn't a debate (and, incidentally, I'm not a Zen master). More important is to match resources to problems that I can say from direct observation inhibited the program last year and threaten to do so again this year. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Introduction
Joerg, We would love to have someone focused on documentation. Are there any particulars areas of interest you have for documentation? Do you have an account on the wiki yet? Cheers, Bayard On Fri, Mar 16, 2012 at 7:10 AM, o...@stephanws.de wrote: Dear @ll, my name is Jörg Stephan and Iam a system administrator at an local domain registrar and registry service. I would like to get involved in the openindiana development. First of all i would like to help on the technical documentation and the handbook, who must i talk to on that topic? Kind regards Jörg ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dilos-userland 1.2.1
Packages, no. We're syncing source first from userland-gate, while also transitioning to gcc as our primary compiler, and thereafter looking to cherry-pick changes from illumian necessary to dpkg support, as Gordon's suggested. To get a sense of what we've plotted, have a look at: https://www.illumos.org/projects/illumos-userland/issues?query_id=20 On Mar 14, 2012, at 12:44 AM, ken mays maybird1...@yahoo.com wrote: Is it on the table to update the oi-experimental repo to reflect the updated packages from dilos-userland? Comparable to https://hg.openindiana.org/upstream/oracle/userland-gate/file/4f64aa9aa05b ~ Ken Mays From: Gordon Ross gordon.w.r...@gmail.com To: OpenIndiana Developer mailing list oi-dev@openindiana.org Cc: userl...@lists.illumos.org userl...@lists.illumos.org Sent: Tuesday, March 13, 2012 3:42 PM Subject: Re: [oi-dev] dilos-userland 1.2.1 I presume that the item of greatest interest to this community is the source repositories on bitbucket (see below) from which people can cherry pick changes if they like. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2260 provide build of richlowe's il_4_4_4 gcc in userland
This build of gcc is provided to support illumos-gate and KVM BFS under OI, following on rm's flag day for moving KVM to richlowe's 4.4.4. This gcc lives under /opt/gcc/4.4.4, which is the path richlowe already uses and that KVM will expect after the flag day. https://www.illumos.org/issues/2260 https://bitbucket.org/buffyg/illumos-userland-2260/compare/..buffyg/illumos-userland ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [userland] 2260 provide build of richlowe's il_4_4_4 gcc in userland
It's not being moved, it's different builds of gcc, one minimally tweaked (/usr for userland), one a bit more tricked out (/opt for illumos-gate/KVM), provided in parallel. On Sat, Mar 10, 2012 at 1:10 PM, Igor Kozhukhov ikozhuk...@gmail.com wrote: Hello, Could you please explain - why gcc have been moved to another location ? Where are located gcc libs ? Why we can't update KVM build for gcc in /usr/gcc/4.4 ? Best regards, -Igor On 3/10/12 5:08 PM, Bayard Bell buffer.g.overf...@gmail.com wrote: This build of gcc is provided to support illumos-gate and KVM BFS under OI, following on rm's flag day for moving KVM to richlowe's 4.4.4. This gcc lives under /opt/gcc/4.4.4, which is the path richlowe already uses and that KVM will expect after the flag day. https://www.illumos.org/issues/2260 https://bitbucket.org/buffyg/illumos-userland-2260/compare/..buffyg/illumo s-userland --- illumos-userland Archives: https://www.listbox.com/member/archive/191052/=now RSS Feed: https://www.listbox.com/member/archive/rss/191052/22234452-ff4867aa Modify Your Subscription: https://www.listbox.com/member/?; 247f Powered by Listbox: http://www.listbox.com --- illumos-userland Archives: https://www.listbox.com/member/archive/191052/=now RSS Feed: https://www.listbox.com/member/archive/rss/191052/22060881-a272e333 Modify Your Subscription: https://www.listbox.com/member/?member_id=22060881id_secret=22060881-240063c0 Powered by Listbox: http://www.listbox.com ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Announcement: new development and contribution model for illumos-userland
http://strictlygeeking.blogspot.com/2012/03/new-development-and-contribution-model.html We'll aim to do a brief QA session at the top of tomorrow's #oi-meeting. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2218 update perl512 with oracle-userland patches (actually perl512 to 5.12.4)
I've provided an update to 5.12.4 instead of the Oracle patches to 5.123, although actually performed that build and tested it before rolling forward to 5.12.4 and stripping the patches. The relevant perldata shows the diff to be minimal, and I believe two of the three changes would otherwise be provided by the Oracle patches: http://search.cpan.org/dist/perl-5.12.4/pod/perl5124delta.pod https://www.illumos.org/issues/2218 https://bitbucket.org/buffyg/illumos-userland-2218/compare/..buffyg/illumos-userland Since there are some pretty serious issues with perl5.10, I'd like to suggest a follow-on change to un-comment the default links and make this the default perl in OI 151, which has been done previously for illumian. Not sure if a separate package is available to manage the default links, but I believe igork had suggested something like that on developer@ at some point. If such a change has already been committed, it should have some mechanics that I'd like to use to split the defaults out of the gcc44-runtime package. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] reminder: components-gnome has been languishing
I'm about to start pulling off this, but, particularly for people who are interested in getting involved as developers, this is an excellent place to start. https://bitbucket.org/buffyg/components-gnome If there's something you'd like to do, please open an issue in the tracker: https://www.illumos.org/projects/illumos-userland/issues I noticed that the Solaris directory seems to be missing for pygtk2. Any way we could get a general refresh of the work aszeszo's done? I'm happy to post it to the repo on bitbucket. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2142 update python2.6 to 2.6.7
https://www.illumos.org/issues/2142 https://bitbucket.org/buffyg/illumos-userland-2142/compare/..buffyg/illumos-userland-1248 I've run the test suite for python 2.6.4 and 2.6.7 with gcc 4.4 and studio. It turns out that considerably more modules have problems under studio than gcc, none fail on gcc that don't also fail on studio, but one module (sys) seems to fail slightly differently, which I'll investigate. I've added a further changeset with the test results to make it easy to access them. This changeset will be stripped before commit: https://bitbucket.org/buffyg/illumos-userland-2142/changeset/1f6f784173d5 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 2142 update python2.6 to 2.6.7
On Fri, Feb 24, 2012 at 10:54 PM, Adam Števko adam.ste...@gmail.com wrote: Hi, what about python27? Separate change, which I'm currently bringing across from oracle-userland and submitting as its own issue. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] lingering ghost of runtime/python-24
I noticed that there are a handful of dependencies left. One is onbld, which I think can be fixed now that we've made mercurial use python2.6. The rest look to be from gnome. Anyone feel like diving in? Or perhaps aszeszo's gnome-components work has progressed to the point where we can fix these in userland? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [userland] Re: illumos-userland update
Hi, Kartik, On Mon, Feb 20, 2012 at 7:54 AM, Kartik Mistry kartik.mis...@gmail.comwrote: On Mon, Feb 20, 2012 at 4:36 AM, Bayard G. Bell buffer.g.overf...@gmail.com wrote: We've started expanding on that. See for examples, the documents hanging off: http://wiki.openindiana.org/oi/Building+with+illumos-userland .. and: https://www.illumos.org/projects/illumian/wiki/Building_illumos-userland We should merge these both. Absolutely. Could we start by getting some packages documenting the illumian packaging tools and process? I had a number of questions in my review notes this weekend, and I've been working to get a reasonable amount of documentation about the Makefile infrastructure, which I'd like to follow up with write-ups for the vanilla userland-gae tools and userland-specific packaging info. richlowe's pointed out that the generic IPS documentation is very useful to anyone who has to use IPS, so I reckon we should link that off the packaging tools page. Is there something similar we could link about generic debian packaging tools? Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Next #oi-meeting 21.2.2012 7PM GMT
Agenda will be sent out tomorrow. We have a lot to discuss, as you will have gathered from recent mail and IRC traffic, not to mention leftovers from last week, but if there's anything you feel needs to be discussed as matter of urgency or would like to register now for a future meeting, please don't hesitate to offer your suggestions. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] gcc44 in illumos-userland
I notice that this has a patch 01.illumos.patch that looks like richlowe's patches in full. I believe it may also include RPATH tweaks. Are those patches I think they are? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Thoughts on FOSDEM and the road ahead
On Mon, Feb 13, 2012 at 1:11 AM, Magnus mag...@yonderway.com wrote: On Feb 12, 2012, at 6:22 PM, Bayard Bell wrote: My surmise is that we've got a lot of users who are--I don't want to say conservative but production-centric. We need to help them make the transition from being Sun customers to OI contributors. In my case, I'm coming from Linux (production) and staring wide-eyed at a new (to me) world with a bit of a learning curve to it. My biggest personal stumbling block to contributing more deeply is the state of the wiki right now. There is a little bit of doc here there but it doesn't seem very thorough, linear, or well-maintained in its current state. Documentation is as important as code in some thriving communities, and I would suggest it's a value worth considering giving greater weight to here. As I've been working a lot with userland recently, I tried to take a bunch of my recurring questions and things that I keep having to pull out of various Makefile includes and document them here: http://wiki.openindiana.org/oi/userland+Makefile+targets+and+variables This is still a work in progress. I was also considered providing a few example Makefiles and package manifests in the wiki as illustrations of how to deal with particular problems (a few of the xemacs Makefiles could be useful here, as would the latest version of git), some of which I touched on in this doc. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] review: gcc as primary compiler
What we've been talking about elsewhere is requiring people to have a direct fork of the main development repo for each issue. You're asking us to review changes against dilos-userland, which is itself a fork of dilus-userland-review, which is private. If you want to have dilos-userland as a playground, that's fine, but if it isn't forked in a way that allows direct comparison on bitbucket (e.g. directly off the code base to which you want to commit), you're asking reviewers to accept something other than just what they can readily see. I find that runs contrary to the premise of seeking reviews in the first place. I don't see a compelling rationale for the more complicated arrangement you're created, and you don't see to be offering one. On Mon, Feb 13, 2012 at 10:52 AM, Igor Kozhukhov ikozhuk...@gmail.comwrote: At this moment illumos-userland - it is fork of dilos-userland - changes will be updated correctly. dilos-userland - it is public repo, not a private. -Igor From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Mon, 13 Feb 2012 10:42:43 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] review: gcc as primary compiler As this is also a policy issue, let's finalize this at #oi-meeting. Also, could we please submit changes to userland via forks of the public illumos-userland or oi-build (with the roll-out of illumos-userland under discussion at the next #oi-meeting, one item should be working off it alone going forward)? Using a fork of a private repo that may or may not diverge substantially from what everyone else is using makes it harder for people to evaluate. On Mon, Feb 13, 2012 at 10:30 AM, Igor Kozhukhov ikozhuk...@gmail.comwrote: Hello All, Please review: https://bitbucket.org/dilos/dilos-userland/changeset/5e3079f6ad40 https://www.illumos.org/issues/2113 It is big changeset with changes for setup GCC as default compiler --- Best regards, Igor Kozhukhov IRC# igork ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1638 add a clean urxvt build to oi-build
Redux: https://www.illumos.org/issues/1638 https://bitbucket.org/buffyg/oi-build-1638/compare/..buffyg/oi-build As far as update_utmp goes, I regard it as possibly useful but not strictly necessary. Because it's not fixed, I've simply disabled the functionality in the build. I noticed that 9.15 adds a bit more content than did 9.12, which is what I tested initially. Not sure why, but this time around urxvt decided to install its own terminal definitions, which I've added to the package and both of which I've given cursory tests. In the course of testing that, however, I noticed a different problem, which is that running plain urxvt for a shell causes it to fail at startup because it can't get control of the terminal. I've tracked down the lines that are generating this error, but I've not yet determined the correct behavior or why I have no problems using urxvt with tmux. Before I ask that this be committed, I'd ask whether others are seeing this problem in earlier version and whether most urxvt users are using it in combination with something like screen or tmux that allows for an effective mitigation of this issue. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1639 add ratpoison to oi-build
Updated at: https://bitbucket.org/buffyg/oi-build-1639/compare/..buffyg/oi-build On Fri, Feb 10, 2012 at 8:13 PM, Bayard Bell buffer.g.overf...@gmail.comwrote: There are two bits of glue added for this package, both noted in the Makefile. The first is to explain to GNOME that ratpoison exists and is a window manager, and the second is a clean-up of the man page not to use BSD macros. https://bitbucket.org/buffyg/oi-build/changeset/61dcc0e2f122 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 2105 Allow ARCHIVE_MIRROR to be overridden by environment
If anyone else wants to take a look, here's the updated location: https://bitbucket.org/buffyg/oi-build-2105/compare/..buffyg/oi-build https://www.illumos.org/issues/2105 On Sat, Feb 11, 2012 at 2:35 PM, Josef 'Jeff' Sipek jef...@josefsipek.netwrote: On Fri, Feb 10, 2012 at 05:51:50PM +, Bayard Bell wrote: It's a one-character change: https://bitbucket.org/buffyg/oi-build/changeset/2949d4b903be LGTM ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists. - Abbie Hoffman ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bug 2104: Mangling of PLAT and SOLARIS_VERSION broken
I've done some fixes that should work for sun.* architectures. Please see: https://bitbucket.org/buffyg/oi-build-2104/compare/..buffyg/oi-build On Fri, Feb 10, 2012 at 6:48 PM, Igor Kozhukhov ikozhuk...@gmail.comwrote: I'll try to re-build userland on SPARC with your changes , but it have long time - about 28 hours On intel I have userland build about 6-8 hours. -Igor From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Fri, 10 Feb 2012 18:46:34 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Bug 2104: Mangling of PLAT and SOLARIS_VERSION broken I've already got a bug fix for this one and will include the SPARC bit while I'm at it. I should have xemacs done tonight, which I'll also publish to bitbucket. Would you mind seeing whether it works on SPARC, combined with this change? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1639 add ratpoison to oi-build
On Mon, Feb 13, 2012 at 2:40 PM, Gordon Ross gordon.w.r...@gmail.comwrote: On Mon, Feb 13, 2012 at 8:37 AM, Bayard Bell buffer.g.overf...@gmail.com wrote: On Mon, Feb 13, 2012 at 1:26 PM, Andrew Stormont andyjstorm...@gmail.com wrote: And next question - who can publish illumos-userland on bitbucket ? I don't think we have agreed yet that that is what we're going to do. It will be decided at the next #oi-meeting. I think we decided we wanted to do mirroring to gh and bb for illumos-userland not too long ago, but the conversion of the canonical illumos.org repos to git held that up. Given the git issue, we should revisit this briefly this week. We have illumos-gate on both github and bitbucket (thanks to BDHA) without having converted the gate on illumos.org to git, so it would not appear that converting the master to git is necessary for _this_ issue. (Granted, you might want the master as git for other reasons.) The ops team wanted to defer on setting up the sync because they were looking to do canonical repo git conversions first. From the way conversation here has drifted, I'd think that we'd quite prefer that they not convert illumos-userland to git ATM. Also, when I asked bdha where the mirroring was done, he couldn't find it. I'll get in touch with him for follow-up. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Andy, I'd think we could use the same tools that illumos uses to mirror from their authoritative repo to BitBucket and GitHub. I'd expect there are two non-exclusive ways to approach mirroring: you can add hooks to the canonical repo that cause it to push to the DVCS hubs as part of the commit, or you can have a looser consistency sync with cron, which could catch you up if a sync on canonical commit fails. I think most of the case for git is a case for co-existence. People potentially interested in OI but not previously involved in OpenSolaris are more likely to know git than mercurial, so not having git available is a potential limit for people who aren't sure the project is so cool they want to bother with a first step that's a new tool. For existing developers, there's not enough differentiation between the two that people necessarily want to commit the time to learning how to use git properly because they doubt it will ever save them a comparable amount. I think both sides are right, which is why I favor allowing both. The significant complication between how we approach DVCS and the way illumos does it is that RTI limits the number of commiters. Ideally I'd prefer to be able to take commits via DVCS pull requests and a bit of workflow, which is something else we talked about at the meetup. I also think this makes the commit process a bit less daunting. I've done some research and feel I've got a decent grasp on what we'd need to do to make this work, and you said you had some previous experience with the APIs that you could contribute to getting it to work. How about we put our heads together around the next meeting and sort this out? Cheers, Bayard On Sun, Feb 12, 2012 at 3:28 PM, Andrew Stormont andyjstorm...@gmail.comwrote: I like the idea but I'm not sure how you'd go about setting something like that up. How would you ensure both repositories are kept in sync? The usual method as I understand it is to have one repository as the master and the rest as mirrors – but this doesn't allow you to commit to the mirrors – so they're not really equal. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
2012/2/12 Andrew Stormont andyjstorm...@gmail.com On 12/02/2012 16:06, Milan Jurik milan.ju...@xylab.cz wrote: And about familiarity - shouldn't it be more about usability/simplicity? Hi, Hopefully this will answer your questions http://whygitisbetterthanx.com/# Avert your eyes, children, the bikeshed may assume other forms! The three differentiators with hg are marginal and can in any case be equalized with bookmarks (cheap local branching, which is probably least applicable to us), cadmium (staging area), and BitBucket (GitHub). Again, I think there are enough strengths to both to argue for enabling both (even if there's a cost to that), and I think the strongest thing git has going for it isn't on the list: all the cool kids already know it. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
richlowe's been working on both, but neither are in use with OI. My preference for all of this functionality would be to have the validation done by the pull request. Webrevs could be generated automatically, and the applicable nits would give feedback requesting either that they be resolved for a subsequent pull or by providing quick notes or tick boxes to explain why they aren't strictly necessary. You're provided an issue tracker ID for the submit request, and that tracks these kinds of things and is responsible for generating the webrev and sending out the review mail once issues immediately applicable to the submission are resolved. Workflow would also be responsible for checking CI build and test status as a prereq. An issue tracker could used to provide all the workflow state, but if that's too clunky (or the issue tracker too unreliable), it could be put into a database. That's my cocktail napkin sketch of workflow (or at least the basics--there are other pieces I have in mind), which fuses some stuff I talked about at the illumos hackathon with the floor discussion on the contribution process we had at FOSDEM. On Sun, Feb 12, 2012 at 6:27 PM, Milan Jurik milan.ju...@xylab.cz wrote: Hi Alan, Alan Coopersmith píše v ne 12. 02. 2012 v 10:01 -0800: On 02/12/12 09:29 AM, Milan Jurik wrote: Btw. how is status of cadmium features on git? Like recommit? git rebase is far more powerful useful than cadmium recommit, especially once you learn git rebase --interactive. I know rebase is very powerfull but as recommit is key part of the process, rebase power is also danger. recommit is simple enough to be nearly 100% safe to use by everybody. The cadmium features that are missing from git are the ones more specific to the opensolaris project, such as webrev integration and checking project policy (nits, pbchk, etc.). I think there is support for git in webrev in queue. pbchk support probably not yet. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Sounds about right to me. The other bits we'd need to sort out as per Brussels is some kind of permissioning for established contributors. This would be something like being granted the Developer role for illumos-userland in Redmine and providing the same ssh key both for your Redmine registration and your DVCS hub account (no other ssh keys allowed, such that this confirms that no one is being clever by registering one public key for impersonation and using another to push, although I suppose there might remain a possible time of use/time of check attack). I think it would still be good to have automatically generated webrev generated for everything that clears Jenkins, with a further list mailed for all submissions requiring review. In the context of CI, I think we should have some kind of dependency graph triggered so that any packages that are dependent on the package being changed are also automatically rebuilt and tested, which particularly helps us for components that may not have their own test suites. On Sun, Feb 12, 2012 at 6:44 PM, Andrew Stormont andyjstorm...@gmail.comwrote: Well I guess if we were to slightly modify the new integration process we discussed at Brussels we could achieve this quite easily: Developer pushes to Bit Bucket or Git Hub - Changeset is intercepted and passed to Jenkins for testing - Build completes successfully and changeset is pushed to master repo (illumos.org) - Sync of Bit Bucket and Git Hub repos is triggered. Andrew From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Sun, 12 Feb 2012 17:40:32 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Lets talk about Git On Sun, Feb 12, 2012 at 5:25 PM, Andrew Stormont andyjstorm...@gmail.comwrote: I just want to say straightaway that I apologise. My intention is not to start a flamewar or bike shedding but to merely show that there are benefits to offering git as an alternative to mercurial. I'm sure if the URL was 'whygitisagoodalternativetox.com' I wouldn't need to have to clarify this ;) No need to apologize, my response was meant to be tongue-in-cheek, not trying to escalate this, just to warn that it becomes a bikeshed if we have to choose between the two, which is preferable to avoid. I'm pretty comfortable that we have a reasonable grasp on how to put together a technical solution to co-existence with complete parity. I'd pretty excited about the prospect of working with you to make sure that happens. I don't think we should keep hg around because it's the best in some absolute sense, I think we should keep it around because it's adequate to our needs and conversion requires cat-herding of existing developers that's best avoided. We should maintain perspective: git has momentum and a very large user base because plenty of people do agree that git is better than the alternatives, and we need to respect that by letting people who like it continue to use it. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] new #oi-meeting this Tuesday 7PM GMT
Agenda: 1) new userland mailgroup/repo/project go-live 2) follow-up on gcc discussion 3) openssl-1.0.0 update 4) contribution process and workflow 5) git parity I expect this will be enough to keep us busy for a full meeting and perhaps then some, but if there are other items people would like to discuss, please let me know. Also, I'd appreciate if someone could point me to the meeting bot documentation, as I'm completely unaware of how to operate it. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1638 add a clean urxvt build to oi-build
On Sat, Feb 11, 2012 at 2:50 PM, Josef 'Jeff' Sipek jef...@josefsipek.netwrote: On Fri, Feb 10, 2012 at 07:53:09PM +, Bayard Bell wrote: I know that jeffpc mentioned having a patch for issues with an earlier version, but it wasn't attached to the issue. I don't know, either, if it's still applicable to the recent version to which I've just upgraded. I trust that will come out in the course of review. https://bitbucket.org/buffyg/oi-build/changeset/3b8c1e923e14 utmp_update is broken (it doesn't do what POSIX says it should) and so it's really an illumos bug. I talked with urxvt folks quite a bit about it, and IIRC, they were going to include a workaround. Looking at the Changelog it looks like that didn't happen. The copyright is wrong unless you took this from Oracle. And three small nits... 1) Why the OSOL CDDL header instead of the Illumos CDDL header? I cleaned up the copyright just after submitting. See previous response for rest. 2) Why keep all those commented out lines in there? Ditto. 3) What's the reasoning behind setting $PATH? Copying and generally assuming that most stuff that stuff that builds with gcc is happier preferring GNU tools to SVR4 ones. Jeff. P.S. FWIW, the correct way to fix utmp_update is to rip it out and write it from scratch. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Thoughts on FOSDEM and the road ahead
I had a chance to talk to some people from the user community at the conference, and a lot of them seemed a bit skittish about getting involved in development. The model I talked about with them is creating nuclea about product areas like LAMP, dynamic language, media players. Let users talk about what they're doing with the various pieces of technology we're packaging or that they want packaged. Start with a very loose consistency model: have them share blogs, and let them create special interest group mailing lists to build communities around focused interests. For some people, looking at the broad problems of developing a distro isn't a way in. Talking about production, documenting what they do, and writing code to test product stability around the operational side they know is something they're comfortable doing. Build them up from that. Once they've done it, they realize they can have confidence building and packaging stuff, knowing that they've got a test rig to show them the confidence is well-founded. My surmise is that we've got a lot of users who are--I don't want to say conservative but production-centric. We need to help them make the transition from being Sun customers to OI contributors. They come from an operational background, so grow them into developers using the devops paradigm: focus them on defining quality, then measuring quality, and then moving the software forward. What I'd like to propose to get us there is three things: one is doing a survey of the user community to figure out where they are, what their interests are, and what they expect from the project. My guess is as good as anyone else's, but we're still guessing. Let's form some hypotheses, write a survey that gets us data to evaluate, and get ourselves something we can analyze more conclusively. And let's do that cross-distro for illumos, if possible: OI, illumian, SmartOS, StormOS, etc. Second, let's try to organize a pan-illumos userland hackathon that's also a bootcamp. Let's target OI users and FOSS developers. We teach a package of skills: how to build stuff with OI, how to measure stuff with DTrace, how to test stuff with the unit testing rig Delphix is putting together (I'm assuming we just want to steal this, but maybe I'm wrong), and how to automate the boring stuff with Jenkins. (As much as possible, downplay packaging in the interest of cross-distro unity: here's the common data you have to understand for all of userland, so you know what to grok if gmake publish fails.) If possible, fly in a DTrace rock star. Teach those skills in a day or less, and spend the rest of the weekend using them so that there's immediate practical reinforcement. Let people sign up ahead to work on packages so that they come away from the event with something read to commit and thus a sense of accomplishment on which to build. The Nexenta OSS Europe conference may be the right event to work off of, as it's just far enough in the future that we can make it our goal now and keep ourselves focused making it happen between now and then. We've got people in Belgium, the Netherlands (I got contact info at FOSDEM for the person who used to run the Solaris users group for Holland), Germany, the UK, Denmark, and Central Europe who could our usual suspects. Tell them to bring friends this time. Help developers see us as a growth platform where it's worth their time to engage with us to make sure their software runs well our platform, which helpfully makes that a measurable question. Third, let's designate some people to organize more locally to pull people in. Give those people a private mailing list and let them talk about what's working and what not. There are a number of places we can go to find organizers, and FOSDEM provided some contacts for people willing to do this. Again, let's go pan-illumos on this to get some scale. Encourage them to cross-pollinate their meetings between software users and software developers. Help them focus on DTrace in particular because it intersects so neatly: illumos is the reference platform, but DTrace is more widely available. I talked to a Python developer at the conference who mostly wanted to rave about how great DTrace was, based on his experience of it on OS X. Our hook is that we make quality something you can hold in your hands. That's what our community wants, that's what makes our community valuable to engage. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Thanks for the write-up and diagram, Jeppe. I don't think the idea is that trusted means that a commit goes right to the repo: I think trusted means if it clears CI, it's good to go. Everyone else has to have eyeballs and peer review. Maybe core people can do manual pushes straight to the repo, but I think that must be a separate level of trust from a developer whose put forward some clean commits. Some areas may not be verifiable through CI (e.g. changes to the userland tools themselves), and I'd suggest those should always require peer review. One other thing we need is a set of ground rules about what people should change. In particular, I don't think we want to have a lot of volatility in terms of what functionality is or isn't enabled in a component. We need to set a clear expectation that changing those build characteristics must be done with a dedicated issue and changeset, and I'd suggest that such changes are an area where we might want to maintain some kind of peer review just to check consensus. We may not be able to check that programmatically, but the norm should be that doing an end-run around that means losing developer status and having eyeballs on everything you do. On Sun, Feb 12, 2012 at 9:56 PM, Jeppe Toustrup openindi...@tenzer.dkwrote: To quickly talk through it - new developers first of need to have a user on GitHub. That way they can create a fork of the illumos-userland repository on the site. They should create a new branch on their own fork for each change/package they want to add, since they then can put in a pull request to get the changes from one branch merged into the illumos-userland main repository. When a pull request gets in, it will trigger a build in Jenkins. Jenkins will then write a comment on the pull request with the results of the build. In case it failed, the contributor can work further on the code, and when new commits are added to the branch, it will start a new Jenkins build. When the build gets successful, the pull request will be tagged with needs review, which then requires a moderator/trusted developer to look through the patch and accept it, or let the contributor know of any changes which may be required before we can accept it. For trusted developers, they can choose one of two things (this should probably be up for discussion). 1. Commit directly into the illumos-userland repository, the most direct way of putting stuff in. 2. Create the commits as they normally would, but instead of pushing them directly to illumos-userland, they make a pull request in order to get the commit checked by Jenkins. If the build is successful, we can make Jenkins accept the pull request by checking the user who made the pull request against the list of users with commit access to illumos-userland. Ideally everything should go through a pull request in order to get built by Jenkins so we make sure the code in illumos-userland can be build at all times. It only requires one extra step - to go and create a pull request, which basically just is a matter of clicking a button, and shortly describe what the pull request does. It is however up to the developers if they think this is reasonable or not. -- Venlig hilsen / Kind regards Jeppe Toustrup (aka. Tenzer) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] error in pkg5 - from oi-prestable
I saw that bit, but I was hoping to get the publisher and package version, as well as the hg fingerprint. On Sat, Feb 11, 2012 at 10:06 AM, Jeppe Toustrup openindi...@tenzer.dkwrote: On Sat, Feb 11, 2012 at 10:12, Bayard Bell buffer.g.overf...@gmail.com wrote: I don't get this error with the version I'm using. What version do you have? It's mentioned in the last line of the output :) The version of pkg(5) is '4d886e93dafc' -- Venlig hilsen / Kind regards Jeppe Toustrup (aka. Tenzer) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Bug 2104: Mangling of PLAT and SOLARIS_VERSION broken
I'm a slacker and haven't done the small amount of administrivia to launch the userland list. I am putting forward a number of changes to oi-dev before I sort out the launch properly. Simple bug, straightforward fix: https://bitbucket.org/buffyg/oi-build/changeset/85f430fcb44e ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2105 Allow ARCHIVE_MIRROR to be overridden by environment
It's a one-character change: https://bitbucket.org/buffyg/oi-build/changeset/2949d4b903be ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Bug 2104: Mangling of PLAT and SOLARIS_VERSION broken
I've already got a bug fix for this one and will include the SPARC bit while I'm at it. I should have xemacs done tonight, which I'll also publish to bitbucket. Would you mind seeing whether it works on SPARC, combined with this change? On Fri, Feb 10, 2012 at 6:33 PM, Igor Kozhukhov ikozhuk...@gmail.comwrote: Ok, I'll check your changes on my Intel and SPARC systems and let you know. -Igor From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Fri, 10 Feb 2012 18:01:28 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Bug 2104: Mangling of PLAT and SOLARIS_VERSION broken I didn't have a SPARC box around to check. My preference would be to set ALTPLAT to sun, given what the generate-cleanup line does. On Fri, Feb 10, 2012 at 5:52 PM, Igor Kozhukhov ikozhuk...@gmail.comwrote: Hi Bayard, You changes contain fix for Intel platform - what about SPARC ? I can see on sparc: # uname -m sun4u How it will be fixed for SPARC ? On intel: $ uname -a SunOS srv240 5.11 72e00c9a704b i86pc i386 i86pc Solaris On SPARC: # uname -a SunOS srv210 5.11 eab0c2354e82 sun4u sparc SUNW,Sun-Blade-2500 Solaris Will be better to have fixes for Intel and SPARC. Best regards, -Igor From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Fri, 10 Feb 2012 17:47:40 + To: oi-dev@openindiana.org Subject: [oi-dev] Bug 2104: Mangling of PLAT and SOLARIS_VERSION broken I'm a slacker and haven't done the small amount of administrivia to launch the userland list. I am putting forward a number of changes to oi-dev before I sort out the launch properly. Simple bug, straightforward fix: https://bitbucket.org/buffyg/oi-build/changeset/85f430fcb44e ___ oi-dev mailing list oi-dev@openindiana.orghttp://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2106 bring xemacs into userland
The packaging is slightly tricky because there are two further sets of lisp packages to make xemacs properly useful. I've packaged them separately in case people want a really minimal install but also provided metapackages (editor/xemacs/xemacs-gnome-full, editor/xemacs/xemacs-x11-full, and editor/xemacs/xemacs-nox11). There's a bit of overlap between emacs and xemacs, so for the time being I've made the latter depend on the former. A follow-on change would be to patch so that the shared executables have an alternate name under xemacs and are called by those names from it (this is what Debian appears to do). https://bitbucket.org/buffyg/oi-build/changeset/0f759efa96bd ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 1638 add a clean urxvt build to oi-build
I know that jeffpc mentioned having a patch for issues with an earlier version, but it wasn't attached to the issue. I don't know, either, if it's still applicable to the recent version to which I've just upgraded. I trust that will come out in the course of review. https://bitbucket.org/buffyg/oi-build/changeset/3b8c1e923e14 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1639 add ratpoison to oi-build
I'm not sure I understand the question: you're asking that the issues be updated with the URL of the proposed changeset? Given that those are fluid and that reviews are currently mail-driven but low volume, seems kind of a hassle. On Fri, Feb 10, 2012 at 10:00 PM, Igor Kozhukhov ikozhuk...@gmail.comwrote: Could you please update all bugs with your URL to bitbucket - will be easy find it for review with bugs -Igor From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Fri, 10 Feb 2012 20:13:37 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: [oi-dev] 1639 add ratpoison to oi-build There are two bits of glue added for this package, both noted in the Makefile. The first is to explain to GNOME that ratpoison exists and is a window manager, and the second is a clean-up of the man page not to use BSD macros. https://bitbucket.org/buffyg/oi-build/changeset/61dcc0e2f122 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2109 IPS_PKG_NAME in sample-manifest doesn't exist
https://www.illumos.org/issues/2109 https://bitbucket.org/buffyg/oi-build/changeset/e7d53695fdae ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] REMINDER: Weekly Meeting on Tuesday Jan 17th at 19:00 UTC
We'll be starting shortly on #oi-meeting. On 16 Jan 2012, at 14:56, Bayard G. Bell buffer.g.overf...@gmail.com wrote: Please note that this is an earlier slot to allow contributors in Russia to participate. The only item already on the agenda is gcc for use in illumos-userland (aka oi-build). We can take other items, as long as they're brief, as this one is likely to be long. I've CC'ed Rich Lowe individually, as there are a number of us who would appreciate any expertise he can offer on the work he's been doing to get a patched gcc 4.4 to build illumos-gate. As time allows, I'll send out notes on preliminary discussions of gcc support issues at recent meetings. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 5 Jun 2011, at 16:31, Volker A. Brandt wrote: I think we need tools that then turn into getting people involved in documentation, this is an opportunity where we need to understand how we capitalise on that for further opportunity. You've expressed some interest in contributing to documentation: what would get you to become involved in this capacity? While the question was directed at Ken Gunderson, I can answer for myself that it's a question of available time. So the best tools would be those that provide easy access, a not-too-steep learning curve, and the opportunity to work on things on and off, not having to do elaborate setup tasks each time. Thank you, that's very helpful feedback. Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
Tobias, I was just discussing this with Deano on IRC... My proposed litmus test is this: my girlfriend is willing to spend some time this summer helping out the project as a tech writer (she's got a background in speciality editing, although not as specialised as IT or *nix in particular). I'm pretty much with Garrett: the problem isn't that we using DocBook and should be using something else instead. If someone is interested in writing documentation, the question seems to be is there a mature toolset whose learning curve we can reduce to get someone willing able to be productive quickly. The issue is mostly one of front-end tools, and the question would thus be whether we can allow most editing to happen in a really simple format that can be marked up to DocBook for interchange, as a format that can be consumed by a PDF reader, a browser, or man. Alasdair's offered similar feedback recently. The DocBook people recognise as much: looking through some of the DocBook sites, I found the following remark: DocBook has the vices that go with its virtues. Some people find it unpleasantly heavyweight, and too verbose to be really comfortable as a composition format. That's OK; as long as the markup tools they like (things like asciidoc or Perl POD or GNU Texinfo) can generate DocBook out their back ends, we can all still get what we want. It doesn't matter whether or not everybody writes in DocBook — as long as it becomes the common document interchange format that everyone uses, we'll still get unified searchable documentation databases.[1] The premise should be what simple format we can use to generate DocBook for what I'd take to be the very simple bulk of documentation tasks, preferably using a wiki-like editor. Doing some very brief research, I came up with Scroll Wiki Exporter, which would allow us to export documentation from the Confluence wikis we're already using for OI and Illumos.[2] One way or another, the topic does seem ripe for discussion. If you're game to work with us through the decision process into implementation, how about we schedule you for a coming oi-meeting? Cheers, Bayard [1] http://tldp.org/HOWTO/DocBook-Demystification-HOWTO/x57.html [2] https://plugins.atlassian.com/plugin/details/7019 On 30 May 2011, at 05:24, Garrett D'Amore wrote: Switching to another less popular doc format doesn't seem like a great idea. I don't work with the documentation frequently, but I'd ask people that do. One thing is that some of these formats are like fads... they come and go. I remember not long ago when SGML was all the rage. :-) From my perspective it would be good to have a format that has good tools available (multiple implementations, at least some of which are portable to other platforms), displays nicely, and provides some basic structure capabitilities to assist in parsing for content or format conversion (e.g. to HTML). If you make me install a bunch of new tools, or learn a format that nobody else uses, I probably will be less inclined to write documentation. (That said, I've not written much except a few man pages, and the format of *those* is relatively constrained by the need to be able to display them with the man command. :-) -- Garrett D'Amore On May 30, 2011, at 2:22 AM, Tobias Famulla u...@famulla.eu wrote: Dear all Developers, As I mentioned on the Discussion-List(see below), I had the idea of transforming the OpenSolaris-documentation to another system and change some parts to the OpenIndiana specific behaviors. Deano wrote on the Discussion-list, that it might be more helpful, to discuss the pros and cons of different systems and especially asking for people who also write the discussion and maintain it afterwards. I think I am not able to maintain such documentation, because I am very new to the OpenIndiana and Solaris operating system and such developement process as a whole. Because of that, I would ask on this list, if anybody sees the importance of an documentation, sees advantages of a special documentation system and would be able to maintain it. The other question is of course, whether the below described idea is an good one, or work on another part would be more helpful. Sincerely, Tobias Original-Nachricht Betreff: [OpenIndiana-discuss] Documentation-Project Datum: Thu, 26 May 2011 15:54:36 +0200 Von: Tobias Famulla e...@famulla.eu Antwort an: Discussion list for OpenIndiana openindiana-disc...@openindiana.org An: Discussion list for OpenIndiana openindiana-disc...@openindiana.org Hello OpenIndiana-Community, I am in an Open-Source-seminar at University, in which we have to hold a presentation about an Open-Source project and participate in the development-process of this project. I chose OpenIndiana for this Course, because I think it is an interesting young project and the developement of a free Solaris
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 30 May 2011, at 18:56, Ken Gunderson wrote: Anywh... I've not checked those links yet but in general would avoid wiki markup. Interesting exception here possibly being since we're using Atlassian wiki already hmmm. This is trouble with the low hanging fruit - it tends not to withstand the test of time. The advatage of SGML and subset docbook is that they do - with cost of higher bar of entry. Why can't we have out cake and eat it too?? Latex might be worth a closer look as I suspect there are lots of FOSS gui'zed editors out there. Ease of use when needed for cranking out text and also power for power user when needed? Hmmm. Else I do think Docbook would be best, even if initial bar is a bit higher. It would not be unlike Solaris in that regard and most folks hereabouts seem capable of dealing with it. I'm not sure you've understand my premise: I'm not suggesting that we reduce editing to using wikis, just that wikis can be a very usefully simplifying front-end for content that can be exported to DocBook and then republished into other formats we need. I'd bet that with a bit of nursing, we can get some of the macros we want for things like man pages working just fine in a wiki so that it's not even a question of leaning heavily on wiki markup per se. I don't mean to suggest that wiki authoring is a 100% solution, as I don't think there is a 100% solution for this in terms of editing tools. I do, however, think that we should be trying to maintain as much content as possible with a front end system that has the lowest barrier to entry in terms of toolset complexity and reserve more complex tools for content for which it is absolutely necessary. As per the cite already provided, DocBook is perfectly happy to see itself as an interchange format, so we can afford to use a range of tools, as long as that doesn't create confusion in its own right. Cheers, Bayard smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 30 May 2011, at 20:13, Alan Coopersmith wrote: Yes - SolBook is still used as the source markup, from which the nroff output is generated for man pages in the OS, and the html pdf output for the site formerly known as docs.sun.com. The DTD is in the ON gate/packages - see /usr/share/lib/sgml/locale/C/dtds/solbookv2 from pkg:/text/doctools . For what it's worth, most of the html/pdf/txt docs on http://www.x.org/releases/X11R7.6/doc/ were generated from Docbook/XML on a Solaris 11 Express machine, though I did have to install a couple extra open source packages that aren't currently in any of the consolidations/package repos: https://fedorahosted.org/xmlto/ http://xmlgraphics.apache.org/fop/ as well as updating to a slightly newer version of the Docbook style sheets than the JDS consolidation currently packages. Personally, I just use emacs to edit docbook files, but I do the same for html too, never having found (or looked that hard for) a more user-friendly front end editor. Tales from the trenches are extremely helpful, thanks, Alan. I did a little searching around, trying to get a sense of how people who were maintaining documentation for large project, either as developers or as tech writers saw the state of the art. Here's a fairly random sample, which also provides some incidental name-dropping to give a sense of where different formats are being used: http://www.scons.org/wiki/DeveloperGuide/Documentation/Discussion http://freerangelibrarian.com/2009/06/07/docbook-xml-and-homebrew/ http://lethargy.org/~jesus/writes/xmlxslt-and-docbook-for-docs http://blog.raspberry.nl/2011/04/12/documentation/ http://ffeathers.wordpress.com/2009/05/18/scroll-converts-wiki-to-docbook-and-pdf/ https://docs.jboss.org/author/display/AUTHGUIDE/How+to+release+documentation http://www.dmncommunications.com/weblog/?p=199 http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/034044.html http://mark-story.com/posts/view/generating-documentation-with-sphinx If anyone else has some points of reference that speak to what's worked for whom where, please share. smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] seeking a modestly brave soul to run some basic benchmarks
After seeing OI/Illumos on VBox suck wind compiling, I've had a chat with some of their developers on #vbox-dev about the problems I'm seeing. They're receptive and simply want to see reproducible simple test cases. Their preferred case is the time to compile VBox OSE itself on a guest. I ran a simple benchmark: compare a guest with 2 vCPUs and 2GB to a guest with 4 vCPUs and 4 GB. The hosts are bloomington and indianapolis, respectively. I ran the compilations twice, with a clean target between the two, just to see if there was any improvement on a second run. Here's what I got from timex: first run result on blooomington real 27:26.03 user 31:39.80 sys11:24.31 second run results on bloomington real 37:08.96 user 36:17.43 sys17:06.48 first run result on indianapolis real 58:50.34 user 1:29:07.86 sys 1:21:58.30 second run result on indianapolis real 1:03:52.51 user 1:41:24.83 sys 1:47:03.53 The degradation going from 2 to 4 vCPUs is consistent with what I've seen previously, and the VBox devs agree that this looks off. Their only concern before proceeding is that my host OS is OS X, which is the least performant and supported host OS for VBox. They'd simply like to see the results reproduced on a 64-bit Solaris, Linux or Windows host with a vaguely comparable hardware baseline (I've got 2x4-core 2.8GHz CPUs with 24GB memory: I'm sure you can do with as little as 8GB if the system isn't running anything else). My guest install is freshly updated pkg.oi.o/dev-il, upgraded from oi-dev-148-text-x86.iso. The build instructions have been updated in response to my queries about dependency information: http://www.virtualbox.org/wiki/Solaris%20build%20instructions The only correction I'd make is that the configure line for Qt4 should be (IIRC): ./configure -v -platform solaris-g++-64 -shared -stl -largefile -sm -qt-libjpeg -qt-libpng -qt-libmng -qt-zlib \ -prefix /opt/vboxose-qt \ -I/usr/include \ -I/usr/X11/include \ -I/usr/X11/share/include \ -I/usr/sfw/include And the configure line for VBox itself should be: ./configure --disable-hardening --with-qt-dir=/opt/vboxose-qt Even if people have no interest in using VBox themselves, please consider that people will be trying out OI on VBox and that they are not likely to adopt if what seems like it should be a well-provisioned guest performs as though hog-tied. Also, please feel free to alert me to anything I've missed up to now. Cheers, Bayard smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gates, queues
One other keepalive on this thread is that I'd really like for us to move to using ssh as the primary means for publishing source, at least for clone/pull. HTTP is fine for browsing/eyeballing, but anyone who means to build off the source should be able to do server authentication as an integrity measure, which means either ssh or https. This protects against things like name service-based MITM, which is quite easy to do (additional note: nice if we got DNSSEC going for openindiana.org). Following the line of thinking even as it becomes a distinct question from source structure and integrity: as we're trying to improve our security posture in rolling out stable, I'd at least suggesting releasing stable with signed packages, so that binary distribution is also protected, albeit by cryptographic protection of the packaging envelope rather than transport integrity. I don't have experience of the latter, but a) I have some background with cryptography and willing to learn new applications and 2) suspect that Triskelios and others from Illumos will have some experience of it from within Sun/Oracle. We can discuss on #oi-dev and/or at the next meeting. I reckon the EC folks have their hands full at the moment, so I thought it better to post notes here as I'm thinking these things through rather than pumping them onto IRC. On 24 May 2011, at 17:00, Bayard Bell wrote: I'm bumping this, as part of the problem that needs sorting is where to manage security patches that need doing around 151. I had an agenda item for last week's meeting to discuss this. Hopefully we'll be able to discuss this at today's meeting (which *is* happening? ;-). On 18 May 2011, at 18:54, Bayard Bell wrote: Just a couple of notes as I've been been a bit frustrated with the way that merge queues are used in OI. I've got nothing against merge queues, it just seems that the source should be offered with merges already done. OI source should be accessible in the repos for cloning or browsing without requiring someone to merge. That's not to say that the patches shouldn't also be just as accessible, as well as the upstream source. It doesn't seem auspicious to me that the top of the OI builds docs contain a pointer to a page on using MQ. What I'd prefer to see is a source namespace that looks like: hg.openindiana.org\ upstream\ illumos-gate\ onnv_147\ [etc.] userland-gate\ build-165\ [etc.] [etc.] oi\ illumos-gate\ oi_147\ [etc.] userland-gate\ oi_147\ [etc.] mq\ illumos-gate\ onnv_147-oi_147\ [etc.] userland-gate\ build-165-oi_147\ [etc.] If people want to see what's in OI or pull OI source, there it is. OI releases under active development may be a separate case that require people to pull merge queues. I've also been thinking about how to maintain patches for CVE audits/incident response going forward. What I'd suggest, building on the previous suggestion is just to have a second series of merge queue that goes on top of an OI release and is regularly merged into the release, so that it can remain private. Thus: sec_mq\ illumos-gate\ oi_147\ [etc] userland-gate\ oi_146 [etc.] I'll admit some of this is just plain branding: OI, as source should be able to be somewhat self-referential. If people want to understand how it works back upstream, fine, but the current system comes across to me as a bit baroque. I'm sure I don't entirely appreciate the reasoning of the current system, but hopefully your responses will get me there. Cheers, Bayard smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gates, queues
On 25 May 2011, at 13:39, Jesus Cea wrote: On 25/05/11 13:54, Garrett D'Amore wrote: illumos is already using ssh as the primary hg mechanism, fyi. Seems to work far better than http. I use HTTPS, with hostfingerprints in the configuration (hg 1.7.x). I don't want SSH because firewalls and because I don't want to mess with users on this machine. Garrett, what far better working are you seeing using mercurial with SSH?. I'm not sure I see an abiding objection here: hg.illumos.org is published via ssh, and, among other virtues, it just works. There are also https mirrors and git/https for people who need to deal with firewall issues or want to fetch with a different SCM. As long as there's a mirror that provides something like https support, do you really care whether the primary repo is https vs. ssh? smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gates, queues
I'm bumping this, as part of the problem that needs sorting is where to manage security patches that need doing around 151. I had an agenda item for last week's meeting to discuss this. Hopefully we'll be able to discuss this at today's meeting (which *is* happening? ;-). On 18 May 2011, at 18:54, Bayard Bell wrote: Just a couple of notes as I've been been a bit frustrated with the way that merge queues are used in OI. I've got nothing against merge queues, it just seems that the source should be offered with merges already done. OI source should be accessible in the repos for cloning or browsing without requiring someone to merge. That's not to say that the patches shouldn't also be just as accessible, as well as the upstream source. It doesn't seem auspicious to me that the top of the OI builds docs contain a pointer to a page on using MQ. What I'd prefer to see is a source namespace that looks like: hg.openindiana.org\ upstream\ illumos-gate\ onnv_147\ [etc.] userland-gate\ build-165\ [etc.] [etc.] oi\ illumos-gate\ oi_147\ [etc.] userland-gate\ oi_147\ [etc.] mq\ illumos-gate\ onnv_147-oi_147\ [etc.] userland-gate\ build-165-oi_147\ [etc.] If people want to see what's in OI or pull OI source, there it is. OI releases under active development may be a separate case that require people to pull merge queues. I've also been thinking about how to maintain patches for CVE audits/incident response going forward. What I'd suggest, building on the previous suggestion is just to have a second series of merge queue that goes on top of an OI release and is regularly merged into the release, so that it can remain private. Thus: sec_mq\ illumos-gate\ oi_147\ [etc] userland-gate\ oi_146 [etc.] I'll admit some of this is just plain branding: OI, as source should be able to be somewhat self-referential. If people want to understand how it works back upstream, fine, but the current system comes across to me as a bit baroque. I'm sure I don't entirely appreciate the reasoning of the current system, but hopefully your responses will get me there. Cheers, Bayard smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] gates, queues
Just a couple of notes as I've been been a bit frustrated with the way that merge queues are used in OI. I've got nothing against merge queues, it just seems that the source should be offered with merges already done. OI source should be accessible in the repos for cloning or browsing without requiring someone to merge. That's not to say that the patches shouldn't also be just as accessible, as well as the upstream source. It doesn't seem auspicious to me that the top of the OI builds docs contain a pointer to a page on using MQ. What I'd prefer to see is a source namespace that looks like: hg.openindiana.org\ upstream\ illumos-gate\ onnv_147\ [etc.] userland-gate\ build-165\ [etc.] [etc.] oi\ illumos-gate\ oi_147\ [etc.] userland-gate\ oi_147\ [etc.] mq\ illumos-gate\ onnv_147-oi_147\ [etc.] userland-gate\ build-165-oi_147\ [etc.] If people want to see what's in OI or pull OI source, there it is. OI releases under active development may be a separate case that require people to pull merge queues. I've also been thinking about how to maintain patches for CVE audits/incident response going forward. What I'd suggest, building on the previous suggestion is just to have a second series of merge queue that goes on top of an OI release and is regularly merged into the release, so that it can remain private. Thus: sec_mq\ illumos-gate\ oi_147\ [etc] userland-gate\ oi_146 [etc.] I'll admit some of this is just plain branding: OI, as source should be able to be somewhat self-referential. If people want to understand how it works back upstream, fine, but the current system comes across to me as a bit baroque. I'm sure I don't entirely appreciate the reasoning of the current system, but hopefully your responses will get me there. Cheers, Bayard smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Fwd: [oi-infra] distribution integrity measures
Quick word about me: I've worked previously in Unix security for a financial services multinational. I'm an MSc candidate in Computer Security and Forensics and will be working for Illumos SoC on IKE this summer. I'm happy to help sort this out. Cheers, Bayard Begin forwarded message: From: Alasdair Lumsden alasdai...@gmail.com Date: 28 April 2011 12:20:03 GMT+01:00 To: OpenIndiana Infrastructure mailing list oi-in...@openindiana.org Subject: Re: [oi-infra] distribution integrity measures Hi Bayard, Probably not - OI Infra is for those people looking after the server instances, of which there aren't that many people at present. I'd recommend re-posting to oi-dev! Cheers, Alasdair On 28 Apr 2011, at 10:39, Bayard Bell wrote: Have I contacted the right list for this question? On 23 Apr 2011, at 15:41, Bayard Bell buffer.g.overf...@googlemail.com wrote: I've been getting up to speed on OpenIndiana/Illumos, and one of things that's struck me so far is what I take to be gaps in distribution integrity measures. I thought I'd start with oi-infra rather than oi-discuss, as this list seems to have more direct ownership. This is a first post, so please forgive me if this isn't the right forum. What I've noticed is a number of variations on the basic problem that there are quite a lot of opportunities to MITM downstream consumers via name-service based attacks or, what is rather less of a risk, session hijacking, creating risks of arbitrary content injection. My recollection is that OpenSolaris signed packages and made extensive use of ssh keys to provide mitigations, and there don't appear to be equivalent measures in OpenIndiana release or package distribution and source mirrors, many of which provide neither transport security nor signing. (Just to summarise what I see: OpenIndiana packages aren't signed, the OpenIndiana mirror of the Illumos source is only available by plain http, mirrors seem to rsync unsigned content without transport security, and the checksums for the distribution ISOs are only available by plain http.) My question is more or less whether this is a known and accepted risk that reflects where the project is in coming up to speed or something more of an oversight. Cheers, Bayard ___ oi-infra mailing list oi-in...@openindiana.org http://openindiana.org/mailman/listinfo/oi-infra ___ oi-infra mailing list oi-in...@openindiana.org http://openindiana.org/mailman/listinfo/oi-infra smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: This is a digitally signed message part ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
