Menu
▾
▴
tilp-devel — This list is intended to TiLP's developers, contributors and advanced users.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2003 |
Jan
(25) |
Feb
(5) |
Mar
(12) |
Apr
(46) |
May
(47) |
Jun
|
Jul
(2) |
Aug
|
Sep
(15) |
Oct
(8) |
Nov
(11) |
Dec
|
| 2004 |
Jan
(25) |
Feb
(24) |
Mar
(13) |
Apr
(59) |
May
(52) |
Jun
(6) |
Jul
(3) |
Aug
(7) |
Sep
(33) |
Oct
(17) |
Nov
(16) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(5) |
May
(50) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(7) |
Oct
(1) |
Nov
(2) |
Dec
(9) |
| 2006 |
Jan
(10) |
Feb
(6) |
Mar
(2) |
Apr
(24) |
May
(32) |
Jun
(53) |
Jul
(26) |
Aug
(28) |
Sep
(59) |
Oct
(72) |
Nov
(85) |
Dec
(57) |
| 2007 |
Jan
(43) |
Feb
(26) |
Mar
(25) |
Apr
(36) |
May
(13) |
Jun
(14) |
Jul
(53) |
Aug
(68) |
Sep
(46) |
Oct
(62) |
Nov
(15) |
Dec
(4) |
| 2008 |
Jan
(4) |
Feb
(5) |
Mar
(7) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(5) |
Nov
|
Dec
(3) |
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Romain <ro...@li...> - 2005-05-15 17:14:22
|
Hi, > ticables: check for lib-usb usability: > ticables: usb filesystem (/proc/bus/usb): mounted > ticables: node /proc/bus/usb/devices: exists > ticables: permissions/user/group: -rw-rw-r-- root root > ticables: is user can r/w on device: no > ticables: are others can r/w on device: no > ticables: is the user 'julien' in the group 'root': no > ticables: =3D> you should add your username at the group 'root' in > '/etc/group' > ticables: =3D> you will have to restart you session, too > ticables: warning: can't use IO_LIBUSB > > Why the hell is libticables wanting to write to /proc/bus/usb/devices ? > > The check in linux_mapping.c is completely, utterly broken. The '-rw-rw-r--' check is broken for sure but fixed in ticables2 library. I will fix it in ticables, too (1 line patch). roms. --=20 Romain Li=E9vin : <ro...@li...> Web site : http://www.lievin.net "Linux, y'a moins bien mais c'est plus cher !" |
|
From: Romain <ro...@li...> - 2005-05-15 17:11:20
|
Hi, > I intend to work again on the native port at some yet unspecified > date; it depends on hardware availability on my side (if you want the > port to resurrect, I accept donations to get a decent Mac Mini to work TI should donate... roms. --=20 Romain Li=E9vin : <ro...@li...> Web site : http://www.lievin.net "Linux, y'a moins bien mais c'est plus cher !" |
|
From: Romain <ro...@li...> - 2005-05-15 16:58:43
|
Hi, > #ifndef __WIN32__ > # include <endian.h> > # if __BYTE_ORDER =3D=3D __BIG_ENDIAN > # define WORDS_BIGENDIAN 1 > # endif /* __BYTE_ORDER =3D=3D __BIG_ENDIAN */ > #endif /* !__WIN32__ */ > > There is no <endian.h> on Mac OS X. There is a <machine/endian.h> that > defines BYTE_ORDER and BIG_ENDIAN, but as far as I see not __BYTE_ORDER > and __BIG_ENDIAN. > > We should decide whether setting WORDS_BIGENDIAN should be done by > configure or in the C code. At the moment, it is done in both places - It should be set in configure script. This is the best place (my opinion)= . > in configure, as added by Romain as part of one of my Mac OS X patches; > in the C code as shown above. roms. --=20 Romain Li=E9vin : <ro...@li...> Web site : http://www.lievin.net "Linux, y'a moins bien mais c'est plus cher !" |
|
From: Julien B. <jb...@jb...> - 2005-05-15 16:48:07
|
Christian Walther <cwa...@gm...> wrote: >> I need the precise (as much as possible) size of the screen for the >> various calcs. > > On my TI-92+, which is an upgraded original TI-92, the area filled > with pixels is 84.0 x 44.8 mm (+- about 0.2 mm - for a more accurate Thanks, that's what I needed. JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Julien B. <jb...@jb...> - 2005-05-15 16:46:36
|
Christian Walther <cwa...@gm...> wrote: >> Thus, do *NOT* use this macro when building TiLP on Mac OS X to obtain >> an *X11* build of TiLP. Failure to do so will terminally break the >> native OS X port. > > Just for the record (as this message was probably mainly directed at > me :) ) - I currently have no plans to work on TiLP. But thanks for > the warning anyway. Maybe > my plans will change one day, as they often do... :) It was intended as a data point for anybody willing to work on a Mac OS X port of any part of the TiLP Project :-) What was written in that mail isn't written anywhere else... JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Julien B. <jb...@jb...> - 2005-05-15 16:45:26
|
Christian Walther <cwa...@gm...> wrote: >> It isn't, as your patch never made it to the repository. At least >> configure.ac was not modified recently. > > It is: <http://svn.tilp.info/cgi-bin/viewcvs.cgi/libtifiles/trunk/ > configure.ac?root=tilp&rev=1022&r1=964&r2=1022>. Romain just didn't > mention it in the commit message. So much for commit messages and changelog files. Gee. >> Re-adding the configure check is probably the easiest way to solve the >> problem. Then my change can be reverted. (the check is known to work >> on the platforms we care for) > > Like this? > > Index: configure.ac > =================================================================== > --- configure.ac (revision 1064) > +++ configure.ac (working copy) > @@ -68,6 +68,9 @@ > AC_TYPE_SIZE_T > AC_STRUCT_TM > > +# Checks for architecture features. > +AC_C_BIGENDIAN > + > # Checks for library functions. > AC_PROG_GCC_TRADITIONAL > AC_FUNC_STAT > @@ -79,8 +82,7 @@ > case "$host" in > *-*-*bsd*) ARCH="-D__BSD__" ;; > *-*-mingw*) ARCH="-D__WIN32__ -D__MINGW32__" ;; > - powerpc-*-linux-*) ARCH="-D__LINUX__ -DWORDS_BIGENDIAN" ;; > - powerpc-apple-darwin*) ARCH="-D__MACOSX__ -DWORDS_BIGENDIAN" ;; > + powerpc-apple-darwin*) ARCH="-D__MACOSX__" ;; > *) ARCH="-D__LINUX__" ;; > esac > CFLAGS="$CFLAGS $ARCH" > =================================================================== Yep. > This works for me, but since I'm not familiar with autoconf, I'd > rather ask before committing. You need to regenerate config.h.in and include config.h where required. > Slightly off-topic: Is there a less-brute-force way of answering the > question "In what revisions, if any, did configure.ac contain > 'ENDIAN'?" than 'svn cat'ting and grepping every single revision? (I > didn't do that, I just wondered...) Not that I know of. JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Julien B. <jb...@jb...> - 2005-05-15 16:34:07
|
Hi again, ticalcs : Is calculator ready ? resetting pipes... done ! ticalcs : PC->TI: RDY? ticalcs : TI->PC: ACKerr: usb_bulk_write (No error). Speaks for itself. I can't touch TiLP without finding a metric fucktons of silly bugs. For my own sanity, I'm throwing in the towel. Have fun, JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Julien B. <jb...@jb...> - 2005-05-15 16:30:48
|
Hi, ticables: check for lib-usb usability: ticables: usb filesystem (/proc/bus/usb): mounted ticables: node /proc/bus/usb/devices: exists ticables: permissions/user/group: -rw-rw-r-- root root ticables: is user can r/w on device: no ticables: are others can r/w on device: no ticables: is the user 'julien' in the group 'root': no ticables: => you should add your username at the group 'root' in '/etc/group' ticables: => you will have to restart you session, too ticables: warning: can't use IO_LIBUSB Why the hell is libticables wanting to write to /proc/bus/usb/devices ? The check in linux_mapping.c is completely, utterly broken. JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Christian W. <cwa...@gm...> - 2005-05-15 16:13:38
|
> I need the precise (as much as possible) size of the screen for the > various calcs. On my TI-92+, which is an upgraded original TI-92, the area filled with pixels is 84.0 x 44.8 mm (+- about 0.2 mm - for a more accurate measurement, I'd have to take it apart, which I don't want to do at the moment). The black window is about 49.0 x 88.0 mm. -Christian |
|
From: Christian W. <cwa...@gm...> - 2005-05-15 16:00:35
|
Julien BLACHE wrote: > Thus, do *NOT* use this macro when building TiLP on Mac OS X to obtain > an *X11* build of TiLP. Failure to do so will terminally break the > native OS X port. Just for the record (as this message was probably mainly directed at me :) ) - I currently have no plans to work on TiLP. But thanks for the warning anyway. Maybe my plans will change one day, as they often do... :) -Christian |
|
From: Christian W. <cwa...@gm...> - 2005-05-15 15:52:36
|
Julien BLACHE wrote: > Christian Walther <cwa...@gm...> wrote: >> We should decide whether setting WORDS_BIGENDIAN should be done by >> configure or in the C code. At the moment, it is done in both places - >> in configure, as added by Romain as part of one of my Mac OS X > > It isn't, as your patch never made it to the repository. At least > configure.ac was not modified recently. It is: <http://svn.tilp.info/cgi-bin/viewcvs.cgi/libtifiles/trunk/ configure.ac?root=tilp&rev=1022&r1=964&r2=1022>. Romain just didn't mention it in the commit message. > The problem is that the traditional configure check is broken, and > will fail on some platforms. IIRC this check used to be in the > configure script, and I was defining WORDS_BIGENDIAN on Mac OS X from > the command line (because I didn't use the configure script in Project > Builder). > > Re-adding the configure check is probably the easiest way to solve the > problem. Then my change can be reverted. (the check is known to work > on the platforms we care for) Like this? Index: configure.ac =================================================================== --- configure.ac (revision 1064) +++ configure.ac (working copy) @@ -68,6 +68,9 @@ AC_TYPE_SIZE_T AC_STRUCT_TM +# Checks for architecture features. +AC_C_BIGENDIAN + # Checks for library functions. AC_PROG_GCC_TRADITIONAL AC_FUNC_STAT @@ -79,8 +82,7 @@ case "$host" in *-*-*bsd*) ARCH="-D__BSD__" ;; *-*-mingw*) ARCH="-D__WIN32__ -D__MINGW32__" ;; - powerpc-*-linux-*) ARCH="-D__LINUX__ -DWORDS_BIGENDIAN" ;; - powerpc-apple-darwin*) ARCH="-D__MACOSX__ -DWORDS_BIGENDIAN" ;; + powerpc-apple-darwin*) ARCH="-D__MACOSX__" ;; *) ARCH="-D__LINUX__" ;; esac CFLAGS="$CFLAGS $ARCH" =================================================================== This works for me, but since I'm not familiar with autoconf, I'd rather ask before committing. Slightly off-topic: Is there a less-brute-force way of answering the question "In what revisions, if any, did configure.ac contain 'ENDIAN'?" than 'svn cat'ting and grepping every single revision? (I didn't do that, I just wondered...) -Christian |
|
From: Julien B. <jb...@jb...> - 2005-05-15 15:18:08
|
Hi, I'm in the process of adding PostScript/PDF output for the screenshots. I need the precise (as much as possible) size of the screen for the various calcs. Thanks, JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Julien B. <jb...@jb...> - 2005-05-15 15:13:08
|
Hi, A note about the Mac OS X port ... When I did the native port nearly 3 years ago, I used the CPP definition __MACOSX__ to mark specific code sections. I disabled some central sections, like the RC file related functions, because the native port uses the preferences framework offered by Cocoa. Ditto for some other sections. Thus, do *NOT* use this macro when building TiLP on Mac OS X to obtain an *X11* build of TiLP. Failure to do so will terminally break the native OS X port. The above applies only to TiLP itself. The __MACOSX__ define in the libs is not tied to the native port. It might be good to go through the code and s/__MACOSX__/__COCOA__/ where appropriate. Don't do so without coordinating with me. I won't have time for that until early June, so please don't break anything until then. I intend to work again on the native port at some yet unspecified date; it depends on hardware availability on my side (if you want the port to resurrect, I accept donations to get a decent Mac Mini to work on -- decent means the highest clocked model with as much memory as possible, because that's how it works in the Apple world) JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Julien B. <jb...@jb...> - 2005-05-15 14:20:29
|
Christian Walther <cwa...@gm...> wrote: > The following code in libtifiles/src/misc.c, introduced by Julien in > revision 1055 (2005-05-13), doesn't work on Mac OS X (and possibly > other BSDs): > > #ifndef __WIN32__ > # include <endian.h> > # if __BYTE_ORDER == __BIG_ENDIAN > # define WORDS_BIGENDIAN 1 > # endif /* __BYTE_ORDER == __BIG_ENDIAN */ > #endif /* !__WIN32__ */ > > There is no <endian.h> on Mac OS X. There is a <machine/endian.h> that > defines BYTE_ORDER and BIG_ENDIAN, but as far as I see not > __BYTE_ORDER and __BIG_ENDIAN. This is a fucking mess nobody could ever agree on ... anyway. > We should decide whether setting WORDS_BIGENDIAN should be done by > configure or in the C code. At the moment, it is done in both places - > in configure, as added by Romain as part of one of my Mac OS X It isn't, as your patch never made it to the repository. At least configure.ac was not modified recently. > patches; in the C code as shown above. The problem is that the traditional configure check is broken, and will fail on some platforms. IIRC this check used to be in the configure script, and I was defining WORDS_BIGENDIAN on Mac OS X from the command line (because I didn't use the configure script in Project Builder). Re-adding the configure check is probably the easiest way to solve the problem. Then my change can be reverted. (the check is known to work on the platforms we care for) JB. -- Julien BLACHE <http://www.jblache.org> <jb...@jb...> GPG KeyID 0xF5D65169 |
|
From: Christian W. <cwa...@gm...> - 2005-05-15 14:05:49
|
The following code in libtifiles/src/misc.c, introduced by Julien in revision 1055 (2005-05-13), doesn't work on Mac OS X (and possibly other BSDs): #ifndef __WIN32__ # include <endian.h> # if __BYTE_ORDER == __BIG_ENDIAN # define WORDS_BIGENDIAN 1 # endif /* __BYTE_ORDER == __BIG_ENDIAN */ #endif /* !__WIN32__ */ There is no <endian.h> on Mac OS X. There is a <machine/endian.h> that defines BYTE_ORDER and BIG_ENDIAN, but as far as I see not __BYTE_ORDER and __BIG_ENDIAN. We should decide whether setting WORDS_BIGENDIAN should be done by configure or in the C code. At the moment, it is done in both places - in configure, as added by Romain as part of one of my Mac OS X patches; in the C code as shown above. -Christian |
|
From: Julien B. <jb...@jb...> - 2005-05-07 18:07:55
|
Hi folks,
You may have noticed the old SVN server has been down for a couple
hours now, due to a disk failure on its RAID arrays. It's backing up
right now, so all services have been disabled.
I've just completed the move to the new server, so please make the
switch on your end:
- go to the root of your working copy
- run svn info to get the URL
- run svn switch --relocate <old URL> <new URL>
To get the new URL, replace {http,https}://svn.technologeek.org by
http://svn.tilp.info. Remember that SSL isn't available right now; I'm
not yet sure it'll become available again, but there's a good chance
(not decided yet).
If you want your password to be changed, mail me with the new
password.
If you were using WebSVN to browse the repositories, the new URL
follows the same rule.
Christian, your account on the tiemu repository should be working.
If there's any problem, contact me ASAP.
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb...@jb...> GPG KeyID 0xF5D65169
|
|
From: Kevin K. <kev...@ch...> - 2005-05-05 19:57:34
|
> > By the way, the TiLP and TiEmu specfiles are not final. They currently don't > > install any menu icon. I want to fix this, of course, because I hate RPMs > > which install GUI programs without a menu entry. ;-) > > I believe there also is some mime magic stuff that needs to be done - or > at least should be done. That might require trigger scripts for KDE mime > stuff, gnome supposedly uses the freedesktop.org stuff but KDE does not > (yet) so it may need a trigger script to add the mime information to KDE > if KDE either is installed, or is installed at a later date. I'll look at some of the specfiles in Core and/or Extras CVS to see how they are doing things. Kevin Kofler |
|
From: Michael A. P. <mp...@ma...> - 2005-05-05 19:47:12
|
On Thu, 2005-05-05 at 00:37 +0200, Kevin Kofler wrote: > By the way, the TiLP and TiEmu specfiles are not final. They currently don't > install any menu icon. I want to fix this, of course, because I hate RPMs > which install GUI programs without a menu entry. ;-) I believe there also is some mime magic stuff that needs to be done - or at least should be done. That might require trigger scripts for KDE mime stuff, gnome supposedly uses the freedesktop.org stuff but KDE does not (yet) so it may need a trigger script to add the mime information to KDE if KDE either is installed, or is installed at a later date. |
|
From: Kevin K. <kev...@ch...> - 2005-05-04 22:41:28
|
By the way, the TiLP and TiEmu specfiles are not final. They currently don't
install any menu icon. I want to fix this, of course, because I hate RPMs
which install GUI programs without a menu entry. ;-)
Kevin Kofler
|
|
From: Julien B. <jb...@jb...> - 2005-05-04 21:16:29
|
Hi,
A quick update about the SVN move, hopefully the last one before the
move happens.
The new server will be racked on Friday, and is loaded with the TiLP,
TiEmu and tidrivers repositories as of Friday (April 29th) evening.
The tilp.info domain has been moved to a DNS server under my direct
control, and an svn.tilp.info host has been added.
IMPORTANT: the new server won't accept commits using HTTPS; actually
HTTPS won't be available *at all* for svn.tilp.info. This is because I
have only 1 IP address for this server, and SSL is needed for another
hosted domain. So, if you wish to change your SVN password for
whatever reason, contact me ASAP.
Once the new server will be here, you'll have 2 options:
- delete your working copies and grab a fresh checkout
-OR-
- use svn switch to relocate your working copy:
- go to the root of your working copy
- run svn switch --relocate OLDURL NEWURL
Note that the location of the various repositories have *NOT* changed,
only the hostname has.
The current SVN server will probably go down for a short period this
week-end, after what it will become read-only. The new server should
be usable right after that step, if only for the time to transfer the
incremental dumps for this week.
I'll post yet another message once the new server will be usable.
Romain: it'd be nice to update the website ASAP once the switch will
be done; the svn server is mentionned at least on the Mac OS X page.
JB.
--
Julien BLACHE <http://www.jblache.org>
<jb...@jb...> GPG KeyID 0xF5D65169
|
|
From: <kev...@ch...> - 2005-05-04 11:40:03
|
> The restriction was requested by Julien but some users wanted to browse
> outside their home.
Then what about making --enable-exit-homedir the default? (While you're on both anyway, I'm also CCing tilp-devel
because it doesn't really have anything to do with TiEmu. ;-) )
> You're right, GTK+ refuses suid and I feel that very
> annoying. Anyways, anyone who wants security don't install X server at all
> (and gcc compiler, believe me ;-).
I think it is pretty easy to get rid of that restriction with a binary patch (so you don't even need to recompile GTK to get rid
of it).
Kevin Kofler
|
|
From: Kevin K. <kev...@ch...> - 2005-05-03 21:27:51
|
> I would like to recommend that you join Fedora Extras and submit your > packages there. > > Fedora Extras provides a QA process to help ensure that what the user > installs is packaged professionally, actually works, and is made > available on as many platforms as possible. I'm very well aware of Fedora Extras, I'm using their packages since back when it was still at fedora.us (FC1 time - I upgraded directly from RHL 7.3 to FC1, so I haven't used the fedora.us packages for RHL 8 and 9 prior to the merger with Red Hat), and I even follow what's happening on their lists. One annoyance with the new Extras at Red Hat is bureaucracy: I don't like copyright assignment forms at all (the FSF one annoys me as well) and they are of dubious legality here in Austria (you can't assign your copyrights here, that's a US law concept). Another is that, well, I think they'll prefer release RPMs to the SVN snapshots I'm currently building (especially the TiEmu ones which are from a development branch). The legal issues with TiEmu you're mentioning are also a good point, though you can now run TiEmu without any non-GPL stuff thanks to PedroM (you can even run a few games under that ROM, it's not just a toy ROM). > I actually would appreciate that very much - I sat down today to rebuild > my rpm's for TiLP in rawhide (using the stable release versions). > > I do not like to add lots of little repos, that's how problems happen. It's true that repository mixing is a big source of problems, but rest assured that my packages are compatible with the current Fedora Extras (I'm running many packages from there myself). And if TiLP etc. packages really do get into Extras, then I think I won't bother building them anymore. > The three libraries build just fine, but TiLP does not (with gcc4 or > gcc32) - hence my reading of the list looking to see if a patch has been > submitted yet. Does build fine in fc3 though. Well, actually the tarball currently on ticalc.org doesn't seem to build at all. One guy I talked to on IRC yesterday (FpgForce) didn't manage to build it on Debian either (some make target missing in the plugins folder). I sent him the latest SVN HEAD snapshot I've used for my RPM, and it did build. > Please do not use --disable-nls when building rpm's for public use. They > are important to some people. Use the %find_lang macro to specify the > locale files - those who don't want them can specify to rpm to only > install the locale files they need. Well, have you ever looked at how the NLS for development tools like GCC actually looks like? It's horribly badly translated, many times someone translated something literally without understanding anything about GCC or compilers in general. I don't think it is any better for GDB. As for Romain's own code, I don't think the translations are anywhere near up to date. My main project, TIGCC, actually doesn't support NLS at all: our tools have no translation facility, and we remove the translation files from GCC and Binutils because as I said the translations are of horrible quality, they only waste space and make bug reports harder for us to understand (and errors harder to understand for our users, too, because of the bad translations). But thanks for the example NLS-enabled specfile. Kevin Kofler |
|
From: Romain <ro...@li...> - 2005-05-03 12:21:59
|
Hi, > They probably will not want the TiEmu since they are very gunshy of anything that requires a ROM to operate, but the libraries and tilp would likely be very welcome there. Well, a GPL'ed ROM is provided with TiEmu now. Thus, this issue does not matter any longer. > Please do not use --disable-nls when building rpm's for public use. The= y are important to some people. Use the %find_lang macro to specify the locale files - those who don't want them can specify to rpm to only install the locale files they need. Language files are somewhat broken/incomplete. It may be better like this= . Thanks, Michael ;-) --=20 Romain Li=E9vin : <ro...@li...> Web site : http://www.lievin.net "Linux, y'a moins bien mais c'est plus cher !" |
|
From: Michael A. P. <mp...@ma...> - 2005-05-03 08:09:49
|
On Mon, 2005-05-02 at 15:53 +0200, Kevin Kofler wrote: > Hi, > > Sorry for the cross-post, but as this is a one-time announcement which > really concerns all four lists, I hope I'll get away with it. ;-) (I'm > subscribed only to gtktiemu-devel, so please either leave that in the > recipients lists on your replies or CC me. It's not a good idea to do both > though, because that leaves me with duplicate mails.) > > I want to announce that RPMs of libticables, libtifiles, libticalcs, tilp > and tiemu-tigcc-debugging built on and for Fedora Core 3 (with all updates > applied) are now available at: > http://sourceforge.net/project/showfiles.php?group_id=23169 I would like to recommend that you join Fedora Extras and submit your packages there. Fedora Extras provides a QA process to help ensure that what the user installs is packaged professionally, actually works, and is made available on as many platforms as possible. I actually would appreciate that very much - I sat down today to rebuild my rpm's for TiLP in rawhide (using the stable release versions). I do not like to add lots of little repos, that's how problems happen. The three libraries build just fine, but TiLP does not (with gcc4 or gcc32) - hence my reading of the list looking to see if a patch has been submitted yet. Does build fine in fc3 though. I'm just a casual TiLP user - about once a month or so I backup my Ti86 just so I don't have to reload Tetris and a few other things should it go south on me. So if a dedicated user was to submit and maintain packages, it would be better. http://www.fedoraproject.org/wiki/Extras They probably will not want the TiEmu since they are very gunshy of anything that requires a ROM to operate, but the libraries and tilp would likely be very welcome there. Please do not use --disable-nls when building rpm's for public use. They are important to some people. Use the %find_lang macro to specify the locale files - those who don't want them can specify to rpm to only install the locale files they need. Here is an example: Name: libtifiles Version: 0.6.3 Release: 0.1 Summary: TI Calculator support files *snip* %build %configure make %{?_smp_mflags} %install rm -rf %buildroot make install DESTDIR=%buildroot find %buildroot%_libdir -type f -name "*.la" -exec rm -f {} ';' %find_lang %{name} %clean rm -rf %buildroot %post /sbin/ldconfig %postun /sbin/ldconfig %files -f %{name}.lang %defattr(-,root,root,-) %doc ABOUT-NLS AUTHORS ChangeLog COPYING LOGO NEWS README %_libdir/libtifiles.so.* %files devel %defattr(-,root,root,-) %_includedir/tilp/*.h %_libdir/libtifiles.so %_libdir/pkgconfig/tifiles.pc *snip* |
|
From: Kevin K. <kev...@ch...> - 2005-05-02 14:02:14
|
Hi, Sorry for the cross-post, but as this is a one-time announcement which really concerns all four lists, I hope I'll get away with it. ;-) (I'm subscribed only to gtktiemu-devel, so please either leave that in the recipients lists on your replies or CC me. It's not a good idea to do both though, because that leaves me with duplicate mails.) I want to announce that RPMs of libticables, libtifiles, libticalcs, tilp and tiemu-tigcc-debugging built on and for Fedora Core 3 (with all updates applied) are now available at: http://sourceforge.net/project/showfiles.php?group_id=23169 These RPMs are built from SVN repository snapshots. TiEmu comes from the tigcc-debugging-branch, which has support for C debugging thanks to a built-in GDB. The packages are built with the following options: * libticables: --disable-nls * libtifiles: --disable-nls * libticalcs: --disable-nls * tilp: --disable-nls --enable-exit-homedir * tiemu-tigcc-debugging: --disable-nls --with-kde The prefix is /usr, and the CFLAGS are "-Os -s -fno-exceptions -fomit-frame-pointer". I plan on regularly updating these RPMs, especially if something interesting gets committed to the SVN repository. I recommend installing all RPMs at once, but if you feel you have to install them one by one, make sure you install libticables, libtifiles and libticalcs first, in that order. Otherwise, you'll get dependency errors. An easy way to install the packages is to use apt-rpm. Enter the following (all in one line): apt-get -o RPM::GPG-Check=false install http://belnet.dl.sourceforge.net/sourceforge/gtktiemu/libticables-20050502-1 .i386.rpm http://belnet.dl.sourceforge.net/sourceforge/gtktiemu/libtifiles-20050502-1. i386.rpm http://belnet.dl.sourceforge.net/sourceforge/gtktiemu/libticalcs-20050502-1. i386.rpm http://belnet.dl.sourceforge.net/sourceforge/gtktiemu/tilp-20050502-1.i386.r pm http://belnet.dl.sourceforge.net/sourceforge/gtktiemu/tiemu-tigcc-debugging- 20050502-1.i386.rpm (You can of course substitute any mirror from the download list for "belnet".) Apt-get will take care of fetching and installing the packages for you, and also install any dependencies you might not have installed yet. Kevin Kofler |
379 messages has been excluded from this view by a project administrator.
