Re: [oi-dev] Resignation
A related issue however is the apparent lack of ownership over the wiki. In terms of ownership, EveryCity is providing free hosting of various bits of OpenIndiana physical infrastructure, but it's down to the OpenIndiana project to determine who has ownership. There is a gulf here that nobody has stepped up to fill after my resignation. Keith Wesolowski quipped a joke about OI, referring to it as the Bernie Lomax distribution, which I think is quite apt: https://en.wikipedia.org/wiki/Weekend_at_Bernie's I don't think the project is going to succeed unless the various interested parties come together and figure out who is responsible for what. People are going to have to step up and take responsibility, otherwise it's just a lot of complaining and hot air about how nothing is happening. Regarding the wiki directly, various people, myself included, have admin accounts and can create more. If you're volunteering, I'm happy to set you up with one. If you want access to the zone confluence is running in, I can provide that also. Not that I'm involved any more and I largely just lurk, but I think the disconnect between /dev and /hipster needs to end. It's confusing. I have proposed for years now that: /hipster = rolling release /dev = snapshots of /hipster /release = /periodic snapshots of /dev that are considered more stable For example you could do automatic /dev releases every 2 weeks. /release can come out once a year, and in the month running up to a /release, you can focus on fixes rather than new features. Easy, simple. It does mean /dev and Jon Tibble's effort making way for Andrzej/ALP/etc's hipster effort. The first /release could be based on /dev as is now, but after that, my personal opinion is that Jon Tibble should help with the hipster effort. Perhaps in particular with ensuring quality /release releases and managing that bug fixing process. Also some of the peanut gallery posts on this mailing list make me want to throw up. I don't think anyone should be allowed to attend an OI meeting unless they have contributed at least X months worth of commits to the OI github account. 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. The project is on life support. Commit or GTFO. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] flowcontrol 10Gbe intel x520
Hi Randy, Your best bet is to mail the illumos mailing list - none of the illumos developers hang out on the oi-dev mailing list, this list is for distribution work (i.e. packaging etc). To test the patch on that issue, you'd have to rebuild illumos-gate and install the resulting packages. Cheers, Alasdair From: sim@live.nl To: oi-dev@openindiana.org Date: Sat, 26 Apr 2014 23:44:48 +0200 Subject: Re: [oi-dev] flowcontrol 10Gbe intel x520 I found the following issue regarding this nic.Can anyone tell me if the fix in this document has been implemented yet or what the status isIt seems to solve my problem (if it is a stable fix).If somebody could give me a short mini howto on implementing / testing this? https://www.illumos.org/issues/4063 Regards, RFrom: sim@live.nl To: oi-dev@openindiana.org Date: Sat, 26 Apr 2014 12:25:35 +0200 Subject: [oi-dev] flowcontrol 10Gbe intel x520 Hi all,I hope this is readable . Using an OI 151a7 I'm trying to turn off flowcontroll on an Intel X520-DA2 10Gbe nicI have put flow_control = 0; in /kernel/drv/ixgbe.conf and also done:dladm set-linkprop -p flowctrl=no ixgbe0 results after reboot: dladm show-ether -x ixgbe0 LINKPTYPESTATEAUTO SPEED-DUPLEX PAUSE ixgbe1 current up yes 10G-f bi-- capable -- yes 1G-f,100M-f bi--adv -- yes 1G-f bi-- peeradv -- no-- none == dladm show-linkprop -p flowctrl ixgbe0 LINK PROPERTYPERM VALUE DEFAULTPOSSIBLEixgbe0 flowctrlrw no no no,tx,rx,bi ===The second output seems ok, but the first puzzles me. Als the dladm command doesn't show any immediate effect, I think it doesn't work. question on: can somebody clarify to me if flowcontrol is now turned off or not? And if not, what do I have to do to turn it off? I know that there were issues with the ixgbe driver in OI151a7, can this have something todo with that? If this is solved in a9, how would I go about adding the a9 driver to this a7 system (if thats's possible). Greetings, ___ 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] [OpenIndiana-New-developers] Greetings
I'm not exactly sure. I've been using a UNIX-like operating systems for the past 15 years personally and professionally in one form or another. I've followed the free and open source movement for as long. I've always wanted to contribute to a FOSS project but I've never had the time. Now, I find myself with a lot of time and was looking for a project that I could contribute to. I can program in: Shell, C and Lisp relatively well; I'm a quick study. I poked around the OpenIndiana site for where help was needed but didn't find anything. Perhaps you could point me in the right direction? Hi Scott, Sorry for the delay in getting back to you! The OpenIndiana site is quite out of date. The wiki is a bit better, but it's also very out of date. So I'd say the quickest way to get involved is probably to hop onto #oi-dev and #illumos on irc.freenode.net - this way you can chat in real time with the devs. I myself aren't involved at all as a developer although I hang around pointing people in the right direction occasionally. The main area of development is on the /hipster branch (not sure if you're familiar with this). You can see the Git repo here: https://github.com/OpenIndiana/oi-userland Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [HEADSUP] gstreamer is rebuilt,
I never agreed with SFE shipping packages to the system namespace. Conflicts and a general mess was inevitable. They should have shipped to /opt/sfe or similar. Date: Tue, 18 Mar 2014 12:39:10 -0400 From: g...@genashor.com To: a...@rsu.ru; oi-dev@openindiana.org Subject: Re: [oi-dev] [HEADSUP] gstreamer is rebuilt, On 03/18/2014 10:15 AM, Alexander Pyhalov wrote: On 03/18/2014 16:54, Gary Gendel wrote: There is a conflict between the new gstreamer packages and sfe so ffmpeg cannot be installed after updating gsteamer. in sfe-encumbered ffmpeg depends on libschroder which depends on orc. Gstreamer has orc which conflicts with sfe-encumbered. Gary Hello. What do you mean by 'gstreamer has orc'? I think you mean that gstreamer/plugin/base and gstreamer/plugin/good depends on developer/orc. SFE provides system/library/orc. This inconsistency in naming leads to a conflict. Is your system/library/orc coming from SFE? The other issue is that in /dev system/library/orc is at 0.5.11 version now. So we have to use fictive package version to allow updates /dev = /hipster. snip # pfexec pkg install ffmpeg Creating Plan (Checking for conflicting actions): \ pkg install: The following packages all deliver file actions to usr/include/orc-0.4/orc/orcdebug.h: pkg://sfe/system/library/orc@0.4.16,5.11-0.151.1.5:20120806T214221Z pkg://openindiana.org/developer/orc@0.4.17,5.11-2014.0.0.0:20140225T205246Z These packages may not be installed together. Any non-conflicting set may be, or the packages must be corrected before they can be installed. snip ___ 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] Git or Mercurial?
Hi Jim, You're pretty much right on all of that - github.com/illumos/illumos-gate is the main source for illumos. Some OI stuff has made its way onto https://github.com/openindiana However much of the legacy OI stuff is still on http://hg.openindiana.org illumos-gate build instructions should reference the github one. OI stuff relating to /hipster should reference github, whilst the /dev stuff probably still the old hg stuff. Date: Thu, 13 Mar 2014 16:45:43 +0100 From: jimkli...@cos.ru To: oi-dev@openindiana.org Subject: [oi-dev] Git or Mercurial? Hello all, Many instructions on both the illumos and OI wikis (including some pages compiled by myself a couple of years ago) describe Mercurial (hg) as the way to fetch the illumos-gate sources. How up-to-date is this information? I believe the active development repository for both projects has gone over to GitHub, with its simplicity of forks etc., and the hg.illumos.org replicates (checks out/updates) from the Git master version. Is this understanding correct? In consequence, should the Wiki instructions be updated to promote the GitHub (original gate or private forks) as the suggested way to go (in particular, to easily publish and share fixes and developments made by this developer), with HG being a legacy option? Thanks, //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
[oi-dev] Test
test ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] threaded perl and possible troubles
Hey Alexander, Date: Wed, 26 Feb 2014 23:23:25 +0400 From: a...@rsu.ru Hello. It looks like mod_perl 2.0.8 for Apache 2.4 requires threaded perl. Do I understand correctly that after rebuilding perl with -Duseithreads we have to rebuild all perl 5.16-dependent binary modules (luckily, they are in the gate)? What about other software? How does it depend on this? Regarding rebuilding binary modules, I don't know - that may be a question for the Perl mailing lists. A lot of the dependencies below may just be wanting the interpreter, rather than being a binary module? pkgdepend knows to look at the hashbang at the top of scripts. Cheers, Alasdair Software, which depends on perl 5.16: PACKAGE pkg:/backup/zetaback pkg:/benchmark/filebench pkg:/communication/im/pidgin pkg:/database/percona-server-55/tests pkg:/database/postgres-84/language-bindings pkg:/database/postgres-93/language-bindings pkg:/desktop/xscreensaver pkg:/desktop/xscreensaver/hacks pkg:/developer/build/automake-110 pkg:/developer/build/automake-111 pkg:/developer/versioning/git pkg:/file/mc pkg:/image/graphviz/graphviz-perl-516 pkg:/library/perl-5/database-516 pkg:/library/perl-5/libwww-perl-516 pkg:/metapackages/build-essential pkg:/network/chat/irssi pkg:/network/ipfilter pkg:/print/filter/a2ps pkg:/print/psutils pkg:/runtime/perl-516/module/sun-solaris pkg:/service/database/postgres-84/language-bindings pkg:/service/database/postgres-92/language-bindings pkg:/shell/parallel pkg:/system/fault-management/eversholt-utilities pkg:/system/management/snmp/net-snmp pkg:/system/network/ppp pkg:/text/convmv pkg:/web/proxy/squid pkg:/web/server/apache-22/module/apache-perl -- System Administrator of Southern Federal University Computer Center ___ 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] /dev - /hipster update
Date: Fri, 21 Feb 2014 14:59:04 +0400 From: a...@rsu.ru snip Good day. I've been working on updates to several packages in /hipster which are older than in /dev. This work is necessary to allow /dev - /hipster updates. Current status is shown here: https://docs.google.com/document/d/1teq-uByT4z1wojY74B8J-r35zeLa1CpuEXaBQWhqikY/edit Excellent work! :-) Have you thought about pkgrecv-ing the dependents from /dev to /hipster, rather than rebuilding? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
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: http://github.com/illumos/illumos-gate/graphs/contributors?from=2013-02-17to=2014-02-16type=c Given that SchillixON has 1 collaborator, is it not possible that the barrier to collaboration between yourself and illumos is not illumos, but you? It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, and/or no packaging at all. Well, where is the SVr4 package meta data in Illumos? Note that IPS meta data is limited compared to Svr4 package meta data and for this reason, there is no way to convert meta data correctly. illumos is not a distribution. It carries packaging metadata in IPS format as a convenience for downstream distributions, but downstream distributions are not obliged to use IPS. Perhaps in the future illumos will stop shipping package metadata completely. Many other illumos based distributions use other package formats, such as rpm, deb and SVR4. Ultimately, packaging is a distribution specific implementation detail. If you wish to use SVR4 in SchilliX, you are free to do so. Nobody is stopping you. snip Illumos would need to verify first that Illumos is collaborative. Currently we have the unfortunate state that Illumos did not include some software even though this was promised and a code review has been presented. Colaboration of course also means that partners are trustworthy and implement promises. Once Illumos turned into a trustworthy and collaborative entity, it makes of curse sense to file bugs against Illumos. Illumos is very collaborative. A diverse array of individuals and organisations successfully collaborate on illumos every day: https://github.com/illumos/illumos-gate/graphs/commit-activity Illumos has a clearly defined contribution process: http://wiki.illumos.org/display/illumos/How+To+Contribute If you want to collaborate, you have to follow the procedure. Everyone does. If you're not prepared to follow the procedure, then that's your problem, and nobody else's. If you correctly follow the procedure, and the community decides it doesn't want that specific feature, the mature adult thing to do is to accept this and move on and continue to attempt to collaborate on other items. Forking illumos as SchilliX-ON because you can't follow procedures or because people don't want a specific feature integrated is petty and childish. Then complaining about it for years afterwards on mailing lists is further evidence of stunted emotional development. If you want to collaborate, collaborate and follow the god damned procedure. Otherwise, stop bothering everyone on these mailing lists. Regards, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] GSoC? Decision time....
Date: Fri, 14 Feb 2014 15:23:51 + From: keith.wesolow...@joyent.com snip But I guess that's just me. Bluntly, leading with OI or treating it as special is thoroughly and uncompromisingly insane. Pretending that, in 2014 no less, achieving desktop application parity with 1997 GNU/Linux is an important goal in operating systems development probably covers half the syndromes described by the DSM-5. In the community I *thought* we were a part of, that's a nonissue, because the insanity is kept off to the side, separate from the core effort and merely one consumer among equals. To each his own. Live and let live. What I'm learning here is that many people don't see things that way, and want to explicitly define illumos and OI as having a single, shared vision. If that's what's happening here, I'll be aboard the next train out of this nuthouse. Hi Keith, You've made an assumption that OI is purely a desktop OS. What a ludicrous viewpoint. OpenIndiana aims to be a general purpose operating system for use in numerous deployment scenarios, including on servers. Heck, I'd bet most OI installations are on servers doing storage work. Nobody ever made the claim that OI wanted to compete with Linux for the desktop. That's a complete waste of everyone's time. My personal development work on OI was all done on a MacBook. My goal at the time was to have a replacement for OpenSolaris, which we had been using on servers at my dayjob. However there are plenty of people who do want to run it on the desktop, and who are you to tell them they should not do this? You seem to think that anyone wanting to have an illumos OS that supports the desktop, thinks it can compete with the likes of Windows 8 and Mac OS X. Bullshit. Most of the folk running OI on their desktop just want a functional X Windows with the latest desktop FOSS. They're workstation power users, probably spending most of their time in a terminal window. I seriously doubt they are thinking OI will ever gain widespread adoption amongst the general public. There are also plenty of reasons why having a strong general purpose distro with desktop support is in everyone's interest. Plenty of server customers wish to run the likes of LibreOffice, Firefox etc in headless mode, and OI facilitates this kind of development work. There are also plenty of people who want to run a community maintained distribution that's not affiliated with any commercial entity, which OI provides. Given the community status, and given the shared heritage, it's fitting that illumos use OI as a reference distro for builds and integration work. Not that I represent the distribution any more, or have any say in these things. But someone has to set the record straight. Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [discuss] Re: oi_151a9 roadmap planning
From: darth.seri...@gmail.com snip Thank you all for your response. I am driving you to re-think. It is my personal dream to see our community finally take off and overcome this heritage of missing collaboration from Sun in illumos and OpenIndiana. With all due respect Seth, you don't know what you're talking about. These discussions were had years ago. Who are you to tell us all what you think we should all be doing? What gives you the right to pop up out of nowhere, and tell others what to do? We've all made our choices. We all have diametrically opposed viewpoints on how things should be done. Many of these viewpoints are irreconcilable, such as the IPS debate. I love IPS, and many of the core OI devs love IPS. IPS in our opinion is an excellent package management system. I can't speak for all the OI devs but I have absolutely no interest what so ever moving away from it. Peter, Jorg and Martin hate IPS. They still think it can't deliver file based packages, demonstrating a complete bloody mindedness the likes of which you'll only find in UNIX circles. Maybe you'll get some consensus there, but I doubt it. Tribblix, OpenSXCE and Schillix are each distinct separate operating systems. Each of them is a personal passion project. Each of them has been done mostly in isolation with few outside collaborators. I can't see any of them abandoning their babies now. OpenIndiana is the only distro with a wide (albeit still tiny in the grand scheme of things) community developer base. You want to help? Join #oi-dev on irc.freenode.net and check out oi-userland and start hacking: https://github.com/OpenIndiana/oi-userland This circle jerk nirvana future you wish to create will never exist. If you want to help, pick a project and start hacking. Talk is cheap. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Hipster zone update: command_substitute: cannot duplicate pipe as fd 1: Bad file number
Hi Lou, Pipe errors mean the libc in the zone is out of step with the libc in the global zone or the kernel running. Postwait added some new features to some system calls including pipe which are not backwards compatible. You will need to make sure your NGZ has updated properly and got the latest libc bits. It's possible your pkg update didn't get everything... Regards, Alasdair On Tue, Jul 9, 2013 at 4:54 PM, Lou Picciano loupicci...@comcast.netwrote: Adam, Alexander, Tks for comments on this... No, the GZ on this machine has been updated to a8, though some weeks ago now. It's worth noting that all of the many NGZs updated at that time are working beautifully; not a hiccup. We did have similar mileage to yours at that time, though, in that many services were not starting; filesystem/local turned out to be the root of those evils... The ultimate culprit there was the mount command, segfaulting due to the need for the updated libc (Tks to JT-EC and igork for help). We were also seeing the 'unable to unmount filesystem' problems which others have reported. Solution to above was updating GZ as well (make perfect sense; sure), and rebooting it. Current situation is different: Attempt to update _another_ NGZ - still seeing the 'unable to unmount' errors, but pkg (-R /zone/root) image-update appears to work just fine. But the subsequent zlogin never gets to the OpenIndiana banner; it reports this: The Illumos Project SunOS 5.11 illumos-b49b27dcJuly 2013 -bash: command_substitute: cannot duplicate pipe as fd 1: Bad file number -bash: command_substitute: cannot duplicate pipe as fd 1: Bad file number root@: Looking at repo, enough stuff has changed that I'm assuming the GZ needs another update to make all this hang together. Hypothesis check, experts? Regards to all, Lou Picciano - Original Message - From: Adam Števko To: OpenIndiana Developer mailing list Sent: Mon, 08 Jul 2013 00:00:40 - (UTC) Subject: Re: [oi-dev] Hipster zone update: command_substitute: cannotduplicate pipe as fd 1: Bad file number Hi, I have same issue. However, my zone seems to be in some inconsistent state, where no SMF service started. I upgraded zone to hipster release, but the GZ is on /dev. Can this be the issue? Cheers, Adam On Jul 7, 2013, at 1:14 PM, Lou Picciano loupicci...@comcast.net wrote: Have recently updated many of our zones to a8 Hipster - working great! And thanks for your hard work, Andrzej and others... Having just updated yet another zone - using the repo as of late yesterday( 06 July), we see the following on zlogin. Never get near the OpenIndiana banner: The Illumos ProjectSunOS 5.11 illumos-b49b27dcJuly 2013 -bash: command_substitute: cannot duplicate pipe as fd 1: Bad file number I'll have to dig through the various .profiles and scripts which may be(?) on this container, but does above ring any bells? Lou Picciano___ 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 -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
Hi All, Back in the days of oi-build, we tried to have a process, and enforce quality, and it just resulted in super slow progress followed by near-death. Andrzej didn't contribute at all as he didn't like the bureaucracy, he just wants to hack-and-go. So after all that, I basically think Andrzej is completely right with his current approach - breaking things should be allowed. You can't make an omelette quickly and easily without breaking a few eggs. Hipster is an experimental development branch for making rapid progress. If you break something, you can fix it after, no big deal. I do think that /dev should get moved to /release, and /hipster should go to /dev. Not many know about hipster beyond the oi-dev list. It would show people in the outside world that progress is being made on OI. And on an unrelated note, someone motivated enough should do something about www.openindiana.org - it's ugly and out of date :-) Regards, Alasdair On Thu, Jul 11, 2013 at 3:19 PM, Ken Gunderson kgund...@teamcool.netwrote: At Thu, 11 Jul 2013 01:12:50 +0200, Adam Števko wrote: Hi Erol, On Jul 10, 2013, at 11:50 PM, Erol Zavidic ero...@gmail.com wrote: Good evening folks, thanks for your feedbacks so far, here's the summary clustered in some way: 1.0 - Release Engineering: 1.1- should not be bureaucratic, i.e. rather an internal agreement (Alex) I support this type for now. 1.2- the process of pushing updates to /dev or /stable repos is undefined (Alex) 1.3- safeguarding /stable repo (Jon) 1.4- streamline code review and integration process LGTMs (Adam) 1.5- build of many desktop packages impossible due to missing Manifests (David) 1.6- creation of development, release and stable branches within hipster repository (Erol) I don't code and been away from OI for a while visiting other interesting lands. It's good to see OI getting some traction. I have used platforms developed on the release, stable, and testing model for many years, e.g. FreeBSD. It worked. But I question whether this may have become rather outdated with the advancement of more modern, agile like models. For example, on the desktop I have been using Archlinux, wh/uses a rolling release model, and it has been working out quite nicely. This model eliminates the extra manpower required to maintain separate branches. Of course not many that I know of are using Arch server side and I think a /stable branch may be beneficial and justifiable on OI. OTOH, OI was intended as continuation of OS, so maybe desktop is it's niches, especially in light of SmartOS and OmniOS offerings for server side use. What compelling features does OI offer to compete with these? Hence, maybe best not to and focus on desktop niche. Maybe not... In any case, I have been doing some DevOps Engineering as of late and moving more towards a rolling release model would facilitate Continuous Delivery http://continuousdelivery.com/. Frequent smaller changes make breakages easier to track than vetting big releases and keep things fresher on the desktop. Just a few thoughts. We now return you to your regularly scheduled programming... Peace-- Ken ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Andrzej, Your vision is pretty much the same one I had. The challenge is this: Existing releng process and contribution process prevent anything from happening though. I would like to help to change that. How? On Fri, May 10, 2013 at 12:54 PM, Jim Klimov jimkli...@cos.ru wrote: On 2013-05-10 02:19, Garrett D'Amore wrote: There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. I would be entirely *unsurprised* if distro vendors like RedHat and Oracle simply *ditched* their desktop support at some point in the future -- its clear to me at least that folks aren't running those distros on the desktop. Well, Oracle does provide and promote SunRays, and while admittedly most of their market targeting is about VDI and access to virtual Windows desktops, there are many requests on the SRSS mailing list about adding support for server-side Ubuntu as the SRSS terminal server, because certain apps only exist for Linux and tunneling of connections makes their graphics lag, and RHEL/OEL/Solaris desktops are argued to be not so user-friendly (I have no opinion on this, to me X11 is a means to display more characters on screen than possible in a text mode). Not that Oracle seems to care to address that demand, at least publicly - just recently they began supporting versions 6 of RHEL and OEL as server-side Linuxes. But there is certain demand for non-MS/Apple desktops, and one linked to commercial interest as well. I am not sure if OI/illumos can ride that tide, though. Maybe with some other terminal client technologies (ThinLinc, Wyse, etc)?.. //Jim __**_ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/**mailman/listinfo/oi-devhttp://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
Hi, One thing to keep in mind that OI has (or at least, had) the largest install base of any OpenSolaris derived distro, thanks to the fact it is upgrade compatible with OpenSolaris. If you don't maintain that, then there is no point in continuing with OI - you may as well start with OmniOS. My personal view was that I wanted OI to be to illumos what Debian was to Linux - a community maintained general purpose operating system. If we had managed to kick OI into shape with regular releases and up to date software, it might have had a bright future. It certainly had plenty of users. Alasdair On Thu, May 9, 2013 at 2:05 PM, ken mays maybird1...@yahoo.com wrote: Hello, 1. Provide an updated kernel userland (i.e. Illumos-gate, rev: 19e11862653b or higher). This allows people that use OI for server-based projects to stay in sync with Illumos development on a much wider scale. 2. Optionally, implement JDS updates already maintained by Milan from http://pkg.opensolaris.cz/osol/en/index.shtml. That is it. This also keeps most things consistent to other project work dealing with GNU/userland/spec-files-extra testing with = oi_151a7. You can do this with very minimal manpower and not need to rebuild components / entire consolidations as much (aka 'project overkill'). You can also just dump the updated packages in a IPS repo for testing and review. You don't necessarily have to 'make world' right off the cuff. Start small, then think big. Fact: Entire distribution projects like Tribblix, Milax/OpenSXCE, EON, and DilOS are maintained by 1-2 people. Hope that helped, Ken Mays -- *From:* Andrzej Szeszo asze...@gmail.com *To:* OpenIndiana Developer mailing list oi-dev@openindiana.org *Sent:* Thursday, May 9, 2013 4:01 AM *Subject:* [oi-dev] OI project reboot required Hi All (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Regards, Andrzej ___ 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 -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] State of development
Hi GB, If you're looking to move to a new OpenSolaris derived distro (i.e. based on illumos, which is where all the kernel/core userland development takes place across all distros) then there are many choices besides OpenIndiana. I'd strongly recommend looking at SmartOS or OmniOS. SmartOS is developed commercially by Joyent, a large cloud computing provider in the US. OmniOS is also developed commercially by OmniTI, a fairly large IT services company. SmartOS may make a good choice as you're from a BSD background, it uses pkgsrc for packages. OpenIndiana was started as an open source community developed distro similar to Debian, but due to a lack of interest there are only a few developers working on it part time, so updates are slow, and limited in scope due to the size of the project. Regards, Alasdair On Sun, Apr 14, 2013 at 4:16 PM, Magnus mag...@yonderway.com wrote: On Apr 14, 2013, at 10:51 AM, G B wrote: OI's last release was Oct 2012, so my question is when is the next release (151a8) scheduled to be released? If you're coming from OpenBSD, this shouldn't be at all alarming. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Alasdair Lumsden http://www.everycity.co.uk EveryCity Managed Hosting Studio 18 Bluelion Place 237 Long Lane, London, SE1 4PU general: 020 7183 2800 support: 020 7183 2801 email: a...@everycity.co.uk Every City Limited Registered in England and Wales, No. 5689474 Registered Office: Roper Yard, Roper Road, Canterbury, CT2 7EX ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 2324 bring unrar changes from userland-gate
Hi Adam, On 10/ 1/12 07:42 PM, Adam Števko wrote: URL: https://www.illumos.org/issues/2324 Changeset: https://bitbucket.org/xenol/oi-build-2324/changeset/e4324e058d735b541e1603ba97840b49cc407d9c To sum up, oracle removed one patch, which was accepted by upstream. Package can be compiled by studio and works. Any feedback welcome. Looks good! Only one comment and it looks like the Oracle copyright lines were removed rather than just added to. Since they were the original author we need to keep those - would you mind adding them back? Otherwise, +1! ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Please comment #2314 isc-dhcp
On 04/09/2012 23:45, g...@genashor.com wrote: I've cleaned up and updated isc-dhcp to 4.2.4-R1. This already has the updates provided by Oracle so I removed the patches which are not required. I also removed duplicate items in the p5m file and fixed the Makefile so the BIND sub-module gets built correctly. This is my first foray into helping with oi userland so be critical so I can grow as a contributor. Thanks. My clone is at https://bitbucket.org/ggendel/oi-build Hi Gary, Thanks for contributing this - I see you also updated the copyright/license notice as per Adam's comments - thanks for doing that. Just one last thing - you removed dhcpd4.leases~, dhcpd6.leases and dhcpd6.leases~ - could you talk me through this change? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [userland] 3079 add libssh2 into illumos-userland
On 09/09/2012 22:12, Adam Števko wrote: Bump, anyone else? LGTM! I'll ship it to oi-build shortly. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] is there a vector for donating to OI?
On 06/09/2012 20:27, Ken Gunderson wrote: As for Alasdair having resigned as project lead, I would politely ask if we could prevail upon him to re-don his lead hat for this one last action. Why? In short; I feel he, likely more than anyone, has the community's trust. Hi Ken, Sure I don't mind providing some input on this... I think OI is a member of the illumos family and I'd be more than happy for the illumos foundation to take donations on our behalf, as long as it's earmarked for OI use specifically. If someone wants to donate to OI rather than illumos, it makes sense for it to be ringfenced. (Otherwise they'd just donate to illumos). It may be worth illumos setting up some kind of method of taking donations via something like PayPal. The illumos website could let people donate to illumos, and the OpenIndiana website could let people donate to OpenIndiana (but via the same facility), with some way of differentiating between the payments so they can be earmarked for illumos-general or OpenIndiana (or other projects that live within the illumosphere). Does that make sense? Or is that too complicated? I also am happy for it to take a cut of the donations for administrative overheads, as long as it's not too excessive. Obviously there is work involved in maintaining the foundation. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] is there a vector for donating to OI?
On 07/09/2012 06:07, garrett.dam...@dey-sys.com wrote: There have been technical disagreements, and I've pointed out that there has been in the past what I think represents a lack of clear vision for OI. But that's *my* opinion, and I don't speak for illumos in this regard. (Nor can I -- or anyone else -- illumos is moving towards a mutual benefit corporation that would preclude a single person dictating the position of illumos.) I'm sorry if our vision wasn't communicated properly. When OI started, Oracle were still publishing all the source to OpenSolaris including ONNV. OI was started to provide binary builds of that so that those of us using OpenSolaris could continue to do so. This made us equivalent to the CentOS-RedHat relationship. Then Oracle closed the gate and illumos took on a life of its own, and soon after OpenIndiana abandoned any notions of being a clone of Solaris 11. The new vision that arose from this was very much about being the leading *community* developed illumos based general purpose operating system. Basically what Debian is to the Linux world. I hope that's clear. However I think OI and illumos have been fairly symbiotic -- indeed OI still builds upon the illumos base, and at the moment OI is the de-facto reference distribution of illumos. However, if OI is considering a different base -- say SchilliX -- then that would probably represent a significant rift. (I have some concerns about the topics of conversation on oi-dev of late; decisions to for example change the shell or filesystem layout can have broad ramifications. While a distro can choose to do as it wants, if there is that much difference between the base and the distro, then it will be much harder for the base developers to continue to use the distro as a reference.) The relationship has been entirely symbiotic and I don't think we've really had that many disagreements, perhaps only some tension at the beginning. OI was always understaffed and it took a lot of time and effort for the volunteers to get up to speed on how everything worked. A lot of the talk you've seen on the oi-dev mailing list regarding changing the default shell, splitting off /usr or switching to Schillix is coming from the peanut gallery of people who like to provide their opinions on things but who have never actually contributed to the project. We have no intention of moving away from illumos-gate nor making any major changes. I also want to RTI all the non-branding related changes in our illumos-gate fork - we only maintain it because none of us have had time to RTI stuff. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
Hi Nick, On 05/09/2012 18:49, Nick Zivkovic wrote: Someone thought it would be a good idea to have a unified build system across consolidations. I think it's a pretty good idea to standardize on one build system. I'm merely asking which one would be preferred by the community (assuming the community would be willing to standardize). The decision was already made by the core OI devs to use the userland-gate format. That's the future unified build system. So the choice doesn't really have to be made again - it's why oi-build is in userland-gate format. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On 05/09/2012 19:49, Joerg Schilling wrote: The buildsystem for sfw is a nightmare: - It only works if the whole set of tools has already been installed in /usr on the compiling system before with exactly the same version as the one that is going to be compiled. This causes that you need an unknown number of iteration to compile and install on the build machine before you are able to compile everything at all. You need at least one additional install/compile cycle before you can be sure that the compile/link results will no longer change. It sounds like what you want is a completely self contained build system, like pkgsrc, which bootstraps itself, requires only a compiler, knows how to build things in the correct order, and installs everything to a custom destination prefix. That approach is fine for building 3rd party software, but not for maintaining system software which ships to /usr. Why? Because even in a minimal zone, bootstrapping involves overwriting things in /usr that are already maintained by the packaging system. You could build software and upgrade to those packages as you go, but that's very hard to do especially when refactoring packages. If you instead tried to install everything to a custom destination prefix, you couldn't then just package it up and install it to /usr, because lots of software embeds their build prefix in the binary. If you built stuff with /foo as your prefix, then packaged it and delivered it to /usr, /usr/bin/someprogram would be looking for /foo/etc/someconfigfile.conf It's far easier just to use a build zone and install the dependencies you need, and ensure your build zone is running the latest bits from the package repository. - It may be that you would need to manually install at least older versions of strategic tools before you may start to compile at all. The programs in question are gmake, bash, gm4, ... That is not an issue with userland-gate or oi-build. You do have to install gmake, bash and a bunch of dependencies, but they're all available in the package repo. - It installs unmodified autoconf results in /usr/include with the effect that you cannot compile depending other software using an older version of the compilers than the one you used to compile sfw. Can you supply an example? I'm not sure I understand this complaint. I do find it highly annoying that a lot of software jots down the compiler flags it was built with and stores them in a [softwarename]_config file, such as mysql_config, which is used by extensions to get the CFLAGS/LDFLAGS/etc. On OSOL/OI these are often Sun Studio flags that aren't compatible with gcc. You then end up in a situation where if you're doing gem install somelibrary or pecl install somelibrary with gcc as your compiler, it chokes when linking against a system program that supplies Sun Studio CFLAGS/LDFLAGS. SFW was a nightmare for many reasons, but not the reasons you listed. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On 05/09/2012 21:12, Alan Coopersmith wrote: Correct. Userland was designed from the ground up for IPS, since that was the only packaging system in use when it was created. Nexenta enhanced their fork of userland to support generating .deb packages, so adding SVR4 probably wouldn't be too hard. Why you'd want to is another matter. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On 05/09/2012 21:22, Bob Friesenhahn wrote: What do you suggest as a better replacement for this? Oh it's easy - you strip most of them out after the file is generated. Very easy to do with a post-install sed rule in the build recipe. The bulk of them are pointless optimisations that aren't really relevant when compiling an extension. The main LDFLAGS to preserve are -L/-R and -l, and for CFLAGS its -D and -I. As an example, mysql_config spits out this for CFLAGS: -I/usr/mysql/5.1/include/mysql -xprefetch=auto -xprefetch_level=3 -mt -fns=no -fsimple=1 -xbuiltin=%all -xlibmil -xlibmopt -xnorunpath -DHAVE_RWLOCK_T -DUNIV_SOLARIS The only thing you really need for extensions to build is the -I bit. The rest is Sun Studio pedantry. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On 05/09/2012 21:36, Andrew Stormont wrote: These sorts of scripts are just broken. What it really should do is check the value of CC before adding any compiler specific flags. Patching it to do that would be my preferred way of solving the problem. That works too. The thing is they're pretty dumb in operation - they pick up the compiler environment, which in the case of mysql was optimised for the database server. Client libraries really won't benefit from the optimisations. We could store the Sun Studio optimisations, and expose them with CC is detected as Studio, but gcc users miss out on them. So for equality it seems easier just to strip them. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On 05/09/2012 21:58, Joerg Schilling wrote: Alasdair Lumsden alasdai...@gmail.com wrote: It seems that you missunderstand the problem. The main issue is that the build system linked against /usr instead of linking against something like: /home/user/proto/usr userland-gate still links against /usr - it has a per-package proto area rather than a build-system wide proto area. - It may be that you would need to manually install at least older versions of strategic tools before you may start to compile at all. The programs in question are gmake, bash, gm4, ... That is not an issue with userland-gate or oi-build. You do have to install gmake, bash and a bunch of dependencies, but they're all available in the package repo. It is not a real issue with SchilliX either but for a looking at a self-contained system it would. - It installs unmodified autoconf results in /usr/include with the effect that you cannot compile depending other software using an older version of the compilers than the one you used to compile sfw. Can you supply an example? I'm not sure I understand this complaint. Check e.g. the notes about sfw in: ftp://ftp.berlios.de/pub/schillix/AN-0.8 You need to comment out line 71 of the file /usr/include/net-snmp/net-snmp-config.h do that it then looks this way: /*#define HAVE_CPP_UNDERBAR_FUNCTION_DEFINED 1*/ This is needed as the sunstudio-12 compiler and gcc-3.4.3 do not support __FUNCTION__ That's an autoconf problem, not a problem with the build system. If you build software with a new compiler, autoconf will detect its new features. To work around it, the net-snmp build recipe can modify the generated header prior to packaging it. However, typically a distribution will ship with a particular supported compiler version, and the headers of the software on the system will match that version. It is unreasonable to expect an older compiler to link against all software delivered by the system when the system uses a newer compiler. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
I've actually realised it would be really useful if there was a single document explaining all this stuff, a kind of In the beginning there was... style walk through of how things came to be. I'll try to write one over the next few weeks and put it on the wiki, as it would probably help new developers get their head around things. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 2483 Bring libcaca into illumos-userland from s10-userland
Hi All, I have committed libcaca to oi-build. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SVR4-based illumos distro WAS: how to fix support for system_locale in sysidcfg for non global zone installation
(Moving this to oi-dev) On 27/05/2012 16:47, Jim Klimov wrote: 2012-05-27 4:15, Alasdair Lumsden wrote: As project lead I can tell you that we won't be doing SPARC unless someone comes along and takes ownership of that project, and we definitely won't ever be doing SVR4 packaging as long as I'm project lead. No Bart, you cannot have the cookie now after all. Your mother made a very loud point! (C) The Simpsons Sorry :-) I subscribe very strongly to the design principles of IPS which came about due to shortcomings in SVR4. IPS may have some implementation weaknesses, but it admirably solves the problems it set out to and in my experience works very well indeed. When people pine for the days of SVR4 I just get annoyed, because it's trying to undo progress. Yes, IPS requires retooling and relearning, but ultimately IMHO it's very worth it. There are a number of blog posts on this topic by Stephen Hahn: https://blogs.oracle.com/sch/entry/observations_on_packaging (Click next through the blog posts as there's quite a few) I think, supporting the minimal-interruption *migration* from legacy (SVR4) systems would be more important to me than an SVR4-based distro, especially if that option is so firmly fought against. However, comfortable migration should support running legacy local (fullroot) zone roots provided as-is (i.e. without IPS packaging), even if not directly supporting installation of such (SVR4) zones with OI. Do you loudly object even to that? No, and if a sound implementation was presented for us to integrate I'm sure we would. However as unpaid volunteers working on a community project we need to stay focused on what's important, and right now that's things like: 1. Getting our /stable release out 2. Sorting out /experimental and our release engineering processes 3. Updating software, fixing security holes, fixing bugs Then to clarify: 1) SVR4 support: as I see - at the moment SVR4 are installable on OpenIndiana as is, including the pre/post-scripts, which is good for those legacy users who can't/won't migrate for whatever their reasoning is. Is this going to remain in place, or are there plans to rip out pkgadd,etc. and still claim being the upgrade path? ;) There are no plans to rip it out. One limitation that I see however, is that an SVR4 package installed in GZ does not get auto-installed/updated in LZ... Oh well, that's likely an IPS brand thing... That's by design. SVR4 package installation is there as a compatibility thing and not for general systems management. IPS branded zones are effectively isolated containers with their own private package sets. A fresh zone gets a minimal set of software. 2) Is there a documented and/or scripted upgrade path for users of SVR4-based systems to export-import their zones into an IPS system (i.e. use same-named SUNW* package names if available via IPS and update them from an old SXCE/Sol10 image to the current OI baseline upon zone import)? Something simple, working in-place on (a clone of) the old zone dataset, and that would not require reinstalling the whole set of zones and manually migrating the settings, data, installed third-party programs (packaged or standalone)? That would be a huge amount of work. Things have changed so very much since Sol10 and SXCE that there is no 1:1 direct mapping any more and most software would just break horribly. There are however Solaris 10 branded zones. Potentially that brand could be adapted to SXCE. The problem is that SXCE was a moving target with lots of builds. To the very least, it would suffice if the SXCE zones just worked as is in OpenIndiana, allowing for quick upgrades of the host OS and little downtime for tasks-in-zones being upgraded later - alas, they don't, even after some hammering. Again, you want an SXCE implementation of Solaris 10 branded zones. The main problem is that the core system software (like the ifconfig, zfs, etc) commands inside the zones have to be kept in sync with the global zone. I am not sure how the S10 brand achieves this. But once it's done you're left with this aging security nightmare frankenstein of a zone, so why bother? People are better off investing the time in properly migrating their legacy apps and data into modern zones. That way you get the latest software with the latest security updates, in a far more supported fashion. I appeal to your logical side. 3) Regarding sparse-root zones: does the IPS theory firmly forbid the sparse-root zones with their benefits of faster provisioning, smaller footprint on disk/RAM/cache, fast propagation of OS-wide updates, and whatever else people liked about them? Or is it possible to tame IPS code into compatibility with the concept of sparse read-only rootfs (/usr, /lib...)? As far as I know sparse zones support was never a design goal. Oracle employ a team of people to maintain IPS and what you're asking for would be a major deviation from their work
Re: [oi-dev] [developer] how to fix support for system_locale in sysidcfg for non global zone installation
On 26 May 2012, at 17:46, Garrett D'Amore wrote: sysidtool (where this lives) is not part of illumos-gate. Its a part of OpenIndiana. I'm having trouble locating the sources they used for this. I'm not entirely certain the source for it *is* open. Evidently it was part of the installer and was never opened up. I'm a little dismayed about this -- I never realized this to be the case, although admittedly there are distributions which make no use of sysidtool at all. I'm not sure where the sysidcfg code lives (Will have to have a rummage) but I've never liked the way any of it works and I'm sure I'm not alone. We (OpenIndiana) may want to adopt the approach OmniOS took which is to get rid of it and use something much simpler. If the OmniOS approach is sufficiently good enough for most people then we could just import it. I imagine adding compatibility with the sysidcfg file would be pretty trivial if anyone really cared about it. Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2682 Supply CC, CXX, CFLAGS, LDFLAGS etc to CONFIGURE_ENV by default
Hi All, I have a rather large changeset for review: https://bitbucket.org/alasdairlumsden/illumos-userland-2682/compare/..illumos/illumos-userland This abstracts a large amount of unnecessary common autoconf code out. The key files are make-rules/configure.mk and make-rules/shared-macros.mk I have also updated the CDDL header for each file I've changed as well as updated the digest from sha1 to sha256 (which userland-gate are doing). Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Fwd: [userland] hackathon info
FYI - location info for the hackathon. Begin forwarded message: From: Bayard Bell buffer.g.overf...@gmail.com Date: 21 May 2012 15:12:13 CEST To: userl...@lists.illumos.org Subject: [userland] hackathon info Reply-To: userl...@lists.illumos.org The hackathon will take place May 23rd at Middenweg 33, flat 3: http://g.co/maps/by6q3 If you're feeling energetic, we'll also be there May 24th. The nearest rail station in Amstel (this would be quite a walk from Amsterdam Centraal), which should be a 15 minute walk. The nearest landmark is Oosterpark, which is less than five minutes away. It's slightly more difficult getting from the flat to the conference hotel because you have to thread through bridges to get there, make it a longer trip than as the crow flies. If you want to get rail routes from Schiphol airport (there's a train station underneath the airport's massive central lobby), please see the Dutch national rail company (Nederlandse Spoorweg) site: http://www.ns.nl/en/travellers/home If you haven't already, please e-mail me with your mobile number (even if I have/should have it from exchanges previous to the conference, it would be helpful if I didn't have to dig it up), and I'll put together a phone directory for everyone who's attending. Cheers, Bayard --- illumos-userland Archives: https://www.listbox.com/member/archive/191052/=now RSS Feed: https://www.listbox.com/member/archive/rss/191052/22216987-e95844d6 Modify Your Subscription: https://www.listbox.com/member/?member_id=22216987id_secret=22216987-664aa7bb 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] [userland] illumos-userland hackathon May 22 in Amsterdam
Hi All, I need to book flights for this as time is running out and I still don't really have enough information in order to choose dates and times - can someone please confirm: 1. What day the hackathon is on (22nd?) 2. What time of day the hackathon is (all day? just the evening?) 3. What accommodation has been booked and what days is it available on? I can't easily choose what flights to get without the above information, and I need to know if I need to book a hotel room etc. I am interested in us getting an apartment hotel with bedrooms and staying there, even if only on the floor in a sleeping bag. But I need to confirm I have *somewhere* to sleep :-) Thanks, Alasdair On 05/05/2012 02:37, Bayard Bell wrote: 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 --- illumos-userland Archives: https://www.listbox.com/member/archive/191052/=now RSS Feed: https://www.listbox.com/member/archive/rss/191052/22216987-e95844d6 Modify Your Subscription: https://www.listbox.com/member/?member_id=22216987id_secret=22216987-664aa7bb 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
On 10 May 2012, at 01:41, Bayard Bell wrote: 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? I have created: https://www.illumos.org/issues/2714 I may look at this once I've finished my higher priority changesets, unless someone else wants to take the issue before hand. ___ 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 10 May 2012, at 00:42, Bayard Bell wrote: 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. Yes indeedy - it's really helpful especially for bulk builds. You can also restore the old behaviour by setting USERLAND_ARCHIVES=./ (or possibly =$(COMPONENT_DIR)). And you can still make use of an alternative ARCHIVE_MIRROR. It also looks like Oracle attempted to implement USERLAND_ARCHIVES originally but either didn't finish, or broke it later on when adding support for multiple archives in a component. So this is fixing a currently broken feature. I'd like to write a continuous-integration rule for pushing valid archives (based on the digest) automagically up to the dlc mirror. I'll look into that soon. 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. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Assorted recipes
Hi Jeff, On 10 May 2012, at 04:46, Josef 'Jeff' Sipek wrote: I've been a bit too lazy about this, so at least I'll let you guys know about a couple of things I've done for my test repo. Feel free to take them and get them integrated: Great! Thanks for posting these... Having a starting point reduces the amount of effort involved significantly. If nobody picks these up I'll definitely get them polished off and put up for final review. If people are busy and don't have time to do the polishing/integration themselves then this is definitely the next best thing and I'd love to see more of these. A work in progress is a million times better than nothing at all. postfix (missing SMF manifest): http://hg.31bits.net/oi-jeffpc/oi-build/rev/d27273c8771f notion window manager [1]: http://hg.31bits.net/oi-jeffpc/oi-build/rev/961d976c440e http://hg.31bits.net/oi-jeffpc/oi-build/rev/793871cc2fa9 irssi's path fix: http://hg.31bits.net/oi-jeffpc/oi-build/rev/78657b9613fe (pretty sure that the i86pc-solaris-64int is wrong too since the Makefile only builds a 32-bit binary) fix lua build (without this, the lua build won't know how to do popen and other POSIX-y stuff): http://hg.31bits.net/oi-jeffpc/oi-build/rev/9b3ec2748616 I've been using these for a couple of months and things seem to work pretty well. Cool stuff! ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44
Hi Milan, Urgh what a mess of output that is. It comes down to the unfortunate fact that the work being done to /dev is conflicting with the work I'm doing on /experimental. Right now you're on 0.151.1.4 which has newer versions of things like the nvidia package, so /experimental is no longer an upgrade, it'd be a downgrade for some packages which pkg forbids. I'm going to have to come up with a quick and easy way of overlaying illumos-userland on top of the latest release of /dev each time a new version of /dev comes out. Once /stable comes out this won't be a problem as things will logically fork. I'm not entirely sure what's going on with gnome-incorporation there but it's pointless fixing that until /experimental is updated. Unfortunately I won't be able to look at it today as I have to go out, but I've bumped this to the top of the priority list. Cheers, Alasdair On 6 May 2012, at 08:20, Milan Jurik wrote: Hi, slightly better: http://www.opensolaris.cz/builds/new.pkg.log.txt Best regards, Milan Alasdair Lumsden píše v so 05. 05. 2012 v 01:00 +0100: Hi Milan, Could you try now? I haven't sucked in the new prestable version yet but I've resolved the conflicts, so it should install. 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 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 2483 Bring libcaca into illumos-userland from s10-userland
On 5 May 2012, at 16:31, Andrew Stormont wrote: Not a fan of the license but the changes LGTM. Copied verbatim from the source. They're a strange bunch. Does this require gcc-4.4 to build? It won't build with Studio out of the box. It could be patched, but I don't think it's worth doing for this novelty item. I'm not entirely sure what the policy is on building with gcc is at the moment - should I remove GCC_ROOT? If I want to use 4.4 by default should I set that elsewhere? Also if this is intended for illumos-userland it might be a good idea to cc userland@ Doh, good point. Old habits die hard. Set the To to userl...@lists.illumos.org and the CC to the oi-dev list. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Deduplicating illumos-userland
Hi All, In s10-userland, early on we abstracted a lot of commonly used macros up into the shared-macros area. Unfortunately illumos-userland doesn't have this and it has created a situation where a lot of Makefiles unnecessarily duplicate macros. For example, in s10-userland we added the following to configure.mk CONFIGURE_ENV += CC=$(CC) CONFIGURE_ENV += CXX=$(CXX) CONFIGURE_ENV += CFLAGS=$(CFLAGS) CONFIGURE_ENV += LDFLAGS=$(LDFLAGS) CONFIGURE_ENV += PKG_CONFIG=$(PKG_CONFIG_PATH) # Tell autoconf about 64bit builds CONFIGURE_OPTIONS.64 += --build=x86_64-pc-solaris$(SOLARIS_VERSION) CONFIGURE_LOCALSTATEDIR = $(CONFIGURE_PREFIX)/var CONFIGURE_OPTIONS += --infodir=$(CONFIGURE_INFODIR) CONFIGURE_OPTIONS += --sysconfdir=$(CONFIGURE_SYSCONFDIR) CONFIGURE_OPTIONS += --localstatedir=$(CONFIGURE_LOCALSTATEDIR) In shared-macros.mk we added: LDFLAGS+= $(LD_BITS) (Note that the --build above needs improving for SPARC, can probably be derived from MACH64 somehow) The above is all completely missing from illumos-userland/userland-gate for no apparent reason. In s10-userland, we found adding this stuff this flushed out a lot packaging mistakes. For example a lot of software leverages pkgconfig, and 64bit builds were using 32bit pkgconfig cflags/ldflags. Also autoconf/libtool use --build to determine various things related to bittiness; setting -m64 is not by itself always enough. We found few cases where the above caused issues (I can't think of any off the top of my head). There are occasions when a software component has a configure script that is not generated by autoconf, that barfs on some of the above flags, but the correct way to deal with that is set CONFIGURE_OPTIONS= instead of += and define the precise arguments it takes, since these non-autoconf configure scripts are rare and always bespoke. Ideally we want to cater for the general common cases first, avoid unnecessary duplication, and err on the side of safety (which --build and PKG_CONFIG for 64bit improves). Here is random example of how this will cut down on duplicated cruft: --- gd2/Makefile2012-05-05 14:31:12.052620402 +0100 +++ /tmp/gd2_Makefile_new 2012-05-05 16:58:11.668117871 +0100 @@ -37,18 +37,11 @@ include ../../make-rules/ips.mk include ../../make-rules/lint-libraries.mk -PKG_CONFIG_PATH_32 = /usr/lib/pkgconfig -PKG_CONFIG_PATH_64 = /usr/lib/$(MACH64)/pkgconfig - PATCH_LEVEL = 0 CFLAGS += $(CPP_LARGEFILES) CPPFLAGS += $(CPP_LARGEFILES) -CONFIGURE_ENV += CFLAGS=$(CFLAGS) -CONFIGURE_ENV += CPPFLAGS=$(CPPFLAGS) -CONFIGURE_ENV += PKG_CONFIG_PATH=$(PKG_CONFIG_PATH_$(BITS)) - CONFIGURE_OPTIONS += --includedir=$(CONFIGURE_INCLUDEDIR)/gd2 CONFIGURE_OPTIONS += --disable-static CONFIGURE_OPTIONS += --disable-rpath We also created a new make-rules/gnu-ld.mk file that could be included to get GNU ld (unfortunately needed for some multimedia software that uses linker features the Sun linker doesn't support). One for OI would contain: COMPONENT_BUILD_ENV+= LD_ALTEXEC=/usr/gnu/bin/ld COMPONENT_INSTALL_ENV+= LD_ALTEXEC=/usr/gnu/bin/ld CONFIGURE_ENV+= LD=$(ECPREFIX)/bin/ld CONFIGURE_OPTIONS+= --with-gnu-ld (Note on s10-userland we actually supply a 32bit and 64bit build of gnu-binutils as we found a 64bit gld was necessary to link some 64bit objects - I forget the details but this is something that we can look at down the road when we start packaging that software up). We could also add a make-rules/ncurses.mk: # Use ncurses CURSES_DIR_32= /usr/gnu/lib CURSES_DIR_64= /usr/gnu/lib/$(MACH64) CURSES_DIR= $(CURSES_DIR_$(BITS)) LDFLAGS+= -L$(CURSES_DIR) -R$(CURSES_DIR) CPPFLAGS+= -I/usr/include/ncurses This ncurses definition block is used in a number of components that require ncurses, so it makes sense to abstract it out. The gnu-ld.mk/ncurses.mk files are used by simply adding an include ../make-rules/[blah].mk line to the component Makefile. Before I file some issues and begin work on some changesets, does anyone have any feedback/comments? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Downloading archives to a common area
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
Re: [oi-dev] [userland] Re: Downloading archives to a common area
On 5 May 2012, at 17:41, Andrew Stormont wrote: I think this is a great idea. Great - thanks for the feedback! Glad I'm not the only one that thinks it would be useful. I'll get on with a changeset that people can test. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Extracting archives to a source subdirectory
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 ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2679 dcmtk package has wrong package fmri
Hi All, Changeset for review: https://www.illumos.org/issues/2679 https://bitbucket.org/alasdairlumsden/illumos-userland-2679/changeset/d87c903444d1 Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] 2680 2681 - Juggling archive and source dir
Hi All, 2680 Extract source archives to a subdirectory 2681 Downloading archives to a common area I decided to do these two as a single changeset since they're intertwined. https://bitbucket.org/alasdairlumsden/illumos-userland-2680/changeset/34c2dff6cc0d Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44
Hi Milan, All, I haven't had a chance yet to fix the long list of issues with it yet, sorry for taking a while. The /experimental repo is literally just a dump of illumos-userland over a pkgrecv of 0.151.1.3 from /dev (Plus the sfw incorporation adjusted). There are some conflicts that need resolving, and incorporation fixing. I guess I will also now have to find a magic way of importing the latest pre-stable too. Will keep you all updated with progress. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44
Hi Milan, Could you try now? I haven't sucked in the new prestable version yet but I've resolved the conflicts, so it should install. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] pkg.openindiana.org/experimental updated - now with gcc-44
Hi All, I have updated the /experimental repo available at: http://pkg.openindiana.org/experimental This now contains oi_151a3 overlayed with what was previously available in /experimental, plus gcc-44 - all at version string 1.1 Please give this a go and report back any issues. To use it, first update to oi_151a3, then do: pkg set-publisher -p http://pkg.openindiana.org/experimental pkg set-publisher -P oi-experimental pkg set-publisher --non-sticky openindiana.org Your pkg publisher output should look like this: PUBLISHER TYPE STATUS URI oi-experimental origin online http://pkg.openindiana.org/experimental/ openindiana.org (non-sticky) origin online http://pkg.openindiana.org/dev/ You can then pkg update -nv to see if it will successfully update, then you can actually do the update with pkg update -v Note that this hasn't been extensively tested yet and is hot off the press. If you have any issues, please report back with full details. I have tidied up sfw-incorporation by stripping out any packages present in illumos-userland. If I have missed any, you can do this to correct: pkgrepo -s file:///tmp/sfw-repo create pkgrepo -s file:///tmp/sfw-repo set publisher/prefix=sfw-repo pkg contents -m sfw-incorporation /tmp/sfw-incorporation.p5m Then edit the file at /tmp/sfw-incorporation.p5m, (remember to strip out the timestamp in the pkg fmri), then publish it with: pkgsend -s file:///tmp/sfw-repo publish --fmri-in-manifest /tmp/sfw-incorporation.p5m You can then install this with: pkg set-publisher -p file:///tmp/sfw-repo pkg set-publisher -P sfw-repo pkg set-publisher --non-sticky oi-experimental pkg install -v pkg://sfw-repo/consolidation/sfw/sfw-incorporation There may be other consolidation boundary issues that need fixing - if you encounter any, let me know! We're now in good shape to start cranking changes out into illumos-userland and moving packages over from other consolidations :-) It would be good to start importing the work aszeszo did converting JDS packages to userland-gate format and also look at a JDS rebuild. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Which rge driver is in the latest bits?
Hi Milan, It comes from illumos-gate. We have our own patches applied to the tree, but nothing major: https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/ Our last sync with illumos-gate was 5 weeks ago. Cheers, Alasdair On 21 Apr 2012, at 14:11, Milan Jurik wrote: Hi, could somebody give me hint which rge is in the latest published bits? Among issues I found this one - https://www.illumos.org/issues/2040 I am asking because I have big problems with rge, it is able to download only few packets and then stops to work. I would like to debug it but I need to know from where bits are comming. 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] Webrev: Issue 2024 - ZFS dedup=on should not panic the system when two blocks with same checksum exist in DDT
Hi Jim, Did you mean to send this to the illumos developer list rather than the OI one? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Webrev: Issue 2024 - ZFS dedup=on should not panic the system when two blocks with same checksum exist in DDT
On 20 Apr 2012, at 00:56, Jim Klimov wrote: 2012-04-20 3:40, Alasdair Lumsden wrote: Hi Jim, Did you mean to send this to the illumos developer list rather than the OI one? Hmmm... yes, I guess so. This was my first attempt after all ;) I'll repost then. What is your estimate, how much different really are the sets of readers of these two lists? ;) Quite large I imagine :-) OI has few kernel developers working directly on it. Most if the Illumos kernel developers work for commercial entities such as Nexenta, Joyent and Delphix who all have their own distros. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Strange output during upgrade to the latest prestable
Hi Milan, On 15 Apr 2012, at 11:52, Milan Jurik wrote: Removal Phase73/3158 Warning - directory /tmp/tmppQR55O/usr/share/man/cat1m not empty or not expected during operation - contents preserved in /tmp/tmppQR55O/var/pkg/lost +found/usr/share/man/cat1m-20120415T121445Z We'll need to look into why cat1m has changed. Is /tmp/tmppQR55O not where the cloned boot environment was mounted for the pkg to operate on? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Strange output during upgrade to the latest prestable
Hi Milan, I've just checked, and it's because the new OI prestable ships with a newer version of pkg which no longer delivers the cat1m file. The newer pkg version I believe is the S11 pkg version backport to S11X to facilitate upgrading between the two versions. It looks like cat1m/pkg.depotd.1m was moved into the package/pkg/system-repository package in S11 but the backport doesn't provide it. We might want to patch it back into being supplied for the actual stable build. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On 15 Apr 2012, at 13:54, Bayard Bell wrote: A version of 3.6.4 is pending for the illumos-userland head. Hi Walter, Unfortunately however the new version probably won't make the stable branch. The stuff in illumos-userland will be destined for /experimental followed by /dev. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
Hi Martin, On 15 Apr 2012, at 15:10, Martin Walter wrote: snip Unfortunately however the new version probably won't make the stable branch. The stuff in illumos-userland will be destined for /experimental followed by /dev. pkg.openindiana.org/experimental is last updated at 2011-11-19 !? I think such critical security holes should be fixed asap. Otherwise it is really a risk to run Openindiana on big fileservers. The binary repo was last updated quite a while ago, but work continues on the source side at: https://hg.openindiana.org/illumos-userland/ and https://hg.openindiana.org/upstream/oracle/userland-gate The challenge is manpower - 151a was built using a collection of highly unpalatable build systems that few of our developers want to work on. The reason for the delay between oi_151 and our next big release (not the stable) is that we're completely re-tooling around a single build system. Once done, we'll be able to churn out updates far more easily. However the retooling effort has been derailed and held up by the fact it started life as oi-build and became a collaborative effort with Nexenta called illumos-userland, which they are going to also use for Illumian. A lot of resources have had to be diverted to sorting out collaborating with them and dealing with the consequences of this. We're nearly there and hopefully things will speed up again once we get into the swing of things. If you'd like things to proceed faster, I'd like to point out that the devs working on OI are contributing their free time to do this. If you value OI then you're welcome to assist us and help get things updated faster. The stable release is about backporting critical security fixes, and this one sounds like the kind of thing we should look at backporting. So we will look into it and see what can be done. But it probably won't involve a version bump, more a patch to the older version. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
On 15 Apr 2012, at 18:59, Martin Walter wrote: Would it be not easier and better to just make the newest version available? E.g. I would much more prefer just a samba-3.6.4 package than an updated samba-3.5.5. Yes, if we were on the new build system. So updating samba for /experimental wouldn't be too hard. But samba for oi_151a is stuck in an old build system, so updating it would require more effort than anyone we have is willing to take on. And as Rich pointed out, isn't really what the stable branch is about. If you have time you could have a look to see if there is a patch that applies against samba-3.5.5 that fixes the CVE. The usual place to look is other distro's patch sets against samba where their version is close to ours. *That* would be genuinely helpful and more use to us than building stuff :-) Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] samba security
Hi Martin, We've obtained the Debian security patches for 3.5.6 which should hopefully apply fairly cleanly against our 3.5.5: http://security-tracker.debian.org/tracker/source-package/samba We're looking into things. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New BE every package update?
On 15 Apr 2012, at 21:50, Milan Jurik wrote: The reality is that I am flooded with several new BEs per day. My grub list is increasing frequently. OK, I have to live with it :-) There's also: pkg --no-backup-be :-D ___ 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
Hi Bayard, Fine for me! Cheers, Alasdair ___ 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
Hi Bayard, I think your comments regarding VBox being not-fit-for-purpose for Illumos/OI development are completely valid and worth mentioning. 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? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] PostgreSQL 9.1.3 requires OpenSSL 1.0.0
On 2 Mar 2012, at 05:48, Richard PALO wrote: bad news, the latest binary update from http://www.postgresql.org/ftp/binary/v9.1.3/solaris/solaris11/ requires OpenSSL 1.0.0. Boo! That sucks. (probably because Oracle compiled it) Hmm, I have my doubts, as Oracle yanked all traces of Postgresql out of Solaris 11. But who knows! So, the question is will OpenSSL 1.0.0 make it into the upcoming stable release? No, due to the huge number of things the version bump touches. But it is in pkg.openindiana.org/experimental I guess one could also ask if a useable 9.1.3 pg release (with a compatible pgadmin) will make it into the base oi repositories? If new versions of Postgresql arrive, probably only into /experimental and thus into the next /dev release after /stable comes out. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ntfs-3g and fuse
Hi Jean-Pierre, Would you have any interest in adding this to the illumos-userland build framework so that it ships with the distribution in future releases? Regards, Alasdair On 28 Feb 2012, at 09:58, Jean-Pierre André wrote: Hi, I am now releasing the fuse kernel module for OpenIndiana. Ntfs-3g now fully passes the standard tests with this kernel module and without need of the workarounds I had to insert earlier to cope with the bad behavior of the fuse kernel module originated from OpenSolaris. A few optimizations would still be useful. I might have a look at them if there is enough demand. Available on http://b.andre.pagesperso-orange.fr/openindiana-ntfs-3g.html are three packages ready for use : - a full ntfs-3g package in 32-bit mode with the fuse-lite library and ntfsprogs - a full ntfs-3g package in 64-bit mode with the fuse-lite library and ntfsprogs - a fuse kernel module package for both the 32-bit and 64-bit modes The raw source files (not packaged according to OpenIndiana standards) are also available there. I am keeping these files available on line for some time. I also keep the change sets available to whoever enters the source code of the fuse kernel module into a public source code management repository. Enjoy, Jean-Pierre Jean-Pierre André wrote: Hi, Milan Jurik wrote: Hi Jean-Pierre, Jean-Pierre ANDRE píše v út 24. 01. 2012 v 15:16 +0100: Hi, As a maintainer of ntfs-3g, I have received bug reports on OpenIndiana. Digging into them, I found there were almost all caused by the buggy fuse kernel module, which nobody seems to care about. So I had to do it myself ___ 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] 2142 update python2.6 to 2.6.7
On 24/02/2012 22:48, Bayard Bell wrote: 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. Great work! Haven't had a chance to review the changesets but I'll be very happy when we ship Python, Ruby, PHP and friends built with gcc - eggs/gems/pecl will finally work as intended without exploding on native extensions that assume gcc :-) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] error in pkg5 - from oi-prestable
On 11 Feb 2012, at 14:11, Gordon Ross wrote: There's also the difference that pkg is real source code, (right?) where most other things in userland are just build recipes. If I correctly understood the suggestion for a separate tools gate, then I think that sounds helpful. Well! There are options here. pkg could be treated just like every other bit of software inside illumos-userland, like gcc or openssl. The build recipe could check it out, do the build, publish it. Indeed, we already have a rather dirty version of this in s10-userland: http://hg.openindiana.org/users/aszeszo/s10-userland/file/86bc2641a3a0/components/pkg5 I quite liked the idea of having a single repo to check out to be able to build the whole OS - makes it much easier for people to get involved with OS development. But pkg is more specific to OpenIndiana than it is to Illumian, so perhaps OI and Illumian need separate repos for where we deviate? Back when this was oi-build, my plan was for it to be able to build everything - illumos-gate, pkg-gate, etc, all treated as components. Food for thought... ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ntfs-3g and fuse
Hi Jean-Pierre, Great work! I wonder if we could find a way to get these fixes applied upstream. We would also like to add ntfs-3g to oi-build (illumos-userland) Cheers, Alasdair On 24/01/2012 14:16, Jean-Pierre ANDRE wrote: Hi, As a maintainer of ntfs-3g, I have received bug reports on OpenIndiana. Digging into them, I found there were almost all caused by the buggy fuse kernel module, which nobody seems to care about. So I had to do it myself If anybody is interested, please see http://b.andre.pagesperso-orange.fr/openindiana-ntfs-3g.html Bugs fixed in the fuse kernel module : - Return st_blocks as defined by the file system - Process the error returned by the file system on unlink() - Do not send create() for existing files to the file system - Delete sent messages when no reply is expected (memory leak) - Clear the gaps left when writing beyond the end of file - Fix the reference count on directories in order to send releasedir (memory leak) I have still not found why the file size is limited to 2GB. Please note I am not the maintainer or packager of fuse, so whoever wants to take it over would be welcome. Regards Jean-Pierre ___ 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] New prestable release - oi_151a1 0.151.1.1
Nice work JT! This is very promising indeed :-) On 16 Jan 2012, at 19:58, Jon Tibble wrote: Hi all, Today I turned on the repo and made the tarball of said repo available for the first prestable release. Depending on how we go porting security fixes to this or the rest of the community gets on sorting experimental into looking like a sensible oi_151a replacement will determine which becomes OI's first stable release. The release notes and more information can be found here: http://wiki.openindiana.org/oi/oi_151a_prestable0+Release+Notes There won't be ISOs for this one but there will for a near future prestable. The aim of these is to be more frequent so I don't think it is really worth producing ISOs for every release but rest assured there will be some tested before anything goes stable. Unless something particularly funky goes in you'll probably see illumos get bumped every prestable, other than that I'll welcome mainly security fixes. Enjoy, JT ___ 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] Addition of GeoIP to oi-build
Hi Jeppe, On 12/19/11 10:40 PM, Jeppe Toustrup wrote: Could somebody please look through this change set, and see if everything looks okay? https://bitbucket.org/Tenzer/oi-build/changeset/7ca13070e339 Great stuff - thanks for doing this! A few comments: 1. Could you replace the OpenSolaris CDDL notice with the Illumos one 2. Was this taken from userland-gate or written by yourself? If taken from userland-gate, you can keep the Oracle copyright in the Makefile and .p5m, otherwise remove it. In either case, please do add your own copyright line. 3. Use a transform at the top to set etc/GeoIP.conf and GeoIP.dat preserve=true, via: transform file path=etc/GeoIP\.conf - default preserve true transform file path=usr/share/GeoIP/GeoIP\.dat - default preserve true This will ensure that if someone edits the conf or replaces the GeoIP database that it won't be wiped out on a pkg update Apart from that, it looks good! Thank you very much for contributing this. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Weekly Meeting on Tuesday Dec 20th at 19:00 UTC
Hi All, We should have a quick weekly meeting before the Christmas festive period kicks in - I've set the time at 19:00 so igork from Nexenta can join us, it will be 11pm for him then. There is no fixed agenda, but I imagine it will revolve around illumos-userland, Illumian and getting things moving again as development has been quite quiet recently. Hopefully see you all on Tuesday! Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads Up: CDN turned off, mod_bw enabled
Hi All, Due to the high cost of hosting OpenIndiana's dlc.openindiana.org on the CDN, I have decided to instead discontinue this in favour of getting worldwide mirrors online. As of now, dlc.openindiana.org points at the origin server in the UK instead of the CDN. I have enabled mod_bw in Apache and restricted downloads of the .iso/.usb files to 250KB/sec. We will be contacting worldwide mirrors asking them to mirror dlc.openindiana.org via rsync (which is not rate limited) and once we have a reasonable number we can update the website to list these. And obviously we still have the torrents too. Thanks, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] illumos-gate update
Hi Jeff, Great work! I'm going to install this shortly and give it a go. Can you just confirm where you built illumos-gate and whether it was a vanilla oi_151a install or if it had been updated to /experimental? I have one of those new Intel cards in my PC so I'm looking forward to giving this a spin :-D Cheers, Alasdair On 12/ 3/11 08:15 PM, Josef 'Jeff' Sipek wrote: I pushed out an updated build of illumos-gate to pkg.openindiana.org/dev-il. I'd appreciate some testing before it gets pushed to /dev. This update contains lots of usedful changes, including (but not limited to): - OS X Lion CIFS permission handling fix - e1000g0 update to support new Intel cards (82579) - Russian timezone info update - assorted DTrace fixes - Sandy Bridge related bug-fixes You can try it out by running: # pkg set-publisher -g http://pkg.openindiana.org/dev-il openindiana.org # pkg update Thanks, Jeff. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] illumos-gate update
Hi Jeff, On 12/ 4/11 09:20 PM, Josef 'Jeff' Sipek wrote: snip I built it on the 151 sustaining zone @ EC. Perfect - just the answer I was looking for :-) I have one of those new Intel cards in my PC so I'm looking forward to giving this a spin :-D It works! Hurrah! *rips out the unnecessary PCIe one* If we can get another +1 from someone on this (Trisk/richlowe) then I think we can consider pushing out to /dev We might want to get the new pkg-gate built and pushed out soon too. Thanks again for this Jeff. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1818 - Upgrade m4 to latest version
Hi Bart, On 11/27/11 02:07 PM, Bart Coddens wrote: Hi List, Can this be reviewed ? https://bitbucket.org/bcoddens/oi-build/changeset/06a34066db9b it published fine on my machine and works without problems. Many thanks for providing this. GNU themselves on the Autoconf website say Autoconf works better with GNU M4 version 1.4.14 or later so updating from 1.4.12 to 1.4.16 sounds like a good move. I don't know if there will be any build consequences of doing this, however the whole point of /experimental is to find out. Only one minor nitpick before a +1, could you add your Copyright to the Makefile? Also, what was the reasoning behind removing the opensolaris arc_url? Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] userland-gate resync
Hi All, I was wondering if anyone had any comments on how we go about doing this - there are a considerable number of changesets to import, and RTI-ing them all would take forever. I was thinking we could do the userland-gate resync as one big RTI; clone oi-build on bitbucket, sync with userland resolving conflicts, then RTI it. Once it's RTI'd I can kick off a full rebuild in Jenkins and we'll see what has broken. I'd say that to keep the pace of development rapid, we should be aggressive with forward progress and allow moderate breakage of packages on the basis that the breakage can be fixed. We should still review contributions to ensure crap doesn't end up in the gate, but the userland-gate work is already reviewed over at Oracle, so in this instance I don't think we need to be overly bureaucratic. Does anyone want to do this particular block of work? It's fairly procedural and not too hard. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Feature 1768 - add dovecot to oi-build
Hi Colin, On 11/19/11 10:00 PM, Colin Ellis wrote: https://bitbucket.org/cellis_oidev/oi-build/changeset/d7b944645d37 Great stuff! You're going to hate me though... I have more work for you! :-D If you don't have time or would prefer me to do it just say and I'll do it. In the Makefile, you've put multiple flags on the same configure line. Would you mind splitting them out so it's one configuration option per CONFIGURE_OPTION ? I tend to group into clusters, so you'd have: CONFIGURE_OPTIONS += --enable-shared CONFIGURE_OPTIONS += --disable-static CONFIGURE_OPTIONS += --enable-header-install CONFIGURE_OPTIONS += --sysconfdir=$(ETCDIR) CONFIGURE_OPTIONS += --localstatedir=/var CONFIGURE_OPTIONS += --with-rundir=/var/run/$(COMPONENT_NAME) CONFIGURE_OPTIONS += --with-solr CONFIGURE_OPTIONS += --with-gssapi CONFIGURE_OPTIONS += --with-sqlite CONFIGURE_OPTIONS += --with-mysql CONFIGURE_OPTIONS += --with-pgsql CONFIGURE_OPTIONS += --with-ldap=plugin CONFIGURE_OPTIONS += --with-sql=plugin I was surprised to see /var hardcoded, thinking it would be in shared-macros.mk, but it appears it's missing! Do any other oi-builders think we should add a VARDIR= macro to shared-macros.mk? You should change /usr/lib to $(USRLIBDIR) and /usr to $(USRDIR) - this includes inside the LDFLAGS definitions. I'd also recommend refactoring the versioning, to: COMPONENT_MAJOR_VER= 2.0 COMPONENT_MINOR_VER= 15 COMPONENT_VERSION= $(COMPONENT_MAJOR_VER).$(COMPONENT_MINOR_VER) So that you can have: COMPONENT_ARCHIVE_URL= http://www.dovecot.org/releases/$(COMPONENT_MAJOR_VER)/$(COMPONENT_ARCHIVE) (Perhaps I'm being too anal!) For the SMF service, I'd recommend ditching the start method script and do the start/stop stuff in the manifest itself. I have no idea why so many services have one of these when they're often completely unnecessary. The if [ -f /etc/dovecot/dovecot.conf ] check can be turned into an SMF dependency, a la: dependency name='configuration-file' grouping='require_all' restart_on='refresh' type='path' service_fmri value='file://localhost/etc/dovecot/dovecot.conf' / /dependency (I think that's correct - I'm not 100% sure on the restart_on) For the start method, you can just directly have /usr/sbin/dovecot, for the refresh method you can use the lovely SMF macro, :kill -HUP, and for stop you can use :kill I'd also recommend changing enabled='true' to enabled='false' so it doesn't get automatically started when dovecot is installed. You'll also want to add the Illumos CDDL header to the manifest file, along with your own copyright line. You can ditch the ident GPG line. You also committed the removal of components/gcc46/gcc.p5m in that commit which you probably didn't want to do! Not an issue though we can work around it when we commit this to the main repo. Last nitpick is the .la files are still there - I'd recommend dropping these by adding the following transform near the top: transform file path=.+/lib/.+\.la - drop (This is better than removing them manually - it makes maintaining the .p5m file easier as someone else can do make sample-manifest and diff them). Apart from these cosmetic changes, it's looking good! Great work Colin and thanks for your hard work :-) Looking forward to doing the full commit. Cheers, Alasdair On Tue, Nov 15, 2011 at 12:43 AM, Josef 'Jeff' Sipek jef...@josefsipek.net mailto:jef...@josefsipek.net wrote: On Sat, Nov 12, 2011 at 11:17:10PM +, Colin Ellis wrote: bitbucket here: https://bitbucket.org/cellis_oidev/oi-build/changeset/d7c2addf18b7 Awesome, this one was on my todo list. Less work for me :) 1) no need to set --prefix --sbindir yourself 2) $(ETCDIR) instead of /etc 3) did the `gmake publish` not complain about the missing info.classification? 4) Do we really need to ship all those .a and .la files? Solaris likes shared libs a lot - and handles them pretty well too. 5) Do the files in usr/share/doc have the doc facet? (They should; you can check the published manifest.) 6) Is there an SMF manifest? Thanks! Jeff. -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer. — IBM Manual, 1925 ___ oi-dev mailing list oi-dev@openindiana.org mailto:oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org
Re: [oi-dev] Feature 1768 - add dovecot to oi-build
Forgot to mention, your .p5m files need the opensolaris package classifications being filled in. If you're not sure what to use, just shout and we can collectively think up an answer. On 11/19/11 10:00 PM, Colin Ellis wrote: https://bitbucket.org/cellis_oidev/oi-build/changeset/d7b944645d37 On Tue, Nov 15, 2011 at 12:43 AM, Josef 'Jeff' Sipek jef...@josefsipek.net mailto:jef...@josefsipek.net wrote: On Sat, Nov 12, 2011 at 11:17:10PM +, Colin Ellis wrote: bitbucket here: https://bitbucket.org/cellis_oidev/oi-build/changeset/d7c2addf18b7 Awesome, this one was on my todo list. Less work for me :) 1) no need to set --prefix --sbindir yourself 2) $(ETCDIR) instead of /etc 3) did the `gmake publish` not complain about the missing info.classification? 4) Do we really need to ship all those .a and .la files? Solaris likes shared libs a lot - and handles them pretty well too. 5) Do the files in usr/share/doc have the doc facet? (They should; you can check the published manifest.) 6) Is there an SMF manifest? Thanks! Jeff. -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer. — IBM Manual, 1925 ___ oi-dev mailing list oi-dev@openindiana.org mailto: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] Fuse and NTFS-3g
Hi Damian, Yes, very much. oi-build is probably the best place to stick it. http://wiki.openindiana.org/oi/Contribution+Process http://wiki.openindiana.org/oi/Building+with+oi-build Cheers, Alasdair On 3 Nov 2011, at 08:58, Damian Wojsław wrote: Hi I would like to work on inclusion of fuse and ntfs-3g into main openindiana package repo and also maintain packages if they get included. Is OI interested? -- Damian Wojsław This message was sent using IMP, the Internet Messaging Program. ___ 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] Building Userland on Solaris 10
Hi John, s10-userland is exactly for that purpose. We have a bootstrap tarball you can extract to / from here: http://svn.everycity.co.uk/public/solaris/misc/pkg5-s10-bootstrap-20110518.tar.gz This will install the IPS package manager to /ec/bin/pkg which you can then use to install packages from http://s10.pkg.ec If you want to change the prefix from /ec you'll need to rebuild everything in the s10-userland repo having modified the make rules. It's quite a big job but not impossible. There's an old and somewhat out of date but still helpful/useful video here: http://linux01.everycity.co.uk/~alasdair/Userland.mov If you encounter any issues let us know. Cheers, Alasdair On 1 Nov 2011, at 20:47, John Center wrote: Hi, I don't know if this is the right place to ask this, but I'd like to build some Userland applications on Solaris 10. I see there is something called s10-userland, can it be used for this purpose? If so, any pointers to getting started? Thanks. -John -- John Center Villanova University ___ 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] aszeszo gnome bits available
Hi Bayard, Many thanks for picking that up - it's much appreciated! Also a big big thanks to Andrzej Szeszo for the initial high quality work here; it has been a large investment in his time and it'll be great to get these packages integrated. Cheers, Alasdair On 17 Oct 2011, at 21:38, Bayard G. Bell wrote: As per the last #oi-meeting, people agreed to pick up most of these to clean up for oi-build. These are now available at: https://bitbucket.org/buffyg/components-gnome I'll briefly transfer the assignments made at #oi-meetings into items in the BB issue tracker for the project. If you want to pick up something unassigned, just submit an issue saying which component(s) you'd like to sort out. I'll close items and remove them from this gate as they are accepted here by the standard submission process. 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
Re: [oi-dev] 1653 package xmessage
On 15 Oct 2011, at 18:33, Josef 'Jeff' Sipek wrote: Any issues with merging this? http://hg.31bits.net/oi/oi-build-xmessage/rev/2a8d1caea18f LGTM! ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Continuous Integration Improvements
Hi Jeff, On 10 Oct 2011, at 02:58, Josef 'Jeff' Sipek wrote: First of all...very cool! I hope to add the new repo to some of my systems to start benefiting from the additional/updated software. Remember to be careful - here be dragons etc ;-) Now, the questions/issues... :) The catalog [1] lists (or it says that it lists 59 packages. There are about 160 directories in oi-build/components. Are things still building? Are some of them not publishing? Is the repo broken (out of date index)? Everything is built, but the publishing stage (publishing to the local repo after a build) has been failing on a lot of packages due to pkgdepend errors. The errors are a result of me switching from oi-build as a publisher to oi-experimental. This was so that the ci-build box can easily publish to pkg.oi.o/experimental without needing a lengthy set-publisher phase. I'm working on this and everything should be published soon. Moving forwards it won't be an issue - it will just work. It looks like I'll be pushing out irssi to oi-build in the next day or two. Sadly, that's included in the gnome-incorporation. /experimental has entire, sfw-incorporation, etc. but nothing to fix JDS. I've just shipped an empty gnome-incorporation to /experimental: http://pkg.openindiana.org/experimental/info/0/pkg%3A%2F%2Foi-experimental%2Fconsolidation%2Fgnome%2Fgnome-incorporation%400.5.11%2C5.11-1.1%3A20111010T103810Z Looking forward to irssi. Adding new bits of software requires running a script on the ci-master box then prodding jenkins to reload its config files. I'm going to try to find a way to do that automagically. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Continuous Integration Improvements
Hi All, Behold: http://ci-master.uk.openindiana.org/ I have a bulk build of everything in progress, and after each successful package install, it will publish to http://pkg.openindiana.org/experimental/ This is exactly what we have been after for some time now :-) It should hopefully be very satisfying for developers to see their work go very rapidly from http://hg.openindiana.org/oi-build/ to the public repo for all to use. The /experimental repo needs more work - the pkg version in the repo at present is somewhat broken due to linked images, and there will no doubt be other sources of breakage, but at least we now have a strong base to work from. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1576 update irssi package, attempt 2
Hi Jeff, Looks good :-) My only comment is you might want to drop: file path=usr/lib/irssi/modules/libirc_proxy.a But other than that it looks really good! :-D Cheers, Alasdair On 8 Oct 2011, at 00:07, Josef 'Jeff' Sipek wrote: Here's attempt #2: http://hg.31bits.net/oi/oi-build-irssi/rev/76d6998dea83 I dropped one of the JDS patches since oi-build has a manpage stability mangler. The weird /usr/include/irssi/src is weird, but that's how it's supposed to look like. Jeff. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. ___ 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] 1535 update gmake to 3.82
On 20 Sep 2011, at 17:46, Josef 'Jeff' Sipek wrote: On Tue, Sep 20, 2011 at 11:08:36AM +0100, Alasdair Lumsden wrote: Hi Peter, On 19/09/2011 18:36, Peter Tribble wrote: My notes say that gmake-3.82 broke my build of gstreamer. I found that out pretty quickly and rolled back, so didn't investigate many more packages. (That was under Solaris 10, by the way, if that matters.) I wouldn't necessarily take my feedback as derailing gmake-3.82, just as a warning that it's probably worth testing it more thoroughly. *nods* Given how critical it is I think we'll err on the side of caution, I've updated the issue so we deliver an additional 3.82 package. https://www.illumos.org/issues/1535 Fair enough. Since it's not something that we must update, I'll put it on the back burner. It would be good to have it for the LibreOffice build, so if you get a chance you'd get a +1 for delivering an additional gmake-3.82 binary from me. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1220 add /usr/bin/gpg symlink
Hi Bayard, On 3 Oct 2011, at 18:11, Bayard G. Bell wrote: On Sat, 2011-10-01 at 20:29 -0400, Josef 'Jeff' Sipek wrote: Any issues with merging this? http://hg.31bits.net/oi/oi-build-gnupg/rev/6e09047a6043 (https://www.illumos.org/issues/1220) If the bug report is agreed, I reckon there needs to be a comment summarising this. Anything that has to be done in addition to or as a modification of copying out the proto tree needs some kind of reader's notes, and manifests may be the de facto place to retain that information, either as comments or README files. Yes, it is probably worth annotating additions/deletions to the .p5m file so that someone coming along and updating a package knows what the deviations from a gmake sample-manifest are. Perhaps # Adding gpg symlink as per Illumos issue #1220 ? In s10-userland we actually store the gmake sample-manifest files in a sample-manifests subdirectory so that it is trivial to compare the proto areas when bumping software versions. I wonder if it's worth us doing this in oi-build. It would probably help avoid mistakes when version-bumping software where the .p5m file has been modified. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1220 add /usr/bin/gpg symlink
On 3 Oct 2011, at 21:14, Josef 'Jeff' Sipek wrote: On Mon, Oct 03, 2011 at 09:56:26PM +0200, Guido Berhoerster wrote: Hi, * Josef 'Jeff' Sipek jef...@josefsipek.net [2011-10-02 02:29]: Any issues with merging this? http://hg.31bits.net/oi/oi-build-gnupg/rev/6e09047a6043 (https://www.illumos.org/issues/1220) if you create this link for gpg2 you should also create it for gpgv2 for consistency and also add symlinks for their respective manpages. Good point! Don't suppose you got around to an updated changeset? :-D Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1262 Berkeley-db package
Hi Alex, On 3 Oct 2011, at 22:08, Alex Viskovatoff wrote: On Mon, 2011-10-03 at 16:34 -0400, Josef 'Jeff' Sipek wrote: snip Is there some special reason why you are working on this package, given that oi-sfe already delivers it and the Before adding new packages to oi-build remark in http://wiki.openindiana.org/oi/Building+with+oi-build ? SFE is technically a third party repo, which doesn't receive the same amount of QA/testing that our core packages do. Think of it as a contrib repo. The note on the wiki is really referring to extra or additional software like VLC/Inkscape/etc which are big less commonly used software. BerkeleyDB is an important, core bit of software that we should deliver in oi-build. Since oi-sfe uses IPS, packages built with oi-build can depend on packages from oi-sfe. Definitely not - the core distro should not depend on optional 3rd party repos that might not be present in an end-users publisher list. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1262 Berkeley-db package
On 3 Oct 2011, at 23:31, Bayard G. Bell wrote: On Mon, 2011-10-03 at 17:08 -0400, Alex Viskovatoff wrote: On Mon, 2011-10-03 at 16:34 -0400, Josef 'Jeff' Sipek wrote: Bayard made a good point, one will generally want multiple versions of bdb. Thoughts about having bdb-4.8 (and bdb-5.2)? Can you or he give examples of why one would want that? It would be a nuisance, because one would have to decide on some naming convention, so that multiple versions could be installed together. Do Linux distributions ship multiple versions of bdb? Ubuntu, for example, delivers libdb4.6, libdb4.7, and libdb4.8 for libraries. (I'm running BackTrack 5, which is based off 10.04, so this is a bit dated.) The distro simply doesn't deliver any links to the libraries, so everything has to decide which version to link against by both major and minor version. I've ended up with one each for the core C runtime because I have essentially three packages, each using a different version. I've seen similar things in other porting environments, which leads me to suspect that, if there's a nuisance argument, it's that, as a porting system carries more packages, it decides the greatest nuisance is forcing them all to use one version of BDB. That's an important point. That presumably means drop: link path=usr/lib/libdb-4.so target=libdb-4.8.so link path=usr/lib/libdb.so target=libdb-4.8.so ? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1262 Berkeley-db package
Hi Jeff, Bayard, Bayard - nice review points! On 3 Oct 2011, at 18:06, Bayard G. Bell wrote: snip 2) is there any basis for thinking that bdb should only be built for 32-bit support, or would we reasonably expect that 64-bit binaries would need to link against it? For a library like bdb, we should ship 64bit binaries/libraries. 3) it looks like the default behaviour for library link generation is to create links that look like libname-version.so rather than libname.so.version; which convention is expected for OI? I'm not sure we should adjust the software vendor's defaults - and usually these are generated by libtool (I think!). But, the exception I'd say if other distros adjust the name, then we probably should too. 4) a lot of the content appears to be documentation; have you confirmed that all of it is correctly tagged with the doc facet? Good catch. snip 6) given the prevalence of bdb and how low it tends to be in the stack, might we also consider providing debug support? are there any standing rules on how that should be done? No rules on debug support as far as I know. There might be some funky pkg5 way of delivering debug vs non-debug binaries but I'd have to look that up. I think it could be omitted on a first pass and added later if desired. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1262 Berkeley-db package
Hi Guido, On 3 Oct 2011, at 23:55, Guido Berhoerster wrote: snip Also the documentation should be delivered into /usr/share/doc/package and not /usr/docs. Good catch! ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1262 Berkeley-db package
Hi Bayard, On 4 Oct 2011, at 02:09, Bayard G. Bell wrote: snip If OI decides now is the time to start delivering, let's at least check for other areas of overlap and make sure that we're standing solidly on your shoulders. In particular, how about other questions raised, such as delivering debug and multiple bitness versions? Also, since the docs pointed to the question of language bindings, we really should decide whether the same component in oi-build should deliver bindings other than the basic C stuff and divy up documentation with the appropriate library packages. Debug builds - tbc. Is it possible to deliver multiple versions of the same file with IPS, eg if you had a debug facet or something (straying past the edge of my IPS knowledge here). Multiple bitness - the convention is that libraries or packages that benefit from 64bit should be shipped as a combined 32bit/64bit. BerkeleyDB classifies as a system library so should ship with 64bit. Apache/MySQL/PHP also qualify as deserving 64bit versions. XCowsay or mutt for example would be fine as 32bit only. Dropping documentation for bindings we don't deliver seems completely reasonable to me! :-) Looking quickly at my Ubuntu/BT systems, it looks like they package java, tcl, and c++ libraries separately for each libdb release. Should we do the same, plus providing debug facets or variants? (I assume that the dynamic languages provide their own libraries, possibly in the core release.) Putting the question more broadly, what expectation do we have about providing debug libraries, particularly for things taken to be common/pervasive (I'm asking a leading question, as I'm wondering if we ought to try to bake some form of debug support simplification into the Makefile infrastructure)? Is this BerkeleyDB commit just the pure C bindings or does this package cover C++, Java and TCL as well? The debug question sounds like more hassle than it's worth at this point. The urgent need is for updated and additional packages. Debug support is just going to add more work to the packaging procedure. Potentially in the future it's worth adding but I'd prefer to keep the packaging procedure lightweight right now and try to build up the volume of commits/maintainers/contributors. Then we can start throwing additional work at them :-D Potentially if someone wants debug support badly, they can check out oi-build and rebuild the package in question themselves, since the idea is that oi-build should be super-easy to use. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1262 Berkeley-db package
On 4 Oct 2011, at 12:24, Guido Berhoerster wrote: * Josef 'Jeff' Sipek jef...@josefsipek.net [2011-10-02 02:59]: Any issues with merging this? http://hg.31bits.net/oi/oi-build-bdb/rev/ecc62b981eb7 (https://www.illumos.org/issues/1262) Thanks, The Userland-gate mirror is back online, so you should have a look at http://hg.openindiana.org/upstream/oracle/userland-gate/rev/aded0f0f9594 Yes - definitely worth comparing yours to this one and taking any useful bits from it. Looking forward to a revised changeset. Thanks for all the hard work Jeff! :-D ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Request for volunteers: Building LibreOffice
Hi All, http://alasdairrr.tumblr.com/post/10404734792/libreoffice We've been joined by a LibreOffice developer in #oi-dev, who is willing to help us with a port of LibreOffice to OpenIndiana. Unfortunately all the usual suspects who might work on this are tied up - so I'm mailing the lists to find out if anyone might be interested in collaborating with us on this? Ideally someone who steps forward should know their way around a Makefile pretty well and have ported software to Solaris before - LibreOffice is pretty big. Getting LibreOffice into OI would be a big win - it's an often requested package. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Request for volunteers: Building LibreOffice
Awesome! Be great to have LibreOffice on OI, if only to snub Oracle :-P Quite :-) Last I poked around, the jury was still out on LibreOffice vs. Apache's incarnation of OpenOffice as preferred office suite on OI. But I've been being a fun hog and away from the 'puter for much of the summer - has OI subsequently developed a consensus? 00:43 -!- Irssi: #openoffice: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal] 00:43 -!- Irssi: #libreoffice: Total of 79 nicks [7 ops, 0 halfops, 0 voices, 72 normal I think LibreOffice has gotten the mindshare - happy to be corrected if thats not the case. I don't even mind if we ship both, but I think LibreOffice is the logical choice. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1535 update gmake to 3.82
Hi Jeff, On 19/09/2011 15:45, Josef 'Jeff' Sipek wrote: The current version of gmake is 3.81. That was released in 2006. There has been bugfixes since, and version 3.82 was released in April 2010. This change bumps the gmake version to 3.82. As far as testing is concerned, I used it to build parts of oi-build. http://hg.31bits.net/oi/oi-build-make/rev/0305fbc59d33 Oh, and before you ask... I had to remove the rw locale from the manifest since gmake no longer ships it. (From the gmake changelog: One of our translations disappeared from the translations site so remove it.) Looks good to me! I'm not aware of any problems that might result from upgrading to gmake 3.82 - does anyone on-list know of any? Are there any main-stream distros using it as their main gmake? Cheers, Alasdir ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1535 update gmake to 3.82
Hi Peter, On 19/09/2011 16:52, Peter Tribble wrote: On Mon, Sep 19, 2011 at 4:29 PM, Alasdair Lumsdenalasdai...@gmail.com wrote: snip Looks good to me! I'm not aware of any problems that might result from upgrading to gmake 3.82 - does anyone on-list know of any? I've had several build failures caused by gmake 3.82. I can't remember what applications failed (not on the right system at the moment) but my general conclusion was to stick at 3.81 and blacklist 3.82. Hmm, that's a bit annoying. We were hoping to use 3.82 to fix a problem with the libreoffice build. What about making a copy of the userland component to ship an additional gmake-3.82 package which delivers only the newer gmake binary? That way /usr/bin/gmake is 3.81 and /usr/bin/gmake-3.82 is 3.82, both co-existing together. This would help assist with the libre office build. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Possible bug with zones/crossbow using OpenIndiana oi_151
Hi There, On 09/10/11 04:34 PM, carlopmart wrote: On 09/08/2011 09:41 AM, carlopmart wrote: snip Can somebody confirms that maybe exists a bug using exclude as ip-type option under OpenIndiana oi_151's zones/crossbow?? Exclusive IP zones work fine. As far as I know there are no major bugs with it - we use Zones with vnics to host all the OpenIndiana services like hg.openindiana.org, pkg.openindiana.org, dlc.openindiana.org, etc. It's more likely to be something with your networking setup. Start simple, and build up from there. Regards, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Possible bug with zones/crossbow using OpenIndiana oi_151
On 09/10/11 05:36 PM, carlopmart wrote: Thanks Alasdair, but using what build 148 or 151?? We've got boxes running 147, 148 and 151... ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New Issue - 1486 Firefox Bookmarks out of date
Hi Gary, On 09/ 9/11 05:08 PM, Gary wrote: some mod_rewrite redirects could fix the problem temporarily for the mailing list link but with pkgdev.openindiana.org http://pkgdev.openindiana.org you'd have to have DNS point somewhere else for a redirect to work. Yes that's probably a good idea - pkgdev is a zone that runs pkg servers. I can spin up a basic apache and redirect. I guess we'd need to speak to the Illumos folk about the mailing lists url. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New OI 151a test ISO available
Hi TJ, On 10 Sep 2011, at 01:25, TJ Yang wrote: Also, should we offer vm images by vmware and virtualbox for people to download ? I can volunteer myself for vmware image preparation. That would be exceptionally useful - yes! Once the release is out please get in touch :-) Also thanks for reporting the grub issue, I'll look into it this weekend. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New OI 151a test ISO available
Hi TJ, Was your grub issue with the Text Installer or the Live ISO? It looks like the splashimage bits are missing so your bootfs line runs on to the kernel line. I can't reproduce it with the Live ISO (gui installer) so am wondering if you installed from the Text installer. Cheers, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
