From maciej at opencsw.org Mon Apr 1 00:28:23 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 31 Mar 2013 23:28:23 +0100 Subject: [csw-maintainers] I'm currently breaking things on the buildfarm In-Reply-To: References: Message-ID: 2013/3/31 Yann Rouillard : > I don't know it this is related but I am currently having the following > error message when trying upload: I'm currently working on this. From maciej at opencsw.org Mon Apr 1 00:35:26 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 31 Mar 2013 23:35:26 +0100 Subject: [csw-maintainers] I'm currently breaking things on the buildfarm In-Reply-To: References: Message-ID: 2013/3/31 Maciej (Matchek) Blizi?ski : > 2013/3/31 Yann Rouillard : >> I don't know it this is related but I am currently having the following >> error message when trying upload: > > I'm currently working on this. Solved: https://sourceforge.net/apps/trac/gar/changeset/20556 As a bonus, it's better from the security standpoint. Maciej From maciej at opencsw.org Mon Apr 1 18:59:56 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 1 Apr 2013 17:59:56 +0100 Subject: [csw-maintainers] The statistics page is missing latest data Message-ID: http://www.opencsw.org/get-it/package-statistics/ It only shows data until November 2012. Does anyone know what could be the problem? From maciej at opencsw.org Tue Apr 2 19:38:52 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 2 Apr 2013 18:38:52 +0100 Subject: [csw-maintainers] Symbols information and checkpkg database In-Reply-To: References: Message-ID: 2013/3/29 Maciej (Matchek) Blizi?ski : > 1. Drop the automatic mode (...) TL;DR I'm going to rip out the automatic checkpkg setup code, unless somebody stops me. If you think it's a bad idea speak now or forever hold your peace. From dam at opencsw.org Tue Apr 2 19:46:14 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 2 Apr 2013 19:46:14 +0200 Subject: [csw-maintainers] Bugs for dbus gone? References: Message-ID: <52843C2B-7C7C-413B-9D29-355D1D665E10@opencsw.org> Hi, from the package page for dbus http://www.opencsw.org/packages/CSWdbus/ the page for the bugs seems to have gone: http://www.opencsw.org/mantis/set_project.php?project_id=1555 Does anyone have an idea how this could have happened? Ben probably? 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 pfelecan at opencsw.org Tue Apr 2 19:46:48 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 02 Apr 2013 19:46:48 +0200 Subject: [csw-maintainers] Symbols information and checkpkg database In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 2 Apr 2013 18:38:52 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/3/29 Maciej (Matchek) Blizi?ski : >> 1. Drop the automatic mode (...) > > TL;DR I'm going to rip out the automatic checkpkg setup code, unless > somebody stops me. > > If you think it's a bad idea speak now or forever hold your peace. If this precludes the usage of the tool outside of the current build-farm I'm speaking up my war opposition... -- Peter From maciej at opencsw.org Tue Apr 2 20:44:42 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 2 Apr 2013 19:44:42 +0100 Subject: [csw-maintainers] Symbols information and checkpkg database In-Reply-To: References: Message-ID: 2013/4/2 Peter FELECAN : > If this precludes the usage of the tool outside of the current > build-farm I'm speaking up my war opposition... It allows you to use it outside the buildfarm, but it forces you to set up it the same way, meaning you need to run pkgdb system-files-to-file, pkgdb import-system-file and pkgdb sync-catalogs-from-tree. Your buildfarm was set up this way I think, is that correct? The new required piece will be the requirement to configure a web server to run the REST API. I plan to gradually move all the tool-to-db interaction off the database driver and into HTTP. Maciej From bwalton at opencsw.org Tue Apr 2 20:47:16 2013 From: bwalton at opencsw.org (Ben Walton) Date: Tue, 2 Apr 2013 19:47:16 +0100 Subject: [csw-maintainers] Bugs for dbus gone? In-Reply-To: References: Message-ID: The automated db maintenance may have marked a dbus package as retired which would hide the bugs (it never touched the bugs themselves) or if there was renaming, they may just be on a different project in mantis now? I'll try to look tonight but my in laws are visiting so I may not get to it. Thanks -Ben On Apr 2, 2013 6:45 PM, "Dagobert Michelsen" wrote: > Hi, > > from the package page for dbus > http://www.opencsw.org/packages/CSWdbus/ > the page for the bugs seems to have gone: > http://www.opencsw.org/mantis/set_project.php?project_id=1555 > > Does anyone have an idea how this could have happened? > > Ben probably? > > > Best regards > > -- Dago > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Apr 2 20:49:37 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 2 Apr 2013 19:49:37 +0100 Subject: [csw-maintainers] Small pkgdb-web prettification Message-ID: I tend to not put too much effort into the looks of database tools, but over the holidays I improved the layout of two URLs in the web app: http://buildfarm.opencsw.org/pkgdb/catalognames/ - alphabetical index on top http://buildfarm.opencsw.org/pkgdb/catalogs/ - displaying catalogs in a table Maciej From bonivart at opencsw.org Tue Apr 2 21:06:32 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Tue, 2 Apr 2013 21:06:32 +0200 Subject: [csw-maintainers] Small pkgdb-web prettification In-Reply-To: References: Message-ID: On Tue, Apr 2, 2013 at 8:49 PM, Maciej (Matchek) Blizi?ski wrote: > I tend to not put too much effort into the looks of database tools, > but over the holidays I improved the layout of two URLs in the web > app: > > http://buildfarm.opencsw.org/pkgdb/catalognames/ - alphabetical index on top > http://buildfarm.opencsw.org/pkgdb/catalogs/ - displaying catalogs in a table Very nice! From pfelecan at opencsw.org Wed Apr 3 20:12:41 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 03 Apr 2013 20:12:41 +0200 Subject: [csw-maintainers] Symbols information and checkpkg database In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 2 Apr 2013 19:44:42 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/4/2 Peter FELECAN : >> If this precludes the usage of the tool outside of the current >> build-farm I'm speaking up my war opposition... > > It allows you to use it outside the buildfarm, but it forces you to > set up it the same way, meaning you need to run pkgdb > system-files-to-file, pkgdb import-system-file and pkgdb > sync-catalogs-from-tree. Your buildfarm was set up this way I think, > is that correct? > > The new required piece will be the requirement to configure a web > server to run the REST API. I plan to gradually move all the > tool-to-db interaction off the database driver and into HTTP. All this is alright for me. Thank you. -- Peter From pfelecan at opencsw.org Wed Apr 3 20:17:55 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 03 Apr 2013 20:17:55 +0200 Subject: [csw-maintainers] Small pkgdb-web prettification In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Tue, 2 Apr 2013 19:49:37 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > I tend to not put too much effort into the looks of database tools, > but over the holidays I improved the layout of two URLs in the web > app: > > http://buildfarm.opencsw.org/pkgdb/catalognames/ - alphabetical index on top > http://buildfarm.opencsw.org/pkgdb/catalogs/ - displaying catalogs in a table Quite useful. However, link the package to the description otherwise you have a cycle... e.g. http://buildfarm.opencsw.org/pkgdb/catalognames/a2ps/ to http://buildfarm.opencsw.org/pkgdb/srv4/0081cafba415a45801d8191ebdbfee56/ to http://buildfarm.opencsw.org/pkgdb/catalognames/a2ps/ Also, back-links would be useful. Hope that I'm clear :-( -- Peter From grzemba at contac-dt.de Thu Apr 4 09:55:04 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Thu, 04 Apr 2013 09:55:04 +0200 Subject: [csw-maintainers] opencsw QT 4 & 5 In-Reply-To: References: Message-ID: Peter, the QT 4.8.1 builds now (takes some hours). I had a bug in the XSHAPE patch. Without the gxx path it conflicts with CSWqt package (Qt3). The only package witch has Qt3 dependency is CSWsip which seams to be unmaintained (?). So I guess we can obsoleting the CSWqt package by CSWqt4? Thoughts? Am 01.04.13 schrieb Peter FELECAN : > Carsten, > > As I wrote about Qt on Mantis, in my opinion, there is no need to have a > specific "gxx" set of package. > > You certainly noticed that I made 2 modifications to the current recipe > in order to have a non-interactive configure phase and to use the > current master site for the open-sourced version instead of Nokia's one > which is now obsolete. > > Trying to build the current package set I encountered issues around > QT_NO_SHAPE, in src/gui/kernel/qdnd_x11.cpp, specifically the definition > of ShapeBounding variable, in line 1471. I didn't have the time to > diagnose this for the moment. > > If you don't have the required time and you agree, I can explore 2 axes: > > 1. Try Qt 4.8.4 as it's the latest release in the 4 series > 2. Try Qt 5.0.1 as it's the last stable > > I will do this on 2 separate branches with slightly modified recipes. > > What do you think? > -- > Peter FELECAN > mailto:peter at felecan.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Apr 4 11:19:08 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 4 Apr 2013 10:19:08 +0100 Subject: [csw-maintainers] opencsw QT 4 & 5 In-Reply-To: References: Message-ID: 2013/4/4 Carsten Grzemba : > the QT 4.8.1 builds now (takes some hours). I had a bug in the XSHAPE patch. > Without the gxx path it conflicts with CSWqt package (Qt3). The only package > witch has Qt3 dependency is CSWsip which seams to be unmaintained (?). > So I guess we can obsoleting the CSWqt package by CSWqt4? I dropped sip and qt from the unstable catalog, so that they no longer stand in your way. Maciej From william at wbonnet.net Thu Apr 4 21:41:46 2013 From: william at wbonnet.net (William Bonnet) Date: Thu, 04 Apr 2013 21:41:46 +0200 Subject: [csw-maintainers] Maintainer's last activity information In-Reply-To: References: Message-ID: <515DD77A.3020702@wbonnet.net> Hi > I don't know where this is pulled from, but interestingly it doesn't > list that package as belonging to him. Looks like a bug... need some help ? Cheers W. From bwalton at opencsw.org Thu Apr 4 23:18:11 2013 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 4 Apr 2013 22:18:11 +0100 Subject: [csw-maintainers] Bugs for dbus gone? In-Reply-To: References: Message-ID: Heh...guess I'll be resetting Damjan's password. /me slaps forehead. Thanks -Ben On Thu, Apr 4, 2013 at 10:17 PM, Ben Walton wrote: > The root cause of this problem is that due to something happening in > the catalog to make old packages re-appear as new, the code is trying > to register this ancient package and we don't have a username for > Damjan. > > DEBUG: Registering new project psiconv > DEBUG: SELECT id FROM mantis_project_table WHERE name = ? > WARNING: Project psiconv exists. Updating instead. > DEBUG: Updating project psiconv > DEBUG: SELECT id FROM mantis_project_table WHERE name = ? > DEBUG: UPDATE mantis_project_table SET status = ?, enabled = ?, > view_state = ?, description = ? WHERE name = ? > DEBUG: Updating maintainer for psiconv > DEBUG: Fetching: > http://buildfarm.opencsw.org/pkgdb/rest/srv4/86570a53b0c9d3172883d7baebdfc250/ > DEBUG: {"maintainer_full_name": null, "version_string": > "0.8.3,REV=2003.04.27", "basename": > "psiconv-0.8.3,REV=2003.04.27-SunOS5.8-i386-CSW.pkg.gz", > "maintainer_id": 49, "maintainer_email": > "damjan.perenic at guest.arnes.si", "mtime": "2008-08-20T10:00:07", > "repository_url": null, "file_basename": > "psiconv-0.8.3,REV=2003.04.27-SunOS5.8-i386-CSW.pkg.gz", "arch": > "i386", "osrel": "SunOS5.8", "size": 193003, "md5_sum": > "86570a53b0c9d3172883d7baebdfc250", "pkgname": "CSWpsiconv", "rev": > "2003.04.27", "filename_arch": "i386", "version": > "0.8.3,REV=2003.04.27", "vendor_url": > "http://huizen.dds.nl/~frodol/psiconv/", "catalogname": "psiconv"} > DEBUG: Looking up maintainer id for damjan.perenic > DEBUG: SELECT id FROM mantis_user_table WHERE username = ? > ./../lib/csw/db/mantis.rb:133:in `get_maint_id': undefined method `[]' > for nil:NilClass (NoMethodError) > from ./../lib/csw/db/mantis.rb:114:in `update_maint' > from ./../lib/csw/db/mantis.rb:85:in `update_prj' > from ./../lib/csw/db/mantis.rb:39:in `register_prj' > from ./update_mantis:142 > from ./update_mantis:138:in `each' > from ./update_mantis:138 > > I was going to simply update Damjan's username in mantis and set a > realname field but given the last_visit date that may break his > access. > > mysql> select * from mantis_user_table where email like 'damjan.p%'\G; > *************************** 1. row *************************** > id: 60 > username: damjan > realname: > email: damjan.perenic at guest.arnes.si > password: 12b3638553c1f4a535a047e7003d9ac4 > date_created: 2003-02-09 23:06:55 > last_visit: 2012-05-26 18:01:59 > enabled: 1 > protected: 0 > access_level: 25 > login_count: 33 > lost_password_request_count: 0 > failed_login_count: 0 > cookie_string: > 7e624d4f73f2106f4ef54a52d7f63e092c6fcd344b6b221c51700585ea423f0a > 1 row in set (0.00 sec) > > In this case, I'm going to temporarily fudge things and then reset it > when the import is corrected. I've found other breakages for similar > reasons, so I'll ensure that things get fixed up before I go to bed > tonight. > > I recall getting a few weird catalog notifier updates recently...I > wonder if this is related. Maciej, do you recall the reason for those > updates? Was it related to the stuckness due to the huge symbol info > storage? > > Thanks > -Ben > > > On Tue, Apr 2, 2013 at 6:45 PM, Dagobert Michelsen wrote: >> Hi, >> >> from the package page for dbus >> http://www.opencsw.org/packages/CSWdbus/ >> the page for the bugs seems to have gone: >> http://www.opencsw.org/mantis/set_project.php?project_id=1555 >> >> Does anyone have an idea how this could have happened? >> >> Ben probably? >> >> >> Best regards >> >> -- Dago > > > > -- > --------------------------------------------------------------------------------------------------------------------------- > Take the risk of thinking for yourself. Much more happiness, > truth, beauty and wisdom will come to you that way. > > -Christopher Hitchens > --------------------------------------------------------------------------------------------------------------------------- From bwalton at opencsw.org Fri Apr 5 00:23:03 2013 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 4 Apr 2013 23:23:03 +0100 Subject: [csw-maintainers] Bugs for dbus gone? In-Reply-To: References: Message-ID: On Tue, Apr 2, 2013 at 6:45 PM, Dagobert Michelsen wrote: > Hi, > > from the package page for dbus > http://www.opencsw.org/packages/CSWdbus/ > the page for the bugs seems to have gone: > http://www.opencsw.org/mantis/set_project.php?project_id=1555 This is back in action now. Thanks -Ben From bwalton at opencsw.org Fri Apr 5 00:24:59 2013 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 4 Apr 2013 23:24:59 +0100 Subject: [csw-maintainers] Maintainer's last activity information In-Reply-To: <515DD77A.3020702@wbonnet.net> References: <515DD77A.3020702@wbonnet.net> Message-ID: I have never looked at this code and I don't mind diving in, but if you could focus me in the right direction, that would be very helpful. :) Thanks -Ben On Thu, Apr 4, 2013 at 8:41 PM, William Bonnet wrote: > Hi > > >> I don't know where this is pulled from, but interestingly it doesn't >> >> list that package as belonging to him. > > > Looks like a bug... need some help ? > > Cheers > W. > > From dam at opencsw.org Fri Apr 5 09:13:46 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 5 Apr 2013 09:13:46 +0200 Subject: [csw-maintainers] Bugs for dbus gone? References: <5281639E-889F-441E-A47C-671D7F8102E0@baltic-online.de> Message-ID: Hi Ben, Am 05.04.2013 um 00:23 schrieb Ben Walton : > On Tue, Apr 2, 2013 at 6:45 PM, Dagobert Michelsen wrote: >> from the package page for dbus >> http://www.opencsw.org/packages/CSWdbus/ >> the page for the bugs seems to have gone: >> http://www.opencsw.org/mantis/set_project.php?project_id=1555 > > This is back in action now. Cool, thanks! 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 pfelecan at opencsw.org Fri Apr 5 19:39:21 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 05 Apr 2013 19:39:21 +0200 Subject: [csw-maintainers] opencsw QT 4 & 5 In-Reply-To: (Carsten Grzemba's message of "Thu, 04 Apr 2013 09:55:04 +0200") References: Message-ID: Carsten Grzemba writes: > the QT 4.8.1 builds now (takes some hours). I had a bug in the XSHAPE patch. Thank you for the effort. -- Peter From dam at opencsw.org Sat Apr 6 19:31:58 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 6 Apr 2013 19:31:58 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> Message-ID: <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> Hi Yann, (adding maintainers@) Am 06.04.2013 um 19:29 schrieb Yann Rouillard : > Hi Dago, > > Thanks for tun. > > For pound, I am doing non maintainer uploads to rebuild against openssl 1.0.0. > I am trying to keep the packages as close as possible from the ones currently released, so I am less likely to introduce bugs. > I can't know all these packages and I only do basic testing after, so I prefer to be cautious. > > I will revert back the recipe after the upload (and make sure they compile against libssl 1.0.0). > > For pound, if you intend to release a new version pound shortly, I am stopping right now !! :) > When do you think you will release the new version ? Well, I have been working on it the past few weeks and it will probable take another two. However, I would prefer if you would apply the patches needed for openssl 1.0 compatibility. The same is probably true for the other packages. Lets bump to latest. I can help working on the other parts of the packages. What is left? Best regards -- DAgo > > Yann > > > > > > > > > > > > > > 2013/4/6 Dagobert Michelsen > Hi Yann, > > Am 06.04.2013 um 19:22 schrieb Yann Rouillard : > > Could you please install CSWtun on the buildfarm ? > > Done. > > BTW, why are you reverting pound instead of moving forward? I am about 80% through > updating pound. > > > 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 > > -- "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 yann at pleiades.fr.eu.org Sat Apr 6 19:46:30 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 6 Apr 2013 19:46:30 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> Message-ID: Hi Dago, Well, I have been working on it the past few weeks and it will probable > take another two. > However, I would prefer if you would apply the patches needed for openssl > 1.0 compatibility. > Great !! I am doing this right now ! > The same is probably true for the other packages. Lets bump to latest. > Well I don't agree, I am not ready to tackle the new bugs that might get introduced. If a package doesn't work anymore because of the update, I might not be able to fix it quickly which would not be good for our users. I only bump if I know the software and I am ready to take ownership. Even rebuilding the current version takes a lot of time because the environment changed and some don't have recipe. I am trying not to mix problem and just work here on the ssl upgrade. But with some help, that would change the deal ! :) > I can help working on the other parts of the packages. What is left? > All the packages not striked on http://wiki.opencsw.org/project-openssl I've already sent you an email concerning yours. Which one on the list would you be interested in working ? Yann > > > Best regards > > -- DAgo > > > Yann > > > > > > > > > > > > > > 2013/4/6 Dagobert Michelsen > >> Hi Yann, >> >> Am 06.04.2013 um 19:22 schrieb Yann Rouillard : >> > Could you please install CSWtun on the buildfarm ? >> >> Done. >> >> BTW, why are you reverting pound instead of moving forward? I am about >> 80% through >> updating pound. >> >> >> 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 >> >> > > -- > "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 Sat Apr 6 19:53:32 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 6 Apr 2013 19:53:32 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> Message-ID: <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> Hi Yann, Am 06.04.2013 um 19:46 schrieb Yann Rouillard : > Hi Dago, > > Well, I have been working on it the past few weeks and it will probable take another two. > However, I would prefer if you would apply the patches needed for openssl 1.0 compatibility. > > Great !! I am doing this right now ! > > The same is probably true for the other packages. Lets bump to latest. > > Well I don't agree, I am not ready to tackle the new bugs that might get introduced. If a package doesn't work anymore because of the update, I might not be able to fix it quickly which would not be good for our users. > I only bump if I know the software and I am ready to take ownership. > > Even rebuilding the current version takes a lot of time because the environment changed and some don't have recipe. I am trying not to mix problem and just work here on the ssl upgrade. > > But with some help, that would change the deal ! :) > > I can help working on the other parts of the packages. What is left? > > All the packages not striked on http://wiki.opencsw.org/project-openssl > I've already sent you an email concerning yours. > > Which one on the list would you be interested in working ? nmap is really hard and needs porting. I suggest dropping it or taking a real stab. no idea about openvpn. I already updated nginx some time ago. pound is in the works. gadu is hell, docs and support are only available is some slavic language I can't understand. Maybe Juraj can help? J?rgen worked on monit AFAIK. bitlbee has made a major bump and it took ~20 patches for the previous version to actually compile on Solaris. I suggest dropping it. I could do libarchive. libcurl3 can now be dropped that acroread has been fixed. Can you take over libfbopenssl? It is more your focus IMHO. I could do the others on my list. conserver was hard last time I looked. I took a stab on James' fetchmail but never finished it. ntp would be nice to have in GAR, but would take some effort. ntop is probably hard, probably as hard as nmap. gimpprint can be dropped IMHO. dsniff doesn't work on newer versions on Solaris unfortunately. Best regards -- Dago > > Yann > > > > > > Best regards > > -- DAgo > >> >> Yann >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2013/4/6 Dagobert Michelsen >> Hi Yann, >> >> Am 06.04.2013 um 19:22 schrieb Yann Rouillard : >> > Could you please install CSWtun on the buildfarm ? >> >> Done. >> >> BTW, why are you reverting pound instead of moving forward? I am about 80% through >> updating pound. >> >> >> 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 >> >> > > > -- > "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 > > -- "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 yann at pleiades.fr.eu.org Sat Apr 6 22:15:34 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 6 Apr 2013 22:15:34 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> Message-ID: > Which one on the list would you be interested in working ? > > > nmap is really hard and needs porting. I suggest dropping it or taking a > real stab. > I was currenlyt working on it. I will give up if it proves to be too hard. > no idea about openvpn. > I can rebuild a new package rebuilt again libssl 1.0 with the same version, it seems to be working fine but I don't have a vpn to test it. > > I already updated nginx some time ago. > Did you update only the recipe or did you also released a new package ? > > pound is in the works. > > gadu is hell, docs and support are only available is some slavic language > I can't understand. > Maybe Juraj can help? > gadu is CSWlibgadu, it's only the library. It doesn't have any reverse dependency: http://www.opencsw.org/packages/gadu/, so it seems we can drop it. > > J?rgen worked on monit AFAIK. > J?rgen ? Do you intend to work on it again ? > > bitlbee has made a major bump and it took ~20 patches for the previous > version > to actually compile on Solaris. I suggest dropping it. > Ok, I am dropping it now. > > I could do libarchive. > > libcurl3 can now be dropped that acroread has been fixed. > You need to update curl and curl_rt_stub before. > > Can you take over libfbopenssl? It is more your focus IMHO. > Don't know this one at all but I can give it a try. > > I could do the others on my list. > > conserver was hard last time I looked. > > I took a stab on James' fetchmail but never finished it. > > ntp would be nice to have in GAR, but would take some effort. > > ntop is probably hard, probably as hard as nmap. > > gimpprint can be dropped IMHO. > It implies that we drop gimp as well. Any objection ? > > dsniff doesn't work on newer versions on Solaris unfortunately. > The current version doesn't even work at all. It depends on a version of libnids that isn't in the repository anymore. Based on your comment I will drop it unless someone objects Yann > > > Best regards > > -- Dago > > > Yann > > > > >> >> >> Best regards >> >> -- DAgo >> >> >> Yann >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2013/4/6 Dagobert Michelsen >> >>> Hi Yann, >>> >>> Am 06.04.2013 um 19:22 schrieb Yann Rouillard : >>> > Could you please install CSWtun on the buildfarm ? >>> >>> Done. >>> >>> BTW, why are you reverting pound instead of moving forward? I am about >>> 80% through >>> updating pound. >>> >>> >>> 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 >>> >>> >> >> -- >> "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 >> >> > > -- > "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 bonivart at opencsw.org Sun Apr 7 02:23:58 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 7 Apr 2013 02:23:58 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> Message-ID: On Sat, Apr 6, 2013 at 7:53 PM, Dagobert Michelsen wrote: > ntp would be nice to have in GAR, but would take some effort. This was an easy build, ISC always tests all their software on Solaris. I have working packages on my experimental site, http://buildfarm.opencsw.org/experimental.html#bonivart, but I need a start script, a sample config file and maybe I will split the package so the main package doesn't depend on CSWlibnetsnmp25 (only ntpsnmpd needs it). ntp-4.2.6p5,REV=2013.04.07-SunOS5.10-sparc-CSW.pkg.gz ntp-4.2.6p5,REV=2013.04.07-SunOS5.10-i386-CSW.pkg.gz /peter From jh at opencsw.org Sun Apr 7 11:39:22 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Sun, 07 Apr 2013 11:39:22 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> Message-ID: <51613ECA.9030405@opencsw.org> Hi, Am 06.04.13 22:15, schrieb Yann Rouillard: > > >> >> Which one on the list would you be interested in working ? > > nmap is really hard and needs porting. I suggest dropping it or > taking a real stab. > > > I was currenlyt working on it. I will give up if it proves to be too hard. We do have a nmap zone and someone did request that like 2 years ago or so. Don't know if that was an upstream guy. Checking the page it was not. I don't remember which user that was. But guess he is lost. Greetings Jan From dam at opencsw.org Sun Apr 7 11:48:51 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Apr 2013 11:48:51 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: <51613ECA.9030405@opencsw.org> References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> <51613ECA.9030405@opencsw.org> Message-ID: Hi Jan, Am 07.04.2013 um 11:39 schrieb Jan Holzhueter : > Am 06.04.13 22:15, schrieb Yann Rouillard: >> >>> Which one on the list would you be interested in working ? >> >> nmap is really hard and needs porting. I suggest dropping it or >> taking a real stab. >> >> I was currenlyt working on it. I will give up if it proves to be too hard. > > We do have a nmap zone and someone did request that like 2 years ago or > so. Don't know if that was an upstream guy. Checking the page it was not. > I don't remember which user that was. But guess he is lost. That was David Fifield himself, but Solaris is not a focus of nmap. I did port most of the previous version 5.59BETA1, but there are again lots of things prohibiting a compile. 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 bonivart at opencsw.org Sun Apr 7 12:03:52 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Sun, 7 Apr 2013 12:03:52 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> Message-ID: On Sun, Apr 7, 2013 at 2:23 AM, Peter Bonivart wrote: > On Sat, Apr 6, 2013 at 7:53 PM, Dagobert Michelsen wrote: >> ntp would be nice to have in GAR, but would take some effort. > > This was an easy build, ISC always tests all their software on > Solaris. I have working packages on my experimental site, > http://buildfarm.opencsw.org/experimental.html#bonivart, but I need a > start script, a sample config file and maybe I will split the package > so the main package doesn't depend on CSWlibnetsnmp25 (only ntpsnmpd > needs it). > > ntp-4.2.6p5,REV=2013.04.07-SunOS5.10-sparc-CSW.pkg.gz > ntp-4.2.6p5,REV=2013.04.07-SunOS5.10-i386-CSW.pkg.gz I fixed the above and uploaded to unstable. /peter From yann at pleiades.fr.eu.org Sun Apr 7 12:08:04 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 7 Apr 2013 12:08:04 +0200 Subject: [csw-maintainers] [csw-buildfarm] Request to install tun In-Reply-To: References: <52F20359-1C3F-47D3-A9F6-E160D8A1610F@opencsw.org> <619FDC3E-459D-4EE7-A65A-6C30D9E53069@opencsw.org> <3965E6D7-371E-4CF2-9792-FDED0CCA466A@opencsw.org> Message-ID: Great Peter ! Thanks for this quick update !! Yann 2013/4/7 Peter Bonivart > On Sat, Apr 6, 2013 at 7:53 PM, Dagobert Michelsen > wrote: > > ntp would be nice to have in GAR, but would take some effort. > > This was an easy build, ISC always tests all their software on > Solaris. I have working packages on my experimental site, > http://buildfarm.opencsw.org/experimental.html#bonivart, but I need a > start script, a sample config file and maybe I will split the package > so the main package doesn't depend on CSWlibnetsnmp25 (only ntpsnmpd > needs it). > > ntp-4.2.6p5,REV=2013.04.07-SunOS5.10-sparc-CSW.pkg.gz > ntp-4.2.6p5,REV=2013.04.07-SunOS5.10-i386-CSW.pkg.gz > > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Sun Apr 7 12:08:33 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 7 Apr 2013 12:08:33 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration Message-ID: Hi everyone, I checked the status of the libssl update (0.9.8 -> 1.0.0) and began to work on updating a lot of these packages so this whole migration is behind us. Here are the remaing packages, sorted by maintainer, that need to be updated before we can complete the migration. *Alessio Cervellin ( Retired )* nmap : I rebuilt it with it fails under sparc. Following Dago's comment, *I will drop it unless someone objects*. The recipe will still be there if someone wants to work on it. *Andy Igoshin* nginx : Dago, you already updated the recipe. Can you update a release a new package ? *Benny von Mossner ( Sabbatical )* pound and pound2: Dago is working on this ones. *Ben Walton* libruby1_9_1_1 and ruby18: Ben will work soon on updating these packages. *Chad Harp ( Sabbatical ) *gadu : this is a library without reverse dependency. *I will drop it unless someone objects*. *Cyrus Mehta ( Missing ) *monit : Jorgen might work on it (Jurgen ?). If not, I will release a package *Dagobert Michelsen* libarchive2 and libarchive_utils: Dago takes care of it. libfbopenssl0 : I rebuilt it but I don't know how to test it. libneon26_feature : I think this package can be dropped. It doesn't have any real reverse depenency. Dago what do you think ? lynx : I already updated the recipe and tested the package. I can directly upload the package if you want. Are you ok with this Dago ? pm_netssleay : Dago takes care of it. py_m2crypto : Dago takes care of it. rdesktop : Dago takes care of it. *Darin Perusich* conserver : I rebuilt a package close to the current one. I will mail Darin before uploading it. *Ihsan Dogan* ldnsdrill : this library doesn't have any reverse dependency. Ihsan, can we drop this one ? unbound_host , libunbound2 and unbound : Ihsan should take care of it *Jake Goerzen:* flphoto and gftp: Jake, can you update these packages or do you think we can drop them ? *James Lee:* fetchmail : I didn't have the time to work on it. Someone interested ? *Jon Craig:* ntop : I updated the recipe but it breaks existing installation because of the gdbm update. Jon, do you intend to work on it ? *Ken Mays ( Retired ) *gimpprint : Dago suggested to drop this package, but it means that we drop gimp as well. *I intend to do that as gimp doesn't have any active maintainer*. Any objection ? Only 26 packages remaining ! We can make it ! :) Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Sun Apr 7 12:27:24 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 7 Apr 2013 12:27:24 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration In-Reply-To: References: Message-ID: <7C0380B1-5830-4002-827C-21691F8E7565@opencsw.org> Hi Yann, Am 07.04.2013 um 12:08 schrieb Yann Rouillard : > Hi everyone, > > I checked the status of the libssl update (0.9.8 -> 1.0.0) and began to work on updating a lot of these packages so this whole migration is behind us. > Here are the remaing packages, sorted by maintainer, that need to be updated before we can complete the migration. > > Alessio Cervellin ( Retired ) > nmap: I rebuilt it with it fails under sparc. Following Dago's comment, I will drop it unless someone objects. > The recipe will still be there if someone wants to work on it. It would be something worthwhile, but I don't feel competent enough to do it on my own. If maybe some others chime in I'd like to take a stab, though. > Andy Igoshin > nginx: Dago, you already updated the recipe. Can you update a release a new package ? Yes, will do. > > Benny von Mossner ( Sabbatical ) > pound and pound2: Dago is working on this ones. > > Ben Walton > libruby1_9_1_1 and ruby18: Ben will work soon on updating these packages. > > Chad Harp ( Sabbatical ) > gadu: this is a library without reverse dependency. I will drop it unless someone objects. > > Cyrus Mehta ( Missing ) > monit: Jorgen might work on it (Jurgen ?). If not, I will release a package J?rgen :-) > > Dagobert Michelsen > libarchive2 and libarchive_utils: Dago takes care of it. > libfbopenssl0: I rebuilt it but I don't know how to test it. > libneon26_feature: I think this package can be dropped. It doesn't have any real reverse depenency. Dago what do you think ? Yes, and also drop neon_stub and libneon26. > lynx: I already updated the recipe and tested the package. I can directly upload the package if you want. Are you ok with this Dago ? Please do. I committed some cosmetical changes to the recipe I already did. > pm_netssleay: Dago takes care of it. > py_m2crypto: Dago takes care of it. > rdesktop: Dago takes care of it. > > Darin Perusich > conserver: I rebuilt a package close to the current one. I will mail Darin before uploading it. > > Ihsan Dogan > ldnsdrill: this library doesn't have any reverse dependency. Ihsan, can we drop this one ? > unbound_host, libunbound2 and unbound: Ihsan should take care of it > > Jake Goerzen: > flphoto and gftp: Jake, can you update these packages or do you think we can drop them ? > > James Lee: > fetchmail: I didn't have the time to work on it. Someone interested ? I did a recipe which looks ready for release, but someone should test it. > > Jon Craig: > ntop: I updated the recipe but it breaks existing installation because of the gdbm update. > Jon, do you intend to work on it ? > > Ken Mays ( Retired ) > gimpprint: Dago suggested to drop this package, but it means that we drop gimp as well. I intend to do that as gimp doesn't have any active maintainer. Any objection ? > > /me scratches head. I think I worked on some of the dependencies, but I can't remember needing gimp, so it is probably ok. > Only 26 packages remaining ! We can make it ! :) OpenCSW FTW!! Best regards -- Dago > > > Yann > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "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 maciej at opencsw.org Sun Apr 7 15:33:42 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 7 Apr 2013 14:33:42 +0100 Subject: [csw-maintainers] Small pkgdb-web prettification In-Reply-To: References: Message-ID: 2013/4/3 Peter FELECAN : > Quite useful. However, link the package to the description otherwise you > have a cycle... e.g. > > http://buildfarm.opencsw.org/pkgdb/catalognames/a2ps/ to > http://buildfarm.opencsw.org/pkgdb/srv4/0081cafba415a45801d8191ebdbfee56/ to > http://buildfarm.opencsw.org/pkgdb/catalognames/a2ps/ This loop is intentional, the link back to a2ps is a link to the catalogname, because the thing under link is a catalogname. > Also, back-links would be useful. You mean, some sort of a common navbar? It's probably doable with includes, but the templates we're using are Cheetah templates[1] and their "#include" seems messed up to me. I asked about it on their mailing list: http://permalink.gmane.org/gmane.comp.python.cheetah/2825 ...and got zero answers. I think that if we want to improve our templates, we should switch a different engine with sane #include, for example jinja2. In the meantime, everybody's welcome to tweak the existing templates. For information how to set up pkgdb and releases, see the README file[2] (I just updated it). By the way, if anyone comes up with a way to set these scripts up using lighttpd, please contribute your setup instructions! It would be a better fit on small setups like virtual machines at home. Maciej [1] https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/templates [2] https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/README From maciej at opencsw.org Mon Apr 8 15:19:26 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 8 Apr 2013 14:19:26 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) Message-ID: 2013/1/9 Maciej (Matchek) Blizi?ski : > 2013/1/8 pfelecan : >> On the maintainers mailing list, announce your intention to work on >> the recipe and eventually take up the maintenance. > > What if I want to make a change and upload it, but not become a > permanent maintainer of the package? I had loads of such cases, > especially with packages depending on old libraries. I want to remove > an old library, so I rebuild packages depending on it. Obviously, most > of these packages are not maintained. But I only care about them not > depending on a legacy dependency I want to kill, I don't want to spend > weeks on all the bugs that such package might have filed in Mantis. > > Currently, the result is that I have a lot of bugs assigned to me, > which are legitimate bugs, but I have no intention to fix them, > because I didn't want to take over these packages. But the mechanics > of our uploads work in such a way that it's impossible not to appear > as the main maintainer after you've uploaded a package. I'd like to bring this topic back to discussion. Is there something easy we could do right away? For instance, setting the maintainer field to a fake maintainer? Maciej From bonivart at opencsw.org Mon Apr 8 15:26:05 2013 From: bonivart at opencsw.org (Peter Bonivart) Date: Mon, 8 Apr 2013 15:26:05 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: On Mon, Apr 8, 2013 at 3:19 PM, Maciej (Matchek) Blizi?ski wrote: > I'd like to bring this topic back to discussion. Is there something > easy we could do right away? For instance, setting the maintainer > field to a fake maintainer? Yes, some placeholder would work. But I think it should only be allowed to use either your own name or the placeholder, not any maintainers name. /peter From maciej at opencsw.org Mon Apr 8 18:58:31 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 8 Apr 2013 17:58:31 +0100 Subject: [csw-maintainers] Symbols information and checkpkg database In-Reply-To: References: Message-ID: 2013/4/2 Maciej (Matchek) Blizi?ski : > The new required piece will be the requirement to configure a web > server to run the REST API. I plan to gradually move all the > tool-to-db interaction off the database driver and into HTTP. I spent some time on this over the weekend and I have a proof of concept for a new simple data store. It's really dumb: it's a REST interface where you upload a stats JSON file with a PUT request, delete with DELETE and GET with get (or vice versa?). Internally, files are simplistically saved on disk with md5 hashes used for file names. In the future, we'll split that into 2 or more separate files, to reduce the amount of data to process with one request. I looked through the statistics collection code and decided that it needs an overhaul. Unfortunately, there isn't a way other than read the whole messy code, get to understand it again, and rewrite it. The main rewrite idea will be to go from the current set of classes with vaguely stated purposes into a simpler, linear workflow. This will mean that the workflow will be less flexible, but it looks like in practice we don't need too much flexibility anyway. I also noticed some code that is no longer used. One of them is a package comparator which we used some years ago, but I don't hear about it being used any more, so I'll delete it. Maciej From yann at pleiades.fr.eu.org Mon Apr 8 21:04:48 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 8 Apr 2013 21:04:48 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: Hi, I think there are two topics here: 1. how to handle NMU, 2. how to handle orphaned packages. If you have a lot of bugs assigned to you, it's probably because the maintainers are not active anymore and didn't upload new packages. In fact, the packages are rather orphaned. For 2., I would propose to create a dedicated fake maintainer. The emails address of this fake maintainer would be a mailing-list, all interested maintainers in helping to keep orphaned package up to date would be subscribed to this list. For 1., it might be better to register the official maintainer somewhere (the easiest is in the Makefile). If someone else uploads a package it could just add an "UPLOADER" field in the pkginfo file but would not change the official maintainer of the package. Yann 2013/4/8 Peter Bonivart > On Mon, Apr 8, 2013 at 3:19 PM, Maciej (Matchek) Blizi?ski > wrote: > > I'd like to bring this topic back to discussion. Is there something > > easy we could do right away? For instance, setting the maintainer > > field to a fake maintainer? > > Yes, some placeholder would work. But I think it should only be > allowed to use either your own name or the placeholder, not any > maintainers name. > > /peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rupert at opencsw.org Tue Apr 9 06:48:06 2013 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 9 Apr 2013 06:48:06 +0200 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References: <29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> Message-ID: hi, i tried to compile it again, the contents is: CSWlibserf1-2/root/opt/csw/lib: total 105 -rwxr-xr-x 1 rupert csw 184616 Apr 9 01:10 libserf-1.so.0.0.0 should this not be libserf.so.1.2, or libserf-1.so.1.2 ? rupert On Thu, Mar 7, 2013 at 8:09 PM, Dagobert Michelsen wrote: > Hi Yann, > > Am 07.03.2013 um 20:01 schrieb Yann Rouillard: > > Use "ldd -Ur" and you should have the errors displayed by ldd. > > > Yes, a lot of unreferences objects > > What bug is caused by using "-z ignore" ? > > > I haven't tried the resulting library yet, may I should just see what > happens. > > > Best regards > > -- Dago > > > Yann > > > > 2013/3/7 Dagobert Michelsen >> >> Hi, >> >> Am 07.03.2013 um 19:35 schrieb rupert THURNER: >> > If you could quickly change the makefile including a retiring of the old >> > version should it be appropriate i d appreciate it. I got an error months >> > ago while doing this and just left the version in place because of it. But >> > that is not your intention afaiu. >> > >> > Rupert >> > >> > Am 06.03.2013 22:38 schrieb "Maciej (Matchek) Blizi?ski" >> > : >> > >> > > 2013/3/5 rupert THURNER : >> > > > could somebody mgar knowledgable help to make a correct new version >> > > > of >> > > > libserf or point me to a good / simple example of another library >> > > > which >> > > > changed the version? >> > > >> > > The short answer is that you just build the new library, and if they >> > > changed the soname, you adjust the package name accordingly. Did you >> > > try that and ran into a problem? >> >> There are a couple of issues with -z ignore as all libraries are not >> pulled in any more. >> After adding >> LINKER_IGNORE = >> I get several warnings again: >> >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|libsendfile.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|libuuid.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|libiconv.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|libexpat.so.1|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|libdb-4.8.so|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|liblber-2.4.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> CHECKPKG_OVERRIDES_CSWlibserf1-0 += >> soname-unused|libldap-2.4.so.2|is|needed|by|/opt/csw/lib/libserf-1.so.0.0.0|but|never|used >> >> This is pretty strange, as at least some of them should be used, however >> ldd -r >> works fine. Any idea how this can happen? >> >> >> Best regards >> >> -- Dago >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From rupert at opencsw.org Tue Apr 9 07:01:46 2013 From: rupert at opencsw.org (rupert THURNER) Date: Tue, 9 Apr 2013 07:01:46 +0200 Subject: [csw-maintainers] current procedure of testing packages Message-ID: hi, what is the current procedure of testing packages? first, i checked if it is auto-installed: rupert @ experimental10x : ~ $ svn --version svn, version 1.7.8 (r1419691) compiled Dec 30 2012, 12:53:08 which seems to be not the case. then i tried to install it: rupert @ experimental10x : ~ $ sudo pkgadd pkgs/09.Apr.2013/*1.7.9* We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. Password: Sorry, try again. rupert From maciej at opencsw.org Tue Apr 9 10:35:30 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 9 Apr 2013 09:35:30 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: 2013/4/8 Yann Rouillard : > I think there are two topics here: > 1. how to handle NMU, > 2. how to handle orphaned packages. > > If you have a lot of bugs assigned to you, it's probably because the > maintainers are not active anymore and didn't upload new packages. In fact, > the packages are rather orphaned. > > For 2., I would propose to create a dedicated fake maintainer. The emails > address of this fake maintainer would be a mailing-list, all interested > maintainers in helping to keep orphaned package up to date would be > subscribed to this list. > > For 1., it might be better to register the official maintainer somewhere > (the easiest is in the Makefile). If someone else uploads a package it could > just add an "UPLOADER" field in the pkginfo file but would not change the > official maintainer of the package. Our current field has exactly this meaning, it's whomever last uploaded the package. There's also 2 things we need to distinguish: - how we can change our infrastructure to be better - what we can do right now I'm more interested in what we can do now, without changing our infrastructure. For now we have just one field; adjusting this field causes packages to look as if they changed ownership, although the field really only means the last uploader. So what do we do with this field for now? Maciej From grzemba at contac-dt.de Tue Apr 9 11:05:49 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 09 Apr 2013 11:05:49 +0200 Subject: [csw-maintainers] vidalia on Qt4_gxx vs. Qt4 In-Reply-To: References: Message-ID: ?Hi Jake, we plan to replace the Qt4_gxx 4.8.0 with Qt4 (gxx path removed) 4.8.1 (or newer). Do you like to rebuild CSWvidalia with QT 4.8.1 so we can remove the QT4_gxx package from the database finally. The other reverse dependent package CSWlibreCAD I have already rebuild. What do you think? Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Tue Apr 9 12:36:16 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 9 Apr 2013 12:36:16 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: 2013/4/9 Maciej (Matchek) Blizi?ski > > 2013/4/8 Yann Rouillard : > > I think there are two topics here: > > 1. how to handle NMU, > > 2. how to handle orphaned packages. > > > > If you have a lot of bugs assigned to you, it's probably because the > > maintainers are not active anymore and didn't upload new packages. In fact, > > the packages are rather orphaned. > > > > For 2., I would propose to create a dedicated fake maintainer. The emails > > address of this fake maintainer would be a mailing-list, all interested > > maintainers in helping to keep orphaned package up to date would be > > subscribed to this list. > > > > For 1., it might be better to register the official maintainer somewhere > > (the easiest is in the Makefile). If someone else uploads a package it could > > just add an "UPLOADER" field in the pkginfo file but would not change the > > official maintainer of the package. > > Our current field has exactly this meaning, it's whomever last > uploaded the package. This has not been the case from the beginning, has it ? That is not entirely clear from the outside I think: the maintainers pages still mentions "packages maintained by" and not "packages last uploaded by": http://www.opencsw.org/maintainers/yann/ And the email contact in the pkginfo file is the last uploader's one and not the maintainer's one. > > There's also 2 things we need to distinguish: > > - how we can change our infrastructure to be better > - what we can do right now > > I'm more interested in what we can do now, without changing our > infrastructure. For now we have just one field; adjusting this field > causes packages to look as if they changed ownership, although the > field really only means the last uploader. So what do we do with this > field for now? Without changing anything, I think this field should be used for the official maintainer. When we do a NMU we make sure this field doesn't change. Using a fake maintainer without changing anything in the current infrastructure has to drawbacks I think: - from the outside, it will look like the package doesn't have a maintainer anymore, - the real maintainer will not receive anymore bugs and reminders about his package. Of course we should contact the maintainer before doing this kind of upload. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Apr 9 19:31:43 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 9 Apr 2013 18:31:43 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: 2013/4/9 Yann Rouillard : > > 2013/4/9 Maciej (Matchek) Blizi?ski > >> 2013/4/8 Yann Rouillard : >> > I think there are two topics here: >> > 1. how to handle NMU, >> > 2. how to handle orphaned packages. >> > >> > If you have a lot of bugs assigned to you, it's probably because the >> > maintainers are not active anymore and didn't upload new packages. In >> > fact, >> > the packages are rather orphaned. >> > >> > For 2., I would propose to create a dedicated fake maintainer. The >> > emails >> > address of this fake maintainer would be a mailing-list, all interested >> > maintainers in helping to keep orphaned package up to date would be >> > subscribed to this list. >> > >> > For 1., it might be better to register the official maintainer somewhere >> > (the easiest is in the Makefile). If someone else uploads a package it >> > could >> > just add an "UPLOADER" field in the pkginfo file but would not change >> > the >> > official maintainer of the package. >> >> Our current field has exactly this meaning, it's whomever last >> uploaded the package. > > This has not been the case from the beginning, has it ? > That is not entirely clear from the outside I think: the maintainers pages > still mentions "packages maintained by" and not "packages last uploaded by": > http://www.opencsw.org/maintainers/yann/ It's an omission, we did update it on the package page, maybe we forgot to update it on this page. Originally we used this field as the maintainer / owner field, under the assumption that only the owner builds and uploads the package. > And the email contact in the pkginfo file is the last uploader's one and not > the maintainer's one. Right. If you look at how it works, we basically have no field for the maintainer, only for whomever last uploaded it. >> There's also 2 things we need to distinguish: >> >> - how we can change our infrastructure to be better >> - what we can do right now >> >> I'm more interested in what we can do now, without changing our >> infrastructure. For now we have just one field; adjusting this field >> causes packages to look as if they changed ownership, although the >> field really only means the last uploader. So what do we do with this >> field for now? > > Without changing anything, I think this field should be used for the > official maintainer. When we do a NMU we make sure this field doesn't > change. Either way is bad. We either make a package belong to someone who only did a NMU, or we make it look like a package was uploaded by a ghost. I would personally prefer the first kind of problem. I would definitely not like something to be uploaded with my name on it. If it is to have my name on it, I want to do it myself. > Using a fake maintainer without changing anything in the current > infrastructure has to drawbacks I think: > - from the outside, it will look like the package doesn't have a > maintainer anymore, If it has a maintainer, all that's necessary for the maintainer, is to log in, run mgar platforms and csw-upload-pkg, that's it. If the maintainer can't do even that, can we call the package maintained? > - the real maintainer will not receive anymore bugs and reminders about > his package. Right, but it's enough to re-upload to reverse it. It might look silly in mantis with bugs bouncing between two people, but who cares? Scripts are doing all the work. > Of course we should contact the maintainer before doing this kind of upload. Right, and the maintainer can come in, rebuild and reupload. It can be after a week or few weeks, the person who does courtesy uploads while working on a bigger project doesn't have to wait. So I'd say there should be 2 scenarios after you contact a maintainer: - if the maintainer responds, you upload as yourself, you explain that you're only doing courtesy rebuilds, and the maintainer is welcome to come in and reupload to assign the package back to them - if the maintainer doesn't respond, you reassign the package to a fake maintainer / mailing list, because if the maintainer is gone, the package is orphaned in practice. Maciej From yann at pleiades.fr.eu.org Tue Apr 9 21:53:56 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 9 Apr 2013 21:53:56 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: > This has not been the case from the beginning, has it ? > > That is not entirely clear from the outside I think: the maintainers > pages > > still mentions "packages maintained by" and not "packages last uploaded > by": > > http://www.opencsw.org/maintainers/yann/ > > It's an omission, we did update it on the package page, maybe we > forgot to update it on this page. > So do we change the text on this page from "List of packages maintained by" to "List of packages last uploaded by" ? I also find it strange that packages appear in the QA page of a maintainer if he just did a courtesy upload. > I would > definitely not like something to be uploaded with my name on it. If it > is to have my name on it, I want to do it myself. > It seems this is the thing that bothers you, I understand your concern (especially as the web page currently says "last uploaded by" and not "maintained by") but I personnally don't mind as long as I was contacted before. BTW, This is also the way it works in Debian, it does seems to work there. Of course the last uploader is visible in the changelog and the uploader is supposed to have a look at the bugtracker after the NMU, but the maintainer doesn't change. > > > So I'd say there should be 2 scenarios after you contact a maintainer: > > - if the maintainer responds, you upload as yourself, you explain that > you're only doing courtesy rebuilds, and the maintainer is welcome to > come in and reupload to assign the package back to them. > I am rather for reverting back "last uploaded by" to "maintained by" and doing NMU without changing the maintainer, and eventually add the last uploader information somewhere. But on this subject I will be a consensus guy and follow whatever the consensus is. In the end what is most important is that package do get updated. > - if the maintainer doesn't respond, you reassign the package to a > fake maintainer / mailing list, because if the maintainer is gone, the > package is orphaned in practice. > I definitely agree on this one. This is the "orphaned package" case and I think this is the most common case currently. So let's agree on the fake maintainer name and the mailing list ! "Orphanage Caretaker team", "Orphaned package", ... ? orphanage at list.opencsw.org ? (hmm, I am not very inspired here). Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Apr 9 22:26:55 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 9 Apr 2013 21:26:55 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: 2013/4/9 Yann Rouillard : > So do we change the text on this page from "List of packages maintained by" > to "List of packages last uploaded by" ? Yes, I've submitted the change: https://sourceforge.net/p/opencsw/code/661/ I tried to make it live, but: -bash-3.2$ pwd /var/www/www.opencsw.org/htdocs -bash-3.2$ svn info svn: E155007: '/var/www/www.opencsw.org/htdocs' is not a working copy This seems wrong to me. I thought we were controlling the website with our subversion repository. How do we integrate the repository with the live website, can anyone elucidate? > I also find it strange that packages appear in the QA page of a maintainer > if he just did a courtesy upload. > >> >> I would >> definitely not like something to be uploaded with my name on it. If it >> is to have my name on it, I want to do it myself. > > > It seems this is the thing that bothers you, I understand your concern > (especially as the web page currently says "last uploaded by" and not > "maintained by") but I personnally don't mind as long as I was contacted > before. > > BTW, This is also the way it works in Debian, it does seems to work there. > Of course the last uploader is visible in the changelog and the uploader is > supposed to have a look at the bugtracker after the NMU, but the maintainer > doesn't change. Debian packages track package's changelog, so you have a more accurate view of what was happening. >> So I'd say there should be 2 scenarios after you contact a maintainer: >> >> - if the maintainer responds, you upload as yourself, you explain that >> you're only doing courtesy rebuilds, and the maintainer is welcome to >> come in and reupload to assign the package back to them. > > > I am rather for reverting back "last uploaded by" to "maintained by" and > doing NMU without changing the maintainer, and eventually add the last > uploader information somewhere. The thing I'm trying to say is that we don't store the information who the maintainer is. In practice, we only store information who last uploaded it. This is how it works in practice, and this is how we should treat information. This leads to imperfections such as the QA page listing the last uploader, but it's simply because we don't have the information who the long-term owner of the package is (or if there is one at all). So in my opinion we have the last uploader information available, and what we need to do, is adding the maintainer field. > But on this subject I will be a consensus guy and follow whatever the > consensus is. > In the end what is most important is that package do get updated. > > >> >> - if the maintainer doesn't respond, you reassign the package to a >> fake maintainer / mailing list, because if the maintainer is gone, the >> package is orphaned in practice. > > > I definitely agree on this one. This is the "orphaned package" case and I > think this is the most common case currently. Cool! > So let's agree on the fake maintainer name and the mailing list ! > "Orphanage Caretaker team", "Orphaned package", ... ? > orphanage at list.opencsw.org ? > (hmm, I am not very inspired here). Maybe even an existing mailing list such as 'devel' or 'pkgrequests'. I would be hesitant to set this to 'maintainers' because of spam potential (?). Maciej From yann at pleiades.fr.eu.org Tue Apr 9 23:00:48 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 9 Apr 2013 23:00:48 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: > BTW, This is also the way it works in Debian, it does seems to work there. > > Of course the last uploader is visible in the changelog and the > uploader is > > supposed to have a look at the bugtracker after the NMU, but the > maintainer > > doesn't change. > > Debian packages track package's changelog, so you have a more accurate > view of what was happening. > Yeah definitely, but it should not so complicated for us to do the same thing (in fact, some maintainers already manually maintain a changelog like the Debian one). > > > I am rather for reverting back "last uploaded by" to "maintained by" and > > doing NMU without changing the maintainer, and eventually add the last > > uploader information somewhere. > > The thing I'm trying to say is that we don't store the information who > the maintainer is. In practice, we only store information who last > uploaded it. This is how it works in practice, and this is how we > should treat information. This leads to imperfections such as the QA > page listing the last uploader, but it's simply because we don't have > the information who the long-term owner of the package is (or if there > is one at all). > > So in my opinion we have the last uploader information available, and > what we need to do, is adding the maintainer field. > Ok, eventually the result is the same we will have both information. That's fine for me. > > > So let's agree on the fake maintainer name and the mailing list ! > > "Orphanage Caretaker team", "Orphaned package", ... ? > > orphanage at list.opencsw.org ? > > (hmm, I am not very inspired here). > > Maybe even an existing mailing list such as 'devel' or 'pkgrequests'. > I would be hesitant to set this to 'maintainers' because of spam > potential (?). > I don't think all maintainers are interested in co-maintaing orphaned package even in best effort mode, so I agree that it's best not to use 'maintainers'. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Wed Apr 10 09:16:27 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 10 Apr 2013 08:16:27 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: 2013/4/9 Yann Rouillard : >> Debian packages track package's changelog, so you have a more accurate >> view of what was happening. > > Yeah definitely, but it should not so complicated for us to do the same > thing (in fact, some maintainers already manually maintain a changelog like > the Debian one). In Debian, the changelog is used for a lot of things. Even the version of the package you're building, is taken from the changelog; the software version isn't stored anywhere else, changelog is the authoritative source. Looking at the Debian package page... http://packages.debian.org/unstable/database/mysql-server-5.5 ...it lists multiple maintainers. For a package such as MySQL, it makes complete sense. I don't know the internals, but I'm pretty sure that the list of maintainer is kept as a separate entity from the changelog. I would be all for copying their way of managing this. Maybe we could even adapt their tools. The question is, who will implement the changes. I'm currently working on restoring buildfarm functionality, I can't take on more or nothing will get done. >> > I am rather for reverting back "last uploaded by" to "maintained by" and >> > doing NMU without changing the maintainer, and eventually add the last >> > uploader information somewhere. >> >> The thing I'm trying to say is that we don't store the information who >> the maintainer is. In practice, we only store information who last >> uploaded it. This is how it works in practice, and this is how we >> should treat information. This leads to imperfections such as the QA >> page listing the last uploader, but it's simply because we don't have >> the information who the long-term owner of the package is (or if there >> is one at all). >> >> So in my opinion we have the last uploader information available, and >> what we need to do, is adding the maintainer field. > > > Ok, eventually the result is the same we will have both information. That's > fine for me. Cool. >> > So let's agree on the fake maintainer name and the mailing list ! >> > "Orphanage Caretaker team", "Orphaned package", ... ? >> > orphanage at list.opencsw.org ? >> > (hmm, I am not very inspired here). >> >> Maybe even an existing mailing list such as 'devel' or 'pkgrequests'. >> I would be hesitant to set this to 'maintainers' because of spam >> potential (?). > > > I don't think all maintainers are interested in co-maintaing orphaned > package even in best effort mode, so I agree that it's best not to use > 'maintainers'. Looking at the existing lists: https://lists.opencsw.org/mailman/listinfo Maybe pkgrequests would be best? If someone is making an inquiry about an orphaned package, it's very similar to someone making an inquiry to add something to our catalog - for us it means potentially starting to maintain a package we haven't been maintaining. Maciej From maciej at opencsw.org Wed Apr 10 09:29:09 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 10 Apr 2013 08:29:09 +0100 Subject: [csw-maintainers] libserf-1.2.0, how? In-Reply-To: References: <29EF90D5-EDEA-4A00-B2CA-82A015D7C59B@opencsw.org> Message-ID: 2013/4/9 rupert THURNER : > hi, i tried to compile it again, the contents is: > CSWlibserf1-2/root/opt/csw/lib: > total 105 > -rwxr-xr-x 1 rupert csw 184616 Apr 9 01:10 libserf-1.so.0.0.0 > > should this not be libserf.so.1.2, or libserf-1.so.1.2 ? The library version doesn't have to follow the version of the software. If the upstream didn't change the soname, then it didn't change. It depends on what's in the sources, in the place where the soname is set. Maciej From dam at opencsw.org Wed Apr 10 09:31:17 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 10 Apr 2013 09:31:17 +0200 Subject: [csw-maintainers] current procedure of testing packages In-Reply-To: References: Message-ID: Hi Rupert, Am 09.04.2013 um 07:01 schrieb rupert THURNER : > what is the current procedure of testing packages? Well, the usual case is that you install the packages on your machines and test them :-) The experimental machines are available for testing, but as there is no sane way for console access without giving root to the whole buildfarm it is mostly used when there are no other testing possibilities. Would you need access? 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 grzemba at contac-dt.de Wed Apr 10 11:14:06 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Wed, 10 Apr 2013 11:14:06 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration In-Reply-To: References: <7C0380B1-5830-4002-827C-21691F8E7565@opencsw.org> Message-ID: I am interested in gimp and have gimp 2.8.2 on experimental, but to good news: it don't need gimpprint. Carsten > > > > > > > > > > Ken Mays ( Retired ) > > gimpprint(http://www.opencsw.org/p/gimpprint): Dago suggested to drop this package, but it means that we drop gimp as well. I intend to do that as gimp doesn't have any active maintainer. Any objection ? > > > > > > > > > > > > > /me scratches head. I think I worked on some of the dependencies, but I can't remember > needing gimp, so it is probably ok. > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Wed Apr 10 22:21:27 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Wed, 10 Apr 2013 22:21:27 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: http://packages.debian.org/unstable/database/mysql-server-5.5 > > ...it lists multiple maintainers. For a package such as MySQL, it > makes complete sense. I don't know the internals, but I'm pretty sure > that the list of maintainer is kept as a separate entity from the > changelog. The maintainers's information is located in the debian/control file, in the source package. > > The question is, who will implement the changes. I'm currently working > on restoring buildfarm functionality, I can't take on more or nothing > will get done. > Yes that's the question. I can work on it after having finished the ssl migration and fixed a problem with the scripts updating the package history on the web site. Maybe pkgrequests would be best? If someone is making an inquiry about > an orphaned package, it's very similar to someone making an inquiry to > add something to our catalog - for us it means potentially starting to > maintain a package we haven't been maintaining. > Among the existing list, pkgrequests is the best match. So are we ok to use a fake maintainer like this one: "Orphaned package" < pkgrequests at lists.opencsw.org> ? Any other opinion about this ? Yann > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at bender.opencsw.org Wed Apr 10 23:50:36 2013 From: rmottola at bender.opencsw.org (Riccardo Mottola) Date: Wed, 10 Apr 2013 23:50:36 +0200 Subject: [csw-maintainers] Introduction Message-ID: <20130410215036.GA3038@bender.opencsw.org> Hi all! first post to the list, to say hello and present myself and what my reasons are of why I joined in here. I am a long-time open-source programmer and in the past 10 years about I concentrated in the Objective-C and GNUstep fied. I am both official maintainer in GNUstep itself (GWorkspace) as wll as co-leader and developer of the GNUstep Application project itself. It is possible that you heard little of GNUstep, but it is an official GNU and FSF project. And as there was NeXT for Sparc and then OpenStep ontop of Solaris, so I want to take care that we still support SPARC and Solaris. Personally I'd like to see GNUstep work on Solaris 8 and 10. I don't know if many will be interested in it, but the core part, even without the GUI, is a very powerful framework used already at enterprise-level. In the beginning, I won't be even asking for packages, I will work directly in the GNUstep sources to test and smooth things out. Right now I can't even get the base stuff to compile wither on Solaris 8 as on 10. Given that, I have seen that the Solaris 8 packages are old. Although they are very helpful, I think that several packages would need updating. Since I thought others might benefit from that too, the best place were to work on this would be directly this project. I know, by speaking in the IRC channel, that some of you would not undertake this and that there will be problems. I do not want to cause troubles to more current versions and to hamper any body, but leveraging more modern receipts sounds like a good idea. I'd be happy with a subset of packages, but those more up-to-date. Eg. compilers or security critical stuff like openssl/openssh. Perhaps there will be the need for more packages too (e.g. because some system dependencies are just too old or for other reasons). I don't know the build system yet, but Macjej already pointed out about possible flexibility problems. So, again, I come in peace, even if perhaps I stir up something :) Riccardo From maciej at opencsw.org Thu Apr 11 10:32:21 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 11 Apr 2013 09:32:21 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads (was: reminder on contributing on recipes) In-Reply-To: References: Message-ID: 2013/4/10 Yann Rouillard : >> The question is, who will implement the changes. I'm currently working >> on restoring buildfarm functionality, I can't take on more or nothing >> will get done. > > Yes that's the question. I can work on it after having finished the ssl > migration and fixed a problem with the scripts updating the package history > on the web site. Yes, looks good. One project at a time. >> Maybe pkgrequests would be best? If someone is making an inquiry about >> an orphaned package, it's very similar to someone making an inquiry to >> add something to our catalog - for us it means potentially starting to >> maintain a package we haven't been maintaining. > > Among the existing list, pkgrequests is the best match. > > So are we ok to use a fake maintainer like this one: "Orphaned package" > ? Sounds good to me. One thing I'm not sure about - is the world able/permitted to send email to that list directly? A side comment - maybe we shouldn't publish our mailing list email addresses for spammer harversters to pick up. Maciej From maciej at opencsw.org Thu Apr 11 10:40:44 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 11 Apr 2013 09:40:44 +0100 Subject: [csw-maintainers] Introduction In-Reply-To: <20130410215036.GA3038@bender.opencsw.org> References: <20130410215036.GA3038@bender.opencsw.org> Message-ID: 2013/4/10 Riccardo Mottola : > I'd be happy with a subset of packages, but those more up-to-date. Eg. compilers or security critical stuff like openssl/openssh. > Perhaps there will be the need for more packages too (e.g. because some system dependencies are just too old or for other reasons). > > I don't know the build system yet, but Macjej already pointed out about possible flexibility problems. > > So, again, I come in peace, even if perhaps I stir up something :) Hey Riccardo, it's good to see new people in here. I think the best course of action for you is to familiarize yourself with the build system on Solaris 10, and once you have an idea how it works, looking into the Solaris 8 stuff. One problematic part would be running checkpkg which has a number of dependencies such as Python, with a couple modules and libmagic, but if that fails, maybe you can build on Solaris 8 and index/check packages on Solaris 9 or 10. Welcome aboard! Maciej From dam at opencsw.org Fri Apr 12 09:54:19 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Apr 2013 09:54:19 +0200 Subject: [csw-maintainers] Modifying check for /usr/share Message-ID: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> Hi, I would like to suggest a change in the check for /usr/share presence, where the presence of /usr/share/lib/zoneinfo is acceptable, as this should be taken from the system. Thoughts? Best regards -- Dago From dam at opencsw.org Fri Apr 12 10:53:18 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Apr 2013 10:53:18 +0200 Subject: [csw-maintainers] Missing definition of G_CONST_RETURN Message-ID: <42352C37-7AB0-46CD-84E3-C78C9AE61DAF@opencsw.org> Hi, I am trying to compile a recent wireshark and get errors that G_CONST_RETURN is not defined. This should be the case during glib.h inclusion, so I figure this is a general problem that most likely someone has already seen and solved, right? ;-) > gmake[2]: Entering directory `/home/dam/mgar/pkg/wireshark/trunk/work/solaris10-sparc/build-isa-sparcv8plus/wireshark-1.8.6/ui/gtk' > source='about_dlg.c' object='libgtkui_a-about_dlg.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ > /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../wiretap -I/opt/csw/include -I/opt/csw/include -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -D_U_="" -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include '-DPLUGIN_DIR="/opt/csw/lib/wireshark/plugins/1.8.6"' -xO3 -m32 -xarch=sparc -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS -DXUSE_MTSAFE_API -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/gdk-pixbuf-2.0 -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include/libpng15 -c -o libgtkui_a-about_dlg.o `test -f 'about_dlg.c' || echo './'`about_dlg.c > "/opt/csw/include/glib-2.0/gobject/gparam.h", line 158: warning: integer overflow detected: op "<<" > "/opt/csw/include/pango-1.0/pango/pango-script.h", line 132: syntax error before or at: G_CONST_RETURN > "/opt/csw/include/pango-1.0/pango/pango-script.h", line 132: warning: undefined or missing type for: G_CONST_RETURN > "/opt/csw/include/pango-1.0/pango/pango-script.h", line 133: warning: undefined or missing type for: char > "/opt/csw/include/pango-1.0/pango/pango-script.h", line 134: warning: undefined or missing type for: PangoScript > "/opt/csw/include/pango-1.0/pango/pango-language.h", line 37: warning: old-style declaration or incorrect type for: G_CONST_RETURN > "/opt/csw/include/pango-1.0/pango/pango-language.h", line 37: syntax error before or at: char > "/opt/csw/include/pango-1.0/pango/pango-language.h", line 41: warning: old-style declaration or incorrect type for: G_CONST_RETURN > "/opt/csw/include/pango-1.0/pango/pango-language.h", line 41: syntax error before or at: char > "/opt/csw/include/pango-1.0/pango/pango-language.h", line 51: warning: old-style declaration or incorrect type for: G_CONST_RETURN > "/opt/csw/include/pango-1.0/pango/pango-language.h", line 51: syntax error before or at: PangoScript > "/opt/csw/include/pango-1.0/pango/pango-font.h", line 120: warning: old-style declaration or incorrect type for: G_CONST_RETURN > "/opt/csw/include/pango-1.0/pango/pango-font.h", line 120: syntax error before or at: char > "/opt/csw/include/pango-1.0/pango/pango-font.h", line 215: warning: old-style declaration or incorrect type for: G_CONST_RETURN Best regards -- Dago From pfelecan at opencsw.org Fri Apr 12 20:45:59 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 12 Apr 2013 20:45:59 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: (Yann Rouillard's message of "Wed, 10 Apr 2013 22:21:27 +0200") References: Message-ID: Yann Rouillard writes: > http://packages.debian.org/unstable/database/mysql-server-5.5 >> >> ...it lists multiple maintainers. For a package such as MySQL, it >> makes complete sense. I don't know the internals, but I'm pretty sure >> that the list of maintainer is kept as a separate entity from the >> changelog. > > > The maintainers's information is located in the debian/control file, in the > source package. Our "control" file is the recipe, i.e., the Makefile. Having a variable containing a list of maintainers seems to be a nice addition. What Dag thinks about this? -- Peter From pfelecan at opencsw.org Fri Apr 12 20:47:43 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 12 Apr 2013 20:47:43 +0200 Subject: [csw-maintainers] Modifying check for /usr/share In-Reply-To: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> (Dagobert Michelsen's message of "Fri, 12 Apr 2013 09:54:19 +0200") References: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> Message-ID: Dagobert Michelsen writes: > Hi, > > I would like to suggest a change in the check for /usr/share presence, where the presence of > /usr/share/lib/zoneinfo is acceptable, as this should be taken from the system. Thoughts? If we don't provide a specific "zoneinfo" file, and why should we ?, then this seems very reasonable. -- Peter From dam at opencsw.org Fri Apr 12 20:56:33 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 12 Apr 2013 20:56:33 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: Message-ID: Hi Peter, Am 12.04.2013 um 20:45 schrieb Peter FELECAN: > Yann Rouillard writes: >> http://packages.debian.org/unstable/database/mysql-server-5.5 >>> >>> ...it lists multiple maintainers. For a package such as MySQL, it >>> makes complete sense. I don't know the internals, but I'm pretty sure >>> that the list of maintainer is kept as a separate entity from the >>> changelog. >> >> >> The maintainers's information is located in the debian/control file, in the >> source package. > > Our "control" file is the recipe, i.e., the Makefile. Having a variable > containing a list of maintainers seems to be a nice addition. What Dag > thinks about this? I am ok with this. MAINTAINED_BY += pfelecan MAINTAINED_BY += dam How would a workflow look like? Best regards -- Dago From pfelecan at opencsw.org Fri Apr 12 21:10:07 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 12 Apr 2013 21:10:07 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: (Dagobert Michelsen's message of "Fri, 12 Apr 2013 20:56:33 +0200") References: Message-ID: Dagobert Michelsen writes: > Hi Peter, > > Am 12.04.2013 um 20:45 schrieb Peter FELECAN: >> Yann Rouillard writes: >>> http://packages.debian.org/unstable/database/mysql-server-5.5 >>>> >>>> ...it lists multiple maintainers. For a package such as MySQL, it >>>> makes complete sense. I don't know the internals, but I'm pretty sure >>>> that the list of maintainer is kept as a separate entity from the >>>> changelog. >>> >>> >>> The maintainers's information is located in the debian/control file, in the >>> source package. >> >> Our "control" file is the recipe, i.e., the Makefile. Having a variable >> containing a list of maintainers seems to be a nice addition. What Dag >> thinks about this? > > I am ok with this. > MAINTAINED_BY += pfelecan > MAINTAINED_BY += dam > > How would a workflow look like? In the pkginfo file we have this: VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter Felecan EMAIL=pfelecan at opencsw.org We should have: VENDOR=http://leocad.googlecode.com/files/ EMAIL=pfelecan at opencsw.org ... OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen The last variable contain the values of the multi-valuated attribute "maintainer". The user uploading the package is the value of the attribute "NMU" --- when I'm writing about "attribute" I'm thinking to the packages database schema. The variable in the pkginfo file is generated at packaging time. The attributes are valuated at upload time. Does it seems reasonable? What thinks our data-base czar but not less enlightened colleague? :-) -- Peter From maciej at opencsw.org Sat Apr 13 10:24:32 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 13 Apr 2013 09:24:32 +0100 Subject: [csw-maintainers] Modifying check for /usr/share In-Reply-To: References: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> Message-ID: 2013/4/12 Peter FELECAN : >> I would like to suggest a change in the check for /usr/share presence, where the presence of >> /usr/share/lib/zoneinfo is acceptable, as this should be taken from the system. Thoughts? > > If we don't provide a specific "zoneinfo" file, and why should we ?, > then this seems very reasonable. I have a general feeling that these content checks are too broad and produce so many false positives, that they border on unhelpful. Maybe we should make them less broad as the first measure. For starters, they should only concern binaries. We could also review how useful they are in the long run. We did have a bug caused by a reference to /usr/share, but if this check did not help us since, we can remove it without losing much. Maciej From pfelecan at opencsw.org Sat Apr 13 11:18:47 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sat, 13 Apr 2013 11:18:47 +0200 Subject: [csw-maintainers] Modifying check for /usr/share In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sat, 13 Apr 2013 09:24:32 +0100") References: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/4/12 Peter FELECAN : >>> I would like to suggest a change in the check for /usr/share presence, where the presence of >>> /usr/share/lib/zoneinfo is acceptable, as this should be taken from the system. Thoughts? >> >> If we don't provide a specific "zoneinfo" file, and why should we ?, >> then this seems very reasonable. > > I have a general feeling that these content checks are too broad and > produce so many false positives, that they border on unhelpful. Maybe > we should make them less broad as the first measure. For starters, > they should only concern binaries. > > We could also review how useful they are in the long run. We did have > a bug caused by a reference to /usr/share, but if this check did not > help us since, we can remove it without losing much. Globally agree with you. IMHO we can exclude from this kind of check the Info files, the manual pages and the documentation in general. Also, specific files as "zoneinfo" are good candidates. But removing all these checks is not a good solution. -- Peter From ihsan at opencsw.org Sun Apr 14 12:42:21 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 14 Apr 2013 12:42:21 +0200 Subject: [csw-maintainers] lists.opencsw.org certificate Message-ID: <516A880D.7040809@opencsw.org> Hi, The SSL certificate for lists.opencsw.org expired today. I've missed to order a new one early enough. Sorry for that. I've requested just a few minutes ago a new certificate. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Sun Apr 14 12:52:30 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 14 Apr 2013 11:52:30 +0100 Subject: [csw-maintainers] lists.opencsw.org certificate In-Reply-To: <516A880D.7040809@opencsw.org> References: <516A880D.7040809@opencsw.org> Message-ID: 2013/4/14 ?hsan Do?an : > Hi, > > The SSL certificate for lists.opencsw.org expired today. I've missed to > order a new one early enough. Sorry for that. > > I've requested just a few minutes ago a new certificate. I didn't know we had a https version of this site. If we do and the new certificate is installed, maybe we should place a HTTP redirect to go from http:// to https://? Maciej From ihsan at opencsw.org Sun Apr 14 14:08:45 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 14 Apr 2013 14:08:45 +0200 Subject: [csw-maintainers] lists.opencsw.org certificate In-Reply-To: <516A880D.7040809@opencsw.org> References: <516A880D.7040809@opencsw.org> Message-ID: <516A9C4D.5060602@opencsw.org> Am 14.04.2013 12:42, schrieb ?hsan Do?an: > The SSL certificate for lists.opencsw.org expired today. I've missed to > order a new one early enough. Sorry for that. > > I've requested just a few minutes ago a new certificate. New certificate is now in place. No more SSL warnings. :-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Sun Apr 14 14:10:40 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 14 Apr 2013 14:10:40 +0200 Subject: [csw-maintainers] lists.opencsw.org certificate In-Reply-To: References: <516A880D.7040809@opencsw.org> Message-ID: <516A9CC0.2020107@opencsw.org> Am 14.04.2013 12:52, schrieb Maciej (Matchek) Blizi?ski: >> The SSL certificate for lists.opencsw.org expired today. I've missed to >> order a new one early enough. Sorry for that. >> >> I've requested just a few minutes ago a new certificate. > > I didn't know we had a https version of this site. If we do and the > new certificate is installed, maybe we should place a HTTP redirect to > go from http:// to https://? There have been all the time an SSL version of it, with automatich redirects. While the list archives are non-SSL, the complete Mailman admin and user interface is completely on SSL. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Sun Apr 14 15:48:34 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 14 Apr 2013 14:48:34 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: Message-ID: 2013/4/12 Peter FELECAN : > In the pkginfo file we have this: > > VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter Felecan > EMAIL=pfelecan at opencsw.org > > We should have: > > VENDOR=http://leocad.googlecode.com/files/ > EMAIL=pfelecan at opencsw.org > ... > OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen > > The last variable contain the values of the multi-valuated attribute > "maintainer". The user uploading the package is the value of the > attribute "NMU" --- when I'm writing about "attribute" I'm thinking to > the packages database schema. One more distinction: The user who uploads the package doesn't have to be the same user who ran "mgar package". So we have: 1. users who are long-term maintainers of a given package 2. user who ran "mgar package" 3. user who uploaded the package (ran csw-upload-pkg) > The variable in the pkginfo file is generated at packaging time. > > The attributes are valuated at upload time. We can no longer modify the package contents at upload time, and I'm guessing we want everything to be inside the package. > Does it seems reasonable? > > What thinks our data-base czar but not less enlightened colleague? :-) Looks like nobody wants to claim the title of DB czar! So I'll chime in. The list of maintainers needs to be in one of the pkginfo fields, that's simple. But I think it should be a list of user names, or a list of valid (rich) email addresses: OPENCSW_MAINTAINERS=joe, jane or OPENCSW_MAINTAINERS=Joe Doe , Jane Dow One more thing: different people have different attitudes towards different packages. There are packages that are simple libraries, there's little technical decisions involved there, e.g. Perl or Python modules. You just build them, push them out, done. But then there are larger packages, such as Perl or Python themselves, where there are big decisions involved. For example, the horrible patch[1] for Python that has screwed us up big time. Library rebuilds - I don't care, anyone who wants can rebuild them. But screwing up Python like in [1] ? over my dead body. So I'd put my name up as the Python package maintainer, but not for Python modules. The package's maintainer list has to be optional. Maciej [1] https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/lang-python/python/trunk/files/site.diff From pfelecan at opencsw.org Sun Apr 14 16:14:03 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 14 Apr 2013 16:14:03 +0200 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 14 Apr 2013 14:48:34 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > 2013/4/12 Peter FELECAN : >> In the pkginfo file we have this: >> >> VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter Felecan >> EMAIL=pfelecan at opencsw.org >> >> We should have: >> >> VENDOR=http://leocad.googlecode.com/files/ >> EMAIL=pfelecan at opencsw.org >> ... >> OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen >> >> The last variable contain the values of the multi-valuated attribute >> "maintainer". The user uploading the package is the value of the >> attribute "NMU" --- when I'm writing about "attribute" I'm thinking to >> the packages database schema. > > One more distinction: The user who uploads the package doesn't have to > be the same user who ran "mgar package". So we have: > > 1. users who are long-term maintainers of a given package These are in variable containing the list and which is in the recipe, i.e. Makefile and used to generate the corresponding information in the pkginfo file. > 2. user who ran "mgar package" Who cares? But if you find it useful, why not. > 3. user who uploaded the package (ran csw-upload-pkg) This is more important that one who runs mgar and should be recorded by the upload process. > >> The variable in the pkginfo file is generated at packaging time. >> >> The attributes are valuated at upload time. > > We can no longer modify the package contents at upload time, and I'm > guessing we want everything to be inside the package. At upload time, the database's attributes are valuated from what's in the package, isn't it? >> Does it seems reasonable? >> >> What thinks our data-base czar but not less enlightened colleague? :-) > > Looks like nobody wants to claim the title of DB czar! So I'll chime in. De facto. > The list of maintainers needs to be in one of the pkginfo fields, > that's simple. But I think it should be a list of user names, or a > list of valid (rich) email addresses: > > OPENCSW_MAINTAINERS=joe, jane > > or > > OPENCSW_MAINTAINERS=Joe Doe , Jane Dow Too complex from my POV but why not. > One more thing: different people have different attitudes towards > different packages. There are packages that are simple libraries, > there's little technical decisions involved there, e.g. Perl or Python > modules. You just build them, push them out, done. But then there are > larger packages, such as Perl or Python themselves, where there are > big decisions involved. For example, the horrible patch[1] for Python > that has screwed us up big time. Library rebuilds - I don't care, > anyone who wants can rebuild them. But screwing up Python like in [1] > ? over my dead body. So I'd put my name up as the Python package > maintainer, but not for Python modules. The package's maintainer list > has to be optional. Agree 100% -- Peter From ihsan at opencsw.org Sun Apr 14 16:18:42 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Sun, 14 Apr 2013 16:18:42 +0200 Subject: [csw-maintainers] packaging issue with multiple ISA Message-ID: <516ABAC2.6000101@opencsw.org> Hi, I've build the unbound package with multiple ISA, but excluded the parts, were CPU optimization is not necessary. MERGE_DIRS_isa-sparcv8plus = $(libdir) MERGE_DIRS_isa-sparcv8plus += $(sbindir) MERGE_DIRS_isa-pentium_pro = $(libdir) MERGE_DIRS_isa-pentium_pro += $(sbindir) ISAXEC_DIRS = $(sbindir) EXTRA_ISAEXEC_EXCLUDE_FILES = $(sbindir)/unbound-anchor EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-checkconf EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control-setup EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-host EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro = $(prefix)/sbin/unbound-anchor EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-checkconf EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-control EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-control-setup EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-host EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus = $(prefix)/sbin/unbound-anchor EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-checkconf EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-control EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-control-setup EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-host And specified the files for the package: CATALOGNAME_CSWunbound-host = unbound_host SPKG_DESC_CSWunbound-host = Unbound DNS lookup utility PKGFILES_CSWunbound-host += $(sbindir)/unbound-host PKGFILES_CSWunbound-host += $(mandir)/man1/unbound-host.1 RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibldns1 RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibssl1-0-0 RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibunbound2 RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibevent2-0-5 That worked once, but now it produced empty packages. What would be the appropriate way to package unbound? Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From jcraig at opencsw.org Sun Apr 14 16:58:22 2013 From: jcraig at opencsw.org (Jonathan Craig) Date: Sun, 14 Apr 2013 10:58:22 -0400 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: Message-ID: What about an entry in the Makefile along the lines of "MAINTAINER_LOCK = maintainer_uname" that once set prevents anyone else from uploading a package unless its cleared by an authorized admin. This would put it in the maintainers hands to lock the stuff they want locked. I would still like the ability to re-build others packages as a learning experience and potentially allow me to create private copies of packages with different choices for personal use. On Sun, Apr 14, 2013 at 10:14 AM, Peter FELECAN wrote: > "Maciej (Matchek) Blizi?ski" writes: > > > 2013/4/12 Peter FELECAN : > >> In the pkginfo file we have this: > >> > >> VENDOR=http://leocad.googlecode.com/files/ packaged for CSW by Peter > Felecan > >> EMAIL=pfelecan at opencsw.org > >> > >> We should have: > >> > >> VENDOR=http://leocad.googlecode.com/files/ > >> EMAIL=pfelecan at opencsw.org > >> ... > >> OPENCSW_MAINTAINERS=Peter Felecan, Dagobert Michelsen > >> > >> The last variable contain the values of the multi-valuated attribute > >> "maintainer". The user uploading the package is the value of the > >> attribute "NMU" --- when I'm writing about "attribute" I'm thinking to > >> the packages database schema. > > > > One more distinction: The user who uploads the package doesn't have to > > be the same user who ran "mgar package". So we have: > > > > 1. users who are long-term maintainers of a given package > > These are in variable containing the list and which is in the recipe, > i.e. Makefile and used to generate the corresponding information in the > pkginfo file. > > > 2. user who ran "mgar package" > > Who cares? But if you find it useful, why not. > > > 3. user who uploaded the package (ran csw-upload-pkg) > > This is more important that one who runs mgar and should be recorded by > the upload process. > > > > >> The variable in the pkginfo file is generated at packaging time. > >> > >> The attributes are valuated at upload time. > > > > We can no longer modify the package contents at upload time, and I'm > > guessing we want everything to be inside the package. > > At upload time, the database's attributes are valuated from what's in the > package, isn't it? > > >> Does it seems reasonable? > >> > >> What thinks our data-base czar but not less enlightened colleague? :-) > > > > Looks like nobody wants to claim the title of DB czar! So I'll chime in. > > De facto. > > > The list of maintainers needs to be in one of the pkginfo fields, > > that's simple. But I think it should be a list of user names, or a > > list of valid (rich) email addresses: > > > > OPENCSW_MAINTAINERS=joe, jane > > > > or > > > > OPENCSW_MAINTAINERS=Joe Doe , Jane Dow < > jane at example.com> > > Too complex from my POV but why not. > > > One more thing: different people have different attitudes towards > > different packages. There are packages that are simple libraries, > > there's little technical decisions involved there, e.g. Perl or Python > > modules. You just build them, push them out, done. But then there are > > larger packages, such as Perl or Python themselves, where there are > > big decisions involved. For example, the horrible patch[1] for Python > > that has screwed us up big time. Library rebuilds - I don't care, > > anyone who wants can rebuild them. But screwing up Python like in [1] > > ? over my dead body. So I'd put my name up as the Python package > > maintainer, but not for Python modules. The package's maintainer list > > has to be optional. > > Agree 100% > -- > Peter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Mon Apr 15 06:51:16 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 15 Apr 2013 06:51:16 +0200 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: <516ABAC2.6000101@opencsw.org> References: <516ABAC2.6000101@opencsw.org> Message-ID: Hi Ihsan, When trying to package unbound to reproduce your problem, I've got the following error on i386: libtool: compile: /opt/SUNWspro/bin/cc -I. -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro -xc99 -flto -D_REENTRANT -c util/storage/dnstree.c -o dnstree.o >/dev/null 2>&1 ./libtool --tag=CC --mode=compile /opt/SUNWspro/bin/cc -I. -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro -xc99 -flto -D_REENTRANT -o lookup3.lo -c `cat .source` libtool: compile: /opt/SUNWspro/bin/cc -I. -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -xO3 -m32 -xarch=pentium_pro -xchip=pentium_pro -xc99 -flto -D_REENTRANT -c util/storage/lookup3.c -KPIC -DPIC -o .libs/lookup3.o cc: Warning: illegal option -flto "util/storage/lookup3.c", line 76: unexpected ")" cc: acomp failed for util/storage/lookup3.c gmake: *** [lookup3.lo] Error 1 gmake: Leaving directory `/home/yann/opencsw/unbound/trunk/work/solaris10-i386/build-isa-pentium_pro/unbound-1.4.20' gmake[1]: *** [build-work/solaris10-i386/build-isa-pentium_pro/unbound-1.4.20/Makefile] Error 2 gmake[1]: Leaving directory `/home/yann/opencsw/unbound/trunk' gmake: *** [merge-isa-pentium_pro] Error 2 You didn't have the same problem ? Yann 2013/4/14 ?hsan Do?an > Hi, > > I've build the unbound package with multiple ISA, but excluded the > parts, were CPU optimization is not necessary. > > MERGE_DIRS_isa-sparcv8plus = $(libdir) > MERGE_DIRS_isa-sparcv8plus += $(sbindir) > MERGE_DIRS_isa-pentium_pro = $(libdir) > MERGE_DIRS_isa-pentium_pro += $(sbindir) > > ISAXEC_DIRS = $(sbindir) > EXTRA_ISAEXEC_EXCLUDE_FILES = $(sbindir)/unbound-anchor > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-checkconf > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control-setup > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-host > > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro = $(prefix)/sbin/unbound-anchor > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += > $(prefix)/sbin/unbound-checkconf > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-control > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += > $(prefix)/sbin/unbound-control-setup > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-host > > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus = $(prefix)/sbin/unbound-anchor > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += > $(prefix)/sbin/unbound-checkconf > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-control > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += > $(prefix)/sbin/unbound-control-setup > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-host > > And specified the files for the package: > > CATALOGNAME_CSWunbound-host = unbound_host > SPKG_DESC_CSWunbound-host = Unbound DNS lookup utility > PKGFILES_CSWunbound-host += $(sbindir)/unbound-host > PKGFILES_CSWunbound-host += $(mandir)/man1/unbound-host.1 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibldns1 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibssl1-0-0 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibunbound2 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibevent2-0-5 > > That worked once, but now it produced empty packages. > > What would be the appropriate way to package unbound? > > > > > Ihsan > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Mon Apr 15 13:43:11 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 15 Apr 2013 13:43:11 +0200 Subject: [csw-maintainers] Modifying check for /usr/share In-Reply-To: References: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> Message-ID: Hi folks, Am 13.04.2013 um 11:18 schrieb Peter FELECAN : > "Maciej (Matchek) Blizi?ski" writes: >> 2013/4/12 Peter FELECAN : >>>> I would like to suggest a change in the check for /usr/share presence, where the presence of >>>> /usr/share/lib/zoneinfo is acceptable, as this should be taken from the system. Thoughts? >>> >>> If we don't provide a specific "zoneinfo" file, and why should we ?, >>> then this seems very reasonable. >> >> I have a general feeling that these content checks are too broad and >> produce so many false positives, that they border on unhelpful. Maybe >> we should make them less broad as the first measure. For starters, >> they should only concern binaries. >> >> We could also review how useful they are in the long run. We did have >> a bug caused by a reference to /usr/share, but if this check did not >> help us since, we can remove it without losing much. > > Globally agree with you. IMHO we can exclude from this kind of check the > Info files, the manual pages and the documentation in general. Also, > specific files as "zoneinfo" are good candidates. But removing all these > checks is not a good solution. I would like to keep the check, there have been occasions where this was extremely useful and helped point out issues which were gone by unnoticed. Taking out the known-to-be-good pathes is IMHO the best way. 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 ihsan at opencsw.org Mon Apr 15 13:54:21 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Mon, 15 Apr 2013 13:54:21 +0200 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: References: <516ABAC2.6000101@opencsw.org> Message-ID: <516BEA6D.7040102@opencsw.org> Hi Yann, On 04/15/2013 06:51 AM, Yann Rouillard wrote: > When trying to package unbound to reproduce your problem, I've got the > following error on i386: [...] > cc: Warning: illegal option -flto > "util/storage/lookup3.c", line 76: unexpected ")" > cc: acomp failed for util/storage/lookup3.c > gmake: *** [lookup3.lo] Error 1 > gmake: Leaving directory > `/home/yann/opencsw/unbound/trunk/work/solaris10-i386/build-isa-pentium_pro/unbound-1.4.20' > gmake[1]: *** > [build-work/solaris10-i386/build-isa-pentium_pro/unbound-1.4.20/Makefile] Error > 2 > gmake[1]: Leaving directory `/home/yann/opencsw/unbound/trunk' > gmake: *** [merge-isa-pentium_pro] Error 2 > > > You didn't have the same problem ? That's new to me. This worked with earlier version on x86. But I have also to say, that this time, I haven't tried to build it on x86. Sparc builds just fine. I'll have a look into this. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From raos at opencsw.org Mon Apr 15 14:09:20 2013 From: raos at opencsw.org (Rafael Ostertag) Date: Mon, 15 Apr 2013 14:09:20 +0200 Subject: [csw-maintainers] Missing definition of G_CONST_RETURN In-Reply-To: <42352C37-7AB0-46CD-84E3-C78C9AE61DAF@opencsw.org> References: <42352C37-7AB0-46CD-84E3-C78C9AE61DAF@opencsw.org> Message-ID: <20130415120920.GB1101@bender.opencsw.org> Hi Dago On Fri, Apr 12, 2013 at 10:53:18AM +0200, Dagobert Michelsen wrote: > Hi, > > I am trying to compile a recent wireshark and get errors that G_CONST_RETURN is not defined. > This should be the case during glib.h inclusion, so I figure this is a general problem that > most likely someone has already seen and solved, right? ;-) > > > gmake[2]: Entering directory `/home/dam/mgar/pkg/wireshark/trunk/work/solaris10-sparc/build-isa-sparcv8plus/wireshark-1.8.6/ui/gtk' > > source='about_dlg.c' object='libgtkui_a-about_dlg.o' libtool=no \ > > DEPDIR=.deps depmode=none /bin/bash ../../depcomp \ > > /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../wiretap -I/opt/csw/include -I/opt/csw/include -DG_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -D_U_="" -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include '-DPLUGIN_DIR="/opt/csw/lib/wireshark/plugins/1.8.6"' -xO3 -m32 -xarch=sparc -D_REENTRANT -D_PTHREADS -D_POSIX_PTHREAD_SEMANTICS -DXTHREADS -DXUSE_MTSAFE_API -I/opt/csw/include/gtk-2.0 -I/opt/csw/lib/gtk-2.0/include -I/opt/csw/include/atk-1.0 -I/opt/csw/include/cairo -I/opt/csw/include/gdk-pixbuf-2.0 -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -I/opt/csw/include -I/opt/csw/include/pixman-1 -I/opt/csw/include/freetype2 -I/opt/csw/include/libpng15 -c -o libgtkui_a-about_dlg.o `test -f 'about_dlg.c' || echo './'`about_dlg.c > > "/opt/csw/include/glib-2.0/gobject/gparam.h", line 158: warning: integer overflow detected: op "<<" > > "/opt/csw/include/pango-1.0/pango/pango-script.h", line 132: syntax error before or at: G_CONST_RETURN > > "/opt/csw/include/pango-1.0/pango/pango-script.h", line 132: warning: undefined or missing type for: G_CONST_RETURN G_CONST_RETURN was deprecated in glib version 2.30 [0] and since -DG_DISABLE_DEPRECATED is defined, G_CONST_RETURN won't be defined [1]. If you could get rid -DG_DISABLE_DEPRECATED, you most likely get rid of the error. cheers rafi [0] https://developer.gnome.org/glib/stable/glib-Standard-Macros.html#G-CONST-RETURN:CAPS [1] /opt/csw/include/glib-2.0/glib/gmacros.h From laurent at opencsw.org Mon Apr 15 16:33:49 2013 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 15 Apr 2013 16:33:49 +0200 Subject: [csw-maintainers] Missing definition of G_CONST_RETURN In-Reply-To: <20130415120920.GB1101@bender.opencsw.org> References: <42352C37-7AB0-46CD-84E3-C78C9AE61DAF@opencsw.org> <20130415120920.GB1101@bender.opencsw.org> Message-ID: <516C0FCD.9020607@opencsw.org> On 04/15/13 14:09, Rafael Ostertag wrote: > > G_CONST_RETURN was deprecated in glib version 2.30 [0] and since -DG_DISABLE_DEPRECATED is defined, G_CONST_RETURN > won't be defined [1]. > > If you could get rid -DG_DISABLE_DEPRECATED, you most likely get rid of the error. > It matches the workaround I just suggested for easytag: # This macro is being phased out of Pango, so this seems like an acceptable fix for now: # https://bugzilla.gnome.org/show_bug.cgi?id=652202 EXTRA_CFLAGS += -DG_CONST_RETURN=const Should it be added to all packages depending on Pango, just in case? Laurent From maciej at opencsw.org Mon Apr 15 19:11:07 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Mon, 15 Apr 2013 18:11:07 +0100 Subject: [csw-maintainers] Modifying check for /usr/share In-Reply-To: References: <5EB64F3B-3F08-44B0-A94C-12BB6047964A@opencsw.org> Message-ID: 2013/4/15 Dagobert Michelsen : > I would like to keep the check, there have been occasions where this was extremely useful > and helped point out issues which were gone by unnoticed. Taking out the known-to-be-good > pathes is IMHO the best way. OK, so we're keeping the check and adding a whitelist. The change needs to go as deep as metadata collection, because we're grepping for predetermined strings. We also need to figure out how to represent this, e.g. what's the outcome if we have two occurrences, one good and one bad; and what if the bad one is a substring of the good one (!). I'm not saying this is hard, just that it has to be programmed correctly (unit tests are strongly encouraged). One change will go into package_stats.py around line 29[1] where we define what we're grepping for. Except now not all regexes will be markers of 'bad' any more, so we might want to rename the variable. Then in package_checks.py line 773[2] there will be a modification which will apply some logic, where it'll look at what regexes matched and make a decision whether to throw an error or not. That's where tests are essential, because we need to make sure that we're covering both common and corner cases. I'm guessing it's a simple enough change, so I'll let you guys knock yourselves out with Python coding, but do send your patch out for review before you commit it. We make sure that the code is readable for other humans. Maciej [1] https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_stats.py#L29 [2] https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py#L773 From yann at pleiades.fr.eu.org Tue Apr 16 01:10:24 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Tue, 16 Apr 2013 01:10:24 +0200 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: <516BEA6D.7040102@opencsw.org> References: <516ABAC2.6000101@opencsw.org> <516BEA6D.7040102@opencsw.org> Message-ID: Hi Ihsan, Why did you comment the following line ? #CONFIGURE_ARGS = $(DIRPATHS) Without this line the "--prefix" option is not passed to configure hence everything is installed in /usr/local instead of /opt/csw. This seems to be the reason why some packages are empty: no library is found under /opt/csw for example. $ grep libunbound.so work/solaris10-sparc/build-global/prototype f none /usr/local/lib/libunbound.so.2.1.5 0755 root bin s none /usr/local/lib/libunbound.so.2=libunbound.so.2.1.5 s none /usr/local/lib/libunbound.so=libunbound.so.2.1.5 Yann 2013/4/15 ?hsan Do?an > Hi Yann, > > On 04/15/2013 06:51 AM, Yann Rouillard wrote: > > > When trying to package unbound to reproduce your problem, I've got the > > following error on i386: > > [...] > > > cc: Warning: illegal option -flto > > "util/storage/lookup3.c", line 76: unexpected ")" > > cc: acomp failed for util/storage/lookup3.c > > gmake: *** [lookup3.lo] Error 1 > > gmake: Leaving directory > > > `/home/yann/opencsw/unbound/trunk/work/solaris10-i386/build-isa-pentium_pro/unbound-1.4.20' > > gmake[1]: *** > > > [build-work/solaris10-i386/build-isa-pentium_pro/unbound-1.4.20/Makefile] > Error > > 2 > > gmake[1]: Leaving directory `/home/yann/opencsw/unbound/trunk' > > gmake: *** [merge-isa-pentium_pro] Error 2 > > > > > > You didn't have the same problem ? > > That's new to me. > This worked with earlier version on x86. But I have also to say, that > this time, I haven't tried to build it on x86. Sparc builds just fine. > > I'll have a look into this. > > > > > Ihsan > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Apr 16 13:54:38 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 16 Apr 2013 12:54:38 +0100 Subject: [csw-maintainers] Upgrade of SourceForge projects In-Reply-To: <82005EB5-B1CD-4E1D-90D7-DCEA1224B307@opencsw.org> References: <82005EB5-B1CD-4E1D-90D7-DCEA1224B307@opencsw.org> Message-ID: 2013/3/4 Dagobert Michelsen : > We must do a similar thing some time in the future for "gar" too, but as this also requires > moving our trac instance it is some time in the future, though. If you researched this, could you summarize what steps do we need to do? If we need to migrate, we can as well migrate now. Maciej From dam at opencsw.org Tue Apr 16 13:58:31 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Apr 2013 13:58:31 +0200 Subject: [csw-maintainers] Upgrade of SourceForge projects In-Reply-To: References: <82005EB5-B1CD-4E1D-90D7-DCEA1224B307@opencsw.org> Message-ID: Hi Maciej, Am 16.04.2013 um 13:54 schrieb Maciej (Matchek) Blizi?ski : > 2013/3/4 Dagobert Michelsen : >> We must do a similar thing some time in the future for "gar" too, but as this also requires >> moving our trac instance it is some time in the future, though. > > If you researched this, could you summarize what steps do we need to > do? If we need to migrate, we can as well migrate now. The current Allura platform from SourceForge cannot fully run Trac. However, they plan to support this. As the forced migration of projects starts soon I just put our project on the list of projects not to be migrated automatically unless Trac is available again. We can however move it to another platforms anytime if we wish to do so. 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 maciej at opencsw.org Tue Apr 16 14:04:35 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 16 Apr 2013 13:04:35 +0100 Subject: [csw-maintainers] Upgrade of SourceForge projects In-Reply-To: References: <82005EB5-B1CD-4E1D-90D7-DCEA1224B307@opencsw.org> Message-ID: 2013/4/16 Dagobert Michelsen : > The current Allura platform from SourceForge cannot fully run Trac. > However, they plan to support this. As the forced migration of projects > starts soon I just put our project on the list of projects not to be migrated > automatically unless Trac is available again. > > We can however move it to another platforms anytime if we wish to do so. How strongly do we depend on Trac? I use it a lot, but mostly for the timeline of recent updates and for browsing the code. There's a bug tracker, but I personally don't use it much. Both the timeline and code browsing can be done elsewhere, e.g. https://sourceforge.net/p/opencsw/code/661/log/ So as much as I like Trac, I also see that it's slow and the new platform is faster. Maciej From dam at opencsw.org Tue Apr 16 19:44:20 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 16 Apr 2013 19:44:20 +0200 Subject: [csw-maintainers] Problems building Botan (from #opencsw) In-Reply-To: References: Message-ID: <9CB60611-C1D6-4890-92B6-11271F26474B@opencsw.org> Hi Peter, (adding maintaienrs@ just in case there are C++ madmen around) Am 16.04.2013 um 17:35 schrieb Peter Bonivart : > I'm trying to build Botan, a crypto library similar to OpenSSL, which > is needed for BIND 10. Wow! "The core of botan is written in C++11" No support of C++11 in SolarisStudio 12.3: https://forums.oracle.com/forums/thread.jspa?messageID=10730210: "Studio 12.3 (C++ 5.12), currently in beta test, has no support for C++11. We will provide full support for C++11 in a future release." And only experimental support in gcc 4.8: http://gcc.gnu.org/gcc-4.8/cxx0x_status.html I guess this is going to be a bumpy ride :-D Best regards -- Dago > However, I get different errors on i386 and > sparc. > > The "mgar build" on i386 ends with lots of lines with this g++ error: > > g++: error: language chip=pentium_pro not recognized > gmake: *** [libbotan-1.10.so.0.5] Error 1 > gmake: Leaving directory > `/home/bonivart/opencsw/Botan/trunk/work/solaris10-i386/build-isa-pentium_pro/Botan-1.10.5' > gmake[1]: *** [build-work/solaris10-i386/build-isa-pentium_pro/Botan-1.10.5/Makefile] > Error 2 > gmake[1]: Leaving directory `/home/bonivart/opencsw/Botan/trunk' > gmake: *** [build-isa-pentium_pro] Error 2 > bonivart at unstable10x[trunk]$ > > On sparc I get this when configure runs: > > (cd work/solaris10-sparc/build-isa-sparcv8plus/Botan-1.10.5; \ > ./configure.py) > INFO: Guessing to use compiler gcc (use --cc to set) > INFO: Guessing target OS is sunos (use --os to set) > ERROR: Unknown or unidentifiable processor "sun4v" > gmake[1]: *** [configure-custom] Error 1 > gmake[1]: Leaving directory `/home/bonivart/opencsw/Botan/trunk' > gmake: *** [build-isa-sparcv8plus] Error 2 > bonivart at unstable10s[trunk]$ > > It's committed as Botan (capital B). -- "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 maciej at opencsw.org Wed Apr 17 11:03:01 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 17 Apr 2013 10:03:01 +0100 Subject: [csw-maintainers] GAR branches Message-ID: We have a number of GAR branches: bts/ v1/ v2/ v2-build64only/ v2-bwalton/ v2-defaultchange/ v2-fortran/ v2-ips/ v2-relocate/ v2-solaris11/ v2-speedup-fetch/ v2-sqlite/ v2-yann/ Are any of these branches stale or unused? If so, can they be removed? Maciej From maciej at opencsw.org Wed Apr 17 11:33:43 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 17 Apr 2013 10:33:43 +0100 Subject: [csw-maintainers] Catalog genration broken? In-Reply-To: References: <51537D77.9080503@opencsw.org> Message-ID: There's a defective package in the catalog, which is currently blocking generation. I've notified the maintainer. Unfortunately, I've just made pushes to kiel and beanie, so after the package is fixed, we'll have to push fixes to kiel and beanie too, before generation will start working again. From dam at opencsw.org Wed Apr 17 11:34:41 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 17 Apr 2013 11:34:41 +0200 Subject: [csw-maintainers] GAR branches In-Reply-To: References: Message-ID: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Hi Maciej, Am 17.04.2013 um 11:03 schrieb Maciej (Matchek) Blizi?ski : > We have a number of GAR branches: > > bts/ I am working on this one for bratislava, it should allow modifying prefix and install location. > v1/ This is a tag of the old release, it should stay for reference. > v2/ This is the main branch and must of course stay. > v2-build64only/ This was integrated in r16506 and r16965, I deleted it. > v2-bwalton/ This contains changes to makepatch. Ben? http://sourceforge.net/apps/trac/gar/changeset?new=10017%40csw%2Fmgar%2Fgar%2Fv2-bwalton&old=9772%40csw%2Fmgar%2Fgar%2Fv2 > v2-defaultchange/ This was integrated in r14023, I deleted in. > v2-fortran/ I think this was integrated. Geoff? http://sourceforge.net/apps/trac/gar/changeset?new=12516%40csw%2Fmgar%2Fgar%2Fv2-fortran&old=10862%40csw%2Fmgar%2Fgar%2Fv2 > v2-ips/ This contains some work towards IPS, I'll integrate later into one branch to consolidate. > v2-relocate/ This was for making relocatable packages which we don't do AFAIK, but it has been integrated AFAIR, Maciej? http://sourceforge.net/apps/trac/gar/changeset?new=8335%40csw%2Fmgar%2Fgar%2Fv2-relocate&old=4939%40csw%2Fmgar%2Fgar%2Fv2 > v2-solaris11/ These are python changes for building SVR4 packages on Solaris 11. AFAIK they have been integrated. Yann, Maciej? http://sourceforge.net/apps/trac/gar/changeset?new=18232%40csw%2Fmgar%2Fgar%2Fv2-solaris11&old=18080%40csw%2Fmgar%2Fgar%2Fv2 > v2-speedup-fetch/ This was done by Sebastian, it looks unfinished. http://sourceforge.net/apps/trac/gar/changeset?new=14200%40csw%2Fmgar%2Fgar%2Fv2-speedup-fetch&old=14158%40csw%2Fmgar%2Fgar%2Fv2 > v2-sqlite/ This contains some Python library changes by you, probably they have been integrated already: http://sourceforge.net/apps/trac/gar/changeset?new=10449%40csw%2Fmgar%2Fgar%2Fv2-sqlite&old=10433%40csw%2Fmgar%2Fgar%2Fv2 > v2-yann/ Contains lots of stuff. Yann? 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 jh at opencsw.org Wed Apr 17 14:11:12 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 17 Apr 2013 14:11:12 +0200 Subject: [csw-maintainers] Migration off the *x Servers In-Reply-To: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Message-ID: <516E9160.1030100@opencsw.org> Hi, I will migrate the *x Servers to a new esx host. Do to CPU change this includes an reboot. If anymone has a long running build job atm. Please let me know. Greetings Jan From jh at opencsw.org Wed Apr 17 15:31:04 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Wed, 17 Apr 2013 15:31:04 +0200 Subject: [csw-maintainers] Migration off the *x Servers In-Reply-To: <516E9160.1030100@opencsw.org> References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> <516E9160.1030100@opencsw.org> Message-ID: <516EA418.5060809@opencsw.org> Am 17.04.13 14:11, schrieb Jan Holzhueter: > Hi, > I will migrate the *x Servers to a new esx host. > Do to CPU change this includes an reboot. > If anymone has a long running build job atm. > Please let me know. I'm done. Greetings Jan From maciej at opencsw.org Wed Apr 17 18:42:21 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 17 Apr 2013 17:42:21 +0100 Subject: [csw-maintainers] Our mirror list is out of date Message-ID: The list of mirrors at http://www.opencsw.org/mirrors/ is out of date. Many mirrors are throwing 404, or DNS not resolved, or they have stale data. A much better place to check the mirrors is http://www.bonivart.com/opencsw/mirrorstatus - what about deleting the whole outdated text and adding a big link to Peter's page? Maciej From pfelecan at opencsw.org Wed Apr 17 19:30:21 2013 From: pfelecan at opencsw.org (Peter FELECAN) Date: Wed, 17 Apr 2013 19:30:21 +0200 Subject: [csw-maintainers] Our mirror list is out of date In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Wed, 17 Apr 2013 17:42:21 +0100") References: Message-ID: "Maciej (Matchek) Blizi?ski" writes: > The list of mirrors at http://www.opencsw.org/mirrors/ is out of date. > Many mirrors are throwing 404, or DNS not resolved, or they have stale > data. > > A much better place to check the mirrors is > http://www.bonivart.com/opencsw/mirrorstatus - what about deleting the > whole outdated text and adding a big link to Peter's page? Peter's page is nice and certainly up to date. The current page, hosted in our site has some merits though: it describes how to set up and use those mirrors. I think that a merge of these pages is the best solution. Is it possible to do it? What work it implies? -- Peter From laurent at opencsw.org Wed Apr 17 20:47:36 2013 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 17 Apr 2013 20:47:36 +0200 Subject: [csw-maintainers] Hello, List Message-ID: <516EEE48.4030209@opencsw.org> Hello all, Well, here's a quick introduction. I've been using Blastwave, then OpenCSW for years, and a few of you at least know I've been badgering^Wmaking useful sugggestions for about the same time. So I guess it was more than time that I got involved directly. There are two things in for me: I use some package in production, MySQL mostly, and some other tools like mbuffer. So I've helped improve those recently. I'm also still using Solaris as a home server, and rather than continue building stuff for myselflike I've done for years, I think it's better I contribute what I'm doing. Right now, I've just finished patches to build the latest version of vim, so I want to see how to push them in the tree. And then, I want to upgrade ScummVM (I've done the Solaris x86 package on scummvm.org for a few years, and let it slide lately, so I want to provide a new one). Laurent From maciej at opencsw.org Wed Apr 17 22:35:56 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 17 Apr 2013 21:35:56 +0100 Subject: [csw-maintainers] Our mirror list is out of date In-Reply-To: References: Message-ID: 2013/4/17 Peter FELECAN : > Peter's page is nice and certainly up to date. The current page, hosted > in our site has some merits though: it describes how to set up and use > those mirrors. I think that a merge of these pages is the best > solution. Is it possible to do it? What work it implies? I'm not sure about what work it implies, but what we can do for now is edit the page on the website to remove all the (potentially) stale links, and replace them with a prominent link to Peter's status page. In the long run we should get the status page running on our infrastructure. I'm guessing there's a cron job writing a HTML file. We could replace this with some form of writing to a database from which Wordpress would read and display. Maciej From ihsan at opencsw.org Thu Apr 18 08:25:03 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuIERvxJ9hbg==?=) Date: Thu, 18 Apr 2013 08:25:03 +0200 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: References: <516ABAC2.6000101@opencsw.org> <516BEA6D.7040102@opencsw.org> Message-ID: <516F91BF.7050402@opencsw.org> Hi Yann, On 04/16/2013 01:10 AM, Yann Rouillard wrote: > Why did you comment the following line ? > #CONFIGURE_ARGS = $(DIRPATHS) I've cleaned up before committing to svn and that was a typo. Fixed now. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From maciej at opencsw.org Thu Apr 18 10:29:55 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 18 Apr 2013 09:29:55 +0100 Subject: [csw-maintainers] GAR branches In-Reply-To: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Message-ID: Added my comments and added Cc: to people who need to respond. 2013/4/17 Dagobert Michelsen : >> bts/ > > I am working on this one for bratislava, it should allow modifying > prefix and install location. We will have to periodically rebase it if we don't want to go insane. >> v1/ > > This is a tag of the old release, it should stay for reference. Fair enough. Does it have to stay here? Maybe we can create something like the tags directory? Branches imply people are working on something. >> v2-bwalton/ > > This contains changes to makepatch. Ben? > http://sourceforge.net/apps/trac/gar/changeset?new=10017%40csw%2Fmgar%2Fgar%2Fv2-bwalton&old=9772%40csw%2Fmgar%2Fgar%2Fv2 > >> v2-fortran/ > > I think this was integrated. Geoff? > http://sourceforge.net/apps/trac/gar/changeset?new=12516%40csw%2Fmgar%2Fgar%2Fv2-fortran&old=10862%40csw%2Fmgar%2Fgar%2Fv2 > >> v2-ips/ > > This contains some work towards IPS, I'll integrate later into one branch to consolidate. > >> v2-relocate/ > > This was for making relocatable packages which we don't do AFAIK, but it has been > integrated AFAIR, Maciej? > http://sourceforge.net/apps/trac/gar/changeset?new=8335%40csw%2Fmgar%2Fgar%2Fv2-relocate&old=4939%40csw%2Fmgar%2Fgar%2Fv2 It wasn't me who was working on it. If we don't care about and/or actively work on relocatable packages, let's kill this branch. We could store the patch for future reference. >> v2-solaris11/ > > These are python changes for building SVR4 packages on Solaris 11. AFAIK they > have been integrated. Yann, Maciej? > http://sourceforge.net/apps/trac/gar/changeset?new=18232%40csw%2Fmgar%2Fgar%2Fv2-solaris11&old=18080%40csw%2Fmgar%2Fgar%2Fv2 I don't know of any outstanding changes that Yann has, but let's wait and see what he says. >> v2-speedup-fetch/ > > This was done by Sebastian, it looks unfinished. > http://sourceforge.net/apps/trac/gar/changeset?new=14200%40csw%2Fmgar%2Fgar%2Fv2-speedup-fetch&old=14158%40csw%2Fmgar%2Fgar%2Fv2 Most probably won't get finished. The change looks interesting and follows my general idea about moving logic away from GAR. On the other hand, I don't see fetching as a significant bottleneck. Maybe let's create a patch from this branch, and store it somewhere, while deleting the branch itself? >> v2-sqlite/ > > This contains some Python library changes by you, probably they > have been integrated already: > http://sourceforge.net/apps/trac/gar/changeset?new=10449%40csw%2Fmgar%2Fgar%2Fv2-sqlite&old=10433%40csw%2Fmgar%2Fgar%2Fv2 I can't remember what I wanted to do there. Deleted. >> v2-yann/ > > Contains lots of stuff. Yann? From maciej at opencsw.org Thu Apr 18 11:13:51 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 18 Apr 2013 10:13:51 +0100 Subject: [csw-maintainers] Hello, List In-Reply-To: <516EEE48.4030209@opencsw.org> References: <516EEE48.4030209@opencsw.org> Message-ID: 2013/4/17 Laurent Blume : > Well, here's a quick introduction. I've been using Blastwave, then OpenCSW > for years, and a few of you at least know I've been badgering^Wmaking useful > sugggestions for about the same time. So I guess it was more than time that > I got involved directly. Good to see you among OpenCSW maintainers! > There are two things in for me: I use some package in production, MySQL > mostly, and some other tools like mbuffer. So I've helped improve those > recently. > I'm also still using Solaris as a home server, and rather than continue > building stuff for myselflike I've done for years, I think it's better I > contribute what I'm doing. Very cool. This is how this community thrives. > Right now, I've just finished patches to build the latest version of vim, so > I want to see how to push them in the tree. And then, I want to upgrade > ScummVM (I've done the Solaris x86 package on scummvm.org for a few years, > and let it slide lately, so I want to provide a new one). Cool. I'll look at your patches sent to users@ and will provide my feedback. Maciej From dam at opencsw.org Thu Apr 18 14:49:52 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 14:49:52 +0200 Subject: [csw-maintainers] GAR branches In-Reply-To: References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Message-ID: Hi Mqciej, Am 18.04.2013 um 10:29 schrieb Maciej (Matchek) Blizi?ski: > Added my comments and added Cc: to people who need to respond. > > 2013/4/17 Dagobert Michelsen : >>> bts/ >> >> I am working on this one for bratislava, it should allow modifying >> prefix and install location. > > We will have to periodically rebase it if we don't want to go insane. Yes :-) >>> v1/ >> >> This is a tag of the old release, it should stay for reference. > > Fair enough. Does it have to stay here? Maybe we can create something > like the tags directory? Branches imply people are working on > something. Well, the gar "versions" below mgar/gar are basically tags and I don't see a point in moving it anywhere else apart from making things more obstruct. I made some further investigations on the specific branches and deleted most of them as explained below. >>> v2-bwalton/ >> >> This contains changes to makepatch. Ben? >> http://sourceforge.net/apps/trac/gar/changeset?new=10017%40csw%2Fmgar%2Fgar%2Fv2-bwalton&old=9772%40csw%2Fmgar%2Fgar%2Fv2 This was integrated in r10012: https://sourceforge.net/apps/trac/gar/changeset/10012 There was one other commit on the branch in r10017 https://sourceforge.net/apps/trac/gar/changeset/10017 which looks erranously and was directly applied to v2 afterwards without merging in r10018: https://sourceforge.net/apps/trac/gar/changeset/10018 @Ben: I deleted the branch as everything was merged, please make a new branch if required. >>> v2-fortran/ >> >> I think this was integrated. Geoff? >> http://sourceforge.net/apps/trac/gar/changeset?new=12516%40csw%2Fmgar%2Fgar%2Fv2-fortran&old=10862%40csw%2Fmgar%2Fgar%2Fv2 This was integrated in r12517: https://sourceforge.net/apps/trac/gar/changeset/12517 Therefore I removed v2-fortran. >> >>> v2-ips/ >> >> This contains some work towards IPS, I'll integrate later into one branch to consolidate. >> >>> v2-relocate/ >> >> This was for making relocatable packages which we don't do AFAIK, but it has been >> integrated AFAIR, Maciej? >> http://sourceforge.net/apps/trac/gar/changeset?new=8335%40csw%2Fmgar%2Fgar%2Fv2-relocate&old=4939%40csw%2Fmgar%2Fgar%2Fv2 > > It wasn't me who was working on it. If we don't care about and/or > actively work on relocatable packages, let's kill this branch. We > could store the patch for future reference. The branch has been integrated into v2 in r11739: https://sourceforge.net/apps/trac/gar/changeset/11739 Therefore I removed v2-relocate/. >>> v2-solaris11/ >> >> These are python changes for building SVR4 packages on Solaris 11. AFAIK they >> have been integrated. Yann, Maciej? >> http://sourceforge.net/apps/trac/gar/changeset?new=18232%40csw%2Fmgar%2Fgar%2Fv2-solaris11&old=18080%40csw%2Fmgar%2Fgar%2Fv2 > > I don't know of any outstanding changes that Yann has, but let's wait > and see what he says. > >>> v2-speedup-fetch/ >> >> This was done by Sebastian, it looks unfinished. >> http://sourceforge.net/apps/trac/gar/changeset?new=14200%40csw%2Fmgar%2Fgar%2Fv2-speedup-fetch&old=14158%40csw%2Fmgar%2Fgar%2Fv2 > > Most probably won't get finished. The change looks interesting and > follows my general idea about moving logic away from GAR. On the other > hand, I don't see fetching as a significant bottleneck. Maybe let's > create a patch from this branch, and store it somewhere, while > deleting the branch itself? I would just keep it in place until someone picks it up. I just don't see a downside of leaving it here. >>> v2-sqlite/ >> >> This contains some Python library changes by you, probably they >> have been integrated already: >> http://sourceforge.net/apps/trac/gar/changeset?new=10449%40csw%2Fmgar%2Fgar%2Fv2-sqlite&old=10433%40csw%2Fmgar%2Fgar%2Fv2 > > I can't remember what I wanted to do there. Deleted. > >>> v2-yann/ >> >> Contains lots of stuff. Yann? Best regards -- Dago From dam at opencsw.org Thu Apr 18 14:57:38 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 14:57:38 +0200 Subject: [csw-maintainers] Our mirror list is out of date In-Reply-To: References: Message-ID: Hi, Am 17.04.2013 um 22:35 schrieb Maciej (Matchek) Blizi?ski: > 2013/4/17 Peter FELECAN : >> Peter's page is nice and certainly up to date. The current page, hosted >> in our site has some merits though: it describes how to set up and use >> those mirrors. I think that a merge of these pages is the best >> solution. Is it possible to do it? What work it implies? > > I'm not sure about what work it implies, but what we can do for now is > edit the page on the website to remove all the (potentially) stale > links, and replace them with a prominent link to Peter's status page. > > In the long run we should get the status page running on our > infrastructure. I'm guessing there's a cron job writing a HTML file. > We could replace this with some form of writing to a database from > which Wordpress would read and display. I installed Peters script on the primary mirror some time ago: http://mirror.opencsw.org/status/ The list is also kept in sync with the official mirror list on the orga-wiki: http://opencsw-orga.wikidot.com/mirror-status (Sorry, free wiki only supports 5 people on restricted wikis and as the list contains upstream mirror maintainer names and emails I don't want to make that real public) I already tried to integrated that into Wordpress, but my WP/PHP foo is too weak. The data is there, if someone volunteers I can gladly help providing all status information. Best regards -- Dago From dam at opencsw.org Thu Apr 18 15:00:22 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 15:00:22 +0200 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: References: Message-ID: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> Hi Yahav, (moving to maintainers@ as you now have an acocount there) Am 16.04.2013 um 18:33 schrieb BIRAN, Yahav (Yahav): > All the required credentials ae in place. > > Can you please help me understand how one can upload the package ceated > to one of the build-frams. > Please note that my intention isto be able to allow our puppet script a > seamless updat of the zabbix packags. You need to finish building the packages without errors on checkpkg. Then you can upload the packages from "login" with csw-upload-pkg ... You must upload all packages depending on each other and all platforms in one go or the upload will not be allowed and stops before publishing. Best regards -- Dago From laurent at opencsw.org Thu Apr 18 15:36:22 2013 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 18 Apr 2013 15:36:22 +0200 Subject: [csw-maintainers] Hello, List In-Reply-To: References: <516EEE48.4030209@opencsw.org> Message-ID: <516FF6D6.4090909@opencsw.org> On 04/18/13 11:13, Maciej (Matchek) Blizi?ski wrote: >> Right now, I've just finished patches to build the latest version of vim, so >> I want to see how to push them in the tree. And then, I want to upgrade >> ScummVM (I've done the Solaris x86 package on scummvm.org for a few years, >> and let it slide lately, so I want to provide a new one). > > Cool. I'll look at your patches sent to users@ and will provide my feedback. You can wait a little more for vim: I've prepared an improved one. I got a patch accepted upstream that removes the need for one of the modifications I had done, and noticed another glitch. I've fixed it on x86, and I'm checking it on the build farm now to make sure it's good on sparc too. So I'll post a newer version this evening if all goes well. Laurent From maciej at opencsw.org Thu Apr 18 20:03:14 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 18 Apr 2013 19:03:14 +0100 Subject: [csw-maintainers] Our mirror list is out of date In-Reply-To: References: Message-ID: 2013/4/18 Dagobert Michelsen > > I installed Peters script on the primary mirror some time ago: > http://mirror.opencsw.org/status/ Cool! I rewrote the mirror page: http://www.opencsw.org/get-it/mirrors/ Did I break the GPG public key code again? I hope not! From yahavb at opencsw.org Thu Apr 18 20:11:04 2013 From: yahavb at opencsw.org (Yahav BIRAN @ openCSW) Date: Thu, 18 Apr 2013 11:11:04 -0700 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> Message-ID: <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> Thank you, Can you please let me know what does it means "login" host? Do I need to manually upload the files to somewhere and run the csw-upload-pkg command? Or do I need to run the local instance of the csw-upload-pkg? if so what version? I found several: -bash-3.2$ find /home/ybiran/ -name "csw-upload*" /home/ybiran/opencsw/.buildsys/v2/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/v2-speedup-fetch/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/v2-ips/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/v2-defaultchange/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/v2-solaris11/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/v2-build64only/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/bts/bin/csw-upload-pkg /home/ybiran/opencsw/.buildsys/v2-yann/bin/csw-upload-pkg /home/ybiran/opencsw/libicu48/tags/SR3-6627678431/gar/bin/csw-upload-pkg when I tried one of it I got the following: -bash-3.2$ /home/ybiran/opencsw/.buildsys/v2/bin/csw-upload-pkg WARNING:root:This script is meant to be run on the login host. Usage: csw-upload-pkg [ options ] [ [ ... ] ] I was trying to look for more details about the "login" host in http://wiki.opencsw.org/automated-release-process but i couldn't figure out where to stat. Please advise, thank you On Apr 18, 2013, at 6:00 AM, Dagobert Michelsen wrote: > Hi Yahav, > > (moving to maintainers@ as you now have an acocount there) > > Am 16.04.2013 um 18:33 schrieb BIRAN, Yahav (Yahav): >> All the required credentials ae in place. >> >> Can you please help me understand how one can upload the package ceated >> to one of the build-frams. >> Please note that my intention isto be able to allow our puppet script a >> seamless updat of the zabbix packags. > > You need to finish building the packages without errors on checkpkg. Then > you can upload the packages from "login" with > csw-upload-pkg ... > You must upload all packages depending on each other and all platforms > in one go or the upload will not be allowed and stops before publishing. > > > Best regards > > -- Dago > _______________________________________________ > 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 Thu Apr 18 20:37:15 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 20:37:15 +0200 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> Message-ID: <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> Hi Yahav, Am 18.04.2013 um 20:11 schrieb Yahav BIRAN @ openCSW: > Can you please let me know what does it means "login" host? Well, the host named "login" as described in /etc/SETUP which you read, right? ;-) > Do I need to manually upload the files to somewhere and run the csw-upload-pkg command? > Or do I need to run the local instance of the csw-upload-pkg? if so what version? I found several: No, you just run csw-upload-pkg located in /opt/csw/bin which should be in your path. This uploads and publishes the package. Best regards -- Dago From yahavb at opencsw.org Thu Apr 18 20:56:47 2013 From: yahavb at opencsw.org (Yahav BIRAN @ openCSW) Date: Thu, 18 Apr 2013 11:56:47 -0700 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> Message-ID: <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> Hi Dago, Yes I read it (but i forgot about it?.:)) Thank you, Now when I upload it I get some errors regards to i386, when i specify the ARCH to spark only it get even worse? Do I need to specify the ARCH option? if so with what value other than sparc? As for the bad-vednor-tag, how this can be populated? with what value? yahavb at login [login]:~ > csw-upload-pkg zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz There is a problem with the presented file list. * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'zabbix_agent') * CheckpkgTag(None, 'bad-vendor-tag', 'filename=zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz expected=CSW actual=UNCOMMITTED') yahavb at login [login]:~ > csw-upload-pkg ARCH=sparc zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz There is a problem with the presented file list. * CheckpkgTag(None, 'bad-arch-or-os-release', 'ARCH=sparc arch=unknown osrel=unspecified') * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'zabbix_agent') * CheckpkgTag(None, 'i386-unspecified-missing', 'zabbix_agent') * CheckpkgTag(None, 'sparc-unspecified-missing', 'zabbix_agent') * CheckpkgTag(None, 'bad-vendor-tag', 'filename=ARCH=sparc expected=CSW actual=UNKN') * CheckpkgTag(None, 'bad-vendor-tag', 'filename=zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz expected=CSW actual=UNCOMMITTED') * CheckpkgTag(None, 'bad-filename', 'filename=ARCH=sparc') On Apr 18, 2013, at 11:37 AM, Dagobert Michelsen wrote: > Hi Yahav, > > Am 18.04.2013 um 20:11 schrieb Yahav BIRAN @ openCSW: >> Can you please let me know what does it means "login" host? > > Well, the host named "login" as described in /etc/SETUP which you read, right? ;-) > >> Do I need to manually upload the files to somewhere and run the csw-upload-pkg command? >> Or do I need to run the local instance of the csw-upload-pkg? if so what version? I found several: > > No, you just run csw-upload-pkg located in /opt/csw/bin which should be in your path. > This uploads and publishes the package. > > > Best regards > > -- Dago > > _______________________________________________ > 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 Thu Apr 18 21:05:02 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 21:05:02 +0200 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> Message-ID: <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> Hi Yahav, Am 18.04.2013 um 20:56 schrieb Yahav BIRAN @ openCSW: > Yes I read it (but i forgot about it?.:)) Thank you, > Now when I upload it I get some errors regards to i386, when i specify the ARCH to spark only it get even worse? > > Do I need to specify the ARCH option? if so with what value other than sparc? > > As for the bad-vednor-tag, how this can be populated? with what value? Do not specify an ARCH. Make sure to commit everything (check with "svn status", there must be no output) before the final packaging. You must always upload all architectures and platforms, which usually is sparc and i386 on 5.10. Best regards -- Dago > > > yahavb at login [login]:~ > csw-upload-pkg zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz > There is a problem with the presented file list. > * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'zabbix_agent') > * CheckpkgTag(None, 'bad-vendor-tag', 'filename=zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz expected=CSW actual=UNCOMMITTED') > yahavb at login [login]:~ > csw-upload-pkg ARCH=sparc zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz > There is a problem with the presented file list. > * CheckpkgTag(None, 'bad-arch-or-os-release', 'ARCH=sparc arch=unknown osrel=unspecified') > * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'zabbix_agent') > * CheckpkgTag(None, 'i386-unspecified-missing', 'zabbix_agent') > * CheckpkgTag(None, 'sparc-unspecified-missing', 'zabbix_agent') > * CheckpkgTag(None, 'bad-vendor-tag', 'filename=ARCH=sparc expected=CSW actual=UNKN') > * CheckpkgTag(None, 'bad-vendor-tag', 'filename=zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz expected=CSW actual=UNCOMMITTED') > * CheckpkgTag(None, 'bad-filename', 'filename=ARCH=sparc') > > > On Apr 18, 2013, at 11:37 AM, Dagobert Michelsen wrote: > >> Hi Yahav, >> >> Am 18.04.2013 um 20:11 schrieb Yahav BIRAN @ openCSW: >>> Can you please let me know what does it means "login" host? >> >> Well, the host named "login" as described in /etc/SETUP which you read, right? ;-) >> >>> Do I need to manually upload the files to somewhere and run the csw-upload-pkg command? >>> Or do I need to run the local instance of the csw-upload-pkg? if so what version? I found several: >> >> No, you just run csw-upload-pkg located in /opt/csw/bin which should be in your path. >> This uploads and publishes the package. >> >> >> Best regards >> >> -- Dago >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From yahavb at opencsw.org Thu Apr 18 21:09:42 2013 From: yahavb at opencsw.org (Yahav BIRAN @ openCSW) Date: Thu, 18 Apr 2013 12:09:42 -0700 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> Message-ID: Thank you, In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 I guess it should be included. Do I need to get two different packages for each arch? Here is the prints from the packaging job: INFO:root:Juicing the svr4 package stream files... 100% |###############################################################################################| INFO:root:Unwrapping candies... 100% |###############################################################################################| INFO:root:Tasting candies one by one... 100% |###############################################################################################| INFO:root:Tasting them all at once... INFO:root:Stuffing the candies under the pillow... 100% |###############################################################################################| CSWzabbix-agent: CSWzabbix-server: The following packages have been built: CSWzabbix-agent /home/ybiran/staging/build-18.Apr.2013/zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz CSWzabbix-server /home/ybiran/staging/build-18.Apr.2013/zabbix_server-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz [package] complete for zabbix. Thank you, On Apr 18, 2013, at 12:05 PM, Dagobert Michelsen wrote: > Hi Yahav, > > Am 18.04.2013 um 20:56 schrieb Yahav BIRAN @ openCSW: >> Yes I read it (but i forgot about it?.:)) Thank you, >> Now when I upload it I get some errors regards to i386, when i specify the ARCH to spark only it get even worse? >> >> Do I need to specify the ARCH option? if so with what value other than sparc? >> >> As for the bad-vednor-tag, how this can be populated? with what value? > > Do not specify an ARCH. Make sure to commit everything (check with "svn status", there > must be no output) before the final packaging. You must always upload all architectures > and platforms, which usually is sparc and i386 on 5.10. > > > Best regards > > -- Dago > >> >> >> yahavb at login [login]:~ > csw-upload-pkg zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz >> There is a problem with the presented file list. >> * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'zabbix_agent') >> * CheckpkgTag(None, 'bad-vendor-tag', 'filename=zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz expected=CSW actual=UNCOMMITTED') >> yahavb at login [login]:~ > csw-upload-pkg ARCH=sparc zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz >> There is a problem with the presented file list. >> * CheckpkgTag(None, 'bad-arch-or-os-release', 'ARCH=sparc arch=unknown osrel=unspecified') >> * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'zabbix_agent') >> * CheckpkgTag(None, 'i386-unspecified-missing', 'zabbix_agent') >> * CheckpkgTag(None, 'sparc-unspecified-missing', 'zabbix_agent') >> * CheckpkgTag(None, 'bad-vendor-tag', 'filename=ARCH=sparc expected=CSW actual=UNKN') >> * CheckpkgTag(None, 'bad-vendor-tag', 'filename=zabbix_agent-2.0.5,REV=2013.04.18-SunOS5.10-sparc-UNCOMMITTED.pkg.gz expected=CSW actual=UNCOMMITTED') >> * CheckpkgTag(None, 'bad-filename', 'filename=ARCH=sparc') >> >> >> On Apr 18, 2013, at 11:37 AM, Dagobert Michelsen wrote: >> >>> Hi Yahav, >>> >>> Am 18.04.2013 um 20:11 schrieb Yahav BIRAN @ openCSW: >>>> Can you please let me know what does it means "login" host? >>> >>> Well, the host named "login" as described in /etc/SETUP which you read, right? ;-) >>> >>>> Do I need to manually upload the files to somewhere and run the csw-upload-pkg command? >>>> Or do I need to run the local instance of the csw-upload-pkg? if so what version? I found several: >>> >>> No, you just run csw-upload-pkg located in /opt/csw/bin which should be in your path. >>> This uploads and publishes the package. >>> >>> >>> Best regards >>> >>> -- Dago >>> >>> _______________________________________________ >>> maintainers mailing list >>> maintainers at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/maintainers >>> .:: This mailing list's archive is public. ::. >>> >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > _______________________________________________ > 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 Thu Apr 18 21:13:43 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 21:13:43 +0200 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> Message-ID: Hi Yahav, Am 18.04.2013 um 21:09 schrieb Yahav BIRAN @ openCSW: > Thank you, > In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 This is not needed as it is the default anyway. > I guess it should be included. > Do I need to get two different packages for each arch? Yes. Please see the "platforms" target in the target reference: https://sourceforge.net/apps/trac/gar/wiki/GAR%20Build%20Targets%20Reference Best regards -- Dago From yahavb at opencsw.org Thu Apr 18 21:25:24 2013 From: yahavb at opencsw.org (Yahav BIRAN @ openCSW) Date: Thu, 18 Apr 2013 12:25:24 -0700 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> Message-ID: <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> Hi Dago, Based on the wiki, platforms Executes the whole build and package process for all possible platforms (i.e. x86 and SPARC) not just the one which you are currently on. Requires build hosts for those different architectures (the OpenCSW build farm has these pre-configured). I will need to do redo the entire packaging process on another type of machine but x86 or i386 in order to finish the upload. Is it correct? if so what will be the required platform? solaris10-i386? any other platform that may be required? If I don't have host that is occupied with i386 what should I do? yahav On Apr 18, 2013, at 12:13 PM, Dagobert Michelsen wrote: > Hi Yahav, > > Am 18.04.2013 um 21:09 schrieb Yahav BIRAN @ openCSW: >> Thank you, >> In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 > > This is not needed as it is the default anyway. > >> I guess it should be included. >> Do I need to get two different packages for each arch? > > Yes. Please see the "platforms" target in the target reference: > https://sourceforge.net/apps/trac/gar/wiki/GAR%20Build%20Targets%20Reference > > > Best regards > > -- Dago > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Thu Apr 18 21:27:15 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 18 Apr 2013 21:27:15 +0200 Subject: [csw-maintainers] GAR branches In-Reply-To: References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Message-ID: Hi, >>> v2-solaris11/ > >> > >> These are python changes for building SVR4 packages on Solaris 11. > AFAIK they > >> have been integrated. Yann, Maciej? > >> > http://sourceforge.net/apps/trac/gar/changeset?new=18232%40csw%2Fmgar%2Fgar%2Fv2-solaris11&old=18080%40csw%2Fmgar%2Fgar%2Fv2 > > > > I don't know of any outstanding changes that Yann has, but let's wait > > and see what he says. > It can be dropped. Changes were integrated. > >>> v2-yann/ > >> > >> Contains lots of stuff. Yann? > Can be dropped also. Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Apr 18 21:30:06 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 21:30:06 +0200 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> Message-ID: Hi Yahav, Am 18.04.2013 um 21:25 schrieb Yahav BIRAN @ openCSW: > Based on the wiki, > platforms > Executes the whole build and package process for all possible platforms (i.e. x86 and SPARC) not just the one which you are currently on. Requires build hosts for those different architectures (the OpenCSW build farm has these pre-configured). > I will need to do redo the entire packaging process on another type of machine but x86 or i386 in order to finish the upload. > Is it correct? "platforms" or "replatforms" does this automatically. > if so what will be the required platform? solaris10-i386? any other platform that may be required? Everything that was specified in PACKAGING_PLATFORMS, usually yes. > If I don't have host that is occupied with i386 what should I do? You are aware that all packages to be pushed *must* be build on the OpenCSW buildfarm, right? We have all kinds of hosts there. Best reagrds -- Dago > > yahav > > > > On Apr 18, 2013, at 12:13 PM, Dagobert Michelsen wrote: > >> Hi Yahav, >> >> Am 18.04.2013 um 21:09 schrieb Yahav BIRAN @ openCSW: >>> Thank you, >>> In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 >> >> This is not needed as it is the default anyway. >> >>> I guess it should be included. >>> Do I need to get two different packages for each arch? >> >> Yes. Please see the "platforms" target in the target reference: >> https://sourceforge.net/apps/trac/gar/wiki/GAR%20Build%20Targets%20Reference >> >> >> Best regards >> >> -- Dago >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yahavb at opencsw.org Thu Apr 18 21:37:23 2013 From: yahavb at opencsw.org (Yahav BIRAN @ openCSW) Date: Thu, 18 Apr 2013 12:37:23 -0700 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> Message-ID: Thank you, I think I am loosing you here, I was trying to execute: /opt/csw/bin/mgar package platforms /opt/csw/bin/mgar platforms /opt/csw/bin/mgar package platforms xhs1.xdev.motive.com all these executions yields errors. What does it means "platforms" or "replatforms" does this automatically.? how those can be used? On Apr 18, 2013, at 12:30 PM, Dagobert Michelsen wrote: > Hi Yahav, > > Am 18.04.2013 um 21:25 schrieb Yahav BIRAN @ openCSW: >> Based on the wiki, >> platforms >> Executes the whole build and package process for all possible platforms (i.e. x86 and SPARC) not just the one which you are currently on. Requires build hosts for those different architectures (the OpenCSW build farm has these pre-configured). >> I will need to do redo the entire packaging process on another type of machine but x86 or i386 in order to finish the upload. >> Is it correct? > "platforms" or "replatforms" does this automatically. > >> if so what will be the required platform? solaris10-i386? any other platform that may be required? > > Everything that was specified in PACKAGING_PLATFORMS, usually yes. > >> If I don't have host that is occupied with i386 what should I do? > > You are aware that all packages to be pushed *must* be build on the OpenCSW buildfarm, right? > We have all kinds of hosts there. > > > Best reagrds > > -- Dago > >> >> yahav >> >> >> >> On Apr 18, 2013, at 12:13 PM, Dagobert Michelsen wrote: >> >>> Hi Yahav, >>> >>> Am 18.04.2013 um 21:09 schrieb Yahav BIRAN @ openCSW: >>>> Thank you, >>>> In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 >>> >>> This is not needed as it is the default anyway. >>> >>>> I guess it should be included. >>>> Do I need to get two different packages for each arch? >>> >>> Yes. Please see the "platforms" target in the target reference: >>> https://sourceforge.net/apps/trac/gar/wiki/GAR%20Build%20Targets%20Reference >>> >>> >>> Best regards >>> >>> -- Dago >>> _______________________________________________ >>> maintainers mailing list >>> maintainers at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/maintainers >>> .:: This mailing list's archive is public. ::. >>> >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Apr 18 21:44:36 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 18 Apr 2013 21:44:36 +0200 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> Message-ID: <7050CCA0-E238-4D07-A569-3635CD02C13A@opencsw.org> Hi Yahav, Am 18.04.2013 um 21:37 schrieb Yahav BIRAN @ openCSW: > I think I am loosing you here, > > I was trying to execute: > > /opt/csw/bin/mgar package platforms "platforms" includes package for all platforms. For details see https://sourceforge.net/apps/trac/gar/wiki/Platforms > /opt/csw/bin/mgar platforms This should work. > /opt/csw/bin/mgar package platforms xhs1.xdev.motive.com > all these executions yields errors. You seem to build outside the buildfarm. Setting up platforms is advanced stuff. If you plan to set this up make sure to watch at least the screencast about platforms at https://www.opencsw.org/category/announcements/ > What does it means "platforms" or "replatforms" does this automatically.? how those can be used? Hop over to all machines necessary to build and merge everything. Please also make sure to watch the "modulations" screencast with special attention to the integration of i386 on 9 and amd64 on 10. I suggest you just stay on the farm because you need to build there anyway. Best regards -- Dago > > > > On Apr 18, 2013, at 12:30 PM, Dagobert Michelsen wrote: > >> Hi Yahav, >> >> Am 18.04.2013 um 21:25 schrieb Yahav BIRAN @ openCSW: >>> Based on the wiki, >>> platforms >>> Executes the whole build and package process for all possible platforms (i.e. x86 and SPARC) not just the one which you are currently on. Requires build hosts for those different architectures (the OpenCSW build farm has these pre-configured). >>> I will need to do redo the entire packaging process on another type of machine but x86 or i386 in order to finish the upload. >>> Is it correct? >> "platforms" or "replatforms" does this automatically. >> >>> if so what will be the required platform? solaris10-i386? any other platform that may be required? >> >> Everything that was specified in PACKAGING_PLATFORMS, usually yes. >> >>> If I don't have host that is occupied with i386 what should I do? >> >> You are aware that all packages to be pushed *must* be build on the OpenCSW buildfarm, right? >> We have all kinds of hosts there. >> >> >> Best reagrds >> >> -- Dago >> >>> >>> yahav >>> >>> >>> >>> On Apr 18, 2013, at 12:13 PM, Dagobert Michelsen wrote: >>> >>>> Hi Yahav, >>>> >>>> Am 18.04.2013 um 21:09 schrieb Yahav BIRAN @ openCSW: >>>>> Thank you, >>>>> In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 >>>> >>>> This is not needed as it is the default anyway. >>>> >>>>> I guess it should be included. >>>>> Do I need to get two different packages for each arch? >>>> >>>> Yes. Please see the "platforms" target in the target reference: >>>> https://sourceforge.net/apps/trac/gar/wiki/GAR%20Build%20Targets%20Reference >>>> >>>> >>>> Best regards >>>> >>>> -- Dago >>>> _______________________________________________ >>>> maintainers mailing list >>>> maintainers at lists.opencsw.org >>>> https://lists.opencsw.org/mailman/listinfo/maintainers >>>> .:: This mailing list's archive is public. ::. >>>> >>> >>> _______________________________________________ >>> maintainers mailing list >>> maintainers at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/maintainers >>> .:: This mailing list's archive is public. ::. >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yahavb at opencsw.org Thu Apr 18 21:51:26 2013 From: yahavb at opencsw.org (Yahav BIRAN @ openCSW) Date: Thu, 18 Apr 2013 12:51:26 -0700 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <7050CCA0-E238-4D07-A569-3635CD02C13A@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> <7050CCA0-E238-4D07-A569-3635CD02C13A@opencsw.org> Message-ID: Hi Dago, Do you know what will be the value of the host that is required by the error below? -bash-3.2$ /opt/csw/bin/mgar platforms /home/ybiran/opencsw/.buildsys/v2/gar//gar.pkg.mk:1060: *** *** No host has been defined for platform solaris10-sparc. Stop. I am working on the host I was doing the entire packaging. DId you mean that the /opt/csw/bin/mgar platforms command should be executed on this machine or another one? If so what machine? On Apr 18, 2013, at 12:44 PM, Dagobert Michelsen wrote: > Hi Yahav, > > Am 18.04.2013 um 21:37 schrieb Yahav BIRAN @ openCSW: >> I think I am loosing you here, >> >> I was trying to execute: >> >> /opt/csw/bin/mgar package platforms > > "platforms" includes package for all platforms. For details see > https://sourceforge.net/apps/trac/gar/wiki/Platforms > >> /opt/csw/bin/mgar platforms > > This should work. > >> /opt/csw/bin/mgar package platforms xhs1.xdev.motive.com >> all these executions yields errors. > > You seem to build outside the buildfarm. Setting up platforms is advanced stuff. > If you plan to set this up make sure to watch at least the screencast about > platforms at > https://www.opencsw.org/category/announcements/ > > >> What does it means "platforms" or "replatforms" does this automatically.? how those can be used? > > Hop over to all machines necessary to build and merge everything. > Please also make sure to watch the "modulations" screencast with special > attention to the integration of i386 on 9 and amd64 on 10. > > I suggest you just stay on the farm because you need to build there anyway. > > > Best regards > > -- Dago > >> >> >> >> On Apr 18, 2013, at 12:30 PM, Dagobert Michelsen wrote: >> >>> Hi Yahav, >>> >>> Am 18.04.2013 um 21:25 schrieb Yahav BIRAN @ openCSW: >>>> Based on the wiki, >>>> platforms >>>> Executes the whole build and package process for all possible platforms (i.e. x86 and SPARC) not just the one which you are currently on. Requires build hosts for those different architectures (the OpenCSW build farm has these pre-configured). >>>> I will need to do redo the entire packaging process on another type of machine but x86 or i386 in order to finish the upload. >>>> Is it correct? >>> "platforms" or "replatforms" does this automatically. >>> >>>> if so what will be the required platform? solaris10-i386? any other platform that may be required? >>> >>> Everything that was specified in PACKAGING_PLATFORMS, usually yes. >>> >>>> If I don't have host that is occupied with i386 what should I do? >>> >>> You are aware that all packages to be pushed *must* be build on the OpenCSW buildfarm, right? >>> We have all kinds of hosts there. >>> >>> >>> Best reagrds >>> >>> -- Dago >>> >>>> >>>> yahav >>>> >>>> >>>> >>>> On Apr 18, 2013, at 12:13 PM, Dagobert Michelsen wrote: >>>> >>>>> Hi Yahav, >>>>> >>>>> Am 18.04.2013 um 21:09 schrieb Yahav BIRAN @ openCSW: >>>>>> Thank you, >>>>>> In the Makefile I specified: PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 >>>>> >>>>> This is not needed as it is the default anyway. >>>>> >>>>>> I guess it should be included. >>>>>> Do I need to get two different packages for each arch? >>>>> >>>>> Yes. Please see the "platforms" target in the target reference: >>>>> https://sourceforge.net/apps/trac/gar/wiki/GAR%20Build%20Targets%20Reference >>>>> >>>>> >>>>> Best regards >>>>> >>>>> -- Dago >>>>> _______________________________________________ >>>>> maintainers mailing list >>>>> maintainers at lists.opencsw.org >>>>> https://lists.opencsw.org/mailman/listinfo/maintainers >>>>> .:: This mailing list's archive is public. ::. >>>>> >>>> >>>> _______________________________________________ >>>> maintainers mailing list >>>> maintainers at lists.opencsw.org >>>> https://lists.opencsw.org/mailman/listinfo/maintainers >>>> .:: This mailing list's archive is public. ::. >>> >>> _______________________________________________ >>> maintainers mailing list >>> maintainers at lists.opencsw.org >>> https://lists.opencsw.org/mailman/listinfo/maintainers >>> .:: This mailing list's archive is public. ::. >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Thu Apr 18 21:52:06 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 18 Apr 2013 20:52:06 +0100 Subject: [csw-maintainers] [csw-users] SUCCESS building zabbix 2.0.5 In-Reply-To: <7050CCA0-E238-4D07-A569-3635CD02C13A@opencsw.org> References: <1AC5BC73-0705-4D91-A22E-09EB0FAB7428@opencsw.org> <391E89E1-389D-4ACC-8F4E-7E3B1804B2BD@opencsw.org> <611A92C7-C52E-4DE7-8600-0EAF92FCFCAF@opencsw.org> <501B0A37-BE71-4192-9566-A1EDF1422B52@opencsw.org> <268CF914-38D4-44A1-9AB4-5F817A66F7F5@opencsw.org> <587895D8-E028-41A1-A4BC-101FDB9920C2@opencsw.org> <7050CCA0-E238-4D07-A569-3635CD02C13A@opencsw.org> Message-ID: Hi Yahav, Looks like it would be faster and easier to talk if you came over to our IRC channel. Hop on to #opencsw on Freenode! http://www.opencsw.org/support/irc-channel/ Maciej From bwalton at opencsw.org Thu Apr 18 23:36:56 2013 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 18 Apr 2013 22:36:56 +0100 Subject: [csw-maintainers] GAR branches In-Reply-To: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Message-ID: On Wed, Apr 17, 2013 at 10:34 AM, Dagobert Michelsen wrote: >> v2-bwalton/ > > This contains changes to makepatch. Ben? > http://sourceforge.net/apps/trac/gar/changeset?new=10017%40csw%2Fmgar%2Fgar%2Fv2-bwalton&old=9772%40csw%2Fmgar%2Fgar%2Fv2 > This was some test work I did before integrating it back to the main v2 branch. It can be dropped. Thanks -Ben From laurent at opencsw.org Fri Apr 19 00:28:26 2013 From: laurent at opencsw.org (Laurent Blume) Date: Fri, 19 Apr 2013 00:28:26 +0200 Subject: [csw-maintainers] Dagobert: Please delete all the /home/src/7.3.* files Message-ID: <5170738A.8060308@opencsw.org> Bram just kindly pointed out to me something terribly obvious in hindsight. The build recipe for vim was using *ftp* to download patches: all those containing non ASCII (ie, UTF-8, some other encodings for tests) were likely to be corrupted, eg, 7.3.336, which I can't delete. $ wget http://ftp.vim.org/pub/vim/patches/7.3/7.3.336 $ gdiff -q /home/src/7.3.336 /tmp/7.3.336 Files /home/src/7.3.336 and /tmp/7.3.336 differ It's difficult to know which are correct and which are not, so I'd rather just start over clean. On my personal system, for some reason, 7.3.336 was downloaded correctly, but 7.3.838 was corrupted. I've modified the recipe to use http and will redownload them all. The checksums will have to be updated. Ah, FTP. I need to get reminded from time to time why nobody should use it anymore ;-) Thanks in advance, Laurent From dam at opencsw.org Fri Apr 19 15:55:30 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Apr 2013 15:55:30 +0200 Subject: [csw-maintainers] Dagobert: Please delete all the /home/src/7.3.* files In-Reply-To: <5170738A.8060308@opencsw.org> References: <5170738A.8060308@opencsw.org> Message-ID: Hi Laurent, Am 19.04.2013 um 00:28 schrieb Laurent Blume: > Bram just kindly pointed out to me something terribly obvious in hindsight. > The build recipe for vim was using *ftp* to download patches: > all those containing non ASCII (ie, UTF-8, some other encodings for > tests) were likely to be corrupted, eg, 7.3.336, which I can't delete. > > $ wget http://ftp.vim.org/pub/vim/patches/7.3/7.3.336 > $ gdiff -q /home/src/7.3.336 /tmp/7.3.336 > Files /home/src/7.3.336 and /tmp/7.3.336 differ > > It's difficult to know which are correct and which are not, so I'd > rather just start over clean. On my personal system, for some reason, > 7.3.336 was downloaded correctly, but 7.3.838 was corrupted. > I've modified the recipe to use http and will redownload them all. The > checksums will have to be updated. > > Ah, FTP. I need to get reminded from time to time why nobody should use > it anymore ;-) > > Thanks in advance, Sure, done. Best regards -- Dago From dam at opencsw.org Fri Apr 19 16:04:52 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Apr 2013 16:04:52 +0200 Subject: [csw-maintainers] OpenSSL connection issue Message-ID: <32106C06-4829-4A37-9A21-22383787579F@opencsw.org> Hi Yann, I just got a bug report for wget not being able to download the patchdiag.xref via https: https://www.opencsw.org/mantis/view.php?id=5068 I can reproduce the problem with openssl: > root at login :/root > openssl s_client -connect getupdates.oracle.com:443 > CONNECTED(00000006) > write:errno=131 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 0 bytes and written 321 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > --- > zsh: 13656 exit 1 openssl s_client -connect getupdates.oracle.com:443 > root at login :/root > It should look like this: > root at login :/root > openssl s_client -connect www.google.com:443 > CONNECTED(00000006) > depth=1 C = US, O = Google Inc, CN = Google Internet Authority > verify error:num=20:unable to get local issuer certificate > verify return:0 > write:errno=0 > --- > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com > i:/C=US/O=Google Inc/CN=Google Internet Authority > 1 s:/C=US/O=Google Inc/CN=Google Internet Authority > i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority > --- > Server certificate > -----BEGIN CERTIFICATE----- > MIIDgDCCAumgAwIBAgIKQJSmXwABAACDizANBgkqhkiG9w0BAQUFADBGMQswCQYD > VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu > dGVybmV0IEF1dGhvcml0eTAeFw0xMzA0MTExMjUxNTJaFw0xMzEyMzExNTU4NTBa > MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N > b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw53d3cu > Z29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA2mKYQJK+Uu1N > B60eCZjotPI4WcFEVlAg1/Wrkn6IgQtgdDdoDqLafkJpzdxpCiS9QfMVTMx0KnSE > q5yqbIsoIGXECo7LP8DqMIXyLhNQxImZGP0ECnBEoDU+846H/SwRqF84iy13ywZq > IgURrEKml5xkFQVeB5VcHz9A25TkxbMCAwEAAaOCAVEwggFNMB0GA1UdJQQWMBQG > CCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQU8/LLjLowUsTURK6fDNOyf3qd > YBswHwYDVR0jBBgwFoAUv8Aw6/VDET5nup6R+/xq2uNrEiQwWwYDVR0fBFQwUjBQ > oE6gTIZKaHR0cDovL3d3dy5nc3RhdGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhv > cml0eS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS5jcmwwZgYIKwYBBQUHAQEEWjBY > MFYGCCsGAQUFBzAChkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dvb2dsZUludGVy > bmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNydDAMBgNVHRMB > Af8EAjAAMBkGA1UdEQQSMBCCDnd3dy5nb29nbGUuY29tMA0GCSqGSIb3DQEBBQUA > A4GBAC2xiFaWgeME1eGE/pmKJYA1KUNb/YwGUaxZ/SOwzSiuA8ke/5NVMrJYHwKW > xAnGkmvQf2IUBaQRVb3PDwMehexQ5SDCc3c5sZcWtxzazLb25HOnFkgO6x3YIpL+ > +jzdQ4Hb/gWhluh660JQpYXO0n8D2aME0PyBQ4+PuBRg6Dog > -----END CERTIFICATE----- > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com > issuer=/C=US/O=Google Inc/CN=Google Internet Authority > --- > No client certificate CA names sent > --- > SSL handshake has read 1900 bytes and written 81 bytes > --- > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA > Server public key is 1024 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-RC4-SHA > Session-ID: > Session-ID-ctx: > Master-Key: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1366380057 > Timeout : 300 (sec) > Verify return code: 20 (unable to get local issuer certificate) > --- > zsh: 13518 exit 1 openssl s_client -connect www.google.com:443 > root at login :/root > openssl s_client -connect getupdates.oracle.com:443 > CONNECTED(00000006) > write:errno=131 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 0 bytes and written 321 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > --- > zsh: 13656 exit 1 openssl s_client -connect getupdates.oracle.com:443 > root at login :/root > Other https-sites of course work also, just not Oracle :-( Any idea how to investigate this? Best regards -- Dago From gadavis at opencsw.org Fri Apr 19 19:11:10 2013 From: gadavis at opencsw.org (Geoff Davis) Date: Fri, 19 Apr 2013 10:11:10 -0700 Subject: [csw-maintainers] GAR branches In-Reply-To: References: <551975FC-09EE-4221-ADEA-6C2B07775087@opencsw.org> Message-ID: <2F51CEF2-94B1-4E19-8CFF-9B9E19B4F4B1@opencsw.org> On Apr 18, 2013, at 1:29 AM, Maciej (Matchek) Blizi?ski wrote: > >>> v2-fortran/ >> >> I think this was integrated. Geoff? >> http://sourceforge.net/apps/trac/gar/changeset?new=12516%40csw%2Fmgar%2Fgar%2Fv2-fortran&old=10862%40csw%2Fmgar%2Fgar%2Fv2 Nuke it, already merged, and nobody's been complaining about it's functionality or lack thereof. From dam at opencsw.org Fri Apr 19 22:00:14 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 19 Apr 2013 22:00:14 +0200 Subject: [csw-maintainers] checkpkg broken at the moment Message-ID: <11A2E942-308E-4575-AD00-D5439EC00737@opencsw.org> Hi Maciej, Laurent just reported a strange issue with checkpkg no longer working, because the Pyhon module "checkpkg" could not be found. I had a v2/lib/python/checkpkg.pyc but no .py. I tried for some time to identify the commit but there were just too many changes :-) https://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2/lib/python Maybe you can rollback the removal? Best regards -- Dago From maciej at opencsw.org Fri Apr 19 22:39:34 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 19 Apr 2013 21:39:34 +0100 Subject: [csw-maintainers] checkpkg broken at the moment In-Reply-To: <11A2E942-308E-4575-AD00-D5439EC00737@opencsw.org> References: <11A2E942-308E-4575-AD00-D5439EC00737@opencsw.org> Message-ID: 2013/4/19 Dagobert Michelsen : > Laurent just reported a strange issue with checkpkg no longer working, because the > Pyhon module "checkpkg" could not be found. I had a v2/lib/python/checkpkg.pyc > but no .py. I tried for some time to identify the commit but there were just > too many changes :-) > https://sourceforge.net/apps/trac/gar/log/csw/mgar/gar/v2/lib/python > > Maybe you can rollback the removal? No need, just nuke all *.pyc files. From maciej at opencsw.org Fri Apr 19 22:44:33 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 19 Apr 2013 21:44:33 +0100 Subject: [csw-maintainers] checkpkg broken at the moment In-Reply-To: References: <11A2E942-308E-4575-AD00-D5439EC00737@opencsw.org> Message-ID: Hm. Hang on. I want to see the actual stack trace. I made these changes carefully and used the changed code for week myself, building many packages with it. I want to see what happened. From maciej at opencsw.org Fri Apr 19 22:58:28 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 19 Apr 2013 21:58:28 +0100 Subject: [csw-maintainers] checkpkg broken at the moment In-Reply-To: References: <11A2E942-308E-4575-AD00-D5439EC00737@opencsw.org> Message-ID: I think I got it. My fault! (as always...) https://sourceforge.net/apps/trac/gar/changeset/20821 I removed all calls to the library, but I forgot to take out the import statement. It still worked for me because I had the *.pyc file. From laurent at opencsw.org Fri Apr 19 23:10:32 2013 From: laurent at opencsw.org (Laurent Blume) Date: Fri, 19 Apr 2013 23:10:32 +0200 Subject: [csw-maintainers] checkpkg broken at the moment In-Reply-To: References: <11A2E942-308E-4575-AD00-D5439EC00737@opencsw.org> Message-ID: <5171B2C8.4080702@opencsw.org> On 2013-04-19 10:58 PM, Maciej (Matchek) Blizi?ski wrote: > I think I got it. My fault! (as always...) > > https://sourceforge.net/apps/trac/gar/changeset/20821 > > I removed all calls to the library, but I forgot to take out the > import statement. It still worked for me because I had the *.pyc file. Lucky for you I'm now here to hit all those glitches before anyone really important does! :-) Laurent From yann at pleiades.fr.eu.org Sat Apr 20 14:56:00 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sat, 20 Apr 2013 14:56:00 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) Message-ID: Hi everyone, Here is a new status update about of the libssl update (0.9.8 -> 1.0.0). Below is the list of the remaining packages, sorted by maintainer, that need to be updated before we can complete the migration. Only 15 packages remaining !! We have never been so close ! :) *Alessio Cervellin ( Retired )* nmap : No one stepped up so I will drop this package, however py_scapy still depends on it. Dago, ca py_scapy be removed or can it be rebuilt without the nmap dependency ? *Benny von Mossner ( Sabbatical )* pound and pound2: Dago is working on this ones. *Ben Walton* libruby1_9_1_1 and ruby18: Ben is working on updating these packages (or rather on new ruby 2.0 packages) *Dagobert Michelsen* libarchive2 and libarchive_utils: Dago takes care of it. libcurl3 : Should be dropped soon after being removed from the dependencies of curl and curl_rt_stub. *Darin Perusich* conserver : I pinged Darin but go no answer. I have updated the package but I don't really know how to use this software. Does someone know a bit about this conserver ? I rather intend to drop it if I don't have an answer from Darin and if no else steps up. *Ihsan Dogan* unbound_host , libunbound2 and unbound : Ihsan is currently updating the packages. *Jake Goerzen:* flphoto and gftp: No answer from Jake yet. Jake, do you think you will be able to work soon on these packages ? *Jon Craig:* ntop : No answer from Jon yet. Jon, do you think you will be able to work soon on these packages ? Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Apr 20 15:22:32 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 20 Apr 2013 14:22:32 +0100 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: I looked at curl_rt_stub - two packages (CSWsquidclamav and CSWgnupgminimal) depended on it. Both were unmaintained and I dropped them. Then I dropped curl_rt_stub. So that's out of the way. The old curl libraries are still bound by the CSWcurl package, but all we need to do is remove the dependencies. From laurent at opencsw.org Sat Apr 20 18:40:53 2013 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 20 Apr 2013 18:40:53 +0200 Subject: [csw-maintainers] vim/gvim 7.3.905 Message-ID: <5172C515.5070801@opencsw.org> Hello, I think my updated recipes for vim & gvim are now ready enough. I've modified the Makefiles too much at this point to make a useful diff, so I've posted the new files on the buildfarm. There's also the additional patch to fix a minor issue (same for both): vim: http://buildfarm.opencsw.org/~laurent/vim/Makefile http://buildfarm.opencsw.org/~laurent/vim/0003-solaris-sleep-does-not-do-decimals.patch gvim: http://buildfarm.opencsw.org/~laurent/gvim/Makefile http://buildfarm.opencsw.org/~laurent/gvim/0003-solaris-sleep-does-not-do-decimals.patch So until I can update it myself, please review and put in place :-) Laurent From jcraig at opencsw.org Sun Apr 21 03:27:16 2013 From: jcraig at opencsw.org (Jonathan Craig) Date: Sat, 20 Apr 2013 21:27:16 -0400 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: On Sat, Apr 20, 2013 at 8:56 AM, Yann Rouillard wrote: > *Jon Craig:* > ntop : No answer from Jon yet. > Jon, do you think you will be able to work soon on these > packages ? > I can re-roll this package against the new openssl but it will break current users. Not sure how I should handle communication of the problems that will result from upgrading. Users will need delete their current DBM files and lose their configurations and history. I'm not prepared to write anything to handle the transition cleanly for them as the upstream hasn't provided any solution that I'm aware of. I use ntop has a spot tool, so loss of config/history is really no big deal to me, but it may be to others. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Sun Apr 21 09:23:22 2013 From: bwalton at opencsw.org (Ben Walton) Date: Sun, 21 Apr 2013 08:23:22 +0100 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: Hi Jonathan, On Sun, Apr 21, 2013 at 2:27 AM, Jonathan Craig wrote: > > On Sat, Apr 20, 2013 at 8:56 AM, Yann Rouillard > wrote: >> >> Jon Craig: >> ntop: No answer from Jon yet. >> Jon, do you think you will be able to work soon on these >> packages ? > > > I can re-roll this package against the new openssl but it will break current > users. Not sure how I should handle communication of the problems that will > result from upgrading. Users will need delete their current DBM files and > lose their configurations and history. I'm not prepared to write anything > to handle the transition cleanly for them as the upstream hasn't provided > any solution that I'm aware of. I use ntop has a spot tool, so loss of > config/history is really no big deal to me, but it may be to others. I'd float this information out on the users@ list and see if someone that does care about this use case is willing to donate a migration tool for inclusion in the updated package? I doubt that anyone will but there is room for surprise. At the very least, this will announce the invasive change and give people time to prepare for it. Thanks -Ben From dam at opencsw.org Sun Apr 21 10:33:54 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 21 Apr 2013 10:33:54 +0200 Subject: [csw-maintainers] vim/gvim 7.3.905 In-Reply-To: <5172C515.5070801@opencsw.org> References: <5172C515.5070801@opencsw.org> Message-ID: <39F4FE11-8671-4C79-93FB-E4D03DF0BFF7@opencsw.org> Hi Laurent, Am 20.04.2013 um 18:40 schrieb Laurent Blume : > I think my updated recipes for vim & gvim are now ready enough. > > I've modified the Makefiles too much at this point to make a useful > diff, so I've posted the new files on the buildfarm. There's also the > additional patch to fix a minor issue (same for both): > > vim: > http://buildfarm.opencsw.org/~laurent/vim/Makefile > http://buildfarm.opencsw.org/~laurent/vim/0003-solaris-sleep-does-not-do-decimals.patch > > gvim: > http://buildfarm.opencsw.org/~laurent/gvim/Makefile > http://buildfarm.opencsw.org/~laurent/gvim/0003-solaris-sleep-does-not-do-decimals.patch > > So until I can update it myself, please review and put in place :-) Why can't you update it yourself? Just give me your sourceforge user name and I'll add you to the project. 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 dam at opencsw.org Sun Apr 21 10:38:41 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 21 Apr 2013 10:38:41 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: <2585F6E5-8AFE-49CC-A7D1-CDBF32832B28@opencsw.org> Hi Yann, Am 20.04.2013 um 14:56 schrieb Yann Rouillard : > Here is a new status update about of the libssl update (0.9.8 -> 1.0.0). > Below is the list of the remaining packages, sorted by maintainer, that need to be updated before we can complete the migration. > > Only 15 packages remaining !! We have never been so close ! :) > > Alessio Cervellin ( Retired ) > nmap: No one stepped up so I will drop this package, however py_scapy still depends on it. > Dago, ca py_scapy be removed or can it be rebuilt without the nmap dependency ? IIRC that was part of mmap, you can drop it. > > Benny von Mossner ( Sabbatical ) > pound and pound2: Dago is working on this ones. Yeah, but no progress due to other things. > > Ben Walton > libruby1_9_1_1 and ruby18: Ben is working on updating these packages (or rather on new ruby 2.0 packages) > > Dagobert Michelsen > libarchive2 and libarchive_utils: Dago takes care of it. There are quite a lot of tests failing. Bug report is open without comment from upstream yet: http://code.google.com/p/libarchive/issues/detail?id=313&colspec=ID%20Type%20Status%20Priority%20Milestone%20OpSys%20Owner%20Summary > libcurl3: Should be dropped soon after being removed from the dependencies of curl and curl_rt_stub. Starting with curl 7.29 something on the bootstrapping with autotools garbled the linker flag inclusion, a bug is open: http://sourceforge.net/p/curl/bugs/1217/ > > Darin Perusich > conserver: I pinged Darin but go no answer. > I have updated the package but I don't really know how to use this software. > Does someone know a bit about this conserver ? > I rather intend to drop it if I don't have an answer from Darin and if no else steps up. > > Ihsan Dogan > unbound_host, libunbound2 and unbound: Ihsan is currently updating the packages. > > Jake Goerzen: > flphoto and gftp: No answer from Jake yet. > Jake, do you think you will be able to work soon on these packages ? > > Jon Craig: > ntop: No answer from Jon yet. > Jon, do you think you will be able to work soon on these packages ? 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 jh at opencsw.org Sun Apr 21 11:08:43 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Sun, 21 Apr 2013 11:08:43 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: <2585F6E5-8AFE-49CC-A7D1-CDBF32832B28@opencsw.org> References: <2585F6E5-8AFE-49CC-A7D1-CDBF32832B28@opencsw.org> Message-ID: <5173AC9B.1050002@opencsw.org> Hi, Am 21.04.13 10:38, schrieb Dagobert Michelsen: > Hi Yann, > > Am 20.04.2013 um 14:56 schrieb Yann Rouillard >: >> Here is a new status update about of the libssl update (0.9.8 -> 1.0.0). >> Below is the list of the remaining packages, sorted by maintainer, >> that need to be updated before we can complete the migration. >> >> Only 15 packages remaining !! We have never been so close ! :) >> >> *Alessio Cervellin ( Retired )* >> nmap : No one stepped up so I will drop >> this package, however py_scapy still depends on it. >> Dago, ca py_scapy be removed or can it be rebuilt without >> the nmap dependency ? > > IIRC that was part of mmap, you can drop it. It's not actually pc_scapy just depneds on a lib iirc but the packages was never cleanly split. @Dago dropping this is kind of bad. As you did build pc_scapy for a customer :) Greetings Jan From maciej at opencsw.org Sun Apr 21 14:11:04 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 21 Apr 2013 13:11:04 +0100 Subject: [csw-maintainers] Symbols information and checkpkg database In-Reply-To: References: Message-ID: I spent more time on this problem. I don't see an easy way out of the current problem. I can define the problem as this: When I view a page of a given package, I want to see its main metadata, such as pkgmap, and the output of the dump utility to see which binaries depend on which sonames. For example: http://buildfarm.opencsw.org/pkgdb/srv4/1bd915f6cdbf1217addd0e6d28823dff/ This page is currently forced to display the following depressing message: "As of January 2013, the stats stored are so big that processing them can take several minutes before they can be served. Disabling until a proper solution is in place." If you try enabling showing of metadata again, you just get a timeout. Current state of affairs means that it's much harder to review and diagnose packages than it needs to be. Things that used to take 10 seconds to check now take 5 to 10 minutes and require shell access: you can't packages by using a web browser. I'm unhappy about this. An obvious solution is to keep the elfdump and ldd data in a separate place, and not include it with the main bulk of metadata. It sounds easier than it looks. The core problem is this: We are no longer capable of keeping a single package's metadata in RAM to analyze them. We might be on the buildfarm, but our longer-term plan is to allow other people with smaller hardware to have their own buildfarm. I'm using a virtual machine with 1.6GB of RAM as a reference. I am not able to index our catalogs on our machine, it just fails because of insufficient RAM. Our package checking code has a nice and simple API: you define a function, which gets your packge's metadata and a few interaction objects it uses to report errors: https://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/package_checks.py Here's a showcase of a check that verifies that a package must not depend on itself: def CheckDependsOnSelf(pkg_data, error_mgr, logger, messenger): pkgname = pkg_data["basic_stats"]["pkgname"] for depname, dep_desc in pkg_data["depends"]: if depname == pkgname: error_mgr.ReportError("depends-on-self") It is a really simple API, because pkg_data is just a data structure deserialized from JSON, the same one you can get via REST, which is a simple HTTP GET you can do with curl or anything else that can talk over HTTP. There are no mysteries, lazy evaluations. You just see what the data structure is, and you can traverse it for whatever data you need. With the current amount of data, we cannot have a simple pkg_data any more. We'll have to switch to something doing lazy evaluation, and we are running a risk that a check function can leak memory and cause checkpkg to crash. Of course, we can implement this, but I can already hear people saying "this is so complicated, why are you preventing me from writing checks?" The new API would have to look something like this: def CheckDependsOnSelf(data_access_object, error_mgr, logger, messenger): pkgname = data_access_object.get("basic_stats")["pkgname"] for depname, dep_desc in data_access_object.get("depends"): if depname == pkgname: error_mgr.ReportError("depends-on-self") It doesn't look that different, but it is different in that instead of accessing a normal dict/list data structure, you're calling an object, which makes REST queries under the hood, and generally does who knows what. I don't have a good solution. Any ideas? Maciej From yann at pleiades.fr.eu.org Sun Apr 21 22:01:09 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Sun, 21 Apr 2013 22:01:09 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: *Jake Goerzen:* > flphoto and gftp: > No answer from Jake yet. > Jake, do you think you will be able to work > soon on these packages ? > I had a look at these packages: - gftp: the recipe has already been updated and it works fine. I was able to make a new package. However the gftp binary seg faults, but I test the current package, and it also seg faults ! No bug reported on the bugtracker, so either I am the only one with this bug or the package is not used. - flphoto: old GAR v1 recipe, it seems to use a deprecated CUPS api and the software has not been updated since 2006. I wonder if these packages are candidate for dropping. What do you think ? Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Mon Apr 22 21:33:14 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Mon, 22 Apr 2013 21:33:14 +0200 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: <2585F6E5-8AFE-49CC-A7D1-CDBF32832B28@opencsw.org> References: <2585F6E5-8AFE-49CC-A7D1-CDBF32832B28@opencsw.org> Message-ID: Hi Dago, *Dagobert Michelsen* > libarchive2 and libarchive_utils: > Dago takes care of it. > > > There are quite a lot of tests failing. Bug report is open without comment > from upstream yet: > > http://code.google.com/p/libarchive/issues/detail?id=313&colspec=ID%20Type%20Status%20Priority%20Milestone%20OpSys%20Owner%20Summary > > Hmm, that might take a lof of time if upstream is not responsive. Would it be possible to revert back to a working version and rebuild it with libssl 1.0 ? Yann -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgoerzen at opencsw.org Tue Apr 23 18:11:12 2013 From: jgoerzen at opencsw.org (Jake Goerzen) Date: Tue, 23 Apr 2013 09:11:12 -0700 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: <5176B2A0.8060303@opencsw.org> Hello! Sorry I have been MIA for a few weeks my work load has been heavy. I'm repackaging gftp now. As for flphoto I do not have time to maintain it anymore. If anyone wants to take it over please do so. Or if you want to drop if from the catalog that is fine with me also. Thanks /Jake On 04/21/13 13:01, Yann Rouillard wrote: > *Jake Goerzen:* > > flphoto and gftp > : No answer from Jake yet. > Jake, do you think you will be able > to work soon on these packages ? > > > I had a look at these packages: > - gftp: the recipe has already been updated and it works fine. I was > able to make a new package. > However the gftp binary seg faults, but I test the current > package, and it also seg faults ! > No bug reported on the bugtracker, so either I am the only one > with this bug or the package is not used. > > - flphoto: old GAR v1 recipe, it seems to use a deprecated CUPS api > and the software has not been updated since 2006. > > I wonder if these packages are candidate for dropping. > > What do you think ? > > > Yann > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Tue Apr 23 23:53:05 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 23 Apr 2013 22:53:05 +0100 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: <5176B2A0.8060303@opencsw.org> References: <5176B2A0.8060303@opencsw.org> Message-ID: /4/23 Jake Goerzen > Hello! Sorry I have been MIA for a few weeks my work load has been > heavy. I'm repackaging gftp now. As for flphoto I do not have time to > maintain it anymore. If anyone wants to take it over please do so. Or if > you want to drop if from the catalog that is fine with me also. I dropped flphoto for now. If anyone wants to step up and rebuild, go ahead! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 25 10:17:11 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 25 Apr 2013 10:17:11 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: <5178E57B.40903@lutter.sk> References: <5178E57B.40903@lutter.sk> Message-ID: <5178E687.1000701@opencsw.org> Hi, after recent OpenSSL upgrade, my postfix started to yield following: Apr 25 10:09:31 filesrv1 postfix-ltc-ssl/smtpd[24885]: [ID 947731 mail.warning] warning: Digest algorithm "sha1" not found: disabling TLS support Have anyone of you also encountered this kind of behaviour? Thanks. -- Juraj Lutter URL: http://www.wilbury.sk/ XMPP: juraj at lutter.sk Pekny, mily a usmievavy webhosting a serverhousing: http://www.nic.sk/ From wilbury at opencsw.org Thu Apr 25 10:30:57 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 25 Apr 2013 10:30:57 +0200 Subject: [csw-maintainers] OpenSSL connection issue In-Reply-To: <32106C06-4829-4A37-9A21-22383787579F@opencsw.org> References: <32106C06-4829-4A37-9A21-22383787579F@opencsw.org> Message-ID: <5178E9C1.3010103@opencsw.org> On 04/19/2013 04:04 PM, Dagobert Michelsen wrote: > Hi Yann, > > I just got a bug report for wget not being able to download the patchdiag.xref via https: > https://www.opencsw.org/mantis/view.php?id=5068 This seems to be related to my problem with digest algorithms that I've sent out today in another e-mail thread. Digest algorithms not available. > > I can reproduce the problem with openssl: > >> root at login :/root > openssl s_client -connect getupdates.oracle.com:443 >> CONNECTED(00000006) >> write:errno=131 >> --- >> no peer certificate available >> --- >> No client certificate CA names sent >> --- >> SSL handshake has read 0 bytes and written 321 bytes >> --- >> New, (NONE), Cipher is (NONE) >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> --- >> zsh: 13656 exit 1 openssl s_client -connect getupdates.oracle.com:443 >> root at login :/root > > > > It should look like this: > >> root at login :/root > openssl s_client -connect www.google.com:443 >> CONNECTED(00000006) >> depth=1 C = US, O = Google Inc, CN = Google Internet Authority >> verify error:num=20:unable to get local issuer certificate >> verify return:0 >> write:errno=0 >> --- >> Certificate chain >> 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com >> i:/C=US/O=Google Inc/CN=Google Internet Authority >> 1 s:/C=US/O=Google Inc/CN=Google Internet Authority >> i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority >> --- >> Server certificate >> -----BEGIN CERTIFICATE----- >> MIIDgDCCAumgAwIBAgIKQJSmXwABAACDizANBgkqhkiG9w0BAQUFADBGMQswCQYD >> VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu >> dGVybmV0IEF1dGhvcml0eTAeFw0xMzA0MTExMjUxNTJaFw0xMzEyMzExNTU4NTBa >> MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N >> b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw53d3cu >> Z29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA2mKYQJK+Uu1N >> B60eCZjotPI4WcFEVlAg1/Wrkn6IgQtgdDdoDqLafkJpzdxpCiS9QfMVTMx0KnSE >> q5yqbIsoIGXECo7LP8DqMIXyLhNQxImZGP0ECnBEoDU+846H/SwRqF84iy13ywZq >> IgURrEKml5xkFQVeB5VcHz9A25TkxbMCAwEAAaOCAVEwggFNMB0GA1UdJQQWMBQG >> CCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQU8/LLjLowUsTURK6fDNOyf3qd >> YBswHwYDVR0jBBgwFoAUv8Aw6/VDET5nup6R+/xq2uNrEiQwWwYDVR0fBFQwUjBQ >> oE6gTIZKaHR0cDovL3d3dy5nc3RhdGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhv >> cml0eS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS5jcmwwZgYIKwYBBQUHAQEEWjBY >> MFYGCCsGAQUFBzAChkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dvb2dsZUludGVy >> bmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNydDAMBgNVHRMB >> Af8EAjAAMBkGA1UdEQQSMBCCDnd3dy5nb29nbGUuY29tMA0GCSqGSIb3DQEBBQUA >> A4GBAC2xiFaWgeME1eGE/pmKJYA1KUNb/YwGUaxZ/SOwzSiuA8ke/5NVMrJYHwKW >> xAnGkmvQf2IUBaQRVb3PDwMehexQ5SDCc3c5sZcWtxzazLb25HOnFkgO6x3YIpL+ >> +jzdQ4Hb/gWhluh660JQpYXO0n8D2aME0PyBQ4+PuBRg6Dog >> -----END CERTIFICATE----- >> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com >> issuer=/C=US/O=Google Inc/CN=Google Internet Authority >> --- >> No client certificate CA names sent >> --- >> SSL handshake has read 1900 bytes and written 81 bytes >> --- >> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA >> Server public key is 1024 bit >> Secure Renegotiation IS supported >> Compression: NONE >> Expansion: NONE >> SSL-Session: >> Protocol : TLSv1.2 >> Cipher : ECDHE-RSA-RC4-SHA >> Session-ID: >> Session-ID-ctx: >> Master-Key: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 >> Key-Arg : None >> PSK identity: None >> PSK identity hint: None >> SRP username: None >> Start Time: 1366380057 >> Timeout : 300 (sec) >> Verify return code: 20 (unable to get local issuer certificate) >> --- >> zsh: 13518 exit 1 openssl s_client -connect www.google.com:443 >> root at login :/root > openssl s_client -connect getupdates.oracle.com:443 >> CONNECTED(00000006) >> write:errno=131 >> --- >> no peer certificate available >> --- >> No client certificate CA names sent >> --- >> SSL handshake has read 0 bytes and written 321 bytes >> --- >> New, (NONE), Cipher is (NONE) >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> --- >> zsh: 13656 exit 1 openssl s_client -connect getupdates.oracle.com:443 >> root at login :/root > > > Other https-sites of course work also, just not Oracle :-( > > Any idea how to investigate this? > > > Best regards > > -- Dago > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -- Juraj Lutter From yann at pleiades.fr.eu.org Thu Apr 25 17:45:13 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 25 Apr 2013 17:45:13 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: <5178E687.1000701@opencsw.org> References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> Message-ID: Hi Juraj, sha1 seems to be available: $ openssl dgst -sha1 /tmp/file SHA1(/tmp/file)= da39a3ee5e6b4b0d3255bfef95601890afd80709 I don't reproduce your bug. Can you send me your postfix configuration ? Yann 2013/4/25 Juraj Lutter > Hi, > > after recent OpenSSL upgrade, my postfix started to yield following: > > Apr 25 10:09:31 filesrv1 postfix-ltc-ssl/smtpd[24885]: [ID 947731 > mail.warning] warning: Digest algorithm "sha1" not found: disabling TLS > support > > > Have anyone of you also encountered this kind of behaviour? > > Thanks. > > -- > Juraj Lutter > URL: http://www.wilbury.sk/ > XMPP: juraj at lutter.sk > Pekny, mily a usmievavy webhosting a serverhousing: http://www.nic.sk/ > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 25 18:43:34 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 25 Apr 2013 18:43:34 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> Message-ID: <51795D36.3030708@opencsw.org> On 04/25/2013 05:45 PM, Yann Rouillard wrote: > Hi Juraj, > > sha1 seems to be available: > $ openssl dgst -sha1 /tmp/file > SHA1(/tmp/file)= da39a3ee5e6b4b0d3255bfef95601890afd80709 > > I don't reproduce your bug. > Can you send me your postfix configuration ? Relevant lines are: smtpd_tls_security_level = may smtpd_tls_auth_only = no smtpd_tls_key_file = /etc/opt/ows/postfix/ssl1/mailhub.ltc.sk.key smtpd_tls_cert_file = /etc/opt/ows/postfix/ssl1/mailhub.ltc.sk.crt smtpd_tls_CApath = /etc/opt/csw/ssl/certs smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_tls_cipherlist = ALL:!aNULL:!eNULL:!LOW:!SSLv2:TLSv1:SSLv3:+EXP smtpd_tls_ask_ccert = yes smtpd_tls_req_ccert = no smtpd_tls_protocols = !SSLv2,SSLv3,TLSv1 relay_clientcerts = dbm:/etc/opt/ows/postfix/relay_clientcerts tls_random_source = dev:/dev/urandom it's been working FOR YEARS, until yesterday when I've upgraded OpenSSL. :-( > > > Yann > > > > > > > 2013/4/25 Juraj Lutter > > > Hi, > > after recent OpenSSL upgrade, my postfix started to yield following: > > Apr 25 10:09:31 filesrv1 postfix-ltc-ssl/smtpd[24885]: [ID 947731 > mail.warning] warning: Digest algorithm "sha1" not found: disabling TLS > support > > > Have anyone of you also encountered this kind of behaviour? > > Thanks. > > -- > Juraj Lutter > URL: http://www.wilbury.sk/ > XMPP: juraj at lutter.sk > Pekny, mily a usmievavy webhosting a serverhousing: http://www.nic.sk/ > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > > > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -- Juraj Lutter From jcraig at opencsw.org Thu Apr 25 20:53:11 2013 From: jcraig at opencsw.org (Jonathan Craig) Date: Thu, 25 Apr 2013 14:53:11 -0400 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: On Sat, Apr 20, 2013 at 9:27 PM, Jonathan Craig wrote: > I can re-roll this package against the new openssl but it will break > current users. > Well, it never pays to procrastinate. I went to roll up a new swizzle of ntop to test before sending notices to users about what was going to break (as I wasn't sure of all the bits) and it looks like the last update to automake broke my build process. I'm going to either have to troubleshoot this (and its black magic) or push forward with trying to build the latest version and hope that it better matches the most recent automake. Either way, I'm gonna be slowed down (as if that were more possible). jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at pleiades.fr.eu.org Thu Apr 25 21:03:28 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 25 Apr 2013 21:03:28 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: <51795D36.3030708@opencsw.org> References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> <51795D36.3030708@opencsw.org> Message-ID: I still don't reproduce the bug. I do: $ openssl s_client -cipher ECDHE-RSA-AES256-SHA -connect localhost:465 or $ openssl s_client -cipher ECDHE-RSA-AES256-SHA -connect localhost:25 -starttls smtp And it seems to work fine: Apr 25 23:01:19 solaris11-vm postfix/smtps/smtpd[1466]: [ID 197553 mail.info] Anonymous TLS connection established from solaris11-vm.pleiades.fr.eu.org[127.0.0.1]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) Apr 25 23:02:02 solaris11-vm postfix/smtpd[1448]: [ID 197553 mail.info] Anonymous TLS connection established from solaris11-vm.pleiades.fr.eu.org[127.0.0.1]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) ECDHE-RSA-AES256-SHA use the SHA1 algorithm. What is the client used to trigger the problem ? Yann 2013/4/25 Juraj Lutter > On 04/25/2013 05:45 PM, Yann Rouillard wrote: > > Hi Juraj, > > > > sha1 seems to be available: > > $ openssl dgst -sha1 /tmp/file > > SHA1(/tmp/file)= da39a3ee5e6b4b0d3255bfef95601890afd80709 > > > > I don't reproduce your bug. > > Can you send me your postfix configuration ? > > Relevant lines are: > > smtpd_tls_security_level = may > smtpd_tls_auth_only = no > smtpd_tls_key_file = /etc/opt/ows/postfix/ssl1/mailhub.ltc.sk.key > smtpd_tls_cert_file = /etc/opt/ows/postfix/ssl1/mailhub.ltc.sk.crt > smtpd_tls_CApath = /etc/opt/csw/ssl/certs > smtpd_tls_loglevel = 1 > smtpd_tls_received_header = yes > smtpd_tls_session_cache_timeout = 3600s > smtpd_tls_cipherlist = ALL:!aNULL:!eNULL:!LOW:!SSLv2:TLSv1:SSLv3:+EXP > smtpd_tls_ask_ccert = yes > smtpd_tls_req_ccert = no > smtpd_tls_protocols = !SSLv2,SSLv3,TLSv1 > relay_clientcerts = dbm:/etc/opt/ows/postfix/relay_clientcerts > tls_random_source = dev:/dev/urandom > > it's been working FOR YEARS, until yesterday when I've upgraded OpenSSL. > > :-( > > > > > > > Yann > > > > > > > > > > > > > > 2013/4/25 Juraj Lutter >> > > > > Hi, > > > > after recent OpenSSL upgrade, my postfix started to yield following: > > > > Apr 25 10:09:31 filesrv1 postfix-ltc-ssl/smtpd[24885]: [ID 947731 > > mail.warning] warning: Digest algorithm "sha1" not found: disabling > TLS > > support > > > > > > Have anyone of you also encountered this kind of behaviour? > > > > Thanks. > > > > -- > > Juraj Lutter > > URL: http://www.wilbury.sk/ > > XMPP: juraj at lutter.sk > > Pekny, mily a usmievavy webhosting a serverhousing: > http://www.nic.sk/ > > > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > .:: This mailing list's archive is public. ::. > > > > > > > > > > _______________________________________________ > > maintainers mailing list > > maintainers at lists.opencsw.org > > https://lists.opencsw.org/mailman/listinfo/maintainers > > .:: This mailing list's archive is public. ::. > > > > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bwalton at opencsw.org Thu Apr 25 21:16:10 2013 From: bwalton at opencsw.org (Ben Walton) Date: Thu, 25 Apr 2013 20:16:10 +0100 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: If you commit what you've got, I'll take a look. I've futzed around in automake before so maybe I can save you some time. Thanks -Ben On Apr 25, 2013 7:53 PM, "Jonathan Craig" wrote: > > On Sat, Apr 20, 2013 at 9:27 PM, Jonathan Craig wrote: > >> I can re-roll this package against the new openssl but it will break >> current users. >> > > Well, it never pays to procrastinate. I went to roll up a new swizzle of > ntop to test before sending notices to users about what was going to break > (as I wasn't sure of all the bits) and it looks like the last update to > automake broke my build process. I'm going to either have to troubleshoot > this (and its black magic) or push forward with trying to build the latest > version and hope that it better matches the most recent automake. Either > way, I'm gonna be slowed down (as if that were more possible). > > jon > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcraig at opencsw.org Thu Apr 25 21:31:26 2013 From: jcraig at opencsw.org (Jonathan Craig) Date: Thu, 25 Apr 2013 15:31:26 -0400 Subject: [csw-maintainers] Last remaining packages for the openssl migration (take 2) In-Reply-To: References: Message-ID: The repo is current. Thanks for the assist. Jon On Thu, Apr 25, 2013 at 3:16 PM, Ben Walton wrote: > If you commit what you've got, I'll take a look. I've futzed around in > automake before so maybe I can save you some time. > > Thanks > -Ben > On Apr 25, 2013 7:53 PM, "Jonathan Craig" wrote: > >> >> On Sat, Apr 20, 2013 at 9:27 PM, Jonathan Craig wrote: >> >>> I can re-roll this package against the new openssl but it will break >>> current users. >>> >> >> Well, it never pays to procrastinate. I went to roll up a new swizzle of >> ntop to test before sending notices to users about what was going to break >> (as I wasn't sure of all the bits) and it looks like the last update to >> automake broke my build process. I'm going to either have to troubleshoot >> this (and its black magic) or push forward with trying to build the latest >> version and hope that it better matches the most recent automake. Either >> way, I'm gonna be slowed down (as if that were more possible). >> >> jon >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. >> > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 25 21:36:18 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 25 Apr 2013 21:36:18 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> <51795D36.3030708@opencsw.org> Message-ID: <517985B2.6080906@opencsw.org> On 04/25/2013 09:03 PM, Yann Rouillard wrote: > > What is the client used to trigger the problem ? The client is "mx-out.google.com" :-) or a random SSl/TLS remote SMTP server. At first, I will recompile my postfix instance against new OpenSSL (yes, I run my own compilation) or perhaps switch to OpenCSW postfix package (yes, there were many reasons why I didn't use OpenCSW postfix package from the very beginning.) j. -- Juraj Lutter From yann at pleiades.fr.eu.org Thu Apr 25 21:41:31 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 25 Apr 2013 21:41:31 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: <517985B2.6080906@opencsw.org> References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> <51795D36.3030708@opencsw.org> <517985B2.6080906@opencsw.org> Message-ID: Do you reproduce the bug when using the same "openssl s_client" commands I used ? Can you send send me a network capture of a tls connection that fails ? Yann 2013/4/25 Juraj Lutter > On 04/25/2013 09:03 PM, Yann Rouillard wrote: > > > > What is the client used to trigger the problem ? > > The client is "mx-out.google.com" :-) or a random SSl/TLS remote SMTP > server. > > > At first, I will recompile my postfix instance against new OpenSSL (yes, > I run my own compilation) or perhaps switch to OpenCSW postfix package > (yes, there were many reasons why I didn't use OpenCSW postfix package > from the very beginning.) > > j. > > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilbury at opencsw.org Thu Apr 25 21:49:50 2013 From: wilbury at opencsw.org (Juraj Lutter) Date: Thu, 25 Apr 2013 21:49:50 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> <51795D36.3030708@opencsw.org> <517985B2.6080906@opencsw.org> Message-ID: <517988DE.8000606@opencsw.org> On 04/25/2013 09:41 PM, Yann Rouillard wrote: > Do you reproduce the bug when using the same "openssl s_client" commands > I used ? No, I can not. Read: Not easily, it's a production box with hell of a lot of load. > > Can you send send me a network capture of a tls connection that fails ? No, I can not, every disruption and outage is very very annoying for that 15000 mail users using that server. :-( My action plan is: - Update CSWpostfix package to something more recent - Install and migrate from my own postfix build to CSWpostfix - Test SSl/TLS handling. I will leave the old postfix build (my own one) intact so I can then come back to it and start it again on different IP. Thanks so far. -- Juraj Lutter From yann at pleiades.fr.eu.org Thu Apr 25 21:54:13 2013 From: yann at pleiades.fr.eu.org (Yann Rouillard) Date: Thu, 25 Apr 2013 21:54:13 +0200 Subject: [csw-maintainers] OpenSSL problem after upgrade In-Reply-To: <517988DE.8000606@opencsw.org> References: <5178E57B.40903@lutter.sk> <5178E687.1000701@opencsw.org> <51795D36.3030708@opencsw.org> <517985B2.6080906@opencsw.org> <517988DE.8000606@opencsw.org> Message-ID: Hi Juraj, If it's a production box, why don't you quickly revert to the previous openssl package ? You can find them here: http://mirror.opencsw.org/opencsw/allpkgs/ http://mirror.opencsw.org/opencsw/allpkgs/libssl1_0_0-1.0.1e%2cREV%3d2013.03.12-SunOS5.10-i386-CSW.pkg.gz http://mirror.opencsw.org/opencsw/allpkgs/libssl1_0_0-1.0.1e%2cREV%3d2013.03.12-SunOS5.10-sparc-CSW.pkg.gz Yann 2013/4/25 Juraj Lutter > On 04/25/2013 09:41 PM, Yann Rouillard wrote: > > Do you reproduce the bug when using the same "openssl s_client" commands > > I used ? > > No, I can not. Read: Not easily, it's a production box with hell of a > lot of load. > > > > Can you send send me a network capture of a tls connection that fails ? > > No, I can not, every disruption and outage is very very annoying for > that 15000 mail users using that server. :-( > > My action plan is: > > - Update CSWpostfix package to something more recent > - Install and migrate from my own postfix build to CSWpostfix > - Test SSl/TLS handling. > > > > I will leave the old postfix build (my own one) intact so I can then > come back to it and start it again on different IP. > > Thanks so far. > > > -- > Juraj Lutter > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Fri Apr 26 14:12:17 2013 From: pfelecan at opencsw.org (pfelecan) Date: Fri, 26 Apr 2013 14:12:17 +0200 Subject: [csw-maintainers] request for review of my first Python package Message-ID: <3b1d2dcded64cab19ec32972d2796fdf@opencsw.org> As I'm not used to this kind of stuff, I would like that our Python masters review my first recipe: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/lang-python/dnspython/trunk at 20869 BTW, I'm a little bit intrigued about the lang-python directory and the apparent lack of documentation about the specifics of Python packages. Enlightenment welcomed. TIA From maciej at opencsw.org Fri Apr 26 16:13:47 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 26 Apr 2013 15:13:47 +0100 Subject: [csw-maintainers] request for review of my first Python package In-Reply-To: <3b1d2dcded64cab19ec32972d2796fdf@opencsw.org> References: <3b1d2dcded64cab19ec32972d2796fdf@opencsw.org> Message-ID: 2013/4/26 pfelecan > BTW, I'm a little bit intrigued about the lang-python directory and the > apparent lack of documentation about the specifics of Python packages. > Enlightenment welcomed. I think it's best to look at the corresponding category.mk file: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/categories/python/category.mk We could in principle write a document what's in this file, but the category.mk file has only 15 lines, so I think it's best to just refer to the source. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Apr 26 16:28:32 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 26 Apr 2013 15:28:32 +0100 Subject: [csw-maintainers] NMUs, non-maintainer uploads In-Reply-To: References: Message-ID: What's the conclusion for now? Unless somebody's going to change the way things work, we have to settle on a solution based on what we currently have. Maciej From jgoerzen at opencsw.org Fri Apr 26 23:05:59 2013 From: jgoerzen at opencsw.org (jgoerzen) Date: Fri, 26 Apr 2013 14:05:59 -0700 Subject: [csw-maintainers] =?utf-8?q?vidalia_on_Qt4=5Fgxx_vs=2E_Qt4?= In-Reply-To: References: Message-ID: Hello Carsten, I'll give it a try, Is the install prefix now different than /opt/csw/gxx ? On the buildfarm QT 4.8.0 is still being found by configure: ==> Extracting work/solaris10-i386/download/vidalia-0.2.19.tar.gz [extract-modulated] complete for vidalia. [patch-modulated] complete for vidalia. mkdir work/solaris10-i386/build-isa-pentium_pro/vidalia-0.2.19/build cd work/solaris10-i386/build-isa-pentium_pro/vidalia-0.2.19/build && /opt/csw/bin/cmake \ -DCMAKE_INSTALL_PREFIX:PATH=/opt/csw \ -DCMAKE_INSTALL_RPATH:PATH=/opt/csw/lib:/opt/csw/gxx/lib \ -DCMAKE_EXE_LINKER_FLAGS:STRING='-lsocket -lnsl' \ -DQT_QMAKE_EXECUTABLE=/opt/csw/gxx/bin/qmake .. -- Configuring Vidalia 0.2.19 -- The C compiler identification is SunPro 5.9.0 -- The CXX compiler identification is SunPro 5.9.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/CC -- Check for working CXX compiler: /usr/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found -- Found Qt4: /opt/csw/gxx/bin/qmake (found suitable version "4.8.0", minimum required is "4.3.0") -- Looking for limits.h -- Looking for limits.h - found -- Looking for sys/limits.h -- Looking for sys/limits.h - not found -- Looking for signal.h -- Looking for signal.h - found -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of int -- Check size of int - done -- Looking for sigaction -- Looking for sigaction - found -- Looking for signal -- Looking for signal - found -- Found Doxygen: /opt/csw/bin/doxygen (found version "1.8.3.1") -- Configuring done -- Generating done -- Build files have been written to: /home/jgoerzen/opencsw/vidalia/trunk/work/solaris10-i386/build-isa-pentium_pro/vidalia-0.2.19/build [configure-modulated] complete for vidalia. gmake[1]: Leaving directory `/home/jgoerzen/opencsw/vidalia/trunk' [configure] complete for vidalia. On 2013-04-09 02:05, Carsten Grzemba wrote: > ?Hi Jake, > > we plan to replace the Qt4_gxx 4.8.0 with Qt4 (gxx path removed) > 4.8.1 (or newer). > Do you like to rebuild CSWvidalia with QT 4.8.1 so we can remove the > QT4_gxx package from the database finally. > The other reverse dependent package CSWlibreCAD I have already > rebuild. > > What do you think? > > Carsten > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. From maciej at opencsw.org Sat Apr 27 00:13:40 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 26 Apr 2013 23:13:40 +0100 Subject: [csw-maintainers] Documentation: 4 places and their use Message-ID: ?For historical reasons?, FHR in short. Here are some places where we have documentation: - http://wiki.opencsw.org - mainly for ongoing projects because it's easy to edit - http://www.opencsw.org/manual/ - which we intend to be ?the opencsw book? which is supposed to be carefully written and reviewed and all - https://sourceforge.net/apps/trac/gar/ - for GAR documentation - http://www.opencsw.org/use-it/ - for official project information We also have the archive of old content formerly known as ?standards? or ?packaging standards?: https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/opencsw-manual/trunk/files/archive.txt It doesn't seem like we'll be closing down any of these sites, but I think we should have a generally agreed opinion about what is kept where, and try to make more order in our docs. Take these pages for example: http://www.opencsw.org/manual/for-maintainers/buildfarm-setup.html http://wiki.opencsw.org/buildfarm http://wiki.opencsw.org/checkpkg They are mostly about the same thing. Since this particular part of documentation is largely unchanging, in my opinion it should go into the manual. In the deep past, we were pretty calcified as far as moving documentation is concerned. These days it's easier to make changes, so I would like to propose the following: - have a rough agreement about places for documentation and where we keep what type of docs - advertise that we as a community are OK with people making changes to documentation, e.g. moving things around - provide a rough guideline, mostly stating the common sense things like "if you move content from place A to place B, make a link from A to B so people can still find the stuff you've moved" Thoughts? Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sat Apr 27 09:50:52 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 27 Apr 2013 08:50:52 +0100 Subject: [csw-maintainers] Documentation: 4 places and their use In-Reply-To: References: Message-ID: I have written up a short document ?About documentation?. https://sourceforge.net/apps/trac/gar/changeset/20875 Things in this document are largely just common sense, but I felt they need to be spelled out to remove any potential doubt. Maciej From rupert at opencsw.org Sat Apr 27 23:21:16 2013 From: rupert at opencsw.org (rupert THURNER) Date: Sat, 27 Apr 2013 23:21:16 +0200 Subject: [csw-maintainers] current procedure of testing packages In-Reply-To: References: Message-ID: would be nice, as i do not really have access to a machine to try out now. but only if its easy for you. On Wed, Apr 10, 2013 at 9:31 AM, Dagobert Michelsen wrote: > Hi Rupert, > > Am 09.04.2013 um 07:01 schrieb rupert THURNER : >> what is the current procedure of testing packages? > > Well, the usual case is that you install the packages on your machines and > test them :-) The experimental machines are available for testing, but as there > is no sane way for console access without giving root to the whole buildfarm > it is mostly used when there are no other testing possibilities. Would you need > access? > > > 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 > > _______________________________________________ > 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 Sat Apr 27 23:28:13 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 27 Apr 2013 23:28:13 +0200 Subject: [csw-maintainers] current procedure of testing packages In-Reply-To: References: Message-ID: Hi Rupert, Am 27.04.2013 um 23:21 schrieb rupert THURNER : > would be nice, as i do not really have access to a machine to try out > now. but only if its easy for you. You can now sudo on experimental10s. Please be careful not to foobar the machine. Best regards -- Dago > > On Wed, Apr 10, 2013 at 9:31 AM, Dagobert Michelsen wrote: >> Hi Rupert, >> >> Am 09.04.2013 um 07:01 schrieb rupert THURNER : >>> what is the current procedure of testing packages? >> >> Well, the usual case is that you install the packages on your machines and >> test them :-) The experimental machines are available for testing, but as there >> is no sane way for console access without giving root to the whole buildfarm >> it is mostly used when there are no other testing possibilities. Would you need >> access? >> >> >> 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 >> >> _______________________________________________ >> maintainers mailing list >> maintainers at lists.opencsw.org >> https://lists.opencsw.org/mailman/listinfo/maintainers >> .:: This mailing list's archive is public. ::. > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "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 maciej at opencsw.org Sun Apr 28 20:41:37 2013 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 28 Apr 2013 19:41:37 +0100 Subject: [csw-maintainers] Faster catalog generation Message-ID: TL;DR run mgar up --all I've spent most of today speeding up catalog generation, which was ridiculously slow: about 6 hours. There is now an additional table with only a few pieces of data, the ones that are necessary to generate a catalog: dependencies, incompatible packages, and the description line. Thanks to this table, the catalog generation code doesn't need to download giant blobs with package metadata. https://sourceforge.net/apps/trac/gar/changeset/20893 If I managed to get everything right (what are the odds of that!), catalog generation should work just as well as previously, only faster. I've also incremented the package database schema, so you need to get the latest checkpkg code in order to continue working on the buildfarm. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihsan at opencsw.org Mon Apr 29 08:10:22 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Mon, 29 Apr 2013 09:10:22 +0300 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: <516ABAC2.6000101@opencsw.org> References: <516ABAC2.6000101@opencsw.org> Message-ID: <517E0ECE.2070601@opencsw.org> Hi, This was probably missed. Any ideas how to fix this issue? Ihsan Am 14.04.2013 17:18, schrieb ?hsan Do?an: > Hi, > > I've build the unbound package with multiple ISA, but excluded the > parts, were CPU optimization is not necessary. > > MERGE_DIRS_isa-sparcv8plus = $(libdir) > MERGE_DIRS_isa-sparcv8plus += $(sbindir) > MERGE_DIRS_isa-pentium_pro = $(libdir) > MERGE_DIRS_isa-pentium_pro += $(sbindir) > > ISAXEC_DIRS = $(sbindir) > EXTRA_ISAEXEC_EXCLUDE_FILES = $(sbindir)/unbound-anchor > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-checkconf > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control-setup > EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-host > > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro = $(prefix)/sbin/unbound-anchor > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += > $(prefix)/sbin/unbound-checkconf > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-control > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += > $(prefix)/sbin/unbound-control-setup > EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-host > > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus = $(prefix)/sbin/unbound-anchor > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += > $(prefix)/sbin/unbound-checkconf > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-control > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += > $(prefix)/sbin/unbound-control-setup > EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-host > > And specified the files for the package: > > CATALOGNAME_CSWunbound-host = unbound_host > SPKG_DESC_CSWunbound-host = Unbound DNS lookup utility > PKGFILES_CSWunbound-host += $(sbindir)/unbound-host > PKGFILES_CSWunbound-host += $(mandir)/man1/unbound-host.1 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibldns1 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibssl1-0-0 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibunbound2 > RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibevent2-0-5 > > That worked once, but now it produced empty packages. > > What would be the appropriate way to package unbound? > > > > > Ihsan > -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Mon Apr 29 08:52:09 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 29 Apr 2013 08:52:09 +0200 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: <517E0ECE.2070601@opencsw.org> References: <516ABAC2.6000101@opencsw.org> <517E0ECE.2070601@opencsw.org> Message-ID: Hi Ihsan, Am 29.04.2013 um 08:10 schrieb ?hsan Do?an : > Hi, > > This was probably missed. Any ideas how to fix this issue? pentium_pro and sparcv8plus are now the defaults, so when you exclude them you end up with an empty package. Best regards -- Dago > > > > Ihsan > > Am 14.04.2013 17:18, schrieb ?hsan Do?an: >> Hi, >> >> I've build the unbound package with multiple ISA, but excluded the >> parts, were CPU optimization is not necessary. >> >> MERGE_DIRS_isa-sparcv8plus = $(libdir) >> MERGE_DIRS_isa-sparcv8plus += $(sbindir) >> MERGE_DIRS_isa-pentium_pro = $(libdir) >> MERGE_DIRS_isa-pentium_pro += $(sbindir) >> >> ISAXEC_DIRS = $(sbindir) >> EXTRA_ISAEXEC_EXCLUDE_FILES = $(sbindir)/unbound-anchor >> EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-checkconf >> EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control >> EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-control-setup >> EXTRA_ISAEXEC_EXCLUDE_FILES += $(sbindir)/unbound-host >> >> EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro = $(prefix)/sbin/unbound-anchor >> EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += >> $(prefix)/sbin/unbound-checkconf >> EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-control >> EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += >> $(prefix)/sbin/unbound-control-setup >> EXTRA_MERGE_EXCLUDE_FILES_isa-pentium_pro += $(prefix)/sbin/unbound-host >> >> EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus = $(prefix)/sbin/unbound-anchor >> EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += >> $(prefix)/sbin/unbound-checkconf >> EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-control >> EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += >> $(prefix)/sbin/unbound-control-setup >> EXTRA_MERGE_EXCLUDE_FILES_isa-sparcv8plus += $(prefix)/sbin/unbound-host >> >> And specified the files for the package: >> >> CATALOGNAME_CSWunbound-host = unbound_host >> SPKG_DESC_CSWunbound-host = Unbound DNS lookup utility >> PKGFILES_CSWunbound-host += $(sbindir)/unbound-host >> PKGFILES_CSWunbound-host += $(mandir)/man1/unbound-host.1 >> RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibldns1 >> RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibssl1-0-0 >> RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibunbound2 >> RUNTIME_DEP_PKGS_CSWunbound-host += CSWlibevent2-0-5 >> >> That worked once, but now it produced empty packages. >> >> What would be the appropriate way to package unbound? >> >> >> >> >> Ihsan >> > > -- > ihsan at dogan.ch http://blog.dogan.ch/ > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- "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 grzemba at contac-dt.de Mon Apr 29 09:20:41 2013 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Mon, 29 Apr 2013 09:20:41 +0200 Subject: [csw-maintainers] vidalia on Qt4_gxx vs. Qt4 In-Reply-To: References: Message-ID: Yes, there is still the old version on the buildfarm, we have to make a buildfarm update request. But i have still a question: the CSWqt 4.8.1. package is distinct form CSWqt-gxx 4.8.0 because of the different path. So both packages can stay side by side. But we want to maintain only the CSWqt 4.8.1 package so it is better to obsoleting the old one? Then I will add the OBSOLETED_BY_CSWpkgname constraint to the CSWqt package. Thoughts? Carsten Am 26.04.13 schrieb jgoerzen : > Hello Carsten, > > I'll give it a try, Is the install prefix now different than /opt/csw/gxx ? On the buildfarm QT 4.8.0 is still being found by configure: > > ?==> Extracting work/solaris10-i386/download/vidalia-0.2.19.tar.gz > [extract-modulated] complete for vidalia. > [patch-modulated] complete for vidalia. > mkdir work/solaris10-i386/build-isa-pentium_pro/vidalia-0.2.19/build > cd work/solaris10-i386/build-isa-pentium_pro/vidalia-0.2.19/build && /opt/csw/bin/cmake \ > -DCMAKE_INSTALL_PREFIX:PATH=/opt/csw \ > -DCMAKE_INSTALL_RPATH:PATH=/opt/csw/lib:/opt/csw/gxx/lib \ > -DCMAKE_EXE_LINKER_FLAGS:STRING='-lsocket -lnsl' \ > -DQT_QMAKE_EXECUTABLE=/opt/csw/gxx/bin/qmake .. > -- Configuring Vidalia 0.2.19 > -- The C compiler identification is SunPro 5.9.0 > -- The CXX compiler identification is SunPro 5.9.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/CC > -- Check for working CXX compiler: /usr/bin/CC -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Looking for Q_WS_X11 > -- Looking for Q_WS_X11 - found > -- Looking for Q_WS_WIN > -- Looking for Q_WS_WIN - not found > -- Looking for Q_WS_QWS > -- Looking for Q_WS_QWS - not found > -- Looking for Q_WS_MAC > -- Looking for Q_WS_MAC - not found > -- Found Qt4: /opt/csw/gxx/bin/qmake (found suitable version "4.8.0", minimum required is "4.3.0") > -- Looking for limits.h > -- Looking for limits.h - found > -- Looking for sys/limits.h > -- Looking for sys/limits.h - not found > -- Looking for signal.h > -- Looking for signal.h - found > -- Looking for sys/types.h > -- Looking for sys/types.h - found > -- Looking for stdint.h > -- Looking for stdint.h - found > -- Looking for stddef.h > -- Looking for stddef.h - found > -- Check size of int > -- Check size of int - done > -- Looking for sigaction > -- Looking for sigaction - found > -- Looking for signal > -- Looking for signal - found > -- Found Doxygen: /opt/csw/bin/doxygen (found version "1.8.3.1") > -- Configuring done > -- Generating done > -- Build files have been written to: /home/jgoerzen/opencsw/vidalia/trunk/work/solaris10-i386/build-isa-pentium_pro/vidalia-0.2.19/build > [configure-modulated] complete for vidalia. > gmake[1]: Leaving directory `/home/jgoerzen/opencsw/vidalia/trunk' > [configure] complete for vidalia. > > > > On 2013-04-09 02:05, Carsten Grzemba wrote: > >?Hi Jake, > > > >we plan to replace the Qt4_gxx 4.8.0 with Qt4 (gxx path removed) > >4.8.1 (or newer). > >Do you like to rebuild CSWvidalia with QT 4.8.1 so we can remove the > >QT4_gxx package from the database finally. > >The other reverse dependent package CSWlibreCAD I have already rebuild. > > > >What do you think? > > > >Carsten > >_______________________________________________ > >maintainers mailing list > >maintainers at lists.opencsw.org > >https://lists.opencsw.org/mailman/listinfo/maintainers > >.:: This mailing list's archive is public. ::. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Apr 30 11:58:12 2013 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 30 Apr 2013 11:58:12 +0200 Subject: [csw-maintainers] Next Camp Message-ID: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> Hi folks, time is flying and we should start to plan the next summercamp. We have offers for Zurich and Berlin and probably others on request. As OpenCSW was founded in Zurich it would be nice to come back there and there are also now at least three maintainers in the area. On the other hand during the last camps some maintainers mentioned that Berlin would be a cool location and J?rg Schilling offered to host it. I suggest we first decide for the location and then for the date, probably August or September. Thoughts? 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 Joerg.Schilling at fokus.fraunhofer.de Tue Apr 30 12:01:24 2013 From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling) Date: Tue, 30 Apr 2013 12:01:24 +0200 Subject: [csw-maintainers] Next Camp In-Reply-To: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> References: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> Message-ID: <517f9674.rTYnOHUQoILgGdFj%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen wrote: > time is flying and we should start to plan the next summercamp. We have offers for > Zurich and Berlin and probably others on request. As OpenCSW was founded in Zurich > it would be nice to come back there and there are also now at least three maintainers > in the area. On the other hand during the last camps some maintainers mentioned > that Berlin would be a cool location and J?rg Schilling offered to host it. Sorry for the missunderstanding, I would first need to ask whether this is possible at FOKUS. 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 jh at opencsw.org Tue Apr 30 14:56:14 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 30 Apr 2013 14:56:14 +0200 Subject: [csw-maintainers] CSWsynergy In-Reply-To: References: Message-ID: <517FBF6E.20903@opencsw.org> Hi, Am 29.04.13 22:59, schrieb Jeffrey Veiss: > Hi Jan, > > It took quite some effort but I was finally able to compile the latest > (1.4.11) version of synergy on Solaris 10 sparc. Well, I was able > to generate the binaries synergyc, synergyd and synergys which is > all I really wanted. The compilation bombed again on micro/uSynergy.c. > > Here's some of the things I needed to do: > > o I installed CSW gcc 4.6.3 > > o Set the following environment variables: > > export CMAKE_C_FLAGS="-I/usr/openwin/share/include -I/usr/X11/include -lresolv -lsocket -lnsl -lrt" > export CMAKE_CXX_FLAGS="-I/usr/openwin/share/include -I/usr/X11/include -lresolv -lsocket -lnsl -lrt" > export CMAKE_INCLUDE_PATH=/usr/openwin/share/include:/usr/X11/include > export CC=/opt/csw/bin/gcc > > o Added /opt/csw/bin to $PATH and /opt/csw/lib to $LD_LIBRARY_PATH > > o Ran hm.sh conf -g1 > > o Edited ./build/release/tools/CMakeFiles/cryptopp.dir/flags.make > and removed "-march=native" > > o Ran ./hm.sh build > > In response to to the "is private" errors on CProtocolUtil::writef, I > made changes to the following files: > > ./src/lib/ipc/CIpcClientProxy.cpp:147 > ./src/lib/ipc/CIpcServerProxy.cpp:94 > ./src/lib/server/CClientProxy1_4.cpp:105 > > On each call to this function where only three parameters were > provided, I added a fourth parameter of simply "". I also added > static_cast directives to try and force it to use the public version > of the function but that's likely not necessary. For example, from > ipc/CIpcClientProxy.cpp: > > - CProtocolUtil::writef(&m_stream, kIpcMsgLogLine, &logLine); > > + CProtocolUtil::writef(static_cast(&m_stream), static_cast(kIpcMsgLogLine), &logLine, ""); > > It's been over a decade since I've done any C++ development so while > I'm not sure if this is the right thing to do (and unlikely so), it > seemed to satisfy the compiler and synergys 1.4.11 seems to be > working OK with my Win 7 laptop (albeit the mouse is slow but that's > likely a network issue). thank you for that stuff. I added it and it seems to build and not brake on sparc now. It does not yet build on x86 atm. I thought back in the day I had it work on x86 and not on sparc. Now it's the other way around. I will see if I get this going and have a new package. Greetings Jan From jh at opencsw.org Tue Apr 30 15:31:33 2013 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 30 Apr 2013 15:31:33 +0200 Subject: [csw-maintainers] CSWsynergy In-Reply-To: <517FBF6E.20903@opencsw.org> References: <517FBF6E.20903@opencsw.org> Message-ID: <517FC7B5.7020704@opencsw.org> Hi, spoke to soon. Got it now building on both. Please test: http://buildfarm.opencsw.org/experimental.html#jh (should be there soon) Greetings Jan Am 30.04.13 14:56, schrieb Jan Holzhueter: > Hi, > > Am 29.04.13 22:59, schrieb Jeffrey Veiss: >> Hi Jan, >> >> It took quite some effort but I was finally able to compile the latest >> (1.4.11) version of synergy on Solaris 10 sparc. Well, I was able >> to generate the binaries synergyc, synergyd and synergys which is >> all I really wanted. The compilation bombed again on micro/uSynergy.c. >> >> Here's some of the things I needed to do: >> >> o I installed CSW gcc 4.6.3 >> >> o Set the following environment variables: >> >> export CMAKE_C_FLAGS="-I/usr/openwin/share/include -I/usr/X11/include -lresolv -lsocket -lnsl -lrt" >> export CMAKE_CXX_FLAGS="-I/usr/openwin/share/include -I/usr/X11/include -lresolv -lsocket -lnsl -lrt" >> export CMAKE_INCLUDE_PATH=/usr/openwin/share/include:/usr/X11/include >> export CC=/opt/csw/bin/gcc >> >> o Added /opt/csw/bin to $PATH and /opt/csw/lib to $LD_LIBRARY_PATH >> >> o Ran hm.sh conf -g1 >> >> o Edited ./build/release/tools/CMakeFiles/cryptopp.dir/flags.make >> and removed "-march=native" >> >> o Ran ./hm.sh build >> >> In response to to the "is private" errors on CProtocolUtil::writef, I >> made changes to the following files: >> >> ./src/lib/ipc/CIpcClientProxy.cpp:147 >> ./src/lib/ipc/CIpcServerProxy.cpp:94 >> ./src/lib/server/CClientProxy1_4.cpp:105 >> >> On each call to this function where only three parameters were >> provided, I added a fourth parameter of simply "". I also added >> static_cast directives to try and force it to use the public version >> of the function but that's likely not necessary. For example, from >> ipc/CIpcClientProxy.cpp: >> >> - CProtocolUtil::writef(&m_stream, kIpcMsgLogLine, &logLine); >> >> + CProtocolUtil::writef(static_cast(&m_stream), static_cast(kIpcMsgLogLine), &logLine, ""); >> >> It's been over a decade since I've done any C++ development so while >> I'm not sure if this is the right thing to do (and unlikely so), it >> seemed to satisfy the compiler and synergys 1.4.11 seems to be >> working OK with my Win 7 laptop (albeit the mouse is slow but that's >> likely a network issue). > > thank you for that stuff. > I added it and it seems to build and not brake on sparc now. > It does not yet build on x86 atm. I thought back in the day I had it > work on x86 and not on sparc. Now it's the other way around. > > I will see if I get this going and have a new package. > > Greetings > Jan > > > _______________________________________________ > maintainers mailing list > maintainers at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > From ihsan at opencsw.org Tue Apr 30 18:03:24 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Tue, 30 Apr 2013 19:03:24 +0300 Subject: [csw-maintainers] Next Camp In-Reply-To: <517f9674.rTYnOHUQoILgGdFj%Joerg.Schilling@fokus.fraunhofer.de> References: <3822BE18-A840-4955-8569-0206018C7555@opencsw.org> <517f9674.rTYnOHUQoILgGdFj%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <517FEB4C.2020208@opencsw.org> Hi, Am 30.04.2013 13:01, schrieb Joerg Schilling: >> time is flying and we should start to plan the next summercamp. We have offers for >> Zurich and Berlin and probably others on request. As OpenCSW was founded in Zurich >> it would be nice to come back there and there are also now at least three maintainers >> in the area. On the other hand during the last camps some maintainers mentioned >> that Berlin would be a cool location and J?rg Schilling offered to host it. > > Sorry for the missunderstanding, I would first need to ask whether this is > possible at FOKUS. Berlin would be really cool. :-) I've asked my manager and it would be possible to do at Swisscom in Zurich. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From ihsan at opencsw.org Tue Apr 30 18:14:30 2013 From: ihsan at opencsw.org (=?UTF-8?B?xLBoc2FuwqBEb8SfYW4=?=) Date: Tue, 30 Apr 2013 19:14:30 +0300 Subject: [csw-maintainers] packaging issue with multiple ISA In-Reply-To: References: <516ABAC2.6000101@opencsw.org> <517E0ECE.2070601@opencsw.org> Message-ID: <517FEDE6.6070606@opencsw.org> Hi Dago, Am 29.04.2013 09:52, schrieb Dagobert Michelsen: >> This was probably missed. Any ideas how to fix this issue? > > pentium_pro and sparcv8plus are now the defaults, so when you exclude them you end up with an empty package. Ok, now everything makes sense. Thanks for the hint. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/