GTK+2.2 packages are in experimental/msek/gnome2 already. But I cannot
move
them into unstable tree because fink will upgrade GTK+2.0 to GTK+2.2 and
fails if user have xfree86-4.2.
I'm wondering how to handle following situation:
build run
xfree864.2 4.3 4.2
Apple has announced their intention to sync with xfree86 4.3, but I don't
know when they'll do that.
-- Dave
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_
On Friday, February 28, 2003, at 04:36 pm, Hisashi T Fujinaka wrote:
On Fri, 28 Feb 2003, Jeff Whitaker wrote:
Folks: Unless I hear objections, I'd like to commit these two
packages to unstable
xfree86-4.3.0-1.info (which builds the new "unified" xfree86 4.3
package)
I've been using your 4.2.
On Fri, 28 Feb 2003, Jeff Whitaker wrote:
>
> Folks: Unless I hear objections, I'd like to commit these two
> packages to unstable
>
> xfree86-4.3.0-1.info (which builds the new "unified" xfree86 4.3 package)
>
> and
>
> xfree86-upgrade-20030228-1.info,patch (which is a shell script that
> perfor
How about a message on fink-announce, too?
> The only way users will know to use xfree86-upgrade is if they run "fink
> info xfree86". Perhaps a message on the fink homepage is also warranted?
>
> I've put these files in experimental/jswhit/x11-system if you want to have
> a look.
>
> -Jeff
-
Folks: Unless I hear objections, I'd like to commit these two
packages to unstable
xfree86-4.3.0-1.info (which builds the new "unified" xfree86 4.3 package)
and
xfree86-upgrade-20030228-1.info,patch (which is a shell script that
performs the necessary dpkg -r --force-depends to install xfree86
On Wed, 26 Feb 2003, Benjamin Reed wrote:
> Well, according to the X website, XFree86 4.3 is due to get tagged
> tomorrow. Has anything been decided yet on how we are going to handle
> the 4.3 upgrade?
>
Ben:
I propose the following:
1) add an xfree86-4.3 package which will requires dpkg -r
Well, according to the X website, XFree86 4.3 is due to get tagged
tomorrow. Has anything been decided yet on how we are going to handle
the 4.3 upgrade?
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT traini
At 6:03 Uhr -0700 08.02.2003, jeff whitaker wrote:
Max et al: I've pulled the xfree86 package (and the xfree86-base,
xfree86-base-threaded upgrades it depends on) from unstable and put them
in expermental/jswhit/x11-system. Probably should have put them there in
the first place - I apologize for
Max et al: I've pulled the xfree86 package (and the xfree86-base,
xfree86-base-threaded upgrades it depends on) from unstable and put them
in expermental/jswhit/x11-system. Probably should have put them there in
the first place - I apologize for that.
Ben H - I would appreciate it if you could k
On Friday, February 7, 2003, at 08:13 PM, jeff whitaker wrote:
Especially if there are binary packages available. The
--force-depends is
necessary - we've had that discussion in the past when the -threaded
package was introduced. Ben Reed has reported a problem with apt -
that
can be fixed
[...]
Ben: I figured that the versioned dependency on xfree86-base |
xfree86-base-threaded would be temporary, perhaps just for the first
revision, in order to allow people to upgrade.
I see the logic behind it, but IMHO the costs do not warrant it, so i
agree with Ben, this should be removed
On Fri, 7 Feb 2003, Ben Hines wrote:
>
> On Friday, February 7, 2003, at 04:02 PM, Jeff Whitaker wrote:
>
> > On Fri, 7 Feb 2003, Benjamin Reed wrote:
> >>
> >> Why exactly does it depend on xfree86 4.2.1.1? Is it only for the
> >> purposes of upgrading?
> >>
> >
> > Yes - to avoid having to tel
I'll give it a shot, see if I can construct a strategy which will work for
upgrades, using apt, and installing from source.
-- Dave
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
ht
On Friday, February 7, 2003, at 04:02 PM, Jeff Whitaker wrote:
On Fri, 7 Feb 2003, Benjamin Reed wrote:
Why exactly does it depend on xfree86 4.2.1.1? Is it only for the
purposes of upgrading?
Yes - to avoid having to tell people to dpkg -r --force-depends.
Also, what about installing
On Friday, February 7, 2003, at 06:56 PM, jeff whitaker wrote:
On Fri, 7 Feb 2003, Ben Hines wrote:
Provides/Conflicts/Replaces should work fine.. the only thing that
needs to be done is to change ALL versioned dependencies in other
packages on xfree* to add "| xfree86". Then
Provides/Conf
On Fri, 7 Feb 2003, Ben Hines wrote:
>
>
> Provides/Conflicts/Replaces should work fine.. the only thing that
> needs to be done is to change ALL versioned dependencies in other
> packages on xfree* to add "| xfree86". Then Provides/Conflicts/Replaces
> should work fine and this abuse of the fink
On Friday, February 7, 2003, at 10:06 AM, Jeff Whitaker wrote:
versions of the xfree86 4.2.1.1 packages which have no "Conflicts".
So,
you'll have to compile xfree86 twice to get the upgrade. Sorry, but
there
was no other way. Hopefully we can move these to stable quickly and
provide binar
On Fri, 7 Feb 2003, Benjamin Reed wrote:
>
> Hrm.
>
> This worked OK for me when I was building it, but it broke when I tried
> getting it through apt to my other machine. Apt ended up
> half-installing things and then xfree86-base's checks for an existing
> X11 kicked it out. My other machine h
On Friday, February 7, 2003, at 01:06 PM, Jeff Whitaker wrote:
I've just committed a package for xfree86 4.2.99.901 - the last
pre-release before 4.3. This package supersedes all the previous
xfree86
variants (-base, -rootless and -threaded). However, in order to avoid
requiring a "sudo dpkg -
Folks:
I've just committed a package for xfree86 4.2.99.901 - the last
pre-release before 4.3. This package supersedes all the previous xfree86
variants (-base, -rootless and -threaded). However, in order to avoid
requiring a "sudo dpkg -r --force-depends" I've made it depend on new
versions of
On Friday, February 7, 2003, at 08:59 AM, Jeff Whitaker wrote:
Folks: I have come across a potential problem while putting together
the
xfree86-4.2.99.901 package. Xfree86 4.3 installs a font database for
fontconfig in /etc/fonts. When you use fink to remove the xfree86
package
containing /e
On Friday, Feb 7, 2003, at 09:10 US/Eastern, Peter O'Gorman wrote:
I'd suggest a PostRmScript with an ln -sf to restore the symlink.
Peter
Or even better, in the postinst script, add a symlink from /etc/fonts to
/sw/etc/fonts, then remove THAT in the postrm script. That way there
is no race co
Another thing which might work is to install directly to /private/etc/fonts
(by moving stuff around at the end of the InstallScript).
That way, dpkg is installing to the actual location and when it removes
the file, won't try to remove the parent. (I think!! Haven't actually
tried this myself.)
I'd suggest a PostRmScript with an ln -sf to restore the symlink.
Peter
On Friday, February 7, 2003, at 10:59 PM, Jeff Whitaker wrote:
Folks: I have come across a potential problem while putting together
the
xfree86-4.2.99.901 package. Xfree86 4.3 installs a font database for
fontconfig i
Folks: I have come across a potential problem while putting together the
xfree86-4.2.99.901 package. Xfree86 4.3 installs a font database for
fontconfig in /etc/fonts. When you use fink to remove the xfree86 package
containing /etc/fonts, dpkg blithely blows away the symlink /private/etc
--> /
26 matches
Mail list logo