Re: installation domains
On Wed, 29 Oct 2008 18:26:13 +, Richard Frith-Macdonald [EMAIL PROTECTED] said: Tentative policy and development proposals ... please enhance and then we can see if we can agree on the way forward. 1. We will move to FHS as the default layout for new installations [...] FWIW, IMHO, I don't think that GNUstep should default to FHS by default. While FHS support is handy for distributions like Debian that insist on everything following the FHS (and even then, we were getting by, just using symlinks to fake the whole thing), I think that it is best to keep the GNUstep layout by default. (And in fact, one of my goals is to eventually get a set of Debian packages that follows the GNUstep layout rather than FHS.) Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/config.h.in Source/GSFFIInvocation.m configure configure.ac
On Sun, 29 Jun 2008 09:54:56 +0200, David Ayers [EMAIL PROTECTED] said: Hello David David Chisnall schrieb: I think calling mmap directly is the wrong solution here. You should be using valloc() with the requested size rounded up to the nearest page size, and then use mprotect to set it as executable. Note that most sane operating systems (and Vista) are moving to W^X, so you need to set it as writeable while creating it, then executable while using it (i.e. call mprotect immediately before the return). My man page for vmalloc states: The obsolete function valloc() allocates size bytes and returns a pointer to the allocated memory. The memory address will be a multiple of the page size. It is equivalent to memalign(sysconf(_SC_PAGESIZE),size). Heh. My man page for memalign says: , | The obsolete function memalign() allocates size bytes and returns a | pointer to the allocated memory. The memory address will be a multiple | of boundary, which must be a power of two. ` and implies that posix_memalign should be used instead. From what I can gather, ptr=valloc(size) is equivalent to posix_memalign(ptr,sysconf(_SC_PAGESIZE),size), but don't quote me on that. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r26723 - in /libs/base/trunk: ChangeLog Headers/Additions/GNUstepBase/config.h.in Source/GSFFIInvocation.m configure configure.ac
On Sun, 29 Jun 2008 23:11:44 +0200, David Ayers [EMAIL PROTECTED] said: Hubert Chathi schrieb: Heh. My man page for memalign says: , | The obsolete function memalign() allocates size bytes and returns a | pointer to the allocated memory. The memory address will be a multiple | of boundary, which must be a power of two. ` and implies that posix_memalign should be used instead. From what I can gather, ptr=valloc(size) is equivalent to posix_memalign(ptr,sysconf(_SC_PAGESIZE),size), but don't quote me on that. I'm on lenny... so one could consider that a bug in the vmalloc man page... would you care to open a bug report? I don't really know anything about those functions, so I'm not sure what I would write in such a bug report. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Release ready?
On Tue, 24 Jun 2008 12:40:28 +0100, Richard Frith-Macdonald [EMAIL PROTECTED] said: Last week I made a stable/bugfix release (1.16.1) of base, to fix a problem I'd found on some 64bit systems. Yup, I noticed that. If you are freezing libraries for Debian at the end of this month, it might make sense to call on the discussion list for people to really try to break this release, and do another 1.16.2 with any bugfixes? What do you think? We're still talking with the Debian release team, trying to make sure that we can get the new GNUstep into Lenny. So for now, go ahead with your plan to do another 1.16.2 release, since it won't stall us (for now). Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: more licensing issues :(
On Sat, 21 Jun 2008 13:15:48 -0700 (PDT), Gregory John Casamento [EMAIL PROTECTED] said: All, I don't think we have an issue as Andrew has agreed to license them under the GPL. ... Excellent. Thanks for looking into this, Gregory. I hope this is the last of the licensing issues, and that we can all get back to coding. ;) Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
more licensing issues :(
Debian Bug #487143 [1] was filed against gnustep-gui, which points out that some of the included images are licensed in a way that prevents modification, and also prevents use for anything other than developing free OpenStep applications. [1] http://bugs.debian.org/487143 This presents a problem since Debian requires that everything in the distribution, including images, sounds, data files, documentation, be freely modifiable, and so this could result in GNUstep being removed from Debian. I should note that this license only applies to certain images: namely the images used for drawing various GUI controls such as checkboxes, etc. Is it possible to get these images relicensed? Thanks Hubert P.S. The link listed in the license: http://www.gnustep.org/UserSuite/UserSuite.html doesn't work. P.P.S. There are additional reasons that I believe that the current license is unreasonable. If anyone is interested, ask me. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Release ready?
On Fri, 13 Jun 2008 21:22:18 -0600, Adam Fedor [EMAIL PROTECTED] said: I'll branch a new stable release tomorrow unless anyone has any objections. I notice the new stable release is still versioned 1.14.x and 0.12.x. Does this mean that, for example, the latest Gorm, ProjectCentre, etc. will not work with it, and that they still require the unstable branch? If so, it looks like we want to try to get the unstable branch into Debian. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Debian GNUstep maintainers] GDL2 Release for Debian Lenny
Yavor Doganov wrote: Hubert Chathi wrote: Perhaps we should take a quick poll. This is an excellent idea, but how do you expect to do it? The lists this discussion is being carried on have limited audience. Of course the opinion of the gnustep-dev subscribers is valuable, and that of the main GNUstep maintainers and contributors matters even more. Right now, I'm mostly interested in the opinion of the GNUstep developers (i.e. those who are subscribed to these two lists), since they probably understand the issues better. Of course, I hope that they would consider regular GNUstep users in their response. So, to everyone: please let me know what you would prefer for us to do in Debian: keeping the old GNUstep release plus (nearly) all applications, or upgrading to the newer release, and being able to upgrade some applications as well, but losing some applications, such as Terminal and Vindaloo. Please let me know by Wednesday, so that I can make a decision. Yes, the powerpc one smells like the old build failure that hit gnustep-examples, so I wonder if the same fix would work, Yup, it looks like Renaissance is building fine on powerpc and hppa now, once I forced it to compile with -O2, so we should have Renaissance 0.9.0 in Debian Lenny. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 Release for Debian Lenny
Yavor Doganov wrote: Resolving the licensing issue for Debian means updating the meta-package and asking for removal or Terminal, Vindaloo (ViewPDF), PopplerKit, EdenMath and others and rebuilding GWorkspace without the PDF inspector. Of course we will reintroduce these packages when/if the problem is resolved. Sad and rather unfortunate, but that's how it is. We (or more precisely you as the leader and maintainer of the most important parts) have to make a decision and there is no time. Perhaps we should take a quick poll. Debian can either: - keep the current LGPL2.1-licensed GNUstep libraries, and keep all the GNUstep applications (except for ProjectCenter [1]), but have outdated copies of Gorm, SimpleAgenda, etc.; or - upgrade to the latest unstable (or the next stable release, if that happens soon enough), but lose Terminal, Vindaloo, PopplerKit, EdenMath. (Unless, of course, we get all the LGPL3/GPL2 issues resolved.) Theoretically, upgrading to the latest unstable GNUstep libraries would also allow us to update etoile, but I don't know if anyone has time to update the packaging soon enough. Let me know what you would rather we do. Anyone is free to reply. You can reply directly to me if you wish. I should add that if we want to upgrade to a newer version of the GNUstep libraries, this could still be vetoed by the Debian Release Managers, if they don't think that we would hold up the release. [1] IIRC, we would lose ProjectCenter because the old version doesn't build with gnustep-make 2.0, and has incorrect templates for gnustep-make 2.0, and the newer versions need a newer GNUstep library. Yavor, correct me if I'm wrong. Yeah, there are a couple of build failures that I need to look into for Renaissance 0.9.0 on powerpc and hppa. AFAIU the hppa build failure is an ICE, so it's a bug in GCC. The powerpc one smells like that too. Yes, the powerpc one smells like the old build failure that hit gnustep-examples, so I wonder if the same fix would work, and I wonder if it would also fix the hppa build. But I need to file a bug against GCC too. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
window focusing issues
Hello everyone, As some of you know, I am participating in the Google Summer of Code this year, looking at fixing various desktop integration issues in GNUstep. Part of this project involves looking at the window focusing issues. As an initial data-gathering step, I'm asking for people to report window focusing issues that they have encountered in GNUstep. Things such as: - windows not gaining focus when they should - windows gaining focus when they shouldn't - the menu disappearing when it shouldn't (or not disappearing when it should) Please send any reports to: mailto:[EMAIL PROTECTED]. Please send a separate mail for each issue that you want to report, and include: - the version of gnustep-base, gnustep-gui, gnustep-back that you are using - the backend that you are using (e.g. art or cairo) - your window manager (including version) - the application(s) that you notice the problem in, if it only happens in certain applications - steps to reproduce (what were you doing when you noticed the issue) - any bundles (e.g. camaelon, wildmenus) that you have loaded Thank you. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Fri, 11 Apr 2008 16:14:57 -0700 (PDT), Gregory John Casamento [EMAIL PROTECTED] said: All, I've written Brett Smith at the FSF to ask about exceptions or any possible solutions to the issues we're discussing. I will post relevant points when he replies to my email. Any news on this? Have the developers reached a consensus on what to do with the licensing issues? Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSoC participant
On Thu, 24 Apr 2008 00:32:20 +0200 (CEST), Nicola Pero [EMAIL PROTECTED] said: Well. let's start simpler. Use WindowMaker. official windowmanager. Set it to have OpenStep behaviour. You still have focus problems. SO before accomodating foreign stuff, the standard neets to work reliably. Let's not confuse Hubert. Starting simple/specific is always a good idea :-) But because of the wildly different behaviours of different desktop environments, fixing the GNUstep focus behaviour with one environment could mean breaking it with another environment. Riccardo and Nicola, thanks for your advice. At this point, it sounds like the best thing for me to do, when I get started on the project, is to just gather all the window focusing issues that people have encountered, and then prioritize them somehow. Part of that somehow will include considering whether it happens in WindowMaker. (It looks like I'll be learning *a lot* about X11 programming this summer.) It sounds like there's a lot of experience on this list, so I'll probably end up asking for advice from the list (in addition, of course, to getting advice from Fred). And I'll try to keep the list informed on what I'm doing. Just to let everyone know, I'm going to be busy working heavily on my thesis for the next week or two, so I'll hardly be spending any time thinking about this project. But after that, I'll start gathering information. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSoC participant
I'm another GSoC participant. My project is Addressing desktop integration issues or something like that. It's a bit of an open-ended project, since there are so many things that I could work on, and so it will depend on what Fred and I decide I should work on. However, initial ideas are: - fixing window focusing issues - ensuring that we support all applicable EWMH hints as much as makes sense for GNUstep - XDND - startup notification - XEmbed client support - System Tray - gstreamer - avahi (for Apple's NSNetService API) - improved .desktop file support - icon naming Just a bit about myself: I've been involved with GNUstep since 2005, and became the main maintainer for the Debian packages of the GNUstep core libraries (don't blame me for the funny filesystem layout. We were forced to follow the FHS). And I've been involved with free software since at least 1996. However, this will be my first time doing any sort of low-level X11 coding, so I'm looking forward to learning more about it. I'm a Ph.D. student in Computer Science, hopefully finishing up this year (once my dissertation is done), which I guess puts me on the old end of GSoC. I'm studying at the University of Waterloo in Ontario, Canada. Congratulations to my fellow GSoCers. Both of the other projects look interesting, and I hope that we can all help to improve GNUstep. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
Graham J. Lee wrote: Presumably, distributing binaries linked against earlier, pre-LGPLv3 GNUstep libraries is acceptable too (whether or not anyone likes the idea); I guess the licence change wasn't propagated back through the SCM history to retroactively apply to earlier revisions of GNUstep. Yes, that's another option, though not a very desirable one. Even if the license change was propagated back, earlier versions of GNUstep were already released under LGPLv2.1, and so the old license can still be used. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: GPLv2 licensing issues
On Thu, 10 Apr 2008 12:40:34 -0700, Matt Rice [EMAIL PROTECTED] said: On Thu, Apr 10, 2008 at 12:16 PM, Fred Kiefer [EMAIL PROTECTED] wrote: I am still not sure whether this problem actually exists. As far as I understand the GPL it only transfers to libraries that are statically linked to it. GNUstep base, gui and back (normally) get linked dynamically and to my understanding this should not cause any problem. But I surely am no expert on this matter. http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. Yup, and the next paragraph: If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GPLv2 licensing issues
On Thu, 10 Apr 2008 19:11:22 -0400, Hubert Chathi [EMAIL PROTECTED] said: On Fri, 11 Apr 2008 01:13:32 +0200, Alexander Malmberg [EMAIL PROTECTED] said: Hubert Chathi wrote: - terminal.app If the GPL2/LGPL3 problems are real, this is problematic for Terminal. The vt100 parsing code is based on the terminal/console handling from the linux kernel and is, for all practical purposes, impossible to relicense. Crap. I was hoping that poppler/xpdf was the only truly problemmatic case. Would it be feasible to steal code from xterm instead? There's also iTerm that the Étoilé people have started work porting, which is licensed under GPLv2 or later. I also found rote, which is a terminal emulation library licensed under the LGPL: http://rote.sourceforge.net/ I don't know how good it is, but it may be worth looking into. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: GPLv2 licensing issues
On Thu, 10 Apr 2008 18:12:17 -0500, Stefan Bidigaray [EMAIL PROTECTED] said: I think another good FAQ question to look at is: *Can I release a program under the GPL which I developed using non-free tools?* [...] However, if you link non-free libraries with the source code, that would be an issue you need to deal with. It does not preclude releasing the source code under the GPL, but if the libraries don't fit under the system library exception, you should affix an explicit notice giving permission to link your program with them. The FSF can give you advice on doing this. Yes, I mentioned the possibility of adding an exception to the applications' license in my original message. This one is also interesting: *If I port my program to GNU/Linux, does that mean I have to release it as Free Software under the GPL or some other Free Software license?* In general, the answer is no—this is not a legal requirement. In specific, the answer depends on which libraries you want to use and what their licenses are. Most system libraries either use the GNU Lesser GPLhttp://www.gnu.org/copyleft/lesser.html, or use the GNU GPL plus an exception permitting linking the library with anything. These libraries can be used in non-free programs; but in the case of the Lesser GPL, it does have some requirements you must follow. Note how it says if the library has an exception, you're in the clear. libobjc has that exception as Matt Rice pointed out. That is an issue of the application's license being compatible with the library's license, whereas the issue that I brought up is a question of the library's license not being compatible with the application's license. There are two different compatibilities that need to be satisfied. That said, this whole conversation is a little moot. If the GPLv2 was this restrictive KDE, for example, would have never happened. QT was originally licensed under a non-free license, obvious incompatible with the GPLv2 on which KDE used. There are millions of other examples where this type of thing happens. Mostly because people just covered their eyes and assumed that there was nothing wrong. However, KDE was kept out of Debian, for example, for a long time because of this very issue. I still don't see the problem Hubert is seeing. The GPL and LGPL where written exactly for this purpose. The LGPLv2 was written to be compatible with the GPLv2, and the LGPLv3 was written to be compatible with the GPLv3. However, the LGPLv3 is not compatible with the GPLv2, which is even mentioned on the FSF's web page which I referenced in my original mail. (And the GPLv3 is not compatible with the GPLv2, so you can't mix GPLv3 and GPLv2 code together.) Heck, the FSF linking against non-free libraries when they first start releasing code, and they specifically made sure not to make GPL software able to link only against LGPL libraries. Yes, the GPL has specific exceptions for linking against major components of the operating system (as the GPLv2 calls it, and System Libraries as the GPLv3 calls it). In my reply to Nicola, I explain that the GNUstep libraries may not fall under that exclusion, and even so, if a program is licensed under the GPLv2, may still be prevented from being distributed along with the GNUstep libraries. Hubert -- who finds it very ironic that proprietary programs have less legal problems linking against LGPLv3 libraries than GPLv2 programs do ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep summer of code
On Wed, 26 Mar 2008 10:02:33 -0600, Adam Fedor [EMAIL PROTECTED] said: Hubert has submitted an application for the GNUstep Summer of Code: http://code.google.com/soc/2008/gnustep/open.html Please add some comments there if you think there are some improvements to be made to the application. (Also, encourage more students to sign up!). I'm working on another proposal right now. See which one is more interesting. Also, someone (I think his nick was risky, or something like that) was asking on IRC yesterday to speak to a (potential) GSOC mentor because he had an idea. Someone should try to get in contact with him too. If he pops up on IRC today, maybe I'll point him to this mailing list. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSOC: desktop integration
On Sun, 23 Mar 2008 19:34:54 -0400, Charles philip Chan [EMAIL PROTECTED] said: Yen-Ju Chen [EMAIL PROTECTED] writes: If there is a window manager which can work on both GNUstep and GNOME/KDE, this problem can be solved. IMHO, I think it is unwise to force people to change their default window manager (as long as it is EWMH compliant) just to run GNUstep apps. I agree. It would be best to support EWMH as much as possible, even if we can't get it completely. If GNUstep programs don't work well in a user's WM of choice when they try it out, they just won't use GNUstep. Users aren't going to install a new WM just to try out a program. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSOC: desktop integration
On Sat, 22 Mar 2008 12:57:32 -0800, Matt Rice [EMAIL PROTECTED] said: On Sat, Mar 22, 2008 at 12:02 PM, Hubert Chathi [EMAIL PROTECTED] wrote: Hi all, I'm looking at applying for Google's SOC this year. I'm interested in looking at GNU/Linux desktop integration issues. So I'd like to look at: - the window focusing issues, and making GNUstep work well in all window managers I think this is a good idea, though I am wondering the scope of your intent, e.g. to make gnustep usable with sloppy focus, or to fix issues with click-to-focus, or both i think these are separate issues so maybe you could elaborate a bit. I'm not sure exactly what the issues are, or how much work is involved in solving them. I just saw the issue listed on the wiki, and I remember reading some discussion about it on the bugs mailing list. - looking at which freedesktop.org standards it would make sense for GNUstep to implement - looking at providing bindings/interfaces for some freedesktop.org software (e.g. dbus is mentioned on the wiki) - although not exactly desktop-integration work, I could also look at bitmap image reading/writing support Does this sound like a worthwhile project? What scope would be reasonable for GSOC? Are there other things I should be looking at? as far as other things one more idea is finishing up the update to the latest xdnd specification, and filling in the missing conversions so we can drag and drop between gnustep and X apps Right, xdnd. I knew there was a big thing that I was forgetting something when I wrote the email. Yes, that's another thing that I would be interested in working on. http://freedesktop.org/wiki/Specifications/XDND Fred can probably elaborate more on what is done and needs to be done with this though. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GSOC: desktop integration
Hi all, I'm looking at applying for Google's SOC this year. I'm interested in looking at GNU/Linux desktop integration issues. So I'd like to look at: - the window focusing issues, and making GNUstep work well in all window managers - looking at which freedesktop.org standards it would make sense for GNUstep to implement - looking at providing bindings/interfaces for some freedesktop.org software (e.g. dbus is mentioned on the wiki) - although not exactly desktop-integration work, I could also look at bitmap image reading/writing support Does this sound like a worthwhile project? What scope would be reasonable for GSOC? Are there other things I should be looking at? Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Adam Fedor wrote: On Mar 3, 2008, at 9:28 AM, Hubert Chathi wrote: I was intending on tracking the GNUstep unstable branch in Debian experimental, but we currently have some unresolved issues regarding ffcall/libffi. I think tracking unstable would be a good idea. OK, I will work on getting unstable in. Are you having general problems with libffi/ffcall or on a particular platform? Well, ffcall, as you know, doesn't work properly on SELinux, PAX, etc. I had a report of libffi not working on x86_64 (see one of my previous messages), and I don't have proper access to an x86_64 box to debug. So it seems like neither solution will work in general for all users. I'm working a solution to provide both versions in Debian, but it'll be a bit before I can implement it, due to lack of time. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
On Sun, 02 Mar 2008 11:51:01 +0100, Riccardo [EMAIL PROTECTED] said: Hi, On 2008-03-02 00:18:47 +0100 Adam Fedor [EMAIL PROTECTED] wrote: It's time for another release. I'll make an unstable release of the core libraries late next week. I also plan a stable base release, but I will not make a stable release of the gui libraries, unless there is some important patch the someone wants there (or better yet, patch the stable branch yourself so I don't have to do it). I know of no blocking issues, I should probably give a compile test on gcc 2.95 in the next days, just to be sure. About stable, since I gather Debian tracks stable (?) it would be nice to have some of the printing stuff backported to stable: PRICE doesn't compile against current debian packages. But it is just my guess: htey have an reasonably up to date base, but a horrid old gui and I thought it was that they track stable. Yes, Debian currently tracks the stable branch. My understanding was that the purpose for stable was to provide a stable ABI for application developers to target. But I'm hearing more about applications that need the unstable branch to compile. (PRICE, and simpleagenda.app, at least.) So, is it better to track stable or unstable at this point? Hubert (with his Debian Developer hat on) -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next release
Stefan Bidigaray wrote: Debian Unstable (Sid) tends to only track stable packages of anything! The so called unstable Debian branch is just unstable due to package problems, but the packages in it are generally the latest stable (assuming there's someone maintaining them). Yes, that is usually true. (A few packages may track the unstable branch, e.g. the GNUMail package, which is based off a daily snapshot. But for the most part, packages in Debian sid track stable branches.) Occasionally, unstable branches can be tracked in Debian experimental. I was intending on tracking the GNUstep unstable branch in Debian experimental, but we currently have some unresolved issues regarding ffcall/libffi. By the way, if anyone wants to help with GNUstep packages, we can always use help. -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: amd64 and libffi
On Mon, 25 Feb 2008 15:12:34 -0500, Hubert Chathi [EMAIL PROTECTED] said: [...] (On the other hand, GNUstep programs apparently don't work with ffcall on Opterons, since ffcall doesn't seem to play well with the NX bit, apparently.) Apparently, I may be wrong about this. The problems with Opterons are probably something completely different, and ffcall apparently does work on them (at least as much as GNUstep needs). I'm still interested in peoples' experiences with libffi on Opterons, though. -- Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
amd64 and libffi
I got a report from a Debian user that GNUstep programs segfault on the amd64 architecture when gnustep-base is compiled with libffi. (On the other hand, GNUstep programs apparently don't work with ffcall on Opterons, since ffcall doesn't seem to play well with the NX bit, apparently.) Unfortunately, I don't have an amd64 to try things out for myself. Does anyone have any experience with libffi under amd64? -- Hubert Chathi [EMAIL PROTECTED] -- Jabber: [EMAIL PROTECTED] PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
