From slowfranklin at opencsw.org Mon Sep 2 15:26:52 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 15:26:52 +0200 Subject: [csw-maintainers] Samba 4 Message-ID: Hi as promised, I'm now on to tackle the Samba 4 package. I've been studying the Fedora Samba 4 package [1], comparing with what we have right now in the gar recipe. The set of package Fedora rolls is substantially different to what we have and imo we should take a similar approach. This is our current set for Samba 4: PACKAGES += CSWsamba4 PACKAGES += CSWsamba4-client PACKAGES += CSWlibnetapi0 PACKAGES += CSWlibnss-winbind1 PACKAGES += CSWsamba4-dev PACKAGES += CSWsamba4-swat PACKAGES += CSWsamba4-winbind These are the Samba 3 packages: PACKAGES += CSWsamba PACKAGES += CSWsamba-client PACKAGES += CSWlibsmbclient0 PACKAGES += CSWlibwbclient0 PACKAGES += CSWlibnetapi0 PACKAGES += CSWlibsmbsharemodes0 PACKAGES += CSWlibtdb1 PACKAGES += CSWsamba-nss PACKAGES += CSWsamba-nss-system-links PACKAGES += CSWsamba-pam-system-links PACKAGES += CSWlibtevent0 PACKAGES += CSWsamba-dev PACKAGES += CSWsamba-swat PACKAGES += CSWsamba-winbind Only Samba 3 package consumed by other packages is CSWlibsmbclient0 (by CSWgnomevfs2 and CSWvlc). For reference, this is Fedora's set: samba4 samba4-client samba4-common samba4-dc samba4-dc-libs samba4-devel samba4-libs samba4-python samba4-pidl samba4-test samba4-winbind samba4-winbind-clients samba4-winbind-krb5-locator libsmbclient libsmbclient-devel libwbclient libwbclient-devel I propose the following changes to the Samba 4 recipe: o drop the 4 prefix, Fedora is considering the same [2]: "As samba4 is a superset of Samba 3 packages in Fedora, we are also considering to discuss renaming samba4 back to samba. As all existing API and ABI for smbd/nmbd/winbindd and libsmbclient library will be the same, the switch is not going to be problematic. However, there is still need to stabilize code through beta and pre-releases before doing that." o add the following packages: CSWsamba-common ... common files CSWsamba-lib ... Samba libraries CSWsamba-dc ... the new Samba 4 AD DC stuff CSWsamba-dc-libs ... libraries for CSWsamba-dc CSWlibtdb1 ... present in Samba 3, but missing in 4 CSWlibwbclient0 ... present in Samba 3, but missing in 4 CSWlibsmbclient0 ... present in Samba 3, but missing in 4 CSWlibsmbsharemodes0 ... present in Samba 3, but missing in 4 CSWsamba-nss-system-links ... present in Samba 3, but missing in 4 CSWsamba-pam-system-links ... present in Samba 3, but missing in 4 o drop the following packages: CSWlibnss-winbind1 ... obsoleted by CSWsamba4-wb-clients CSWlibnetapi0 ... unused CSWsamba4-swat ... SWAT is dead CSWsamba-nss ... merge content to CSWsamba-winbind The expactation is that users of the current Samba 3 package should be able to upgrade to Samba 4 in filesserver/NT DC mode without issues. Anyone who wants to run a AD DC must perform a manual setup as described in the Samba docs. There will be no support for auto-running the new samba AD controller process from init/SMF. Thoughts? -slow [1] [2] From laurent at opencsw.org Mon Sep 2 17:15:38 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 02 Sep 2013 17:15:38 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: Message-ID: <5224AB9A.4090101@opencsw.org> Here are some quick thoughts, below. > I propose the following changes to the Samba 4 recipe: > > o drop the 4 prefix, Fedora is considering the same [2]: > > "As samba4 is a superset of Samba 3 packages in Fedora, What does that bit mean, exactly? Are you sure it applies here, ie, will Samba 4 really be a superset of Samba 3 packages? AFAIK, Fedora is a fast-running distro, they might not care as much for stability. > we are also considering to discuss > renaming samba4 back to samba. As all existing API and ABI for smbd/nmbd/winbindd and > libsmbclient library will be the same, the switch is not going to be problematic. However, > there is still need to stabilize code through beta and pre-releases before doing that." > > o add the following packages: > > CSWsamba-common ... common files > CSWsamba-lib ... Samba libraries > CSWsamba-dc ... the new Samba 4 AD DC stuff > CSWsamba-dc-libs ... libraries for CSWsamba-dc > CSWlibtdb1 ... present in Samba 3, but missing in 4 > CSWlibwbclient0 ... present in Samba 3, but missing in 4 > CSWlibsmbclient0 ... present in Samba 3, but missing in 4 > CSWlibsmbsharemodes0 ... present in Samba 3, but missing in 4 > CSWsamba-nss-system-links ... present in Samba 3, but missing in 4 > CSWsamba-pam-system-links ... present in Samba 3, but missing in 4 So there, how do you handle having packages with the same names but different origins? How will it impact people willing to stay on Samba 3 for the time being? > The expactation is that users of the current Samba 3 package should > be able to upgrade to Samba 4 in filesserver/NT DC mode without > issues. Anyone who wants to run a AD DC must perform a manual setup > as described in the Samba docs. There will be no support for > auto-running the new samba AD controller process from init/SMF. Does that mean that process is run automatically by the regular SMF once it's configured appropriately? Laurent From pfelecan at opencsw.org Mon Sep 2 17:25:36 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 02 Sep 2013 17:25:36 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: (slowfranklin@opencsw.org's message of "Mon, 2 Sep 2013 15:26:52 +0200") References: Message-ID: slowfranklin writes: > Thoughts? Have you explored how Debian is doing this? -- Peter From pfelecan at opencsw.org Mon Sep 2 17:27:05 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 02 Sep 2013 17:27:05 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224AB9A.4090101@opencsw.org> (Laurent Blume's message of "Mon, 02 Sep 2013 17:15:38 +0200") References: <5224AB9A.4090101@opencsw.org> Message-ID: Laurent Blume writes: > So there, how do you handle having packages with the same names but > different origins? How will it impact people willing to stay on Samba > 3 for the time being? Is there a reason to stay on Samba 3 when we will provide Samba 4? -- Peter From slowfranklin at opencsw.org Mon Sep 2 17:36:07 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 17:36:07 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: Message-ID: <1C4C9B94-0910-4D3C-AD0D-0F72ED30D6BC@opencsw.org> Am 02.09.2013 um 15:26 schrieb slowfranklin : > o drop the following packages: > > CSWlibnss-winbind1 ... obsoleted by CSWsamba4-wb-clients wrong. Correct: CSWlibnss-winbind1 ... obsoleted by CSWsamba-winbind -slow From slowfranklin at opencsw.org Mon Sep 2 17:47:49 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 17:47:49 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224AB9A.4090101@opencsw.org> References: <5224AB9A.4090101@opencsw.org> Message-ID: Hi Am 02.09.2013 um 17:15 schrieb Laurent Blume : >> I propose the following changes to the Samba 4 recipe: >> >> o drop the 4 prefix, Fedora is considering the same [2]: >> >> "As samba4 is a superset of Samba 3 packages in Fedora, > > What does that bit mean, exactly? Samba 4 includes all Samba 3 binaries, libs and stuff and can be used a drop-in upgrade. > Are you sure it applies here, ie, will Samba 4 really be a superset of Samba 3 packages? More or less sure, yes. > AFAIK, Fedora is a fast-running distro, they might not care as much for stability. Hey, it's targetting unstable, isn't it? :) And the Samba 4 series is now already at 4.0.9 iirc with a first 4.1 about to be released soon, so we better catch up. :) >> we are also considering to discuss >> renaming samba4 back to samba. As all existing API and ABI for smbd/nmbd/winbindd and >> libsmbclient library will be the same, the switch is not going to be problematic. However, >> there is still need to stabilize code through beta and pre-releases before doing that." >> >> o add the following packages: >> >> CSWsamba-common ... common files >> CSWsamba-lib ... Samba libraries >> CSWsamba-dc ... the new Samba 4 AD DC stuff >> CSWsamba-dc-libs ... libraries for CSWsamba-dc >> CSWlibtdb1 ... present in Samba 3, but missing in 4 >> CSWlibwbclient0 ... present in Samba 3, but missing in 4 >> CSWlibsmbclient0 ... present in Samba 3, but missing in 4 >> CSWlibsmbsharemodes0 ... present in Samba 3, but missing in 4 >> CSWsamba-nss-system-links ... present in Samba 3, but missing in 4 >> CSWsamba-pam-system-links ... present in Samba 3, but missing in 4 > > So there, how do you handle having packages with the same names but different origins? They have the same origin, not a different one, so it's simply a package upgrade. It's major revision bump, but it _should_ be compatible. So I propose we test it out if it really is. > How will it impact people willing to stay on Samba 3 for the time being? Switch to OpenCSW testing or don't upgrade unstable. >> The expactation is that users of the current Samba 3 package should >> be able to upgrade to Samba 4 in filesserver/NT DC mode without >> issues. Anyone who wants to run a AD DC must perform a manual setup >> as described in the Samba docs. There will be no support for >> auto-running the new samba AD controller process from init/SMF. > > Does that mean that process is run automatically by the regular SMF once it's configured appropriately? I said "no support" which was meant to express it's not run by anything. -slow From laurent at opencsw.org Mon Sep 2 17:47:58 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 02 Sep 2013 17:47:58 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> Message-ID: <5224B32E.4060909@opencsw.org> On 02/09/13 17:27, Peter FELECAN wrote: > Is there a reason to stay on Samba 3 when we will provide Samba 4? Is there a reason to switch to Samba 4 as long as Samba 3 is supported? Have you looked at how Debian is doing it? Laurent From slowfranklin at opencsw.org Mon Sep 2 17:52:44 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 17:52:44 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: Message-ID: <5AB0F3ED-F2A2-467E-B216-2CFE5EB99D82@opencsw.org> Hi Peter, Am 02.09.2013 um 17:25 schrieb Peter FELECAN : > slowfranklin writes: > >> Thoughts? > > Have you explored how Debian is doing this? yes. They're using a 4 suffix and iirc is they don't use and include smbd for file services at all, so it doesn't help us: -slow From slowfranklin at opencsw.org Mon Sep 2 17:54:42 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 17:54:42 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224B32E.4060909@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224B32E.4060909@opencsw.org> Message-ID: Am 02.09.2013 um 17:47 schrieb Laurent Blume : > On 02/09/13 17:27, Peter FELECAN wrote: >> Is there a reason to stay on Samba 3 when we will provide Samba 4? > > Is there a reason to switch to Samba 4 as long as Samba 3 is supported? yes, customers are beginning to ask for this. Also, remember that AD DC thingy. -slow From pfelecan at opencsw.org Mon Sep 2 17:57:30 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 02 Sep 2013 17:57:30 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224B32E.4060909@opencsw.org> (Laurent Blume's message of "Mon, 02 Sep 2013 17:47:58 +0200") References: <5224AB9A.4090101@opencsw.org> <5224B32E.4060909@opencsw.org> Message-ID: Laurent Blume writes: > On 02/09/13 17:27, Peter FELECAN wrote: >> Is there a reason to stay on Samba 3 when we will provide Samba 4? > > Is there a reason to switch to Samba 4 as long as Samba 3 is supported? Yes: new features, bugs corrected, fun, walking on the bleeding edge, &c Heck, there is unstable, testing and kind of stable; people has the freedom to choose. -- Peter From laurent at opencsw.org Mon Sep 2 18:07:53 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 02 Sep 2013 18:07:53 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> <5224B32E.4060909@opencsw.org> Message-ID: <5224B7D9.1070000@opencsw.org> On 02/09/13 17:57, Peter FELECAN wrote: > Laurent Blume writes: > >> On 02/09/13 17:27, Peter FELECAN wrote: >>> Is there a reason to stay on Samba 3 when we will provide Samba 4? >> >> Is there a reason to switch to Samba 4 as long as Samba 3 is supported? > > Yes: new features, bugs corrected, fun, walking on the bleeding edge, > &c > > Heck, there is unstable, testing and kind of stable; people has the > freedom to choose. So for that, the Debian way is not the right one? I am confused by your conflicting statements. Please clarify what you are cherry-picking from the Debian model. Laurent From slowfranklin at opencsw.org Mon Sep 2 18:10:47 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 18:10:47 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5AB0F3ED-F2A2-467E-B216-2CFE5EB99D82@opencsw.org> Message-ID: <5B8D7358-F517-4575-9DD2-D31DE42488FA@opencsw.org> Am 02.09.2013 um 17:59 schrieb Peter FELECAN : > slowfranklin writes: > >> Hi Peter, >> >> Am 02.09.2013 um 17:25 schrieb Peter FELECAN : >> >>> slowfranklin writes: >>> >>>> Thoughts? >>> >>> Have you explored how Debian is doing this? >> >> yes. >> >> >> >> They're using a 4 suffix and iirc is they don't use and include smbd for file services at all, so it doesn't help us: >> > > Thank you. That is what I wished to read... digging into the Debian Samba 4 packaging effort some more, I found the most current source for the Samba package. Debian is now unto a "merged" (ie now 4 suffix) naming scheme too. I faintly remebered reading this somewhere before but couldn't find it. -slow From laurent at opencsw.org Mon Sep 2 18:20:05 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 02 Sep 2013 18:20:05 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> Message-ID: <5224BAB5.2030904@opencsw.org> On 02/09/13 17:47, slowfranklin wrote: > Samba 4 includes all Samba 3 binaries, libs and stuff and can be used a drop-in upgrade. I've read that there are some configuration changes. Would an existing configuration just work with no change? > Hey, it's targetting unstable, isn't it? :) > And the Samba 4 series is now already at 4.0.9 iirc with a first 4.1 about to be released soon, so we better catch up. :) Well, I'm all in favour of having Samba 4 :-) But not at the cost of removing Samba 3 from unstable. We have to be realistic here: "testing" on OpenCSW is not usable in any of the production environments I've worked in. It's simply not upgraded enough. We're not a Linux distro, we don't have the resources to backport patches to older versions to keep them secure. That's why I use unstable on my critical production boxes, with as much staging as I can. > They have the same origin, not a different one, so it's simply a package upgrade. It's major revision bump, but it _should_ be compatible. So I propose we test it out if it really is. Ok, so it means it's no longer needed to provide it with Samba 3 once the version from v4 is delivered? Good. > Switch to OpenCSW testing or don't upgrade unstable. We can't tell people that. Seriously. > I said "no support" which was meant to express it's not run by anything. Okay, I still don't get it, I'll need to look at the thing :-) Laurent From slowfranklin at opencsw.org Mon Sep 2 19:15:37 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Mon, 2 Sep 2013 19:15:37 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224BAB5.2030904@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> Message-ID: Am 02.09.2013 um 18:20 schrieb Laurent Blume : > On 02/09/13 17:47, slowfranklin wrote: >> Samba 4 includes all Samba 3 binaries, libs and stuff and can be used a drop-in upgrade. > > I've read that there are some configuration changes. Would an existing configuration just work with no change? Afaict yes. Upgrading a Samba 3 fileserver or NT4-style DC should just work, but of course we may need to test this. I offer to work out the complete gar recipe based on this approach and then push packages to experimental where anybody interested can test em. >> Hey, it's targetting unstable, isn't it? :) >> And the Samba 4 series is now already at 4.0.9 iirc with a first 4.1 about to be released soon, so we better catch up. :) > > Well, I'm all in favour of having Samba 4 :-) > But not at the cost of removing Samba 3 from unstable. Well, Samba 4.0 is the current *stable* Samba release series. > We have to be realistic here: "testing" on OpenCSW is not usable in any of the production environments I've worked in. Of course. > It's simply not upgraded enough. We're not a Linux distro, we don't have the resources to backport patches to older versions to keep them secure. > That's why I use unstable on my critical production boxes, with as much staging as I can. +1 >> They have the same origin, not a different one, so it's simply a package upgrade. It's major revision bump, but it _should_ be compatible. So I propose we test it out if it really is. > > Ok, so it means it's no longer needed to provide it with Samba 3 once the version from v4 is delivered? Good. > >> Switch to OpenCSW testing or don't upgrade unstable. > > We can't tell people that. Seriously. But we can tell people: why are you sticking with 3.x when upgrading to 4.y is a non issue? >> I said "no support" which was meant to express it's not run by anything. > > Okay, I still don't get it, I'll need to look at the thing :-) In Samba 4 you still have smbd, nmdb, winbindd. Additionally you have a new binary named `samba' which is the one used for the whole AD stuff. But you can still run only smbd and friends. The updated package will use the exiting init/SMF stuff so it will only run smbd, nmdb and possibly winbindd by default. Anybody who wants to run a AD DC must disable these and roll his own mechanims for starting `samba' (until we get around adding a default disabled SMF manifest or similar). -slow From pfelecan at opencsw.org Mon Sep 2 19:17:31 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 02 Sep 2013 19:17:31 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224B7D9.1070000@opencsw.org> (Laurent Blume's message of "Mon, 02 Sep 2013 18:07:53 +0200") References: <5224AB9A.4090101@opencsw.org> <5224B32E.4060909@opencsw.org> <5224B7D9.1070000@opencsw.org> Message-ID: Laurent Blume writes: > On 02/09/13 17:57, Peter FELECAN wrote: >> Laurent Blume writes: >> >>> On 02/09/13 17:27, Peter FELECAN wrote: >>>> Is there a reason to stay on Samba 3 when we will provide Samba 4? >>> >>> Is there a reason to switch to Samba 4 as long as Samba 3 is supported? >> >> Yes: new features, bugs corrected, fun, walking on the bleeding edge, >> &c >> >> Heck, there is unstable, testing and kind of stable; people has the >> freedom to choose. > > So for that, the Debian way is not the right one? > > I am confused by your conflicting statements. > > Please clarify what you are cherry-picking from the Debian model. Not cherry picking really. As Slow wrote, Debian is going toward a unique prefix supporting the latest stable upstream release. As Fedora will. As for the confusion and conflict I have no real comment at this point in time. Seriously. -- Peter From laurent at opencsw.org Mon Sep 2 18:45:09 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 02 Sep 2013 18:45:09 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> Message-ID: <5224C095.3070608@opencsw.org> On 2013-09-02 7:15 PM, slowfranklin wrote: > Well, Samba 4.0 is the current *stable* Samba release series. Yup, but 3.6 is still actively maintained (and 3.5 too for security, actually). > But we can tell people: why are you sticking with 3.x when upgrading to 4.y is a non issue? ?Because my boss says so?, ?because my software is only supported for Samba 3?, ?because we have a recertifying process that takes too long?. Believe me, a major version change is an issue that should not be underestimated just because it *should* work (and I'm not an advocate of just staying on old unmaintained versions, but staying on old, *supported* version does makes sense). > In Samba 4 you still have smbd, nmdb, winbindd. Additionally you have > a new binary named `samba' which is the one used for the whole AD > stuff. But you can still run only smbd and friends. The updated > package will use the exiting init/SMF stuff so it will only run smbd, > nmdb and possibly winbindd by default. Anybody who wants to run a AD > DC must disable these and roll his own mechanims for starting `samba' > (until we get around adding a default disabled SMF manifest or > similar). How is this started at boot if not using init or SMF? Laurent From pfelecan at opencsw.org Tue Sep 3 09:24:45 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 03 Sep 2013 09:24:45 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224C095.3070608@opencsw.org> (Laurent Blume's message of "Mon, 02 Sep 2013 18:45:09 +0200") References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> Message-ID: Laurent Blume writes: > On 2013-09-02 7:15 PM, slowfranklin wrote: >> Well, Samba 4.0 is the current *stable* Samba release series. > > Yup, but 3.6 is still actively maintained (and 3.5 too for security, > actually). > >> But we can tell people: why are you sticking with 3.x when upgrading >> to 4.y is a non issue? > > ?Because my boss says so?, ?because my software is only supported for > Samba 3?, ?because we have a recertifying process that takes too long?. > > Believe me, a major version change is an issue that should not be > underestimated just because it *should* work (and I'm not an advocate of > just staying on old unmaintained versions, but staying on old, > *supported* version does makes sense). This is a recurrent argument. If it had prevailed we still provide packages for Solaris 8. Fortunately it had not. A sticky argument also: look how difficult is to stop providing packages for Solaris 9 which is not maintained by its supplier. Lets the enterprises re-certify their platforms as they still have more resources than we have. Note that Solaris 10 U11 provides Samba 3.6.8 As a reminder, our goal is to provide an up to date, i.e. state of the art, package set for Solaris 10 and greater. Samba 4.0.9 corresponds to this definition. -- Peter From slowfranklin at opencsw.org Tue Sep 3 11:29:50 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 11:29:50 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> Message-ID: <7616BC3C-BF88-4624-BCD5-203932940BD0@opencsw.org> Am 03.09.2013 um 09:24 schrieb Peter FELECAN : > Laurent Blume writes: > >> On 2013-09-02 7:15 PM, slowfranklin wrote: >>> Well, Samba 4.0 is the current *stable* Samba release series. >> >> Yup, but 3.6 is still actively maintained (and 3.5 too for security, >> actually). >> >>> But we can tell people: why are you sticking with 3.x when upgrading >>> to 4.y is a non issue? >> >> ?Because my boss says so?, ?because my software is only supported for >> Samba 3?, ?because we have a recertifying process that takes too long?. >> >> Believe me, a major version change is an issue that should not be >> underestimated just because it *should* work (and I'm not an advocate of >> just staying on old unmaintained versions, but staying on old, >> *supported* version does makes sense). > > This is a recurrent argument. If it had prevailed we still provide > packages for Solaris 8. Fortunately it had not. A sticky argument also: > look how difficult is to stop providing packages for Solaris 9 which is > not maintained by its supplier. Lets the enterprises re-certify their > platforms as they still have more resources than we have. > > Note that Solaris 10 U11 provides Samba 3.6.8 > > As a reminder, our goal is to provide an up to date, i.e. state of the > art, package set for Solaris 10 and greater. Samba 4.0.9 corresponds to > this definition. the debate is not so much if we want a Samba 4 package, but how we name it. I'd simply like to avoid a version suffix if possible. If that is not possible for valid reason, and in the context of OpenCSWs current state of branches imo Laurent has brought up valid concerns, then lets keep the current design of the Samba 4 package recipe and add a 4 suffix to the packages. There are several other packages that have versioned names too. I'd prefer to have a unstable catalog that could be used for its purpose and a testing catalog that offered a set of older, stable packages, but afaict testing is far from that. What happened to the automatic package promotion from unstable to testing that is descibed on the website? Eg : "Packages from unstable/ that have no bugs filed against them, are promoted to testing/" If we had something like that we could easily honor Laurent's concerns by going ahead and adding a unversioned Samba 4 package (ie no 4 suffix) and file a bug against it preventing promotion. -slow From laurent at opencsw.org Tue Sep 3 11:36:34 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 11:36:34 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> Message-ID: <5225ADA2.9060801@opencsw.org> On 03/09/13 09:24, Peter FELECAN wrote: > This is a recurrent argument. If it had prevailed we still provide > packages for Solaris 8. Let me repeat it again, in the hope you will read it this time: I am advocating only keeping SUPPORTED VERSIOBS. > Note that Solaris 10 U11 provides Samba 3.6.8 It's patched to 3.6.15, actually. And I've pushed 3.6.18 to OpenCSW. I am using OpenCSW's Samba on Solaris 10 because Sun and now Oracle update path is a complete blackhole, and impossible to predict or influence. They are updating it now, but who knows why or for how long? > As a reminder, our goal is to provide an up to date, i.e. state of the > art, package set for Solaris 10 and greater. Samba 4.0.9 corresponds to > this definition. Gee, thank you very much. That had just completely escaped me. But luckily, Samba 3.6.18 also corresponds to that definition, just as GnuPG 1.4.14 and MySQL 5.5.33. Peter, I am asking you to please make more effort to read other people's posts and not distort their meaning. Thanks. Laurent From slowfranklin at opencsw.org Tue Sep 3 11:40:04 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 11:40:04 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5224C095.3070608@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> Message-ID: <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> Am 02.09.2013 um 18:45 schrieb Laurent Blume : > On 2013-09-02 7:15 PM, slowfranklin wrote: >> Well, Samba 4.0 is the current *stable* Samba release series. > > Yup, but 3.6 is still actively maintained (and 3.5 too for security, > actually). I know. >> But we can tell people: why are you sticking with 3.x when upgrading to 4.y is a non issue? > > ?Because my boss says so?, ?because my software is only supported for > Samba 3?, ?because we have a recertifying process that takes too long?. > > Believe me, a major version change is an issue that should not be > underestimated just because it *should* work (and I'm not an advocate of > just staying on old unmaintained versions, but staying on old, > *supported* version does makes sense). This argument would effectively prevent any major version upgrade in unstable, because for every upgrade someone may have concerns. You're tracking an unstable catalog. The lack of a stable catalog is bad enough off itself, but if we let that influence too much the way we add packages to the unstable catalog, we make things worse, not better. Don't get me wrong, I fully understand your concerns and whole heartedly agree that I wouldn't want my production Samba 3.6 installation being upgraded without need. If others agree I'm open to use a 4 suffix for the package. > >> In Samba 4 you still have smbd, nmdb, winbindd. Additionally you have >> a new binary named `samba' which is the one used for the whole AD >> stuff. But you can still run only smbd and friends. The updated >> package will use the exiting init/SMF stuff so it will only run smbd, >> nmdb and possibly winbindd by default. Anybody who wants to run a AD >> DC must disable these and roll his own mechanims for starting `samba' >> (until we get around adding a default disabled SMF manifest or >> similar). > > How is this started at boot if not using init or SMF? As I was trying to explain repeatedly, it is NOT started at boot. It refers to the `samba' binary. -slow From laurent at opencsw.org Tue Sep 3 11:50:00 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 11:50:00 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <7616BC3C-BF88-4624-BCD5-203932940BD0@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7616BC3C-BF88-4624-BCD5-203932940BD0@opencsw.org> Message-ID: <5225B0C8.6080402@opencsw.org> On 03/09/13 11:29, slowfranklin wrote: > I'd simply like to avoid a version suffix if possible. If that is not > possible for valid reason, and in the context of OpenCSWs current > state of branches imo Laurent has brought up valid concerns, then > lets keep the current design of the Samba 4 package recipe and add a > 4 suffix to the packages. There are several other packages that have > versioned names too. To be honest, I'm not sure I understand the rationale for removing the version suffix (I'm not the one who named the current Samba 3 packages, I'd have kept the number). What's better without a version suffix? Either way look good to me from the user viewpoint, but one makes transitions harder for the maintainers. Of course, that's for critical tools, it's not a casual user that will install Samba in the first place, I expect one to have some knowledge of it. Now since we're really talking about having as recent as possible packages for Solaris 10 - well, someone who is still using Solaris 10 must already have some incentive to stay on older versions, else they'd have switched to a more recent OS. So for some software like Samba which can have a lot of complicated interactions, I will advocate strongly keeping the older versions as long as they are supported and it is reasonably doable. That applies to MySQL, for which I will keep 5.5 running even when we finally have 5.6 (I'd have kept 5.1 if it had been done). Some other programs which are much less critical, of course, I believe they can be upgraded, and without keeping a version suffix. Say, eg, vim: a casual user can install that, and the exact major version won't have much influence. > I'd prefer to have a unstable catalog that could be used for its > purpose and a testing catalog that offered a set of older, stable > packages, but afaict testing is far from that. > > What happened to the automatic package promotion from unstable to > testing that is descibed on the website? Eg > : > > "Packages from unstable/ that have no bugs filed against them, are > promoted to testing/" > > If we had something like that we could easily honor Laurent's > concerns by going ahead and adding a unversioned Samba 4 package (ie > no 4 suffix) and file a bug against it preventing promotion. Yes, the path forward needs to be defined, but I'm afraid it'll be more an issue of resources than anything else :-/ Laurent From laurent at opencsw.org Tue Sep 3 12:02:08 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 12:02:08 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> Message-ID: <5225B3A0.7090007@opencsw.org> On 03/09/13 11:40, slowfranklin wrote: > This argument would effectively prevent any major version upgrade in > unstable, because for every upgrade someone may have concerns. That simply not true. If you must have colliding binaries, you can keep two packages at different versions, one marked incompatible with the other. Of course, they must have different names, but that's a detail. > You're > tracking an unstable catalog. The lack of a stable catalog is bad > enough off itself, but if we let that influence too much the way we > add packages to the unstable catalog, we make things worse, not > better. Actually, thinking about it, I'm starting to believe that only "unstable" and "experimental" should be kept, the former renamed to something more neutral. Resources are stretched too thin. Can we maintain a "stable" repository? Look at how many people are active here. A dozen? With a huge responsibility on a handful, Dago, Maciej, Bonivart, Yann? The popularity of Solaris is not growing. We've got to plan with the current resources. Looking at Fedora, at Debian for inspiration is good. Trying to do exactly as they do is not. > As I was trying to explain repeatedly, it is NOT started at boot. It > refers to the `samba' binary. Yes, I got that. So you mean, right now, you need to run that samba command manually, and later, you will have an SMF for it? Did I get it correctly now? Or am I still too dense? :-) Laurent From slowfranklin at opencsw.org Tue Sep 3 12:39:42 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 12:39:42 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5225B3A0.7090007@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> Message-ID: <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> Hi Am 03.09.2013 um 11:50 schrieb Laurent Blume : > On 03/09/13 11:29, slowfranklin wrote: >> I'd simply like to avoid a version suffix if possible. If that is not >> possible for valid reason, and in the context of OpenCSWs current >> state of branches imo Laurent has brought up valid concerns, then >> lets keep the current design of the Samba 4 package recipe and add a >> 4 suffix to the packages. There are several other packages that have >> versioned names too. > > To be honest, I'm not sure I understand the rationale for removing the version suffix (I'm not the one who named the current Samba 3 packages, I'd have kept the number). > > What's better without a version suffix? Either way look good to me from the user viewpoint, but one makes transitions harder for the maintainers. Fast forward 2 years, fast forward 5 years. Versioned packages all over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, CSWsamba6. *blah* We're *forced* to use verioned package names due to the lack of any usable catalog other then unstable. >> I'd prefer to have a unstable catalog that could be used for its >> purpose and a testing catalog that offered a set of older, stable >> packages, but afaict testing is far from that. >> >> What happened to the automatic package promotion from unstable to >> testing that is descibed on the website? Eg >> : >> >> "Packages from unstable/ that have no bugs filed against them, are >> promoted to testing/" >> >> If we had something like that we could easily honor Laurent's >> concerns by going ahead and adding a unversioned Samba 4 package (ie >> no 4 suffix) and file a bug against it preventing promotion. > > Yes, the path forward needs to be defined, but I'm afraid it'll be more an issue of resources than anything else :-/ If it would be an automated process not su much. But I have no background in packaging and distribution managment. >> You're >> tracking an unstable catalog. The lack of a stable catalog is bad >> enough off itself, but if we let that influence too much the way we >> add packages to the unstable catalog, we make things worse, not >> better. > > Actually, thinking about it, I'm starting to believe that only "unstable" and "experimental" should be kept, the former renamed to something more neutral. > Resources are stretched too thin. Can we maintain a "stable" repository? Look at how many people are active here. A dozen? With a huge responsibility on a handful, Dago, Maciej, Bonivart, Yann? I never suggested to *maintain* a stable catalog. I only came up with what is already described on the website and which is an automated process. But it seems that idea was already killed of for some reasons. >> As I was trying to explain repeatedly, it is NOT started at boot. It >> refers to the `samba' binary. > > Yes, I got that. So you mean, right now, you need to run that samba command manually, and later, you will have an SMF for it? Did I get it correctly now? Or am I still too dense? :-) You got it. :) Adding another (default disabled) init/SMF manifest for the samba daemon is a non issue and easily be done once we have the package in good shape. -slow From laurent at opencsw.org Tue Sep 3 13:26:13 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 13:26:13 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> Message-ID: <5225C755.6050402@opencsw.org> On 03/09/13 12:39, slowfranklin wrote: > Fast forward 2 years, fast forward 5 years. Versioned packages all > over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, > CSWsamba6. *blah* Yes? So what? I'm genuinely puzzled now. How is that a problem? Personal hatred for numbers? :-) If it's just against your personal taste, well, okay, de gustibus et coloribus non disputandum, but it doesn't make it a *bad* technical decision: it avoids problems instead of creating them, So, why not? > We're *forced* to use verioned package names due to the lack of any > usable catalog other then unstable. Well, since others do just that, package versioning, it must not be so wrong. > If it would be an automated process not su much. But I have no > background in packaging and distribution managment. come on, how can it ever be automated? Particularly talking about Samba or other critical packages. also, I think you don't realize that packages can't just go from one repo to the other. In many cases, they must be rebuilt to fit a particular repository dependencies (when the deps in unstables are not the same as in stable). That's why Linux distros apply security patches instead of taking direct updates from upstream: they ensure that a given package is not going to change its soname or something that others depend on. > I never suggested to *maintain* a stable catalog. I only came up with > what is already described on the website and which is an automated > process. But it seems that idea was already killed of for some > reasons. Ok, I see. I think the reason is that days only have 24 hours :-) > You got it. :) Adding another (default disabled) init/SMF manifest > for the samba daemon is a non issue and easily be done once we have > the package in good shape. SMF dependencies need to he handled carefully, though. Laurent From bonivart at opencsw.org Tue Sep 3 13:55:12 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 3 Sep 2013 13:55:12 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> Message-ID: On Tue, Sep 3, 2013 at 12:39 PM, slowfranklin wrote: > Fast forward 2 years, fast forward 5 years. Versioned packages all over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, CSWsamba6. *blah* I don't see that we would ever have more than two at the same time spanning all our catalogs, certainly not in any single catalog. I think it's easier both for us and the users to have this system when it comes to the large titles like samba, apache and so on. No one would like to accidentally upgrade to something that is not compatible and for us to create complicated processes to avoid this is unnecessary work in my opinion. /peter From slowfranklin at opencsw.org Tue Sep 3 14:45:21 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 14:45:21 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5225C755.6050402@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> <5225C755.6050402@opencsw.org> Message-ID: Am 03.09.2013 um 13:26 schrieb Laurent Blume : > On 03/09/13 12:39, slowfranklin wrote: >> Fast forward 2 years, fast forward 5 years. Versioned packages all >> over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, >> CSWsamba6. *blah* > > Yes? So what? I'm genuinely puzzled now. How is that a problem? Personal hatred for numbers? :-) Well, we'll also need versioned libraries like CSWsamba4-libwclient0, CSWsamba4-libsmbclient0. But other then a vague feeling that versioned names are a blatant workaround for a problem that is arising from abusing a rolling catalog, no, I can't substantiate my concerns. > If it's just against your personal taste, well, okay, de gustibus et coloribus non disputandum, but it doesn't make it a *bad* technical decision: it avoids problems instead of creating them, So, why not? > >> We're *forced* to use verioned package names due to the lack of any >> usable catalog other then unstable. > > Well, since others do just that, package versioning, it must not be so wrong. Well, since others (Debian, Fedora, ArchLinux) were all going for an inplace upgrade, I considered that the obvious choice for an unstable rolling catalog. But we now have two votes for using the 4 suffix, so be it. :) -slow From laurent at opencsw.org Tue Sep 3 15:49:11 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 15:49:11 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> <5225C755.6050402@opencsw.org> Message-ID: <5225E8D7.8000903@opencsw.org> On 03/09/13 14:45, slowfranklin wrote: > Well, we'll also need versioned libraries like CSWsamba4-libwclient0, > CSWsamba4-libsmbclient0. For that specific library, actually, it should not be needed, bad example ;-) Okay, I see what you mean, but I don't see it as a problem: mgar, pkgchk and friends make it all too easy to handle. > Well, since others (Debian, Fedora, ArchLinux) were all going for an > inplace upgrade, I considered that the obvious choice for an unstable > rolling catalog. At least for Debian, that's not the case: they're planning on phasing out Samba 3, but it's not close at all. They only do it in experimental at this point. And for having worked with the Debian Samba maintainer, I can assure you the switch is being spread over years, I would say maybe even a decade, with both packages being available together in various forms during this time (experimental, backports, then . > But we now have two votes for using the 4 suffix, so be it. :) In any case, there's nothing set in stone for 4 at this point, since it's not usable yet, so it looks like a safe point to start :-) Laurent From slowfranklin at opencsw.org Tue Sep 3 16:04:39 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 16:04:39 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5225E8D7.8000903@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> <5225C755.6050402@opencsw.org> <5225E8D7.8000903@opencsw.org> Message-ID: <5848A9F0-F642-472B-88C5-370CBE528F2F@opencsw.org> Am 03.09.2013 um 15:49 schrieb Laurent Blume : > On 03/09/13 14:45, slowfranklin wrote: >> Well, we'll also need versioned libraries like CSWsamba4-libwclient0, >> CSWsamba4-libsmbclient0. > > For that specific library, actually, it should not be needed, bad > example ;-) No? Why not?! Otherwise we'd have the same package (eg CSWlibwbclient0) built from two different recipes uploaded to the catalog. Am I missing sth? > Okay, I see what you mean, but I don't see it as a problem: mgar, pkgchk and friends make it all too easy to handle. > >> Well, since others (Debian, Fedora, ArchLinux) were all going for an >> inplace upgrade, I considered that the obvious choice for an unstable >> rolling catalog. > > At least for Debian, that's not the case: they're planning on phasing out Samba 3, but it's not close at all. Hold on. I was not referring to what Debian as a whole achieves by using different catalogs/distributions or backports. I said "obvious choice for an unstable rolling catalog" which would be unstable/sid in the Debian case. And apparently Debian is going to use an unversioned Samba 4 package in sid. -slow From pfelecan at opencsw.org Tue Sep 3 16:21:27 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 03 Sep 2013 16:21:27 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: (Peter Bonivart's message of "Tue, 3 Sep 2013 13:55:12 +0200") References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> Message-ID: Peter Bonivart writes: > On Tue, Sep 3, 2013 at 12:39 PM, slowfranklin wrote: >> Fast forward 2 years, fast forward 5 years. Versioned packages all >> over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, >> CSWsamba6. *blah* > > I don't see that we would ever have more than two at the same time > spanning all our catalogs, certainly not in any single catalog. > > I think it's easier both for us and the users to have this system when > it comes to the large titles like samba, apache and so on. No one > would like to accidentally upgrade to something that is not compatible > and for us to create complicated processes to avoid this is > unnecessary work in my opinion. We currently have python, python27, python3 and almost had python34 but escaped that with an astute feint. We had gcc2, gcc3 and gcc4 (well they were of my initiative) but they are fortunately history. -- Peter From slowfranklin at opencsw.org Tue Sep 3 16:43:20 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 16:43:20 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages Message-ID: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> I propose the following changes to the Samba 4 recipe: o package set: CSWsamba4 CSWsamba4-dc ... Samba 4 AD DC component, can be installed without CSWsamba4 CSWsamba4-client CSWsamba4-winbind ... winbind stuff including NSS am PAM modules CSWsamba4-common ... common files CSWsamba4-libs ... Samba libraries CSWsamba4-dc-libs ... Samba AD DC libraries CSWsamba4-nss-system-links CSWsamba4-pam-system-links o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will still be coming from Samba 3, Samba 4 will use private versions of these libs o the main package is split into libs and common, because it seems in Samba4 libraries like libsmbclient are linked with tons of private Samba libs, so we really want these private libs to be available as a seperate package otherwise the whole Samba packaged would be pulled in when someone installs libsmbclient o iirc running a Samba4 AD DC means you can't run the fileserver daemon smbd on the sambe host. For a AD DC you install CSWsamba4-dc, for a fileserver you install CSWsamba4. Nice and small packages. o no package CSWsamba4-swat, because SWAT is dead o no package CSWsamba4-dev, because we don't package any public library For reference, this is our current set for Samba 4: PACKAGES += CSWsamba4 PACKAGES += CSWsamba4-client PACKAGES += CSWlibnetapi0 PACKAGES += CSWlibnss-winbind1 PACKAGES += CSWsamba4-dev PACKAGES += CSWsamba4-swat PACKAGES += CSWsamba4-winbind These are the Samba 3 packages: PACKAGES += CSWsamba PACKAGES += CSWsamba-client PACKAGES += CSWlibsmbclient0 PACKAGES += CSWlibwbclient0 PACKAGES += CSWlibnetapi0 PACKAGES += CSWlibsmbsharemodes0 PACKAGES += CSWlibtdb1 PACKAGES += CSWsamba-nss PACKAGES += CSWsamba-nss-system-links PACKAGES += CSWsamba-pam-system-links PACKAGES += CSWlibtevent0 PACKAGES += CSWsamba-dev PACKAGES += CSWsamba-swat PACKAGES += CSWsamba-winbind Only Samba 3 package consumed by other packages is CSWlibsmbclient0 (by CSWgnomevfs2 and CSWvlc). Feedback welcome! -slow From laurent at opencsw.org Tue Sep 3 16:44:56 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 16:44:56 +0200 Subject: [csw-maintainers] Samba 4 In-Reply-To: <5848A9F0-F642-472B-88C5-370CBE528F2F@opencsw.org> References: <5224AB9A.4090101@opencsw.org> <5224BAB5.2030904@opencsw.org> <5224C095.3070608@opencsw.org> <7D3575E1-74ED-479F-BA5D-A527E3AC52D9@opencsw.org> <5225B3A0.7090007@opencsw.org> <21E81544-9A52-4B20-AFB6-499B58C6C44B@opencsw.org> <5225C755.6050402@opencsw.org> <5225E8D7.8000903@opencsw.org> <5848A9F0-F642-472B-88C5-370CBE528F2F@opencsw.org> Message-ID: <5225F5E8.4050108@opencsw.org> On 03/09/13 16:04, slowfranklin wrote: > No? Why not?! Otherwise we'd have the same package (eg > CSWlibwbclient0) built from two different recipes uploaded to the > catalog. Am I missing sth? Since from what we discussed, it's just the same lib being built as part of either v3 or v4, one of the two would be dropped without problem. It's not like the tools which do conflict. It's only a matter of selecting which to keep (probably something like v3 while v4 is settling down, then v4 when it's mature). > Hold on. I was not referring to what Debian as a whole achieves by > using different catalogs/distributions or backports. I said "obvious > choice for an unstable rolling catalog" which would be unstable/sid > in the Debian case. And apparently Debian is going to use an > unversioned Samba 4 package in sid. Right now they have some unversioned and versioned package, both from v4 in experimental, and from v3 and v4 respectively in unstable. Maybe it will go unversioned at some point, but they're apparently far from it. For perspective, their stable/testing/unstable contain 4.0.0beta2 and experimental is 4.0.8. So it's not what we're discussing here either. We're planning for 4.1! They won't use that for *years*. Laurent From dam at opencsw.org Tue Sep 3 16:46:00 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Sep 2013 16:46:00 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> Message-ID: Hi Slow, Am 03.09.2013 um 16:43 schrieb slowfranklin : > I propose the following changes to the Samba 4 recipe: > > o package set: > > CSWsamba4 > CSWsamba4-dc ... Samba 4 AD DC component, can be installed without CSWsamba4 > CSWsamba4-client > CSWsamba4-winbind ... winbind stuff including NSS am PAM modules > CSWsamba4-common ... common files > CSWsamba4-libs ... Samba libraries > CSWsamba4-dc-libs ... Samba AD DC libraries > CSWsamba4-nss-system-links > CSWsamba4-pam-system-links > > o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will still be coming > from Samba 3, Samba 4 will use private versions of these libs > > o the main package is split into libs and common, because it seems in Samba4 libraries > like libsmbclient are linked with tons of private Samba libs, so we really want > these private libs to be available as a seperate package otherwise the whole > Samba packaged would be pulled in when someone installs libsmbclient > > o iirc running a Samba4 AD DC means you can't run the fileserver daemon smbd on the > sambe host. For a AD DC you install CSWsamba4-dc, for a fileserver you install CSWsamba4. > Nice and small packages. > > o no package CSWsamba4-swat, because SWAT is dead > o no package CSWsamba4-dev, because we don't package any public library > > For reference, this is our current set for Samba 4: > > PACKAGES += CSWsamba4 > PACKAGES += CSWsamba4-client > PACKAGES += CSWlibnetapi0 ^^ > PACKAGES += CSWlibnss-winbind1 > PACKAGES += CSWsamba4-dev > PACKAGES += CSWsamba4-swat > PACKAGES += CSWsamba4-winbind > > These are the Samba 3 packages: > > PACKAGES += CSWsamba > PACKAGES += CSWsamba-client > PACKAGES += CSWlibsmbclient0 > PACKAGES += CSWlibwbclient0 > PACKAGES += CSWlibnetapi0 Are these two packages from Samba 4, Samba 3, or should they be in different pathes? > PACKAGES += CSWlibsmbsharemodes0 > PACKAGES += CSWlibtdb1 > PACKAGES += CSWsamba-nss > PACKAGES += CSWsamba-nss-system-links > PACKAGES += CSWsamba-pam-system-links > PACKAGES += CSWlibtevent0 > PACKAGES += CSWsamba-dev > PACKAGES += CSWsamba-swat > PACKAGES += CSWsamba-winbind > > Only Samba 3 package consumed by other packages is CSWlibsmbclient0 (by CSWgnomevfs2 and CSWvlc). Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From slowfranklin at opencsw.org Tue Sep 3 16:51:43 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 16:51:43 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> Message-ID: <5A12301A-F782-4F89-8C5F-5D00717184C6@opencsw.org> Hi Dago Am 03.09.2013 um 16:46 schrieb Dagobert Michelsen : > Hi Slow, > > Am 03.09.2013 um 16:43 schrieb slowfranklin : > >> I propose the following changes to the Samba 4 recipe: >> >> o package set: >> >> CSWsamba4 >> CSWsamba4-dc ... Samba 4 AD DC component, can be installed without CSWsamba4 >> CSWsamba4-client >> CSWsamba4-winbind ... winbind stuff including NSS am PAM modules >> CSWsamba4-common ... common files >> CSWsamba4-libs ... Samba libraries >> CSWsamba4-dc-libs ... Samba AD DC libraries >> CSWsamba4-nss-system-links >> CSWsamba4-pam-system-links >> >> o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will still be coming >> from Samba 3, Samba 4 will use private versions of these libs >> >> o the main package is split into libs and common, because it seems in Samba4 libraries >> like libsmbclient are linked with tons of private Samba libs, so we really want >> these private libs to be available as a seperate package otherwise the whole >> Samba packaged would be pulled in when someone installs libsmbclient >> >> o iirc running a Samba4 AD DC means you can't run the fileserver daemon smbd on the >> sambe host. For a AD DC you install CSWsamba4-dc, for a fileserver you install CSWsamba4. >> Nice and small packages. >> >> o no package CSWsamba4-swat, because SWAT is dead >> o no package CSWsamba4-dev, because we don't package any public library >> >> For reference, this is our current set for Samba 4: >> >> PACKAGES += CSWsamba4 >> PACKAGES += CSWsamba4-client >> PACKAGES += CSWlibnetapi0 > > ^^ That is the current gar recipe which I'm going to modify, ie drop the libs. At the top of my mail I list the packages I would like to build from a modified Samba 4 gar recipe. > >> PACKAGES += CSWlibnss-winbind1 >> PACKAGES += CSWsamba4-dev >> PACKAGES += CSWsamba4-swat >> PACKAGES += CSWsamba4-winbind >> >> These are the Samba 3 packages: >> >> PACKAGES += CSWsamba >> PACKAGES += CSWsamba-client >> PACKAGES += CSWlibsmbclient0 >> PACKAGES += CSWlibwbclient0 >> PACKAGES += CSWlibnetapi0 > > Are these two packages from Samba 4, Samba 3, or should they be in different pathes? For now, these libs will not be part of the Samba 4 packages. -slow From laurent at opencsw.org Tue Sep 3 19:05:59 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 19:05:59 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> Message-ID: <522616F7.8090308@opencsw.org> On 2013-09-03 4:43 PM, slowfranklin wrote: > o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will still be coming > from Samba 3, Samba 4 will use private versions of these libs I think you don't need libsmbclient, at all. Like you noted, only gnomevfs depends on it: no Samba binary uses it. So, no need for even a private one; libnetapi appears to be the same case. I see the Debian packages for v4 also have a libsmbclientraw, but that's apparently a different lib, since their libsmbclient (without raw) do switch from 3.6 to 4.0 in experimental. Do you see that one too? > o the main package is split into libs and common, because it seems in Samba4 libraries > like libsmbclient are linked with tons of private Samba libs, so we really want > these private libs to be available as a seperate package otherwise the whole > Samba packaged would be pulled in when someone installs libsmbclient Can you list them? I'm a bit surprised that this libsmbclient would have more dependencies, since it's supposed to be the same. Laurent. From slowfranklin at opencsw.org Tue Sep 3 19:18:00 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 19:18:00 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: <522616F7.8090308@opencsw.org> References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> <522616F7.8090308@opencsw.org> Message-ID: <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> Am 03.09.2013 um 19:05 schrieb Laurent Blume : > > On 2013-09-03 4:43 PM, slowfranklin wrote: >> o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will still be coming >> from Samba 3, Samba 4 will use private versions of these libs > > I think you don't need libsmbclient, at all. Like you noted, only > gnomevfs depends on it: no Samba binary uses it. indeed. I'll see if they can be disabled in the build by configure. > So, no need for even a > private one; libnetapi appears to be the same case. > I see the Debian packages for v4 also have a libsmbclientraw, but that's > apparently a different lib, since their libsmbclient (without raw) do > switch from 3.6 to 4.0 in experimental. Do you see that one too? Yes: $ ls /opt/samba/lib/libsmbclient-raw.so /opt/samba/lib/libsmbclient-raw.so > >> o the main package is split into libs and common, because it seems in Samba4 libraries >> like libsmbclient are linked with tons of private Samba libs, so we really want >> these private libs to be available as a seperate package otherwise the whole >> Samba packaged would be pulled in when someone installs libsmbclient > > Can you list them? I'm a bit surprised that this libsmbclient would have > more dependencies, since it's supposed to be the same. This is from git master HEAD, built on Solaris 11.1 with this simple configure invocation: $ ./configure \ --prefix=/opt/samba \ --with-ads \ --with-shared-modules=vfs_zfsacl slow at solaris:~$ ldd /opt/samba/lib/libwbclient.so | grep /opt/samba libwinbind-client.so => /opt/samba/lib/private/libwinbind-client.so libreplace.so => /opt/samba/lib/private/libreplace.so slow at solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba libsamba-util.so.0 => /opt/samba/lib/libsamba-util.so.0 libgssapi-samba4.so.2 => /opt/samba/lib/private/libgssapi-samba4.so.2 liblibsmb.so => /opt/samba/lib/private/liblibsmb.so libmsrpc3.so => /opt/samba/lib/private/libmsrpc3.so liblibcli_lsa3.so => /opt/samba/lib/private/liblibcli_lsa3.so libsamba-security.so => /opt/samba/lib/private/libsamba-security.so liberrors.so => /opt/samba/lib/private/liberrors.so libsmbconf.so.0 => /opt/samba/lib/libsmbconf.so.0 libtalloc.so.2 => /opt/samba/lib/private/libtalloc.so.2 libndr.so.0 => /opt/samba/lib/libndr.so.0 libcli_smb_common.so => /opt/samba/lib/private/libcli_smb_common.so libgse.so => /opt/samba/lib/private/libgse.so libutil_cmdline.so => /opt/samba/lib/private/libutil_cmdline.so libndr-standard.so.0 => /opt/samba/lib/libndr-standard.so.0 libdcerpc-samba.so => /opt/samba/lib/private/libdcerpc-samba.so libsmbregistry.so => /opt/samba/lib/private/libsmbregistry.so libsecrets3.so => /opt/samba/lib/private/libsecrets3.so libtevent.so.0 => /opt/samba/lib/private/libtevent.so.0 libutil_setid.so => /opt/samba/lib/private/libutil_setid.so libreplace.so => /opt/samba/lib/private/libreplace.so libkrb5-samba4.so.26 => /opt/samba/lib/private/libkrb5-samba4.so.26 libroken-samba4.so.19 => /opt/samba/lib/private/libroken-samba4.so.19 libasn1-samba4.so.8 => /opt/samba/lib/private/libasn1-samba4.so.8 libhcrypto-samba4.so.5 => /opt/samba/lib/private/libhcrypto-samba4.so.5 libcom_err-samba4.so.0 => /opt/samba/lib/private/libcom_err-samba4.so.0 libwind-samba4.so.0 => /opt/samba/lib/private/libwind-samba4.so.0 libheimbase-samba4.so.1 => /opt/samba/lib/private/libheimbase-samba4.so.1 libhx509-samba4.so.5 => /opt/samba/lib/private/libhx509-samba4.so.5 libwbclient.so.0 => /opt/samba/lib/libwbclient.so.0 libsamba-credentials.so.0 => /opt/samba/lib/libsamba-credentials.so.0 libndr-samba.so => /opt/samba/lib/private/libndr-samba.so libcli_cldap.so => /opt/samba/lib/private/libcli_cldap.so libcliauth.so => /opt/samba/lib/private/libcliauth.so libkrb5samba.so => /opt/samba/lib/private/libkrb5samba.so libsamba-sockets.so => /opt/samba/lib/private/libsamba-sockets.so libgensec.so.0 => /opt/samba/lib/libgensec.so.0 libasn1util.so => /opt/samba/lib/private/libasn1util.so libsamba-hostconfig.so.0 => /opt/samba/lib/libsamba-hostconfig.so.0 libndr-nbt.so.0 => /opt/samba/lib/libndr-nbt.so.0 libtevent-util.so.0 => /opt/samba/lib/libtevent-util.so.0 libsmb_transport.so => /opt/samba/lib/private/libsmb_transport.so libsamba3-util.so => /opt/samba/lib/private/libsamba3-util.so libCHARSET3.so => /opt/samba/lib/private/libCHARSET3.so libdcerpc-binding.so.0 => /opt/samba/lib/libdcerpc-binding.so.0 libndr-krb5pac.so.0 => /opt/samba/lib/libndr-krb5pac.so.0 libevents.so => /opt/samba/lib/private/libevents.so libinterfaces.so => /opt/samba/lib/private/libinterfaces.so libccan.so => /opt/samba/lib/private/libccan.so libdbwrap.so => /opt/samba/lib/private/libdbwrap.so libutil_tdb.so => /opt/samba/lib/private/libutil_tdb.so libutil_reg.so => /opt/samba/lib/private/libutil_reg.so libsmbd_shim.so => /opt/samba/lib/private/libsmbd_shim.so libtdb-wrap.so => /opt/samba/lib/private/libtdb-wrap.so libtdb.so.1 => /opt/samba/lib/private/libtdb.so.1 libserver-role.so => /opt/samba/lib/private/libserver-role.so libaddns.so => /opt/samba/lib/private/libaddns.so libauthkrb5.so => /opt/samba/lib/private/libauthkrb5.so libcli-nbt.so => /opt/samba/lib/private/libcli-nbt.so libutil_ntdb.so => /opt/samba/lib/private/libutil_ntdb.so libntdb.so.0 => /opt/samba/lib/private/libntdb.so.0 libwinbind-client.so => /opt/samba/lib/private/libwinbind-client.so libldb.so.1 => /opt/samba/lib/private/libldb.so.1 libsamdb-common.so => /opt/samba/lib/private/libsamdb-common.so libldbsamba.so => /opt/samba/lib/private/libldbsamba.so libcli-ldap-common.so => /opt/samba/lib/private/libcli-ldap-common.so libsamba-modules.so => /opt/samba/lib/private/libsamba-modules.so libsamdb.so.0 => /opt/samba/lib/libsamdb.so.0 libauth_sam_reply.so => /opt/samba/lib/private/libauth_sam_reply.so libflag_mapping.so => /opt/samba/lib/private/libflag_mapping.so From slowfranklin at opencsw.org Tue Sep 3 19:27:55 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 19:27:55 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> <522616F7.8090308@opencsw.org> <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> Message-ID: >>> o the main package is split into libs and common, because it seems in Samba4 libraries >>> like libsmbclient are linked with tons of private Samba libs, so we really want >>> these private libs to be available as a seperate package otherwise the whole >>> Samba packaged would be pulled in when someone installs libsmbclient >> >> Can you list them? I'm a bit surprised that this libsmbclient would have >> more dependencies, since it's supposed to be the same. > > This is from git master HEAD, built on Solaris 11.1 with this simple configure invocation: > > $ ./configure \ > --prefix=/opt/samba \ > --with-ads \ > --with-shared-modules=vfs_zfsacl fwiw, you also need the fix I attached to this PR: As an alternative you can prefix the configure invocation with LDFLAGS=-R. -slow From laurent at opencsw.org Tue Sep 3 19:30:54 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 19:30:54 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> <522616F7.8090308@opencsw.org> <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> Message-ID: <52261CCE.6030301@opencsw.org> On 2013-09-03 7:18 PM, slowfranklin wrote: > indeed. I'll see if they can be disabled in the build by configure. Don't bother too much if there's no option, just don't package them. It's maybe even better: when we switch to it, it'll have been built successfully many times over. > Yes: > > $ ls /opt/samba/lib/libsmbclient-raw.so > /opt/samba/lib/libsmbclient-raw.so Okay, so that one would deserve its own little CSWlibsmbclient-raw package. > slow at solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba > libsamba-util.so.0 => /opt/samba/lib/libsamba-util.so.0 Okay, that's a lot, and really different. I gather you linked with -Bdirect? Can you do ldd with -v to see if they're direct deps? I'm going to investigate in a vboxed Debian. Laurent From slowfranklin at opencsw.org Tue Sep 3 19:49:19 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 3 Sep 2013 19:49:19 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: <52261CCE.6030301@opencsw.org> References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> <522616F7.8090308@opencsw.org> <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> <52261CCE.6030301@opencsw.org> Message-ID: >> slow at solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba >> libsamba-util.so.0 => /opt/samba/lib/libsamba-util.so.0 > > > Okay, that's a lot, and really different. > I gather you linked with -Bdirect? Of course not. :) > Can you do ldd with -v to see if they're direct deps? http://pastebin.com/fJqGE4uh -slow From laurent at opencsw.org Tue Sep 3 20:59:04 2013 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Sep 2013 20:59:04 +0200 Subject: [csw-maintainers] Samba 4, take 2, versioned packages In-Reply-To: References: <514EF0A1-C14A-4EA5-BBE7-00D5680D676F@opencsw.org> <522616F7.8090308@opencsw.org> <5DE6B1AE-C62B-4B74-AD74-0E486F99EB4B@opencsw.org> <52261CCE.6030301@opencsw.org> Message-ID: <52263178.5090309@opencsw.org> On 2013-09-03 7:49 PM, slowfranklin wrote: >>> slow at solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba >>> libsamba-util.so.0 => /opt/samba/lib/libsamba-util.so.0 >> >> >> Okay, that's a lot, and really different. >> I gather you linked with -Bdirect? > > Of course not. :) Give it a try? And -z nolazyload for good measure? >> Can you do ldd with -v to see if they're direct deps? > > http://pastebin.com/fJqGE4uh Really interesting. Most of those are stuffed into the python-samba package on Debian sid: http://packages.debian.org/sid/amd64/python-samba/filelist Then in experimental, they've been moved to other places, such as: http://packages.debian.org/experimental/amd64/libsmbd0/filelist And yet, their libsmbclient 4.0.8 (the one in experimental) does not depend on it that I can see, directly or not. There's something fishy. Laurent From grzemba at contac-dt.de Wed Sep 4 08:09:09 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 04 Sep 2013 08:09:09 +0200 Subject: [csw-maintainers] QT4.8.5 on Sparc core dump In-Reply-To: References: Message-ID: Hi Peter, I am still working on this issue, currently only QT4 without script works for Sparc: CONFIGURE_ARGS_sparc += -no-javascript-jit CONFIGURE_ARGS_sparc += -no-script CONFIGURE_ARGS_sparc += -no-scripttools Can I release such a build? > What did you do to solve this? > > Peter FELECAN > mailto:peter at felecan.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Wed Sep 4 13:33:55 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 04 Sep 2013 13:33:55 +0200 Subject: [csw-maintainers] QT4.8.5 on Sparc core dump In-Reply-To: (Carsten Grzemba's message of "Wed, 04 Sep 2013 08:09:09 +0200") References: Message-ID: Carsten Grzemba writes: > Hi Peter, > > I am still working on this issue, currently only QT4 without script works for Sparc: > CONFIGURE_ARGS_sparc += -no-javascript-jit > CONFIGURE_ARGS_sparc += -no-script > CONFIGURE_ARGS_sparc += -no-scripttools > Can I release such a build? Yes. BTW, I'm currently working on this issues because I wish to include WebKit; I found solutions for almost everything. For the moment, please commit your work and release the packages. -- Peter From maciej at opencsw.org Sat Sep 7 15:48:30 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Sep 2013 14:48:30 +0100 Subject: [csw-maintainers] New ImageMagick In-Reply-To: <51E6505D.9040400@opencsw.org> References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> Message-ID: 2013/7/17 Laurent Blume > Even with using -xO5, Studio is still about 10% slower than GCC4.8. Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. Maciej From rmottola at opencsw.org Sat Sep 7 19:51:45 2013 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Sep 2013 19:51:45 +0200 Subject: [csw-maintainers] #ifdef's for solaris versions Message-ID: <522B67B1.2010001@opencsw.org> Hi, while a bit off-topic, since I am not speaking of software currently packaged, I bet you experienced this in the past while porting. I also hope GNUstep software will get into the packages sooner or later! Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) Ideally something like this: #if solaris #if Solaris=8 xxx #else #endif On Mac, extremely convenient macros are provided where I can check for each evrsion, including doing stuff like "<10.4."... but I did not find equivalent. Since these these patches would go directly in upstream, I need them no to impact anything else! Thank you. I will later report my progress. Riccardo From maciej at opencsw.org Sat Sep 7 17:57:36 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Sep 2013 16:57:36 +0100 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: <522B67B1.2010001@opencsw.org> References: <522B67B1.2010001@opencsw.org> Message-ID: 2013/9/7 Riccardo Mottola > > Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) Why not have a ./configure test for the exact feature or bug you're interested in detecting, and an own #define? From maciej at opencsw.org Sat Sep 7 18:35:55 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Sep 2013 17:35:55 +0100 Subject: [csw-maintainers] =?utf-8?q?Integrating_unstable=E2=86=92testing_?= =?utf-8?b?4oCUIGhhbmRvdmVy?= In-Reply-To: References: Message-ID: I've pasted in the integration documentation into our wiki: http://wiki.opencsw.org/automated-release-process#toc4 The issue is still open, we're looking for someone to handle catalog integrations. Maciej From pfelecan at opencsw.org Sat Sep 7 19:18:12 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 07 Sep 2013 19:18:12 +0200 Subject: [csw-maintainers] =?iso-2022-jp?b?SW50ZWdyYXRpbmcgdW5zdGFibGU=?= =?iso-2022-jp?b?GyRCIiobKEJ0ZXN0aW5nIBskQiE9GyhCIGhhbmRvdmVy?= In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 7 Sep 2013 17:35:55 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > I've pasted in the integration documentation into our wiki: > > http://wiki.opencsw.org/automated-release-process#toc4 > > The issue is still open, we're looking for someone to handle > catalog integrations. IMHO, we need to find somebody to implement the automatic transition from unstable to testing. Remember, we decided that the transition is made when there is no blocking issue reported in our BTS after 2 weeks from release time. -- Peter From laurent at opencsw.org Sat Sep 7 19:28:28 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 07 Sep 2013 19:28:28 +0200 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: References: <522B67B1.2010001@opencsw.org> Message-ID: <522B623C.1020406@opencsw.org> On 2013-09-07 5:57 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/9/7 Riccardo Mottola >> >> Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) > > Why not have a ./configure test for the exact feature or bug you're > interested in detecting, and an own #define? Actually, so far, it's the *only* way. Unlike for Linux distros,which are very stable, Solaris features do vary a lot during the lifetime of a given release. So, the major number is meaningless (you could even have the case where a patched version N has a feature than an unpatched N+1 does not). Update versions don't mean much, since you can get a feature via a patch without changing the update, Patch numbers are unreliable: you would need to know what patch number introduced a feature, but it'll probably be rolled into another patch later. And we're getting far of a simple #ifdef check here. This is all less true in Solaris 11, which has tightened the integration, and forces you the hard way to have an all or nothing upgrade. It still remains to be seen how it will evolve. So, like Maciej said - configure. Laurent From laurent at opencsw.org Sat Sep 7 19:34:55 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 07 Sep 2013 19:34:55 +0200 Subject: [csw-maintainers] New ImageMagick In-Reply-To: References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> Message-ID: <522B63BF.5060402@opencsw.org> On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi?ski wrote: > 2013/7/17 Laurent Blume >> Even with using -xO5, Studio is still about 10% slower than GCC4.8. > > Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. Yes, me too. I still have a plan to run my bench on the M3000 at work, There's one box that's just for that. Laurent From Joerg.Schilling at fokus.fraunhofer.de Sat Sep 7 20:17:59 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Sat, 7 Sep 2013 20:17:59 +0200 Subject: [csw-maintainers] New ImageMagick In-Reply-To: <522B63BF.5060402@opencsw.org> References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> <522B63BF.5060402@opencsw.org> Message-ID: <522b6dd7.wya849MBsHkoCamb%Joerg.Schilling@fokus.fraunhofer.de> Laurent Blume wrote: > On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi??ski wrote: > > 2013/7/17 Laurent Blume > >> Even with using -xO5, Studio is still about 10% slower than GCC4.8. > > > > Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. > > Yes, me too. I still have a plan to run my bench on the M3000 at work, > There's one box that's just for that. AFAIK, -fast is more than -xO5 did you test that? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From laurent at opencsw.org Sat Sep 7 20:28:09 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 07 Sep 2013 20:28:09 +0200 Subject: [csw-maintainers] New ImageMagick In-Reply-To: <522b6dd7.wya849MBsHkoCamb%Joerg.Schilling@fokus.fraunhofer.de> References: <51E3FA6A.90008@opencsw.org> <51E6505D.9040400@opencsw.org> <522B63BF.5060402@opencsw.org> <522b6dd7.wya849MBsHkoCamb%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <522B7039.3030603@opencsw.org> On 2013-09-07 8:17 PM, Joerg Schilling wrote: > Laurent Blume wrote: > >> On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi??ski wrote: >>> 2013/7/17 Laurent Blume >>>> Even with using -xO5, Studio is still about 10% slower than GCC4.8. >>> >>> Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. >> >> Yes, me too. I still have a plan to run my bench on the M3000 at work, >> There's one box that's just for that. > > AFAIK, -fast is more than -xO5 > > did you test that? I tried -native (included in -fast). Studio crashed. GCC won by being about ?? faster. Laurent From maciej at opencsw.org Sat Sep 7 20:29:09 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Sep 2013 19:29:09 +0100 Subject: [csw-maintainers] =?utf-8?q?Integrating_unstable=E2=86=92testing_?= =?utf-8?b?4oCVIGhhbmRvdmVy?= In-Reply-To: References: Message-ID: 2013/9/7 Peter FELECAN > IMHO, we need to find somebody to implement the automatic transition > from unstable to testing. Remember, we decided that the transition is > made when there is no blocking issue reported in our BTS after 2 weeks > from release time. Right. We might start moving in this direction. The database already stores the required information: when was each package inserted into which catalog. There is no REST API for it though. I'll see if I can add it. I'm also thinking that when we transition to the 2 week automatic package promotion, we'll come across a new failure scenario. For example, 2 co-dependent packages are uploaded, let's call them CSWfoo and CSWbar. A bug is discovered in CSWbar. A fixed version of CSWbar is uploaded a week later. But the timer on CSWfoo hasn't been reset, so CSWfoo gets promoted without the accompanying CSWbar. This causes CSWbar to be broken in the testing catalog. So far, I've tried to make the package promotion as simple as possible. Ideally, it was an equivalent of taking a snapshot of unstable and making it the testing catalog. Maciej From laurent at opencsw.org Sat Sep 7 20:37:59 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 07 Sep 2013 20:37:59 +0200 Subject: [csw-maintainers] =?utf-8?q?Integrating_unstable=E2=86=92testing_?= =?utf-8?b?4oCVIGhhbmRvdmVy?= In-Reply-To: References: Message-ID: <522B7287.9090907@opencsw.org> On 2013-09-07 8:29 PM, Maciej (Matchek) Blizi?ski wrote: > So far, I've tried to make the package promotion as simple as > possible. Ideally, it was an equivalent of taking a snapshot of > unstable and making it the testing catalog. Since that's basically what I'm doing in production, I'm all for it. Laurent From maciej at opencsw.org Sat Sep 7 23:15:11 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Sep 2013 22:15:11 +0100 Subject: [csw-maintainers] =?utf-8?q?Integrating_unstable=E2=86=92testing_?= =?utf-8?b?4oCVIGhhbmRvdmVy?= In-Reply-To: <522B7287.9090907@opencsw.org> References: <522B7287.9090907@opencsw.org> Message-ID: 2013/9/7 Laurent Blume > > On 2013-09-07 8:29 PM, Maciej (Matchek) Blizi?ski wrote: > > So far, I've tried to make the package promotion as simple as > > possible. Ideally, it was an equivalent of taking a snapshot of > > unstable and making it the testing catalog. > > Since that's basically what I'm doing in production, I'm all for it. In practice it wasn't that simple, there usually were packages I wanted to skip. Another thing is deletions: we need to propagate them as well, but the database currently doesn't hold the information about when a package was removed from a catalog. This might be an inconvenient feature to implement. We currently have a table which connects a svr4 file, catalog release, OS release and architecture. mysql> describe srv4_file_in_catalog; +-------------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | arch_id | int(11) | NO | MUL | NULL | | | osrel_id | int(11) | NO | MUL | NULL | | | catrel_id | int(11) | NO | MUL | NULL | | | srv4file_id | int(11) | NO | MUL | NULL | | | created_on | datetime | NO | | NULL | | | created_by | varchar(50) | NO | | NULL | | +-------------+-------------+------+-----+---------+----------------+ 7 rows in set (0.37 sec) A row in this table means that such-and-such package is in a specific catalog. If we want to keep the information about deletions, we'll have to keep the row, but the row would need to contain a flag indicating that the package has been removed at certain time. Maciej From pfelecan at opencsw.org Sun Sep 8 09:23:48 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 08 Sep 2013 09:23:48 +0200 Subject: [csw-maintainers] =?gb2312?b?SW50ZWdyYXRpbmcgdW5zdGFibGWh+nRlc3Rp?= =?gb2312?b?bmcgoaogaGFuZG92ZXI=?= In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 7 Sep 2013 19:29:09 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/7 Peter FELECAN >> IMHO, we need to find somebody to implement the automatic transition >> from unstable to testing. Remember, we decided that the transition is >> made when there is no blocking issue reported in our BTS after 2 weeks >> from release time. > > Right. We might start moving in this direction. The database already > stores the required information: when was each package inserted into > which catalog. There is no REST API for it though. I'll see if I can > add it. > > I'm also thinking that when we transition to the 2 week automatic > package promotion, we'll come across a new failure scenario. For > example, 2 co-dependent packages are uploaded, let's call them CSWfoo > and CSWbar. A bug is discovered in CSWbar. A fixed version of CSWbar > is uploaded a week later. But the timer on CSWfoo hasn't been reset, > so CSWfoo gets promoted without the accompanying CSWbar. This causes > CSWbar to be broken in the testing catalog. Of course, the promotion of a package can be done only if all its dependencies can be or are already promoted. This additional complexity is the probable cause of it not being yet implemented. > So far, I've tried to make the package promotion as simple as > possible. Ideally, it was an equivalent of taking a snapshot of > unstable and making it the testing catalog. Oversimplification is its name. -- Peter From pfelecan at opencsw.org Sun Sep 8 09:28:13 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 08 Sep 2013 09:28:13 +0200 Subject: [csw-maintainers] =?gb2312?b?SW50ZWdyYXRpbmcgdW5zdGFibGWh+nRlc3Rp?= =?gb2312?b?bmcgoaogaGFuZG92ZXI=?= In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 7 Sep 2013 22:15:11 +0100") References: <522B7287.9090907@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/7 Laurent Blume >> >> On 2013-09-07 8:29 PM, Maciej (Matchek) Blizi?ski wrote: >> > So far, I've tried to make the package promotion as simple as >> > possible. Ideally, it was an equivalent of taking a snapshot of >> > unstable and making it the testing catalog. >> >> Since that's basically what I'm doing in production, I'm all for it. > > In practice it wasn't that simple, there usually were packages I wanted to skip. > > Another thing is deletions: we need to propagate them as well, but the > database currently doesn't hold the information about when a package > was removed from a catalog. This might be an inconvenient feature to > implement. > > We currently have a table which connects a svr4 file, catalog release, > OS release and architecture. > > mysql> describe srv4_file_in_catalog; > +-------------+-------------+------+-----+---------+----------------+ > | Field | Type | Null | Key | Default | Extra | > +-------------+-------------+------+-----+---------+----------------+ > | id | int(11) | NO | PRI | NULL | auto_increment | > | arch_id | int(11) | NO | MUL | NULL | | > | osrel_id | int(11) | NO | MUL | NULL | | > | catrel_id | int(11) | NO | MUL | NULL | | > | srv4file_id | int(11) | NO | MUL | NULL | | > | created_on | datetime | NO | | NULL | | > | created_by | varchar(50) | NO | | NULL | | > +-------------+-------------+------+-----+---------+----------------+ > 7 rows in set (0.37 sec) > > A row in this table means that such-and-such package is in a specific > catalog. If we want to keep the information about deletions, we'll > have to keep the row, but the row would need to contain a flag > indicating that the package has been removed at certain time. Adding this information helps. The date of the deletion also to keep the "certain time". Of course, the flag can be negated if the package is re-instantiated. BTW, what about increasing the size of created_by attribute to contain a group of maintainers? -- Peter From maciej at opencsw.org Sun Sep 8 10:02:11 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Sep 2013 09:02:11 +0100 Subject: [csw-maintainers] =?utf-8?q?Integrating_unstable=E2=86=92testing_?= =?utf-8?b?4oCUIGhhbmRvdmVy?= In-Reply-To: References: <522B7287.9090907@opencsw.org> Message-ID: 2013/9/8 Peter FELECAN : > Adding this information helps. The date of the deletion also to keep the > "certain time". Of course, the flag can be negated if the package is > re-instantiated. Yes. The problem is that this will require a database schema change and code changes in multiple places. > BTW, what about increasing the size of created_by attribute to contain a > group of maintainers? This field isn't the maintainer, it's the user who initiated the call to insert a package into a catalog. It also currently doesn't work because of the proxy issue we discussed earlier. http://lists.opencsw.org/pipermail/maintainers/2013-May/018107.html Maciej From rupert at opencsw.org Sun Sep 8 14:29:57 2013 From: rupert at opencsw.org (rupert THURNER) Date: Sun, 8 Sep 2013 14:29:57 +0200 Subject: [csw-maintainers] upload error Message-ID: hi, i created the current mercurial packages today by: rupert @ unstable10x : ~/opencsw/mercurial/trunk mgar up mgar spotless remerge replatforms and the upload fails with: rupert @ login : ~ $ csw-upload-pkg pkgs/08.Sep.2013/mercurial-2.7.1\,REV\=2013.09.08-SunOS5.10-* Processing 2 file(s). Please wait. Traceback (most recent call last): File "/opt/csw/bin/csw-upload-pkg", line 509, in uploader.Upload() File "/opt/csw/bin/csw-upload-pkg", line 168, in Upload filename, self.catrel, arch, osrel, md5_sum) File "/opt/csw/bin/csw-upload-pkg", line 243, in _MatchSrv4ToCatalogs arch, osrel, srv4_in_catalog["osrel"], catalogname) KeyError: 'osrel' what did i overlook? rupert From laurent at opencsw.org Sun Sep 8 14:35:38 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 08 Sep 2013 14:35:38 +0200 Subject: [csw-maintainers] upload error In-Reply-To: References: Message-ID: <522C6F1A.2050203@opencsw.org> On 2013-09-08 2:29 PM, rupert THURNER wrote: > hi, i created the current mercurial packages today by: > rupert @ unstable10x : ~/opencsw/mercurial/trunk > mgar up > mgar spotless remerge replatforms > > and the upload fails with: > > rupert @ login : ~ > $ csw-upload-pkg pkgs/08.Sep.2013/mercurial-2.7.1\,REV\=2013.09.08-SunOS5.10-* > Processing 2 file(s). Please wait. > Traceback (most recent call last): > File "/opt/csw/bin/csw-upload-pkg", line 509, in > uploader.Upload() > File "/opt/csw/bin/csw-upload-pkg", line 168, in Upload > filename, self.catrel, arch, osrel, md5_sum) > File "/opt/csw/bin/csw-upload-pkg", line 243, in _MatchSrv4ToCatalogs > arch, osrel, srv4_in_catalog["osrel"], catalogname) > KeyError: 'osrel' > > what did i overlook? Have you done an "mgar up --all" to be sure you picked all the little bits? I had a similar issue yesterday, the full update fixed it for me (Maciej had fixed the issue I was hitting). Laurent From pfelecan at opencsw.org Sun Sep 8 14:56:28 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 08 Sep 2013 14:56:28 +0200 Subject: [csw-maintainers] upload error In-Reply-To: <522C6F1A.2050203@opencsw.org> (Laurent Blume's message of "Sun, 08 Sep 2013 14:35:38 +0200") References: <522C6F1A.2050203@opencsw.org> Message-ID: Laurent Blume writes: > On 2013-09-08 2:29 PM, rupert THURNER wrote: >> hi, i created the current mercurial packages today by: >> rupert @ unstable10x : ~/opencsw/mercurial/trunk >> mgar up >> mgar spotless remerge replatforms >> >> and the upload fails with: >> >> rupert @ login : ~ >> $ csw-upload-pkg pkgs/08.Sep.2013/mercurial-2.7.1\,REV\=2013.09.08-SunOS5.10-* >> Processing 2 file(s). Please wait. >> Traceback (most recent call last): >> File "/opt/csw/bin/csw-upload-pkg", line 509, in >> uploader.Upload() >> File "/opt/csw/bin/csw-upload-pkg", line 168, in Upload >> filename, self.catrel, arch, osrel, md5_sum) >> File "/opt/csw/bin/csw-upload-pkg", line 243, in _MatchSrv4ToCatalogs >> arch, osrel, srv4_in_catalog["osrel"], catalogname) >> KeyError: 'osrel' >> >> what did i overlook? > > Have you done an "mgar up --all" to be sure you picked all the little > bits? I had a similar issue yesterday, the full update fixed it for me > (Maciej had fixed the issue I was hitting). cd ~/opencsw/.buildsys/v2 && svn up . is the necessary and sufficient -- Peter From rmottola at opencsw.org Sun Sep 8 21:32:40 2013 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 08 Sep 2013 21:32:40 +0200 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: References: <522B67B1.2010001@opencsw.org> Message-ID: <522CD0D8.5040706@opencsw.org> Hi, On 09/07/13 17:57, Maciej (Matchek) Blizi??ski wrote: > 2013/9/7 Riccardo Mottola >> Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) > Why not have a ./configure test for the exact feature or bug you're > interested in detecting, and an own #define? First, not everything is easy to check, also these tests need to work on non-solaris platforms. Perhaps you do have some ready tests? The first problem is checking for stdint.h: that's easy, the alternative is inttypes. But then checking for various macros, some of those are defined "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and that kind of stuff). Furthermore, configure is easy for a program, but more difficult to use for a library, a Framework where you install headers, because you don't install config.h, or at least so I understand it. So if you have some solaris ifdef's I would still a appreciate :) There must be! Perhaps a mix of the two tings will eventually help me better. Riccardo From maciej at opencsw.org Sun Sep 8 23:19:42 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Sep 2013 22:19:42 +0100 Subject: [csw-maintainers] External discussions about our project Message-ID: I just found this thread from comp.os.solaris, in April this year: https://groups.google.com/d/msg/comp.unix.solaris/FRucD_DUXrQ/gEHRwubhZzQJ My first impression is that they didn't like our getting started instructions. What should we do? Consolidate? (that is: delete as many pages as possible, move content to one place, put links and/or redirects everywhere else) Maciej From maciej at opencsw.org Sun Sep 8 23:51:48 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Sep 2013 22:51:48 +0100 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: <522CD0D8.5040706@opencsw.org> References: <522B67B1.2010001@opencsw.org> <522CD0D8.5040706@opencsw.org> Message-ID: 2013/9/8 Riccardo Mottola : > Hi, > > > On 09/07/13 17:57, Maciej (Matchek) Blizi??ski wrote: >> >> 2013/9/7 Riccardo Mottola >>> >>> Are there reliable #ifdef's for identifying solaris? and then, in case, >>> its versions? I need certain workaround for solaris and, furthermore some >>> are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with >>> the missing stdint.h and the incomplete inttypes.h) >> >> Why not have a ./configure test for the exact feature or bug you're >> interested in detecting, and an own #define? > > First, not everything is easy to check, also these tests need to work on > non-solaris platforms. Perhaps you do have some ready tests? > The first problem is checking for stdint.h: that's easy, the alternative is > inttypes. But then checking for various macros, some of those are defined > "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and > that kind of stuff). If you could describe here an example of a test that doesn't look easy, maybe someone would chime in with a hint. Is your code available to be viewed? If not, can you post a snippet that breaks? > Furthermore, configure is easy for a program, but more difficult to use for > a library, a Framework where you install headers, because you don't install > config.h, or at least so I understand it. It's possible. You do install config.h, giving it either a unique name such as project-config.h or putting it into a project-specific directory. http://www.openismus.com/documents/linux/building_libraries/building_libraries#installingheaders http://stackoverflow.com/questions/1810216/autoconf-where-does-config-h-go which links to: http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html > So if you have some solaris ifdef's I would still a appreciate :) There must > be! Perhaps a mix of the two tings will eventually help me better. No, this is a wrong way of doing this. All you need is to learn how to write tests and use the results. Maciej From wilbury at opencsw.org Mon Sep 9 00:05:49 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Mon, 09 Sep 2013 00:05:49 +0200 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: References: <522B67B1.2010001@opencsw.org> <522CD0D8.5040706@opencsw.org> Message-ID: <522CF4BD.8030207@opencsw.org> On 09/08/13 23:51, Maciej (Matchek) Blizi?ski wrote: > 2013/9/8 Riccardo Mottola : >> Hi, >> >> >> On 09/07/13 17:57, Maciej (Matchek) Blizi??ski wrote: >>> >>> 2013/9/7 Riccardo Mottola >>>> >>>> Are there reliable #ifdef's for identifying solaris? and then, in case, >>>> its versions? I need certain workaround for solaris and, furthermore some >>>> are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with >>>> the missing stdint.h and the incomplete inttypes.h) >>> >>> Why not have a ./configure test for the exact feature or bug you're >>> interested in detecting, and an own #define? >> >> First, not everything is easy to check, also these tests need to work on >> non-solaris platforms. Perhaps you do have some ready tests? >> The first problem is checking for stdint.h: that's easy, the alternative is >> inttypes. But then checking for various macros, some of those are defined >> "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and >> that kind of stuff). > > If you could describe here an example of a test that doesn't look > easy, maybe someone would chime in with a hint. Is your code available > to be viewed? If not, can you post a snippet that breaks? > >> Furthermore, configure is easy for a program, but more difficult to use for >> a library, a Framework where you install headers, because you don't install >> config.h, or at least so I understand it. > > It's possible. You do install config.h, giving it either a unique name > such as project-config.h or putting it into a project-specific > directory. > > http://www.openismus.com/documents/linux/building_libraries/building_libraries#installingheaders > http://stackoverflow.com/questions/1810216/autoconf-where-does-config-h-go > which links to: > http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html To make long story short: On Solaris, gcc and sunstudio(?) #defines "sun" and gcc defines also "__sun" so #if defined(sun) || defined(__sun) ... #endif will compile block on Solaris plarform. More information: http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system -- Juraj Lutter From maciej at opencsw.org Mon Sep 9 00:14:16 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Sep 2013 23:14:16 +0100 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: <522CF4BD.8030207@opencsw.org> References: <522B67B1.2010001@opencsw.org> <522CD0D8.5040706@opencsw.org> <522CF4BD.8030207@opencsw.org> Message-ID: 2013/9/8 Juraj Lutter : > To make long story short: > > On Solaris, gcc and sunstudio(?) #defines "sun" and gcc defines also > "__sun" so > > #if defined(sun) || defined(__sun) > ... > #endif > > will compile block on Solaris plarform. It has been described in our porting FAQ: http://wiki.opencsw.org/porting-faq#toc22 But this isn't what Riccardo asked. He wanted to detect whether we're on e.g. Solaris 9 or Solaris 10. Maciej From dam at opencsw.org Mon Sep 9 08:06:51 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Sep 2013 08:06:51 +0200 Subject: [csw-maintainers] Anniversary Shirts for Berlin Message-ID: Hi folks, there will be t-shirts again for the Summercamp in Berlin! If you want one you need to tell me the size until tomorrow morning latest, earlier is better. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From grzemba at contac-dt.de Mon Sep 9 08:22:54 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 09 Sep 2013 08:22:54 +0200 Subject: [csw-maintainers] Anniversary Shirts for Berlin In-Reply-To: References: Message-ID: Thanks, ? Size: XL Carsten Am 09.09.13 schrieb Dagobert Michelsen : > Hi folks, > > there will be t-shirts again for the Summercamp in Berlin! If you want one > you need to tell me the size until tomorrow morning latest, earlier is better. > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Sep 9 08:23:32 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Sep 2013 08:23:32 +0200 Subject: [csw-maintainers] External discussions about our project In-Reply-To: References: Message-ID: <69DDA97D-E930-4CB2-9710-845954398564@opencsw.org> Hi Maciej, Am 08.09.2013 um 23:19 schrieb Maciej (Matchek) Blizi?ski : > I just found this thread from comp.os.solaris, in April this year: > > https://groups.google.com/d/msg/comp.unix.solaris/FRucD_DUXrQ/gEHRwubhZzQJ > > My first impression is that they didn't like our getting started > instructions. What should we do? Consolidate? (that is: delete as many > pages as possible, move content to one place, put links and/or > redirects everywhere else) Probable increase the font size and make it look like web 2.0 similar to http://mosh.mit.edu Apart from that David had problems gettings started three years ago: https://groups.google.com/forum/#!topic/comp.unix.solaris/AIj_dYgPB0M Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From dam at opencsw.org Mon Sep 9 08:48:09 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Sep 2013 08:48:09 +0200 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: <522CD0D8.5040706@opencsw.org> References: <522B67B1.2010001@opencsw.org> <522CD0D8.5040706@opencsw.org> Message-ID: <722AA2F8-0BD9-4A3D-8658-81396ACC98C1@opencsw.org> Hi Riccardo, Am 08.09.2013 um 21:32 schrieb Riccardo Mottola : > On 09/07/13 17:57, Maciej (Matchek) Blizi??ski wrote: >> 2013/9/7 Riccardo Mottola >>> Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) >> >> Why not have a ./configure test for the exact feature or bug you're >> interested in detecting, and an own #define? > > First, not everything is easy to check, also these tests need to work on non-solaris platforms. Perhaps you do have some ready tests? > The first problem is checking for stdint.h: that's easy, the alternative is inttypes. But then checking for various macros, some of those are defined "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and that kind of stuff). I suggest seeking inspiration from other portable projects like vlc, rdesktop or mpg123. Apart from that I guess 'host' in autoconf is what you are looking for: http://www.sourceware.org/autobook/autobook/autobook_261.html#SEC261 Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From laurent at opencsw.org Mon Sep 9 12:02:33 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 09 Sep 2013 12:02:33 +0200 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: <722AA2F8-0BD9-4A3D-8658-81396ACC98C1@opencsw.org> References: <522B67B1.2010001@opencsw.org> <522CD0D8.5040706@opencsw.org> <722AA2F8-0BD9-4A3D-8658-81396ACC98C1@opencsw.org> Message-ID: <522D9CB9.8080103@opencsw.org> On 09/09/13 08:48, Dagobert Michelsen wrote: > Apart from that I guess 'host' in autoconf is what you are looking for: > http://www.sourceware.org/autobook/autobook/autobook_261.html#SEC261 Yes, a rather common source of issues in configure scripts, using that host value :-/ Laurent From maciej at opencsw.org Mon Sep 9 17:38:50 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 9 Sep 2013 16:38:50 +0100 Subject: [csw-maintainers] =?utf-8?q?Chef_Happens_=E2=80=93_Managing_Solar?= =?utf-8?q?is_with_Chef?= Message-ID: This article is over a year old, but I haven't seen it mentioned here. It talks about setting up Chef on a Solaris host. http://wix.io/2012/07/22/chef-on-solaris/ It's cool that we get mentioned. I'd be curious to hear why is Ruby from OpenCSW not working correctly, as the article complains. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From raos at opencsw.org Tue Sep 10 07:36:13 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Tue, 10 Sep 2013 07:36:13 +0200 Subject: [csw-maintainers] Anniversary Shirts for Berlin In-Reply-To: References: Message-ID: <20130910053613.GG27086@bender.opencsw.org> Hi Dago On Mon, Sep 09, 2013 at 08:06:51AM +0200, Dagobert Michelsen wrote: > Hi folks, > > there will be t-shirts again for the Summercamp in Berlin! If you want one > you need to tell me the size until tomorrow morning latest, earlier is better. I'd appreciate a L. cheers rafi > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From dam at opencsw.org Tue Sep 10 12:34:06 2013 From: dam at opencsw.org (dam) Date: Tue, 10 Sep 2013 12:34:06 +0200 Subject: [csw-maintainers] Anniversary Shirts for Berlin In-Reply-To: <20130910053613.GG27086@bender.opencsw.org> References: <20130910053613.GG27086@bender.opencsw.org> Message-ID: <55162eafe0d845b8ee98da898f2872b8@opencsw.org> Hi Rafi, Am 2013-09-10 07:36, schrieb Rafael Ostertag: > On Mon, Sep 09, 2013 at 08:06:51AM +0200, Dagobert Michelsen wrote: >> there will be t-shirts again for the Summercamp in Berlin! If you >> want one >> you need to tell me the size until tomorrow morning latest, earlier >> is better. > I'd appreciate a L. So you are in for the camp? Excellent! Please add yourself to the wiki when you'll arrive! Best regards -- Dago From joerg.schilling at fokus.fraunhofer.de Tue Sep 10 14:12:05 2013 From: joerg.schilling at fokus.fraunhofer.de (=?iso-8859-1?Q?Schilling=2C_J=F6rg?=) Date: Tue, 10 Sep 2013 12:12:05 +0000 Subject: [csw-maintainers] Anniversary Shirts for Berlin In-Reply-To: References: Message-ID: I believe i meed xl or xxl -- Send from my Android phone Dagobert Michelsen schrieb: Hi folks, there will be t-shirts again for the Summercamp in Berlin! If you want one you need to tell me the size until tomorrow morning latest, earlier is better. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From raos at opencsw.org Tue Sep 10 19:49:42 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Tue, 10 Sep 2013 19:49:42 +0200 Subject: [csw-maintainers] Anniversary Shirts for Berlin In-Reply-To: <55162eafe0d845b8ee98da898f2872b8@opencsw.org> References: <20130910053613.GG27086@bender.opencsw.org> <55162eafe0d845b8ee98da898f2872b8@opencsw.org> Message-ID: <20130910174942.GH27086@bender.opencsw.org> Hi Dago On Tue, Sep 10, 2013 at 12:34:06PM +0200, dam wrote: [...] > So you are in for the camp? Excellent! Please add yourself to the > wiki when you'll arrive! I guess you mean the wiki page [1], right? Will do as soon as somebody grants my application to the wiki ;) cheers rafi [1] http://wiki.opencsw.org/summercamp-2013 From pfelecan at opencsw.org Wed Sep 11 17:02:21 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 11 Sep 2013 17:02:21 +0200 Subject: [csw-maintainers] WebKit port to Solaris 10 Message-ID: FWIW, I ported WebKit to Solaris 10. All the gory details are in the 21906 revision of the recipe tree http://gar.svn.sourceforge.net/gar/?rev=21906&view=rev The tests pass in their great majority... This is not all about bragging... If there is somebody interested in providing an out of Qt WebKit and/or comment on the details of this port s/he is welcome. -- Peter From maciej at opencsw.org Wed Sep 11 17:49:06 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 11 Sep 2013 16:49:06 +0100 Subject: [csw-maintainers] #ifdef's for solaris versions In-Reply-To: <522B67B1.2010001@opencsw.org> References: <522B67B1.2010001@opencsw.org> Message-ID: Hi Riccardo, 2013/9/7 Riccardo Mottola : > while a bit off-topic, since I am not speaking of software currently > packaged, I bet you experienced this in the past while porting. I also hope > GNUstep software will get into the packages sooner or later! > > Are there reliable #ifdef's for identifying solaris? and then, in case, its > versions? I need certain workaround for solaris and, furthermore some are > needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the > missing stdint.h and the incomplete inttypes.h) > > Ideally something like this: > > #if solaris > #if Solaris=8 > xxx > #else > #endif > > On Mac, extremely convenient macros are provided where I can check for each > evrsion, including doing stuff like "<10.4."... but I did not find > equivalent. Since these these patches would go directly in upstream, I need > them no to impact anything else! I found a recently written book about autotools. It didn't cover this specific topic (library header files varying with ./configure time test results), but I found out that the author sits no the same floor, so came over and had a little chat. The summary of the conversation is this: - I confirmed that you should not depend on platform-dependent defines, but test for features or behavior in the ./configure script - if you're installing header files for a library, you should not install (renamed or not renamed) config.h because it contains defines such as package name and version, which then mess with the same defines in the software you're compiling later (and including the installed library's config.h) - you can tweak the installed foo-config.h to remove/undef the conflicting defines, but it's ugly - since you can build on Solaris 9 and install on Solaris 10, the installed foo-config.h will be probably broken; you need to build separate on 9 and 10 ...and last but not least: - the library headers define the API of your library, right? then why does the API of your library depend on the operating system? if you're using types with varying size and you're hardcoding them in config.h, switch to types with known/explicit sizes, and your library's API will become better. Going back to your original question, could you post a specific example of a 9/10 difference? We can then look how to best handle this example, and we'll potentially all learn something from it. Maciej [1] https://www.flameeyes.eu/autotools-mythbuster/ From raos at opencsw.org Wed Sep 11 20:22:04 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Wed, 11 Sep 2013 20:22:04 +0200 Subject: [csw-maintainers] WebKit port to Solaris 10 In-Reply-To: References: Message-ID: <20130911182204.GA10452@bender.opencsw.org> Hi Peter On Wed, Sep 11, 2013 at 05:02:21PM +0200, Peter FELECAN wrote: > FWIW, I ported WebKit to Solaris 10. All the gory details are in the > 21906 revision of the recipe tree > http://gar.svn.sourceforge.net/gar/?rev=21906&view=rev Out of couriosity, didn't you run into trouble due to missing atomicIncrement()/atomicDecrement() on sparc? cheers rafi From pfelecan at opencsw.org Fri Sep 13 09:56:20 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 13 Sep 2013 09:56:20 +0200 Subject: [csw-maintainers] WebKit port to Solaris 10 References: <20130911182204.GA10452@bender.opencsw.org> Message-ID: Rafael Ostertag writes: > Hi Peter > > On Wed, Sep 11, 2013 at 05:02:21PM +0200, Peter FELECAN wrote: >> FWIW, I ported WebKit to Solaris 10. All the gory details are in the >> 21906 revision of the recipe tree >> http://gar.svn.sourceforge.net/gar/?rev=21906&view=rev > > Out of couriosity, didn't you run into trouble due to missing > atomicIncrement()/atomicDecrement() on sparc? This? #elif COMPILER(GCC) && !CPU(SPARC64) && !OS(SYMBIAN) // sizeof(_Atomic_word) != sizeof(int) on sparc64 gcc #define WTF_USE_LOCKFREE_THREADSAFEREFCOUNTED 1 inline int atomicIncrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, 1) + 1; } inline int atomicDecrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, -1) - 1; } in src/3rdparty/webkit/Source/JavaScriptCore/wtf/Atomics.h Please note that we deliver only 32 bit Qt However, the test is overzealous because gcc 4.8 supplies an implementation for sparc v9. We'll see this when we deliver a 64 bit Qt. -- Peter From raos at opencsw.org Fri Sep 13 12:41:27 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Fri, 13 Sep 2013 12:41:27 +0200 Subject: [csw-maintainers] WebKit port to Solaris 10 In-Reply-To: References: <20130911182204.GA10452@bender.opencsw.org> Message-ID: <20130913104127.GB16450@bender.opencsw.org> Hi Peter On Fri, Sep 13, 2013 at 09:56:20AM +0200, Peter FELECAN wrote: > Rafael Ostertag writes: > > > Hi Peter > > > > On Wed, Sep 11, 2013 at 05:02:21PM +0200, Peter FELECAN wrote: > >> FWIW, I ported WebKit to Solaris 10. All the gory details are in the > >> 21906 revision of the recipe tree > >> http://gar.svn.sourceforge.net/gar/?rev=21906&view=rev > > > > Out of couriosity, didn't you run into trouble due to missing > > atomicIncrement()/atomicDecrement() on sparc? > > This? > > #elif COMPILER(GCC) && !CPU(SPARC64) && !OS(SYMBIAN) // sizeof(_Atomic_word) != sizeof(int) on sparc64 gcc > #define WTF_USE_LOCKFREE_THREADSAFEREFCOUNTED 1 > > inline int atomicIncrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, 1) + 1; } > inline int atomicDecrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, -1) - 1; } > > in src/3rdparty/webkit/Source/JavaScriptCore/wtf/Atomics.h > Yeah, that I meant. Ok, so you are aware of that and that patches would be available. cheers rafi From pfelecan at opencsw.org Fri Sep 13 14:01:40 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 13 Sep 2013 14:01:40 +0200 Subject: [csw-maintainers] WebKit port to Solaris 10 In-Reply-To: <20130913104127.GB16450@bender.opencsw.org> (Rafael Ostertag's message of "Fri, 13 Sep 2013 12:41:27 +0200") References: <20130911182204.GA10452@bender.opencsw.org> <20130913104127.GB16450@bender.opencsw.org> Message-ID: Rafael Ostertag writes: > Hi Peter > On Fri, Sep 13, 2013 at 09:56:20AM +0200, Peter FELECAN wrote: >> Rafael Ostertag writes: >> >> > Hi Peter >> > >> > On Wed, Sep 11, 2013 at 05:02:21PM +0200, Peter FELECAN wrote: >> >> FWIW, I ported WebKit to Solaris 10. All the gory details are in the >> >> 21906 revision of the recipe tree >> >> http://gar.svn.sourceforge.net/gar/?rev=21906&view=rev >> > >> > Out of couriosity, didn't you run into trouble due to missing >> > atomicIncrement()/atomicDecrement() on sparc? >> >> This? >> >> #elif COMPILER(GCC) && !CPU(SPARC64) && !OS(SYMBIAN) // sizeof(_Atomic_word) != sizeof(int) on sparc64 gcc >> #define WTF_USE_LOCKFREE_THREADSAFEREFCOUNTED 1 >> >> inline int atomicIncrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, 1) + 1; } >> inline int atomicDecrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, -1) - 1; } >> >> in src/3rdparty/webkit/Source/JavaScriptCore/wtf/Atomics.h >> > > Yeah, that I meant. Ok, so you are aware of that and that patches would be available. >> Please note that we deliver only 32 bit Qt >> >> However, the test is overzealous because gcc 4.8 supplies an >> implementation for sparc v9. We'll see this when we deliver a 64 bit Qt. Having read the above, about what patch are you thinking? Of course, aside removing "&& !CPU(SPARC64)" when the time come. Frankly, for the moment I would concentrate on delivering a complete Qt4 offering and working on Qt5 as the next step. -- Peter From raos at opencsw.org Fri Sep 13 15:13:02 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Fri, 13 Sep 2013 15:13:02 +0200 Subject: [csw-maintainers] WebKit port to Solaris 10 In-Reply-To: References: <20130911182204.GA10452@bender.opencsw.org> <20130913104127.GB16450@bender.opencsw.org> Message-ID: <20130913131302.GC16450@bender.opencsw.org> Hi Peter On Fri, Sep 13, 2013 at 02:01:40PM +0200, Peter FELECAN wrote: > Rafael Ostertag writes: > > > Hi Peter > > On Fri, Sep 13, 2013 at 09:56:20AM +0200, Peter FELECAN wrote: > >> Rafael Ostertag writes: > >> > >> > Hi Peter > >> > > >> > On Wed, Sep 11, 2013 at 05:02:21PM +0200, Peter FELECAN wrote: > >> >> FWIW, I ported WebKit to Solaris 10. All the gory details are in the > >> >> 21906 revision of the recipe tree > >> >> http://gar.svn.sourceforge.net/gar/?rev=21906&view=rev > >> > > >> > Out of couriosity, didn't you run into trouble due to missing > >> > atomicIncrement()/atomicDecrement() on sparc? > >> > >> This? > >> > >> #elif COMPILER(GCC) && !CPU(SPARC64) && !OS(SYMBIAN) // sizeof(_Atomic_word) != sizeof(int) on sparc64 gcc > >> #define WTF_USE_LOCKFREE_THREADSAFEREFCOUNTED 1 > >> > >> inline int atomicIncrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, 1) + 1; } > >> inline int atomicDecrement(int volatile* addend) { return __gnu_cxx::__exchange_and_add(addend, -1) - 1; } > >> > >> in src/3rdparty/webkit/Source/JavaScriptCore/wtf/Atomics.h > >> > > > > Yeah, that I meant. Ok, so you are aware of that and that patches would be available. > > >> Please note that we deliver only 32 bit Qt > >> > >> However, the test is overzealous because gcc 4.8 supplies an > >> implementation for sparc v9. We'll see this when we deliver a 64 bit Qt. > > Having read the above, about what patch are you thinking? Of course, > aside removing "&& !CPU(SPARC64)" when the time come. Frankly, for the > moment I would concentrate on delivering a complete Qt4 offering and > working on Qt5 as the next step. OpenBSD ports provide a patch for said file on sparc64. Simply removing !CPU(SPARC64) won't do the trick due to the fact of sizeof(_Atomic_word) != sizeof(int) Anyhow. I don't want to bother you anymore, since it's not important at the moment. Just remember if the time comes, I might be of help ;) cheers rafi > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From pfelecan at opencsw.org Mon Sep 16 10:32:33 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 16 Sep 2013 10:32:33 +0200 Subject: [csw-maintainers] notes and/or minutes Summercamp 2013 ? Message-ID: Is there something remarkable to know about what was discussed during this event? -- Peter From maciej at opencsw.org Mon Sep 16 12:05:44 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 16 Sep 2013 11:05:44 +0100 Subject: [csw-maintainers] notes and/or minutes Summercamp 2013 ? In-Reply-To: References: Message-ID: 2013/9/16 Peter FELECAN : > Is there something remarkable to know about what was discussed during > this event? Not really. We spent a lot of time hacking and talking between each other. We discussed a number of topics, most of the time we concluded that we agree about what should be done, and it's a matter of spending the time on researching and implementing our ideas. https://docs.google.com/document/d/1XKNrmUsDjaBlStXWLv8UanJaZLyDtv1iasjBKKIrQwk/view Maciej From pfelecan at opencsw.org Mon Sep 16 14:04:38 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 16 Sep 2013 14:04:38 +0200 Subject: [csw-maintainers] notes and/or minutes Summercamp 2013 ? In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 16 Sep 2013 11:05:44 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/16 Peter FELECAN : >> Is there something remarkable to know about what was discussed during >> this event? > > Not really. We spent a lot of time hacking and talking between each > other. We discussed a number of topics, most of the time we concluded > that we agree about what should be done, and it's a matter of spending > the time on researching and implementing our ideas. > > https://docs.google.com/document/d/1XKNrmUsDjaBlStXWLv8UanJaZLyDtv1iasjBKKIrQwk/view Thank you. Is there an external consequence of the modifications in releases 21921 to 21926 on the NMU process? -- Peter From maciej at opencsw.org Mon Sep 16 15:03:42 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 16 Sep 2013 14:03:42 +0100 Subject: [csw-maintainers] Non-Maintainer Uploads (NMUs) In-Reply-To: References: Message-ID: 2013/8/11 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> I tried and failed. I wanted to record who uploaded which package to >> which catalog. Unfortunately, our web proxy destroys this information. >> Maybe it can be fixed with some clever HTTP header rewriting, but I >> didn't manage to make it work. > > What's the proxy that we use? > > Can you show me where in the code this is done? It turned out that it wasn't the proxy at all. I've discovered the bug accidentally during the camp, while explaining the code to another person. This is the fix: http://sourceforge.net/apps/trac/gar/changeset/21921 >From yesterday on, the buildfarm database has accurate information about who inserted which package to which catalog. There also is a new URL you can call to retrieve this information for a given catalog. For example: url=http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/timing/ curl -s $url | python -m json.tool | less The last 3 elements in each list are: - mtime of the svr4 file - time the package was inserted into the catalog - user name who did it, taken from HTTP auth Going back to the original subject, we know of the following facts / relations of people to a given package: - people who made edits to the build recipe (can be taken from the repository, it's not available for all packages) - person who built the package / ran mgar (this information is embedded in the package) - person who inserted the package into a catalog (could be a different person in each catalog) The above are the things we know. None of these things is the list of the Maintainers Of The Package. Maciej From maciej at opencsw.org Mon Sep 16 15:05:14 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 16 Sep 2013 14:05:14 +0100 Subject: [csw-maintainers] notes and/or minutes Summercamp 2013 ? In-Reply-To: References: Message-ID: 2013/9/16 Peter FELECAN : > Is there an external consequence of the modifications in releases 21921 > to 21926 on the NMU process? No, this was only for bookkeeping of who uploaded which package to which catalog. More here: http://lists.opencsw.org/pipermail/maintainers/2013-September/018582.html From maciej at opencsw.org Wed Sep 18 12:29:19 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 18 Sep 2013 11:29:19 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix Message-ID: At the camp, we've discussed building our packages into a different prefix. We want to allow people to build, from scratch, their own sets of packages. There's a number of challenges to get it done. The string /opt/csw and the "CSW" package prefix is encoded in many, many places across GAR code, checkpkg code and build recipes (including patches). There is a number of things that GAR does: downloading sources, running the compilation (multiple times for different modulations), then merging the result into a single image and creating a package. Maybe some of these parts can be replaced with a different piece of code. For example, the Gentoo project maintains a set of build recipes with patches that build fine on Solaris. What they don't have is modulations and SVR4 package building. If we start working on a custom-prefix build, it makes sense to evaluate this option. If it works out, it'll save us a lot of time. Has anyone tried Gentoo Prefix on Solaris before? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From bonivart at opencsw.org Fri Sep 20 17:39:55 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 20 Sep 2013 17:39:55 +0200 Subject: [csw-maintainers] Help with BIND build (symbol gzopen64 missing) Message-ID: Hi, I'm trying to build the latest BIND version and it fails with this: /opt/csw/bin/gcc-4.8 -O2 -pipe -m32 -march=pentiumpro -I/opt/csw/include/libxml2 -I../../lib/isc/include \ -I/opt/csw/include -D_XPG4_2 -D__EXTENSIONS__ -m32 -march=pentiumpro -L/opt/csw/lib -R/opt/csw/lib -o gen ./gen.c -lpthread -lthread -L/opt/csw/lib -R/opt/csw/lib -lxml2 -lz -lpthread -liconv -lm -lsocket -lnsl Undefined first referenced symbol in file gzopen64 /opt/csw/lib/libxml2.so ld: fatal: symbol referencing errors. No output written to gen collect2: error: ld returned 1 exit status ... Looks like libxml2.so uses this libz: bonivart at unstable10x[trunk]$ ldd /opt/csw/lib/libxml2.so libz.so.1 => /opt/csw/lib/pentium_pro+mmx/libz.so.1 ... And it has gzopen64: bonivart at unstable10x[trunk]$ /usr/xpg4/bin/nm /opt/csw/lib/pentium_pro+mmx/libz.so.1|grep gzopen [136] | 60016| 21|FUNC |GLOB |0 |12 |gzopen [150] | 60040| 21|FUNC |GLOB |0 |12 |gzopen64 But still it fails, the systems libz does not have gzopen64, is that why it fails but why is that libz even used? bonivart at unstable10x[trunk]$ /usr/xpg4/bin/nm /usr/lib/libz.so.1|grep gzopen [159] | 8398| 20|FUNC |GLOB |0 |10 |gzopen /peter From slowfranklin at opencsw.org Fri Sep 20 17:45:46 2013 From: slowfranklin at opencsw.org (slowfranklin) Date: Fri, 20 Sep 2013 17:45:46 +0200 Subject: [csw-maintainers] Help with BIND build (symbol gzopen64 missing) In-Reply-To: References: Message-ID: <33BDE521-98CB-42DC-8824-B8D83DD96E8C@opencsw.org> Hi Peter Am 20.09.2013 um 17:39 schrieb Peter Bonivart : > Hi, I'm trying to build the latest BIND version and it fails with this: > > /opt/csw/bin/gcc-4.8 -O2 -pipe -m32 -march=pentiumpro > -I/opt/csw/include/libxml2 -I../../lib/isc/include \ > -I/opt/csw/include -D_XPG4_2 -D__EXTENSIONS__ -m32 -march=pentiumpro > -L/opt/csw/lib -R/opt/csw/lib -o gen ./gen.c -lpthread -lthread > -L/opt/csw/lib -R/opt/csw/lib -lxml2 -lz -lpthread -liconv -lm > -lsocket -lnsl > Undefined first referenced > symbol in file > gzopen64 /opt/csw/lib/libxml2.so > ld: fatal: symbol referencing errors. No output written to gen > collect2: error: ld returned 1 exit status have you installed CSWlibz-dev ? -slow From jh at opencsw.org Fri Sep 20 17:51:27 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Fri, 20 Sep 2013 17:51:27 +0200 Subject: [csw-maintainers] Help with BIND build (symbol gzopen64 missing) In-Reply-To: <33BDE521-98CB-42DC-8824-B8D83DD96E8C@opencsw.org> References: <33BDE521-98CB-42DC-8824-B8D83DD96E8C@opencsw.org> Message-ID: <523C6EFF.4090504@opencsw.org> Hi, Am 20.09.13 17:45, schrieb slowfranklin: > Hi Peter > > Am 20.09.2013 um 17:39 schrieb Peter Bonivart : > >> Hi, I'm trying to build the latest BIND version and it fails with this: >> >> /opt/csw/bin/gcc-4.8 -O2 -pipe -m32 -march=pentiumpro >> -I/opt/csw/include/libxml2 -I../../lib/isc/include \ >> -I/opt/csw/include -D_XPG4_2 -D__EXTENSIONS__ -m32 -march=pentiumpro >> -L/opt/csw/lib -R/opt/csw/lib -o gen ./gen.c -lpthread -lthread >> -L/opt/csw/lib -R/opt/csw/lib -lxml2 -lz -lpthread -liconv -lm >> -lsocket -lnsl >> Undefined first referenced >> symbol in file >> gzopen64 /opt/csw/lib/libxml2.so >> ld: fatal: symbol referencing errors. No output written to gen >> collect2: error: ld returned 1 exit status > > have you installed CSWlibz-dev ? well it's broken again: jh at unstable10x [global]:/opt/csw/lib > ls -alrth libz* -rwxr-xr-x 1 root bin 495K Jul 6 2012 libzmq.so.1.0.1 lrwxrwxrwx 1 root root 15 Aug 23 2012 libzmq.so -> libzmq.so.1.0.1 lrwxrwxrwx 1 root root 13 Aug 23 2012 libz.so -> libz.so.1.2.7 lrwxrwxrwx 1 root root 15 Aug 23 2012 libzmq.so.1 -> libzmq.so.1.0.1 -rwxr-xr-x 1 root bin 119K Sep 17 09:14 libz.so.1.2.8 lrwxrwxrwx 1 root root 13 Sep 19 11:20 libz.so.1 -> libz.so.1.2.8 reinstalled now should be fixed: Greetings Jan From dam at opencsw.org Fri Sep 20 17:52:57 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Sep 2013 17:52:57 +0200 Subject: [csw-maintainers] Help with BIND build (symbol gzopen64 missing) In-Reply-To: References: Message-ID: <45E4BF40-5293-4A9F-9582-9930222FD763@opencsw.org> Hi Peter, Am 20.09.2013 um 17:39 schrieb Peter Bonivart: > Hi, I'm trying to build the latest BIND version and it fails with this: > > /opt/csw/bin/gcc-4.8 -O2 -pipe -m32 -march=pentiumpro > -I/opt/csw/include/libxml2 -I../../lib/isc/include \ > -I/opt/csw/include -D_XPG4_2 -D__EXTENSIONS__ -m32 -march=pentiumpro > -L/opt/csw/lib -R/opt/csw/lib -o gen ./gen.c -lpthread -lthread > -L/opt/csw/lib -R/opt/csw/lib -lxml2 -lz -lpthread -liconv -lm > -lsocket -lnsl > Undefined first referenced > symbol in file > gzopen64 /opt/csw/lib/libxml2.so > ld: fatal: symbol referencing errors. No output written to gen > collect2: error: ld returned 1 exit status > ... > > Looks like libxml2.so uses this libz: > > bonivart at unstable10x[trunk]$ ldd /opt/csw/lib/libxml2.so > libz.so.1 => /opt/csw/lib/pentium_pro+mmx/libz.so.1 > ... > > And it has gzopen64: > > bonivart at unstable10x[trunk]$ /usr/xpg4/bin/nm > /opt/csw/lib/pentium_pro+mmx/libz.so.1|grep gzopen > [136] | 60016| 21|FUNC |GLOB |0 |12 |gzopen > [150] | 60040| 21|FUNC |GLOB |0 |12 |gzopen64 > > But still it fails, the systems libz does not have gzopen64, is that > why it fails but why is that libz even used? > > bonivart at unstable10x[trunk]$ /usr/xpg4/bin/nm /usr/lib/libz.so.1|grep gzopen > [159] | 8398| 20|FUNC |GLOB |0 |10 |gzopen Maybe this sheds some light: http://lists.opencsw.org/pipermail/maintainers/2013-May/018094.html Best regards -- Dago From dam at opencsw.org Fri Sep 20 17:55:16 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 20 Sep 2013 17:55:16 +0200 Subject: [csw-maintainers] Help with BIND build (symbol gzopen64 missing) In-Reply-To: <523C6EFF.4090504@opencsw.org> References: <33BDE521-98CB-42DC-8824-B8D83DD96E8C@opencsw.org> <523C6EFF.4090504@opencsw.org> Message-ID: Hi Jan, Am 20.09.2013 um 17:51 schrieb Jan Holzhueter: > Am 20.09.13 17:45, schrieb slowfranklin: >> Hi Peter >> >> Am 20.09.2013 um 17:39 schrieb Peter Bonivart : >> >>> Hi, I'm trying to build the latest BIND version and it fails with this: >>> >>> /opt/csw/bin/gcc-4.8 -O2 -pipe -m32 -march=pentiumpro >>> -I/opt/csw/include/libxml2 -I../../lib/isc/include \ >>> -I/opt/csw/include -D_XPG4_2 -D__EXTENSIONS__ -m32 -march=pentiumpro >>> -L/opt/csw/lib -R/opt/csw/lib -o gen ./gen.c -lpthread -lthread >>> -L/opt/csw/lib -R/opt/csw/lib -lxml2 -lz -lpthread -liconv -lm >>> -lsocket -lnsl >>> Undefined first referenced >>> symbol in file >>> gzopen64 /opt/csw/lib/libxml2.so >>> ld: fatal: symbol referencing errors. No output written to gen >>> collect2: error: ld returned 1 exit status >> >> have you installed CSWlibz-dev ? > > well it's broken again: > > jh at unstable10x [global]:/opt/csw/lib > ls -alrth libz* > -rwxr-xr-x 1 root bin 495K Jul 6 2012 libzmq.so.1.0.1 > lrwxrwxrwx 1 root root 15 Aug 23 2012 libzmq.so -> > libzmq.so.1.0.1 > lrwxrwxrwx 1 root root 13 Aug 23 2012 libz.so -> > libz.so.1.2.7 > lrwxrwxrwx 1 root root 15 Aug 23 2012 libzmq.so.1 -> > libzmq.so.1.0.1 > -rwxr-xr-x 1 root bin 119K Sep 17 09:14 libz.so.1.2.8 > lrwxrwxrwx 1 root root 13 Sep 19 11:20 libz.so.1 -> > libz.so.1.2.8 > > reinstalled now should be fixed: Argh, I know how this happened. Rafi updated libz to 1.2.8 and made a buildfarm request to something that pulled in the CSWlibz1 as a dependency, but not the dev package and I failed to update the whole buildfarm. Not good. Maybe I should always update everything after installing things. Best regards -- Dago From bonivart at opencsw.org Fri Sep 20 18:59:29 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Fri, 20 Sep 2013 18:59:29 +0200 Subject: [csw-maintainers] Help with BIND build (symbol gzopen64 missing) In-Reply-To: References: <33BDE521-98CB-42DC-8824-B8D83DD96E8C@opencsw.org> <523C6EFF.4090504@opencsw.org> Message-ID: On Fri, Sep 20, 2013 at 5:55 PM, Dagobert Michelsen wrote: > Argh, I know how this happened. Rafi updated libz to 1.2.8 and made a buildfarm > request to something that pulled in the CSWlibz1 as a dependency, but not the > dev package and I failed to update the whole buildfarm. Not good. Maybe I should > always update everything after installing things. Thanks guys for the explanation and quick fix! It now seems to work again. Dago, I think it would be a good procedure to do that. /peter From pfelecan at opencsw.org Sat Sep 21 11:53:28 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 21 Sep 2013 11:53:28 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 18 Sep 2013 11:29:19 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > At the camp, we've discussed building our packages into a different prefix. > We want to allow people to build, from scratch, their own sets of packages. > > There's a number of challenges to get it done. The string /opt/csw and the > "CSW" package prefix is encoded in many, many places across GAR code, > checkpkg code and build recipes (including patches). > > There is a number of things that GAR does: downloading sources, running the > compilation (multiple times for different modulations), then merging the > result into a single image and creating a package. Maybe some of these > parts can be replaced with a different piece of code. For example, the > Gentoo project maintains a set of build recipes with patches that build > fine on Solaris. What they don't have is modulations and SVR4 package > building. If we start working on a custom-prefix build, it makes sense to > evaluate this option. If it works out, it'll save us a lot of time. Well, why not. But, what's the rationale of this effort? -- Peter From maciej at opencsw.org Sat Sep 21 12:38:46 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 21 Sep 2013 11:38:46 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/21 Peter FELECAN : > Well, why not. But, what's the rationale of this effort? For which effort? To build into a different prefix? The rationale is to make our code base more useful to the world. This is also about making sure that it's possible to rebuild everything from scratch, which is currently uncertain. Maciej From pfelecan at opencsw.org Sat Sep 21 15:12:48 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 21 Sep 2013 15:12:48 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 21 Sep 2013 11:38:46 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/21 Peter FELECAN : >> Well, why not. But, what's the rationale of this effort? > > For which effort? To build into a different prefix? The rationale is > to make our code base more useful to the world. This is also about > making sure that it's possible to rebuild everything from scratch, > which is currently uncertain. I'm thinking about the effort to modify all the gears in the machine to obtain the result of building in a different prefix. How is making this endavour our code base more useful to the world? What rises this as something of a priority for us? -- Peter From maciej at opencsw.org Sat Sep 21 21:21:07 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 21 Sep 2013 20:21:07 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/21 Peter FELECAN : > I'm thinking about the effort to modify all the gears in the machine to > obtain the result of building in a different prefix. > > How is making this endavour our code base more useful to the world? > > What rises this as something of a priority for us? There's no priority rising. It's only for people who care about this and want to do it. If anyone sets out to do the rebuild / prefix build, it might turn out that it takes more time to do it with our build recipes than it takes with Gentoo Prefix. I don't know if it's the case or not, but it's worth a shot. Usefulness for the world comes from paranoid organizations being able to take and audit our code, then run it and build their own package repositories. How to measure this usefulness, I don't know, but it's a volunteer based project, if anyone cares about certain feature, they can work on it. I'm just putting the idea out there: if we want to do a rebuild, we could reuse someone else's code. Maciej From pfelecan at opencsw.org Sun Sep 22 20:20:30 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 22 Sep 2013 20:20:30 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 21 Sep 2013 20:21:07 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/21 Peter FELECAN : >> I'm thinking about the effort to modify all the gears in the machine to >> obtain the result of building in a different prefix. >> >> How is making this endavour our code base more useful to the world? >> >> What rises this as something of a priority for us? > > There's no priority rising. It's only for people who care about this > and want to do it. > > If anyone sets out to do the rebuild / prefix build, it might turn out > that it takes more time to do it with our build recipes than it takes > with Gentoo Prefix. I don't know if it's the case or not, but it's > worth a shot. > > Usefulness for the world comes from paranoid organizations being able > to take and audit our code, then run it and build their own package > repositories. How to measure this usefulness, I don't know, but it's a > volunteer based project, if anyone cares about certain feature, they > can work on it. Thank you. I understand what you say, with the exception of the last phrase: > I'm just putting the idea out there: if we want to do a rebuild, we > could reuse someone else's code. Can you develop a little bit? -- Peter From maciej at opencsw.org Mon Sep 23 00:11:12 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 22 Sep 2013 23:11:12 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/22 Peter FELECAN > > I'm just putting the idea out there: if we want to do a rebuild, we > > could reuse someone else's code. > > Can you develop a little bit? Out of many things that GAR does, the most interesting / unique ones are modulations, CAS integration and other SVR4-specific things. The patching and compilation parts are relatively weak ? it has been done elsewhere, maybe even better than what we did. We could see if it's feasible to reuse that work. For example, instead of calling CONFIGURE_SCRIPTS, GAR could shell out to call portage to build and install a specific piece of code. Then it would merge the installed image and proceed as usual. It's just one idea. Why I think it could be feasible? Our current code hardcodes /opt/csw and other variants of the CSW string in many, many places. To build into a different prefix, e.g. ${HOME}/myproject of an unprivileged user, we would have to correct countless places in our build recipes. The required amount of work could be larger than adopting a different codebase. Maciej From jh at opencsw.org Mon Sep 23 08:41:19 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 23 Sep 2013 08:41:19 +0200 Subject: [csw-maintainers] Cataloge sign Message-ID: <523FE28F.7000609@opencsw.org> Hi, cataloge is broken again :) Probably signing please fix :) Greetings Jan From maciej at opencsw.org Mon Sep 23 08:43:40 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Sep 2013 07:43:40 +0100 Subject: [csw-maintainers] Cataloge sign In-Reply-To: <523FE28F.7000609@opencsw.org> References: <523FE28F.7000609@opencsw.org> Message-ID: 2013/9/23 Jan Holzhueter : > cataloge is broken again :) > Probably signing please fix :) Fortunately not broken, just expired. I've just refreshed it, thanks for the heads up! Maciej From pfelecan at opencsw.org Mon Sep 23 09:37:24 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 23 Sep 2013 09:37:24 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 22 Sep 2013 23:11:12 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/22 Peter FELECAN >> > I'm just putting the idea out there: if we want to do a rebuild, we >> > could reuse someone else's code. >> >> Can you develop a little bit? > > Out of many things that GAR does, the most interesting / unique ones > are modulations, CAS integration and other SVR4-specific things. The > patching and compilation parts are relatively weak ? it has been done > elsewhere, maybe even better than what we did. We could see if it's > feasible to reuse that work. For example, instead of calling > CONFIGURE_SCRIPTS, GAR could shell out to call portage to build and > install a specific piece of code. Then it would merge the installed > image and proceed as usual. It's just one idea. The patching is quite reasonable, especially since there is an internal git. Anyhow, all is reduced to a differential process that is well mastered here and there. The build chain is not really part of gar; we have hooks which are quite versatile. The configuration, build, test and installation of a project are an integral part of it: if it uses autotools all is set; the real issues are when the quality of the project in this area is low. > Why I think it could be feasible? Our current code hardcodes /opt/csw > and other variants of the CSW string in many, many places. To build > into a different prefix, e.g. ${HOME}/myproject of an unprivileged > user, we would have to correct countless places in our build recipes. > The required amount of work could be larger than adopting a different > codebase. This is exactly what I doubt. Because I don't see the relation between changing the prefixes in the recipes and using another code base. I wonder if you are not proposing to use another set of recipes. But you are a nice guy and will clarify, isn't it? -- Peter From maciej at opencsw.org Mon Sep 23 11:27:46 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Sep 2013 10:27:46 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/23 Peter FELECAN : >> Why I think it could be feasible? Our current code hardcodes /opt/csw >> and other variants of the CSW string in many, many places. To build >> into a different prefix, e.g. ${HOME}/myproject of an unprivileged >> user, we would have to correct countless places in our build recipes. >> The required amount of work could be larger than adopting a different >> codebase. > > This is exactly what I doubt. Because I don't see the relation between > changing the prefixes in the recipes and using another code base. I > wonder if you are not proposing to use another set of recipes. But you > are a nice guy and will clarify, isn't it? I am proposing an evaluation of another set of build recipes. The relation between changing the prefix and the code base is that the prefix is hardcoded in many, many places in our code base. To find out how many places, you can try this: find ~/opencsw -name Makefile -o -name '*.patch' -o -name '*.diff' -exec gegrep -ril '/opt/csw' {} \; If anyone is looking into working on making OpenCSW buildable into another prefix, I suggest looking at Gentoo Prefix because they've already done it. If no one is thinking of building OpenCSW into another prefix, then this thread can be dismissed. Maciej From pfelecan at opencsw.org Mon Sep 23 11:56:36 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 23 Sep 2013 11:56:36 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 23 Sep 2013 10:27:46 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/23 Peter FELECAN : >>> Why I think it could be feasible? Our current code hardcodes /opt/csw >>> and other variants of the CSW string in many, many places. To build >>> into a different prefix, e.g. ${HOME}/myproject of an unprivileged >>> user, we would have to correct countless places in our build recipes. >>> The required amount of work could be larger than adopting a different >>> codebase. >> >> This is exactly what I doubt. Because I don't see the relation between >> changing the prefixes in the recipes and using another code base. I >> wonder if you are not proposing to use another set of recipes. But you >> are a nice guy and will clarify, isn't it? > > I am proposing an evaluation of another set of build recipes. > > The relation between changing the prefix and the code base is that the > prefix is hardcoded in many, many places in our code base. To find out > how many places, you can try this: > > find ~/opencsw -name Makefile -o -name '*.patch' -o -name '*.diff' > -exec gegrep -ril '/opt/csw' {} \; 456 occurrences in 139 files Reviewing these I cannot see how this cannot be solved by replacing '/opt/csw' by the "prefix" macro. What I'm missing? Aside of tweaking a little bit mgar. > If anyone is looking into working on making OpenCSW buildable into > another prefix, I suggest looking at Gentoo Prefix because they've > already done it. > > If no one is thinking of building OpenCSW into another prefix, then > this thread can be dismissed. IMHO being able to build in another prefix is an interesting exercise, but not vital, and it will eliminate branches in our recipes such as 'NIM'. However, what's more interesting is to be able to rebuild the complete set of packages from scratch. BTW, you have given this as a rationale. Being able to rebuild from scratch is possible with average but dedicated work. The main obstacle, from my stand point, is the missing documentation for making a build farm. This brings us to another thread which is for the moment moribund. -- Peter From maciej at opencsw.org Mon Sep 23 11:59:51 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Sep 2013 10:59:51 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/23 Peter FELECAN : > The main obstacle, from my stand point, is the missing > documentation for making a build farm. It's not the documentation that's missing. It's the code that's missing. We do not have an actual working buildfarm code. Maciej From pfelecan at opencsw.org Mon Sep 23 14:34:21 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 23 Sep 2013 14:34:21 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 23 Sep 2013 10:59:51 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/23 Peter FELECAN : >> The main obstacle, from my stand point, is the missing >> documentation for making a build farm. > > It's not the documentation that's missing. It's the code that's > missing. We do not have an actual working buildfarm code. This is a strange affirmation. How the heck I'm working on a build farm since more than eight years? C'mon... -- Peter From maciej at opencsw.org Mon Sep 23 16:24:25 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Sep 2013 15:24:25 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/23 Peter FELECAN : > This is a strange affirmation. How the heck I'm working on a build farm > since more than eight years? C'mon... You probably haven't tried setting up a shared database recently. What we have is a very old install on a really beefy machine. That install has been tweaked on-the-fly multiple times. It's not like you can follow the instructions from http://wiki.opencsw.org/checkpkg#toc4 and they will work on a virtual machine. In January this year, I've attempted to make an instructional video how to set up a private buildfarm. I've realized that using the resources I had at home, it was impossible. Therefore, we don't have a working set of code. There is the development version, but it's not finished. If you don't believe me, you can try to set up a shared database, here are the instructions: http://wiki.opencsw.org/checkpkg#toc4 - unless you have a very beefy machine, it will fail. Maciej From pfelecan at opencsw.org Mon Sep 23 16:43:57 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Mon, 23 Sep 2013 16:43:57 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 23 Sep 2013 15:24:25 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/23 Peter FELECAN : >> This is a strange affirmation. How the heck I'm working on a build farm >> since more than eight years? C'mon... > > You probably haven't tried setting up a shared database recently. What > we have is a very old install on a really beefy machine. That install > has been tweaked on-the-fly multiple times. It's not like you can > follow the instructions from http://wiki.opencsw.org/checkpkg#toc4 and > they will work on a virtual machine. > > In January this year, I've attempted to make an instructional video > how to set up a private buildfarm. I've realized that using the > resources I had at home, it was impossible. Therefore, we don't have a > working set of code. There is the development version, but it's not > finished. > > If you don't believe me, you can try to set up a shared database, here > are the instructions: http://wiki.opencsw.org/checkpkg#toc4 - unless > you have a very beefy machine, it will fail. Well, this is not equivalent to "not having the code for the build farm". What we have here is that you cannot have a build farm on virtual machines, only on bare metal and the metal should be quite "beefy". From my stand point, the characteristics of the infrastructure is part of the documentation for constructing a build farm, isn't it? As an aside, I think that you can set up a build farm on a no trivially configured virtual machine, e.g. multi-core assignment, &c, which result in having a "beefy" host and that is equivalent to having a "beefy" metal... -- Peter From maciej at opencsw.org Mon Sep 23 18:49:18 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 23 Sep 2013 17:49:18 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/23 Peter FELECAN > From > my stand point, the characteristics of the infrastructure is part of the > documentation for constructing a build farm, isn't it? Right, and the characteristics are: 1-1.5 GB RAM and 1 core. :) That's what I have at home for a VM and I think it's a reasonable general expectation, don't you agree? From maciej at opencsw.org Tue Sep 24 08:12:55 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Sep 2013 07:12:55 +0100 Subject: [csw-maintainers] Buildfarm setup - documentation Message-ID: Peter Felecan asked about buildfarm setup documentation. I've written about this topic some time ago: http://lists.opencsw.org/pipermail/maintainers/2013-April/017968.html We also talked about consolidating the documentation: Taking one topic, moving all the information in one place and killing all the other places. Let's take buildfarm setup as the first topic. Right now this topic is covered in a number of places: http://sourceforge.net/apps/trac/gar/wiki/GarSetup http://www.opencsw.org/manual/for-maintainers/buildfarm-setup.html http://wiki.opencsw.org/buildfarm http://wiki.opencsw.org/checkpkg#toc4 (old code) http://wiki.opencsw.org/checkpkg#toc25 (new code) What would be the best location for this documentation? Maciej From pfelecan at opencsw.org Tue Sep 24 09:08:04 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 24 Sep 2013 09:08:04 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Mon, 23 Sep 2013 17:49:18 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/23 Peter FELECAN >> From >> my stand point, the characteristics of the infrastructure is part of the >> documentation for constructing a build farm, isn't it? > > Right, and the characteristics are: 1-1.5 GB RAM and 1 core. :) > > That's what I have at home for a VM and I think it's a reasonable > general expectation, don't you agree? I agree with whatever you have empirically determined. However, it contradicts your previous statement about the need of a "beefy" infrastructure. -- Peter From pfelecan at opencsw.org Tue Sep 24 09:09:19 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 24 Sep 2013 09:09:19 +0200 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 24 Sep 2013 07:12:55 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > Peter Felecan asked about buildfarm setup documentation. I've written > about this topic some time ago: > > http://lists.opencsw.org/pipermail/maintainers/2013-April/017968.html > > We also talked about consolidating the documentation: Taking one > topic, moving all the information in one place and killing all the > other places. > > Let's take buildfarm setup as the first topic. Right now this topic is > covered in a number of places: > > http://sourceforge.net/apps/trac/gar/wiki/GarSetup > http://www.opencsw.org/manual/for-maintainers/buildfarm-setup.html > http://wiki.opencsw.org/buildfarm > http://wiki.opencsw.org/checkpkg#toc4 (old code) > http://wiki.opencsw.org/checkpkg#toc25 (new code) > > What would be the best location for this documentation? This: http://www.opencsw.org/manual/for-maintainers/buildfarm-setup.html -- Peter From maciej at opencsw.org Tue Sep 24 09:14:31 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Sep 2013 08:14:31 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/24 Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: > >> 2013/9/23 Peter FELECAN >>> From >>> my stand point, the characteristics of the infrastructure is part of the >>> documentation for constructing a build farm, isn't it? >> >> Right, and the characteristics are: 1-1.5 GB RAM and 1 core. :) >> >> That's what I have at home for a VM and I think it's a reasonable >> general expectation, don't you agree? > > I agree with whatever you have empirically determined. However, it > contradicts your previous statement about the need of a "beefy" > infrastructure. No, I work on this the other way around: I have at home what I have. The buildfarm infrastructure has to run on that. It's the code that doesn't meet the spec, not the hardware. Maciej From pfelecan at opencsw.org Tue Sep 24 09:24:33 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 24 Sep 2013 09:24:33 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 24 Sep 2013 08:14:31 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/24 Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >> >>> 2013/9/23 Peter FELECAN >>>> From >>>> my stand point, the characteristics of the infrastructure is part of the >>>> documentation for constructing a build farm, isn't it? >>> >>> Right, and the characteristics are: 1-1.5 GB RAM and 1 core. :) >>> >>> That's what I have at home for a VM and I think it's a reasonable >>> general expectation, don't you agree? >> >> I agree with whatever you have empirically determined. However, it >> contradicts your previous statement about the need of a "beefy" >> infrastructure. > > No, I work on this the other way around: I have at home what I have. > The buildfarm infrastructure has to run on that. It's the code that > doesn't meet the spec, not the hardware. Alright. But, at least for me, the specifications that you considered were opaque. If it's 1Gb of memory and 1 core virtualized then good luck; I'm not saying that it is not possible to optimize for that, what I'm thinking and say now is that for the moment, documentation wise, we should give the current specs of the only working build farm. When the optimization lowers the bar, the documentation can be changed. -- Peter From maciej at opencsw.org Tue Sep 24 09:44:25 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Sep 2013 08:44:25 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/24 Peter FELECAN : > Alright. But, at least for me, the specifications that you considered > were opaque. If it's 1Gb of memory and 1 core virtualized then good > luck; I'm not saying that it is not possible to optimize for that, what > I'm thinking and say now is that for the moment, documentation wise, we > should give the current specs of the only working build farm. When the > optimization lowers the bar, the documentation can be changed. OK, makes sense. Unfortunately I don't know the current requirements, I don't own a spare machine large enough to actually run the current code. With a lot of RAM (32GB?) it should run in one go, with less RAM it will run out of memory and you'll have to restart the process a couple times until it finishes. I've listed all the locations to consolidate. All the information is available already, it's a matter or rewriting the setup howto and running it to verify that the instructions are actually correct. Is anyone up for doing that? Maciej From pfelecan at opencsw.org Tue Sep 24 10:11:20 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 24 Sep 2013 10:11:20 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 24 Sep 2013 08:44:25 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/24 Peter FELECAN : >> Alright. But, at least for me, the specifications that you considered >> were opaque. If it's 1Gb of memory and 1 core virtualized then good >> luck; I'm not saying that it is not possible to optimize for that, what >> I'm thinking and say now is that for the moment, documentation wise, we >> should give the current specs of the only working build farm. When the >> optimization lowers the bar, the documentation can be changed. > > OK, makes sense. Unfortunately I don't know the current requirements, > I don't own a spare machine large enough to actually run the current > code. With a lot of RAM (32GB?) it should run in one go, with less RAM > it will run out of memory and you'll have to restart the process a > couple times until it finishes. > > I've listed all the locations to consolidate. All the information is > available already, it's a matter or rewriting the setup howto and > running it to verify that the instructions are actually correct. Is > anyone up for doing that? As I wrote in the beginning of the summer, I'm voluntary to test/verify the build farm construction documentation. For the time being, I have only an x86 with 8Gb; unfortunately that is the maximum that the mother board supports :-( but the processor is a quad core Xenon. IMHO the writer/consolidator of the documentation should be another person. Do you think that you can do it? -- Peter From maciej at opencsw.org Tue Sep 24 10:23:41 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Sep 2013 09:23:41 +0100 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: References: Message-ID: 2013/9/24 Peter FELECAN > > IMHO the writer/consolidator of the documentation should be another > person. Do you think that you can do it? Wouldn't that be the game of Chinese whispers? The person who runs the setup finds bugs in the documentation and finds workarounds, has first-hand knowledge how to do it. It would be silly to write through somebody else. Maciej From pfelecan at opencsw.org Tue Sep 24 10:52:59 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 24 Sep 2013 10:52:59 +0200 Subject: [csw-maintainers] Evaluating Gentoo Prefix In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 24 Sep 2013 09:23:41 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/24 Peter FELECAN >> >> IMHO the writer/consolidator of the documentation should be another >> person. Do you think that you can do it? > > Wouldn't that be the game of Chinese whispers? The person who runs the > setup finds bugs in the documentation and finds workarounds, has > first-hand knowledge how to do it. It would be silly to write through > somebody else. What I mean is the initial writing/consolidation. The adaptations/corrections/modifications are done by the verifiers. It's a collaborative project, isn't it? i.e. you do that, I'm doing this. You should visualize the initial process as the specifications... -- Peter From maciej at opencsw.org Tue Sep 24 11:15:47 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Sep 2013 10:15:47 +0100 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: References: Message-ID: 2013/9/24 Peter FELECAN : > What I mean is the initial writing/consolidation. The > adaptations/corrections/modifications are done by the verifiers. It's a > collaborative project, isn't it? i.e. you do that, I'm doing this. You > should visualize the initial process as the specifications... Fair enough. I won't be entirely sure of the ordering of things. For starters I'll simply move all the text blobs to the manual. Maciej From pfelecan at opencsw.org Tue Sep 24 11:24:08 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 24 Sep 2013 11:24:08 +0200 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 24 Sep 2013 10:15:47 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/24 Peter FELECAN : >> What I mean is the initial writing/consolidation. The >> adaptations/corrections/modifications are done by the verifiers. It's a >> collaborative project, isn't it? i.e. you do that, I'm doing this. You >> should visualize the initial process as the specifications... > > Fair enough. I won't be entirely sure of the ordering of things. For > starters I'll simply move all the text blobs to the manual. Great. Let me know when you think that I can start the verification. -- Peter From maciej at opencsw.org Wed Sep 25 14:29:59 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 25 Sep 2013 13:29:59 +0100 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: References: Message-ID: 2013/9/24 Peter FELECAN > Great. Let me know when you think that I can start the verification. I've already started, but it will require some time to complete. Be aware that the length of the howto will be substantial. You'll see a scary wall of text. Maciej From pfelecan at opencsw.org Wed Sep 25 16:19:47 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 25 Sep 2013 16:19:47 +0200 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 25 Sep 2013 13:29:59 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/24 Peter FELECAN >> Great. Let me know when you think that I can start the verification. > > I've already started, but it will require some time to complete. Be > aware that the length of the howto will be substantial. You'll see a > scary wall of text. Good. Walls never scared me. More detailed the documentation, better the chance to succeed. -- Peter From maciej at opencsw.org Thu Sep 26 01:12:21 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 26 Sep 2013 00:12:21 +0100 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: References: Message-ID: 2013/9/25 Peter FELECAN > Good. Walls never scared me. More detailed the documentation, better the > chance to succeed. Done! http://www.opencsw.org/manual/for-maintainers/buildfarm-setup.html This is just the moved content from other locations into one place, I did very little changes to the text. There can still be some outdated text there. The file to edit is this one: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/opencsw-manual/trunk/files/for-maintainers/buildfarm-setup.rst Maciej From pfelecan at opencsw.org Thu Sep 26 17:23:12 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 26 Sep 2013 17:23:12 +0200 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? Message-ID: I'm encountering an issue with web enabled Python application which use mod_wsgi and, indirectly, mod_python. The application in question supports only Python interpreters >= 2.7. Our current and related Apache modules are built with Python 2.6. Reading the documentation, there is no way to change the interpreter used by those Apache modules by configuration. Consequently, I'm looking in a correct way to build dual Apache modules, i.e. which support 2.6 and 2.7 Python interpreters. Any thoughts, suggestions, ideas, &c? -- Peter From maciej at opencsw.org Thu Sep 26 17:58:08 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 26 Sep 2013 16:58:08 +0100 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: References: Message-ID: 2013/9/26 Peter FELECAN > > Consequently, I'm looking in a correct way to build dual Apache modules, > i.e. which support 2.6 and 2.7 Python interpreters. > > Any thoughts, suggestions, ideas, &c? In general, we can drop mod_python, it's a thing of the past. As far as building, can we use alternatives, or create two incompatible packages? Maciej From pfelecan at opencsw.org Thu Sep 26 18:26:18 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 26 Sep 2013 18:26:18 +0200 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 26 Sep 2013 16:58:08 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/26 Peter FELECAN >> >> Consequently, I'm looking in a correct way to build dual Apache modules, >> i.e. which support 2.6 and 2.7 Python interpreters. >> >> Any thoughts, suggestions, ideas, &c? > > In general, we can drop mod_python, it's a thing of the past. Can you explain? Am I wrong that trac uses mod_python? > As far as building, can we use alternatives, or create two > incompatible packages? You mean for mod_wsgi? What's your preference? -- Peter From maciej at opencsw.org Thu Sep 26 18:33:08 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 26 Sep 2013 17:33:08 +0100 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: References: Message-ID: 2013/9/26 Peter FELECAN : >> In general, we can drop mod_python, it's a thing of the past. > > Can you explain? Am I wrong that trac uses mod_python? Web apps can have bindings for more than 1 interface. But mod_python is obsolete for many years now. All python web apps support wsgi now. Trac does too: http://trac.edgewall.org/wiki/TracModWSGI >> As far as building, can we use alternatives, or create two >> incompatible packages? > > You mean for mod_wsgi? What's your preference? Yes, we should build mod_wsgi and drop mod_python entirely. I'm thinking we could have 1 package for 2.6 mod_wsgi and 1 package for 2.7 mod_wsgi, the two packages incompatible with each other, since you can only load one at a time. Or use alternatives ? whichever options looks better to you. Maciej From pfelecan at opencsw.org Thu Sep 26 18:37:21 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 26 Sep 2013 18:37:21 +0200 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Thu, 26 Sep 2013 17:33:08 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/26 Peter FELECAN : >>> In general, we can drop mod_python, it's a thing of the past. >> >> Can you explain? Am I wrong that trac uses mod_python? > > Web apps can have bindings for more than 1 interface. But mod_python > is obsolete for many years now. All python web apps support wsgi now. > Trac does too: http://trac.edgewall.org/wiki/TracModWSGI Thank you. >>> As far as building, can we use alternatives, or create two >>> incompatible packages? >> >> You mean for mod_wsgi? What's your preference? > > Yes, we should build mod_wsgi and drop mod_python entirely. I'm > thinking we could have 1 package for 2.6 mod_wsgi and 1 package for > 2.7 mod_wsgi, the two packages incompatible with each other, since you > can only load one at a time. > > Or use alternatives ? whichever options looks better to you. I let the primacy to Dagobert, who's the maintainer, but I have the feeling that he will ask me to do it. Am I wrong? -- Peter From dam at opencsw.org Thu Sep 26 20:02:23 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 26 Sep 2013 20:02:23 +0200 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: References: Message-ID: Hi Peter, Am 26.09.2013 um 18:37 schrieb Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: >>>> As far as building, can we use alternatives, or create two >>>> incompatible packages? >>> >>> You mean for mod_wsgi? What's your preference? >> >> Yes, we should build mod_wsgi and drop mod_python entirely. I'm >> thinking we could have 1 package for 2.6 mod_wsgi and 1 package for >> 2.7 mod_wsgi, the two packages incompatible with each other, since you >> can only load one at a time. >> >> Or use alternatives ? whichever options looks better to you. > > I let the primacy to Dagobert, who's the maintainer, Whom? Me?? I can't remember! > but I have the > feeling that he will ask me to do it. Am I wrong? You are of course right ;-) I tend to favor alternatives with clearly just one of the packages installed, but "I" packages are somewhat bad when you try to just install everything. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From pfelecan at opencsw.org Thu Sep 26 22:07:16 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 26 Sep 2013 22:07:16 +0200 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: (Dagobert Michelsen's message of "Thu, 26 Sep 2013 20:02:23 +0200") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 26.09.2013 um 18:37 schrieb Peter FELECAN : >> "Maciej (Matchek) Blizi?ski" writes: >>>>> As far as building, can we use alternatives, or create two >>>>> incompatible packages? >>>> >>>> You mean for mod_wsgi? What's your preference? >>> >>> Yes, we should build mod_wsgi and drop mod_python entirely. I'm >>> thinking we could have 1 package for 2.6 mod_wsgi and 1 package for >>> 2.7 mod_wsgi, the two packages incompatible with each other, since you >>> can only load one at a time. >>> >>> Or use alternatives ? whichever options looks better to you. >> >> I let the primacy to Dagobert, who's the maintainer, > > Whom? Me?? I can't remember! Sorry. I missread. It's Ruppert the one who maintains it. >> but I have the >> feeling that he will ask me to do it. Am I wrong? > > You are of course right ;-) I tend to favor alternatives with clearly just > one of the packages installed, but "I" packages are somewhat bad when you > try to just install everything. I agree that alternatives is a better solution. Let hear from Ruppert... -- Peter From maciej at opencsw.org Fri Sep 27 10:45:59 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Sep 2013 09:45:59 +0100 Subject: [csw-maintainers] Buildfarm setup - documentation In-Reply-To: References: Message-ID: 2013/9/24 Peter FELECAN : > Great. Let me know when you think that I can start the verification. I've made some additional changes, I added information about the web app and the location of catalog generation scripts. The buildfarm setup document is far from done: - lot of optional stuff - redundancy - no notion of subsets of things you want to install: mgar? mgar+checkpkg? mgar+checkpkg+compilers? mgar+checkpkg+generation? mgar+checkpkg+generation+signing? - ordering is probably wrong - in many places there's just a textual description of what you're supposed to do, but no copy-pastable lines to execute; existing descriptions can be vague in places - I'm not entirely sure it's complete, there still can be something missing. I just added the missing information about the web apps. I think it will resemble rewriting more than verification. For the new code, we have this: http://wiki.opencsw.org/checkpkg#toc20 This is an actively maintained (by me) howto on setting up the buildfarm database using the new code. Maciej From dam at opencsw.org Fri Sep 27 12:51:53 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Sep 2013 12:51:53 +0200 Subject: [csw-maintainers] Question regarding Python and magic Message-ID: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Hi, when respinning gnu file I get the following checkpkg error: CHECKPKG_OVERRIDES_CSWpy-libmagic += file-collision|/opt/csw/lib/python2.6/site-packages/magic.py|CSWpy-libmagic|CSWpy-magic And indeed both packages contain the file, CSWpy-magic is from Maciej with a different version and pulled form github, CSWpy-libmagic is from me and packages as part of GNU file. Should I drop CSWpy-magic or how do we proceed here? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From schwindt at dfki.uni-kl.de Fri Sep 27 15:32:21 2013 From: schwindt at dfki.uni-kl.de (Nicolai Schwindt) Date: Fri, 27 Sep 2013 15:32:21 +0200 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: References: Message-ID: <20130927153221.00005646@isg-1505> On Thu, 26 Sep 2013 17:23:12 +0200 Peter FELECAN wrote: > I'm encountering an issue with web enabled Python application which use > mod_wsgi and, indirectly, mod_python. > > The application in question supports only Python interpreters >= 2.7. > > Our current and related Apache modules are built with Python 2.6. > > Reading the documentation, there is no way to change the interpreter > used by those Apache modules by configuration. As I had the problem that python was no longer found after I did a full upgrade yesterday , I endet up adding this to /etc/opt/csw/init.d/cswapache2 : [...] PYTHONEXECUTABLE=/opt/csw/bin/python PYTHONHOME=/opt/csw/ export PYTHONEXECUTABLE export PYTHONHOME [...] The errors which showed up : [Thu Sep 26 00:00:04 2013] [error] make_obcallback: could not import mod_python.apache.\n ImportError: No module named mod_python.apache [Thu Sep 26 00:00:04 2013] [error] make_obcallback: Python path being used "['/usr/lib/python26.zi p', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-sunos5', '/usr/lib/python2.6/lib-tk', '/usr/lib /python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/site-packages', '/usr/l ib/python2.6/vendor-packages']". [Thu Sep 26 00:00:04 2013] [error] get_interpreter: no interpreter callback found. [Thu Sep 26 00:00:04 2013] [error] [client 24.86.245.198] python_handler: Can't get/create interpr eter. I am still looking into it, I do not have any clue what has happened. > Consequently, I'm looking in a correct way to build dual Apache modules, > i.e. which support 2.6 and 2.7 Python interpreters. > > Any thoughts, suggestions, ideas, &c? May be this can help choose the interpreter ? BTW: mod_python is again under active development -- MfG, Nicolai Schwindt From maciej at opencsw.org Fri Sep 27 17:07:51 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Sep 2013 16:07:51 +0100 Subject: [csw-maintainers] how to make mod_wsgi, mod_python dual ? In-Reply-To: <20130927153221.00005646@isg-1505> References: <20130927153221.00005646@isg-1505> Message-ID: 2013/9/27 Nicolai Schwindt : > The errors which showed up : > > [Thu Sep 26 00:00:04 2013] [error] make_obcallback: could not import > mod_python.apache.\n ImportError: No module named mod_python.apache > [Thu Sep 26 00:00:04 2013] [error] make_obcallback: Python path being used > "['/usr/lib/python26.zi p', '/usr/lib/python2.6', > '/usr/lib/python2.6/plat-sunos5', '/usr/lib/python2.6/lib-tk', > '/usr/lib /python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', > '/usr/lib/python2.6/site-packages', '/usr/l ib/python2.6/vendor-packages']". > [Thu Sep 26 00:00:04 2013] [error] get_interpreter: no interpreter callback > found. [Thu Sep 26 00:00:04 2013] [error] [client 24.86.245.198] > python_handler: Can't get/create interpr eter. > > I am still looking into it, I do not have any clue what has happened. /opt/csw/lib/python2.6 is not on the search list. Are you sure that the executed python is the one from /opt/csw/bin and not from /usr/bin? Maciej From maciej at opencsw.org Fri Sep 27 18:56:17 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Sep 2013 17:56:17 +0100 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: 2013/9/27 Dagobert Michelsen : > Should I drop CSWpy-magic or how do we proceed here? Let's use the one from libmagic sources. The caveat is that it will be fiddly to make it 2.6+2.7 compatible. We'll need an additional modulator on the Python version. Maciej From pfelecan at opencsw.org Fri Sep 27 19:01:01 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 27 Sep 2013 19:01:01 +0200 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 27 Sep 2013 17:56:17 +0100") References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/27 Dagobert Michelsen : >> Should I drop CSWpy-magic or how do we proceed here? > > Let's use the one from libmagic sources. The caveat is that it will be > fiddly to make it 2.6+2.7 compatible. We'll need an additional > modulator on the Python version. Why is that necessary? Do you care to explain? TIA -- Peter From maciej at opencsw.org Fri Sep 27 19:11:52 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Sep 2013 18:11:52 +0100 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: 2013/9/27 Peter FELECAN : >> Let's use the one from libmagic sources. The caveat is that it will be >> fiddly to make it 2.6+2.7 compatible. We'll need an additional >> modulator on the Python version. > > Why is that necessary? Do you care to explain? TIA It's the same thing that we're already doing for the 'python' category. https://github.com/opencsw/gar/blob/master/categories/python/category.mk#L44 _CATEGORY_MODULATORS ?= PYTHON_VERSION MODULATIONS_PYTHON_VERSION ?= 2_6 2_7 MERGE_SCRIPTS_isa-default-python_version-2_6 ?= copy-all MERGE_SCRIPTS_isa-default-python_version-2_7 ?= copy-all The problem is that the libmagic build recipe is not of 'python' category and therefore does not receive the 2.6+2.7 settings. Maciej From pfelecan at opencsw.org Fri Sep 27 19:28:14 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 27 Sep 2013 19:28:14 +0200 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 27 Sep 2013 18:11:52 +0100") References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/27 Peter FELECAN : >>> Let's use the one from libmagic sources. The caveat is that it will be >>> fiddly to make it 2.6+2.7 compatible. We'll need an additional >>> modulator on the Python version. >> >> Why is that necessary? Do you care to explain? TIA > > It's the same thing that we're already doing for the 'python' category. > > https://github.com/opencsw/gar/blob/master/categories/python/category.mk#L44 > > _CATEGORY_MODULATORS ?= PYTHON_VERSION > MODULATIONS_PYTHON_VERSION ?= 2_6 2_7 > MERGE_SCRIPTS_isa-default-python_version-2_6 ?= copy-all > MERGE_SCRIPTS_isa-default-python_version-2_7 ?= copy-all > > The problem is that the libmagic build recipe is not of 'python' > category and therefore does not receive the 2.6+2.7 settings. If I'm understanding the issue, libmagic provides the conflicting file and py_magic use the one provided by libmagic in whatever target interpreter. Why do you need an additional modulator for such a thing? -- Peter From maciej at opencsw.org Fri Sep 27 23:27:56 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 27 Sep 2013 22:27:56 +0100 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: 2013/9/27 Peter FELECAN : > If I'm understanding the issue, libmagic provides the conflicting file > and py_magic use the one provided by libmagic in whatever target > interpreter. Why do you need an additional modulator for such a thing? I'm not sure I understand what you're asking. Do we need a modulator to build a dual 2.6/2.7 package? Yes, we do. From pfelecan at opencsw.org Sat Sep 28 10:29:35 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 28 Sep 2013 10:29:35 +0200 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Fri, 27 Sep 2013 22:27:56 +0100") References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/27 Peter FELECAN : >> If I'm understanding the issue, libmagic provides the conflicting file >> and py_magic use the one provided by libmagic in whatever target >> interpreter. Why do you need an additional modulator for such a thing? > > I'm not sure I understand what you're asking. Do we need a modulator > to build a dual 2.6/2.7 package? Yes, we do. It's your initial affirmation: > Let's use the one from libmagic sources. The caveat is that it will be > fiddly to make it 2.6+2.7 compatible. We'll need an additional > modulator on the Python version. When you affirmed this we already had modulators for different interpreter versions. My question was and is: what additional modulator and why an additional modulator, aside the existing ones. -- Peter From maciej at opencsw.org Sat Sep 28 12:18:14 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 28 Sep 2013 11:18:14 +0100 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: 2013/9/28 Peter FELECAN : > It's your initial affirmation: > >> Let's use the one from libmagic sources. The caveat is that it will be >> fiddly to make it 2.6+2.7 compatible. We'll need an additional >> modulator on the Python version. > > When you affirmed this we already had modulators for different > interpreter versions. I don't see them. This is the build recipe: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/file/trunk/Makefile In which line are the modulators? > My question was and is: what additional modulator > and why an additional modulator, aside the existing ones. I don't see any modulator in the recipe. Which recipe are you talking about? Maciej From pfelecan at opencsw.org Sat Sep 28 12:24:59 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 28 Sep 2013 12:24:59 +0200 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 28 Sep 2013 11:18:14 +0100") References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/9/28 Peter FELECAN : >> It's your initial affirmation: >> >>> Let's use the one from libmagic sources. The caveat is that it will be >>> fiddly to make it 2.6+2.7 compatible. We'll need an additional >>> modulator on the Python version. >> >> When you affirmed this we already had modulators for different >> interpreter versions. > > I don't see them. This is the build recipe: > https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/file/trunk/Makefile > > In which line are the modulators? > >> My question was and is: what additional modulator >> and why an additional modulator, aside the existing ones. > > I don't see any modulator in the recipe. Which recipe are you talking about? Alright. I'm writing about the generic modulators for Python 2.x, you are writing about the "file" package modulation. You and me not sharing monads... -- Peter From maciej at opencsw.org Sat Sep 28 18:08:56 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 28 Sep 2013 17:08:56 +0100 Subject: [csw-maintainers] Question regarding Python and magic In-Reply-To: References: <41B6A6A0-ABA7-46BB-919B-E8111000B17F@opencsw.org> Message-ID: 2013/9/28 Peter FELECAN > Alright. I'm writing about the generic modulators for Python 2.x, you > are writing about the "file" package modulation. You and me not sharing > monads... Apparently not. :( I think we should use the code from libmagic, but libmagic is not a "CATEGORIES = python" build, which means it's not using the generic Python modulator. Therefore, if we want CSWpy-libmagic to be available for both 2.6 and 2.7, we need to add a modulator to the [1] build recipe. This is what I was trying to say at [2]. [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/file/trunk/Makefile [2] http://lists.opencsw.org/pipermail/maintainers/2013-September/018632.html Maciej From jh at opencsw.org Mon Sep 30 09:30:48 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 30 Sep 2013 09:30:48 +0200 Subject: [csw-maintainers] Cataloge Sign Message-ID: <524928A8.40701@opencsw.org> Hi, it stopped again :) Greetings Jan From maciej at opencsw.org Mon Sep 30 09:35:27 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 30 Sep 2013 08:35:27 +0100 Subject: [csw-maintainers] Cataloge Sign In-Reply-To: <524928A8.40701@opencsw.org> References: <524928A8.40701@opencsw.org> Message-ID: 2013/9/30 Jan Holzhueter > > Hi, > it stopped again :) Can we have the alert reconfigured to notify only the people who can do something about it? Maciej From dam at opencsw.org Mon Sep 30 09:37:57 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 30 Sep 2013 09:37:57 +0200 Subject: [csw-maintainers] Cataloge Sign In-Reply-To: References: <524928A8.40701@opencsw.org> Message-ID: <11C357F4-CAB3-4370-B8DC-45A4F8104C8D@opencsw.org> Hi Maciej, Am 30.09.2013 um 09:35 schrieb Maciej (Matchek) Blizi?ski : > 2013/9/30 Jan Holzhueter >> it stopped again :) > > Can we have the alert reconfigured to notify only the people who can > do something about it? Yes. Plus, the monitoring did not report about failing to sign, but again that the catalog on the primary mirror gets stale. I would like to enhance this. Did it expire? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2351 bytes Desc: not available URL: From maciej at opencsw.org Mon Sep 30 09:50:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 30 Sep 2013 08:50:23 +0100 Subject: [csw-maintainers] Cataloge Sign In-Reply-To: <11C357F4-CAB3-4370-B8DC-45A4F8104C8D@opencsw.org> References: <524928A8.40701@opencsw.org> <11C357F4-CAB3-4370-B8DC-45A4F8104C8D@opencsw.org> Message-ID: 2013/9/30 Dagobert Michelsen : > Yes. Plus, the monitoring did not report about failing to sign, but again > that the catalog on the primary mirror gets stale. I would like to enhance > this. Did it expire? No, it's still running. From jh at opencsw.org Mon Sep 30 09:57:07 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 30 Sep 2013 09:57:07 +0200 Subject: [csw-maintainers] Cataloge Sign In-Reply-To: References: <524928A8.40701@opencsw.org> <11C357F4-CAB3-4370-B8DC-45A4F8104C8D@opencsw.org> Message-ID: <52492ED3.5080607@opencsw.org> Hi, Am 30.09.13 09:50, schrieb Maciej (Matchek) Blizi?ski: > 2013/9/30 Dagobert Michelsen : >> Yes. Plus, the monitoring did not report about failing to sign, but again >> that the catalog on the primary mirror gets stale. I would like to enhance >> this. Did it expire? > > No, it's still running. was a diffrend failor this time :) Sorry for the noise. The process was just still running for some reason. I killed it and will run it know to see if anything is wrong. Greetings Jan