Re: [oi-dev] build-essential package review
On 07/11/2013 05:14, Adam Števko wrote: Hi guys, I created build-essential package and I would like you to review and tell me what else should be included. Changeset URL: https://github.com/xen0l/oi-userland/commit/7026fe8373c2e15a7d1d88595a8d34214e8d1ed8 Packages, which are commented out are either not found in /hipster and need porting from ec-userland or are duplicate (pkg-config vs gnome/gettext). i started with manifest from ec-userland and I added all things from make-rules/build-zone.mk. Next important step is to modify build-zone.mk, so setting up development environment is not complicated and newcomers have easy way to start contributing. I plan on documenting that process as well. And one last thing, do you guys think that Is there a point in including sunstudio12u1 and clang-3.3 as well in this package? Good morning. Some things to note about clang++: 1) we are waiting for http://cr.illumos.org/~webrev/alp/illumos-3853/ to be committed (I've sent requested files for RTI on 8 July) 2) libm manifest should be updated (I'll do it today) 3) Based on Garret's comment ( http://www.listbox.com/member/archive/182179/2013/07/sort/subj/page/5/entry/1:144/20130704093920:1F9F7940-E4AF-11E2-A73A-8A58AD210B6D/ ) components/illumos/illumos-gate/Makefile should be updated to drop sys/lc_core.h and sys/localedef.h (he says these two are legacy and nonfunctional in its current state). -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] build-essential package review
On 11/07/2013 03:51, Udo Grabowski (IMK) wrote: On 11/07/2013 03:14, Adam Števko wrote: Hi guys, I created build-essential package and I would like you to review and tell me what else should be included. Changeset URL: https://github.com/xen0l/oi-userland/commit/7026fe8373c2e15a7d1d88595a8d34214e8d1ed8 Packages, which are commented out are either not found in /hipster and need porting from ec-userland or are duplicate (pkg-config vs gnome/gettext). i started with manifest from ec-userland and I added all things from make-rules/build-zone.mk. Next important step is to modify build-zone.mk, so setting up development environment is not complicated and newcomers have easy way to start contributing. I plan on documenting that process as well. And one last thing, do you guys think that Is there a point in including sunstudio12u1 and clang-3.3 as well in this package? If you want to reduce it to a kernel and oi-developer distribution only, leave out anything that's not needed. But remember, once OI was an effort to continue Opensolaris, which was intended to be run by USERS who do NOT develop a kernel or OS, but use it to do their completely unrelated work (which, in our case, totally relies on having the Sun Studio compiler...you seriously can't use gfortran for any real work !). Forgot to mention the big bunch of packages in /usr/local/ that all have been compiled with sunstudio, which would have to be redone with gcc, which is often a more involved task for those packages So if you drop sunstudio, many packages on a lot of current installations will just fail and would have to be rebuild. -- Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT www.imk-asf.kit.edu/english/sat.php KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] imagemagick
On 07/11/2013 12:23, Udo Grabowski (IMK) wrote:
On 10/07/2013 23:23, Alexander Pyhalov wrote:
I'm a bit confused.
$ pkg search -Hr 'depend::image/imagemagick' | awk '{ print $4; }' |
cut -d @ -f 1 | sort | uniq
pkg:/desktop/xscreensaver/hacks/rss-glx
pkg:/redistributable
pkg:/SUNWimagick
Don't we have anything in repository except one scrensaver that requires
imagemagick ???
Maybe because someone uses ImageMagick because it is a useful
package by itself and not only has been invented to serve another
package as a library ???
Or I'm on a wrong track when I use this, e.g., in perl scripts
to do image processing ?
I'm just trying to estimate possible consequences of updating
ImageMagick and what will be broken.
--
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] build-essential package review
Hi, I will look into pkg-config and add it later tonight. build-essential is primarily targeted to be used to build oi-userland. I have no problem adding things that are needed to build illumos-gate, but I could use an list. Is there anything else besides http://wiki.illumos.org/display/illumos/How+To+Build+illumos#HowToBuildillumos-Installingrequiredpackages ? Cheers, Adam On Jul 11, 2013, at 9:25 AM, David Höppner 0xf...@gmail.com wrote: Hi, looks great. Oracle userland also has a separate pkg-config now. Some stuff for building illumos-gate is missing (intentionally?) -- David [1] https://hg.openindiana.org/upstream/oracle/userland-gate/file/15aec33b84fa/components/pkg-config On 11 July 2013 03:14, Adam Števko adam.ste...@gmail.com wrote: Hi guys, I created build-essential package and I would like you to review and tell me what else should be included. Changeset URL: https://github.com/xen0l/oi-userland/commit/7026fe8373c2e15a7d1d88595a8d34214e8d1ed8 Packages, which are commented out are either not found in /hipster and need porting from ec-userland or are duplicate (pkg-config vs gnome/gettext). i started with manifest from ec-userland and I added all things from make-rules/build-zone.mk. Next important step is to modify build-zone.mk, so setting up development environment is not complicated and newcomers have easy way to start contributing. I plan on documenting that process as well. And one last thing, do you guys think that Is there a point in including sunstudio12u1 and clang-3.3 as well in this package? Cheers, Adam ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev smime.p7s Description: S/MIME cryptographic signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] build-essential package review
On 11 July 2013 12:20, Adam Števko adam.ste...@gmail.com wrote: Is there anything else besides http://wiki.illumos.org/display/illumos/How+To+Build+illumos#HowToBuildillumos-Installingrequiredpackages ? only sunstudio is missing from this list. Sometimes I needed to install gcc-3 to get gcc-44 working. -- David ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] build-essential package review
Adam, Nice! I especially like the gcc-4.7 bits... On Studio 12u1: I (Personally) wouldn't see much value in its being included in a build-essentials package. 12.3 might be another matter, of course, but thought we had a barrier to redistribution on the Studio line? Regards All, Lou - Original Message - From: Adam Števko To: OpenIndiana Developer mailing list Sent: Thu, 11 Jul 2013 01:14:17 - (UTC) Subject: [oi-dev] build-essential package review Hi guys, I created build-essential package and I would like you to review and tell me what else should be included. Changeset URL: https://github.com/xen0l/oi-userland/commit/7026fe8373c2e15a7d1d88595a8d34214e8d1ed8 Packages, which are commented out are either not found in /hipster and need porting from ec-userland or are duplicate (pkg-config vs gnome/gettext). i started with manifest from ec-userland and I added all things from make-rules/build-zone.mk. Next important step is to modify build-zone.mk, so setting up development environment is not complicated and newcomers have easy way to start contributing. I plan on documenting that process as well. And one last thing, do you guys think that Is there a point in including sunstudio12u1 and clang-3.3 as well in this package? Cheers, Adam ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
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
[oi-dev] HEADS UP: imagemagick is updated
Hello. I'd like to inform you that I've updated imagemagick in oi-hipster. It is binary incompatible with previous version. Luckily, the only dependent package in our gate is pkg:/desktop/xscreensaver/hacks/rss-glx It should be recompiled. On 07/11/2013 13:05, ken mays wrote: Nothing major in the core distro depends on it. Safe to integrate. -Ken ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ 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] Release engineering // planing
Strongly agree on all notes Alisdair has made. Furthermore, if people are using OI in production, they should have their own suitable testing procedures in place to avoid the majority of (if not all) upsets. Regards On 11 July 2013 at 17:53 Alasdair Lumsden alasdai...@gmail.com wrote: 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 abouthttp://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.net mailto:kgund...@teamcool.net wrote: 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 mailto: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 mailto: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 mailto: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
As I have a few servers deployed in production with OI I am happy to see the ball rolling again. I use OI as a virtualization host with VBox. How do we get it so there are checkpoints in the release cycle that you can target a specific point in time? Something that doesn't cause too much burden to manage from a developer point of view. When I am deploying an OI server I can target that date/version. thanks, Geoff On 13-07-11 09:58 AM, h...@myhomeemail.co.uk wrote: Strongly agree on all notes Alisdair has made. Furthermore, if people are using OI in production, they should have their own suitable testing procedures in place to avoid the majority of (if not all) upsets. Regards On 11 July 2013 at 17:53 Alasdair Lumsden alasdai...@gmail.com wrote: 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 http://www.openindiana.org - it's ugly and out of date :-) Regards, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 11/07/2013 18:53, Alasdair Lumsden wrote: 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.A ... But at that point, there should be provided a way to switch current people on /dev to /release, surely most do not want to be exposed to hipster... And that seems not to be trivial, probably it needs a bump to a new release number. Personally I think this switch should be done now on the base of a7 (sunstudio compiled, with maybe a few couple of known stable fixes), as hipster is currently going sidewards with all the changes to gcc, it will probably not stabilize within the next two months, and a7 is mostly rock stable (with a few user visible problems due to the png12 -- png14 hassles). smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
I think an updated illumos-gate packages should go into oi_151a7 first, because of NFS related BUG fix #2986. On Jul 11, 2013, at 8:08 PM, Udo Grabowski (IMK) udo.grabow...@kit.edu wrote: On 11/07/2013 18:53, Alasdair Lumsden wrote: 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.A ... But at that point, there should be provided a way to switch current people on /dev to /release, surely most do not want to be exposed to hipster... And that seems not to be trivial, probably it needs a bump to a new release number. Personally I think this switch should be done now on the base of a7 (sunstudio compiled, with maybe a few couple of known stable fixes), as hipster is currently going sidewards with all the changes to gcc, it will probably not stabilize within the next two months, and a7 is mostly rock stable (with a few user visible problems due to the png12 -- png14 hassles). ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Piotr Jasiukajtis ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Bumping zlib to 1.2.8
Folks, I bumped zlib to the latest version. The update should be backwards compatible, but dependency list is long and something might break. Need your assistance here. One of the issues that has to be resolved _before_ updating zlib is to update libxml2 to a version higher that 2.7.6. In 2.7.6 there is a nasty bug, fiddling with zlib internal structures, causing libxml2 coredump with newer zlib versions. I will look into libxml2 recipe later on/tomorrow. Here's the diff for review, please comment. Thx. https://github.com/erolms/oi-userland/compare/zlib Cheers, Erol ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Release engineering // planing
On 11/07/2013 20:33, Piotr Jasiukajtis wrote: I think an updated illumos-gate packages should go into oi_151a7 first, because of NFS related BUG fix #2986. Agreed, most NFS fixes up to now are also very interesting to us, and illumos gate has a good peer review to trust it to be stable. On Jul 11, 2013, at 8:08 PM, Udo Grabowski (IMK) udo.grabow...@kit.edu wrote: On 11/07/2013 18:53, Alasdair Lumsden wrote: 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.A ... But at that point, there should be provided a way to switch current people on /dev to /release, surely most do not want to be exposed to hipster... And that seems not to be trivial, probably it needs a bump to a new release number. Personally I think this switch should be done now on the base of a7 (sunstudio compiled, with maybe a few couple of known stable fixes), as hipster is currently going sidewards with all the changes to gcc, it will probably not stabilize within the next two months, and a7 is mostly rock stable (with a few user visible problems due to the png12 -- png14 hassles). On 11/07/2013 22:06, Jonathan Adams wrote: a separate dev where anything goes however allows development to happen at a much greater pace for initial testing, without disturbing the long term future stables. At least before a stable release is in sight, a /dev repository is a good temporary testbed before rolling out, it can select only the more stable stuff to test, and can rest for a while after the actual release. smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
